<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "> <div><div>> On 4. Jul 2007, at 23:12, Max Lein wrote:</div><div>></div><div>> > The problem with TextMate is that it essentially forces people to</div><div>> > use UTF8.</div><div>></div><div>> Yes, and as I tried to explain, there is good reason it does that.</div><div><br class="webkit-block-placeholder"></div><div>There are usually `good' reasons not to as well. For all I love about</div><div>TextMate, it's a bit pushy here ;-)</div><div><br class="webkit-block-placeholder"></div><div>> > I have yet to find a way how to teach TextMate that my default</div><div>> > encoding is Latin1 (even though this is the default encoding which</div><div>> > I have set in the prefs): as long as a TeX file doesn't contain any</div><div>> > special characters, it will automatically assume they are UTF8 files</div><div>> > (ignoring my preference and -- if existant -- the metadata connected</div><div>> > to that file).</div><div>></div><div>> When checking “use for existing files” it will respect your</div><div>> preference. However, I fixed the problem for next build, so when files</div><div>> with ASCII encoding can’t remain as ASCII, it will first try your</div><div>> preferred encoding (even when the “use for existing files” is not</div><div>> checked).</div><div><br class="webkit-block-placeholder"></div><div>Well, my web pages use UTF8 ... so this option doesn't really solve the</div><div>problem. (I am aware of said option, but it just shifts my problem.) As</div><div>I said, an encoding per project option would be greatly appreciated (I'm</div><div>not sure I understand the last part of your reply correctly and whether</div><div>TextMate 2.0 would effectively resolve this issue).</div><div><br class="webkit-block-placeholder"></div><div>> >> [...]</div><div>> ></div><div>> > However, going UTF8 is sometimes just not an option [...]</div><div>></div><div>> Maybe not, but the bundle commands (which was the topic of this</div><div>> thread) can’t be expected to work with your files, when those</div><div>> are not UTF-8. I.e. go with Latin-1 and use special characters,</div><div>> and you should be prepared to see no or garbled output from script</div><div>> runners (which show script output), diff commands (showing changes in</div><div>> your files), build commands (which quote parts of your source), log</div><div>> commands (showing SCM log entries), various validation/completion/</div><div>> pretty-printing commands, a.s.o.</div><div><br class="webkit-block-placeholder"></div><div>You clearly have the perspective of someone who codes (which is fine by</div><div>me, just an observation), but I haven't noticed any garbled output while</div><div>working with Latin1. That's probably due to the simple fact that I just</div><div>use a very specific subset of TextMate's commands. For me, a one-time</div><div>warning would be acceptable.</div><div><br class="webkit-block-placeholder"></div><div>> > I frequently exchange files with people who work on Windows,</div><div>> > Linux or Solaris and the standard encoding they use is usually</div><div>> > Latin1. Yes, there are ways how to use UTF8 on other OS, but have</div><div>> > you ever tried to convince someone to switch to UTF8 who still</div><div>> > writes his papers in Plain TeX?</div><div>></div><div>> Would plain TeX not be ASCII? :)</div><div><br class="webkit-block-placeholder"></div><div>... but my contribution isn't. The encoding is `hardcoded' into</div><div>LaTeX (it's a simple command), so when the chapters are merged, we'd</div><div>get into trouble (not necessarily with Plain TeX people of which</div><div>there are admittedly very, very few left, but with all of my active</div><div>co-workers). (We usually split our work into sections which are then</div><div>compiled. Obviously any other wants to be able to compile the TeX code</div><div>on his system without fiddling for half an hour. I've seen it happen</div><div>often enough.)</div><div><br class="webkit-block-placeholder"></div><div>> > Instead of blindly arguing for people to convert to UTF8 (which</div><div>> > is what I would use if I got to choose), you should accept that</div><div>> > people (= customers) want to and sometimes need to work with other</div><div>> > encodings as well.</div><div>></div><div>> In what you replied to I gave a technical explanation of why it</div><div>> is highly infeasible to support other than UTF-8 for the various</div><div>> commands, which was the topic raised. Me accepting that some can’t</div><div>> use UTF-8 doesn’t really change that.</div><div><br class="webkit-block-placeholder"></div><div>Well, I understand the reasons you gave, but people who use LaTeX need</div><div>just functionality, most of which is provided by the LaTeX (or Beamer)</div><div>bundle. I think if people consciously change the encoding to something</div><div>other than UTF8, they have a good reason for doing so. Give them a</div><div>warning (once) that some commands may not work would be acceptable to</div><div>me. I haven't heard of people in my field using diff on their TeX source</div><div>files, for instance. I've also never had any problems with TextMate's</div><div>built-in commands that produced no or garbled output.</div><div><br class="webkit-block-placeholder"></div><div>I can certainly understand if you'd rather fix other problems than</div><div>these. But I think there are certain fields when this is just an</div><div>essential feature and the people would even be willing to live with a</div><div>smaller feature set.</div><div><br class="webkit-block-placeholder"></div><div>> > I'm still longing for an `encoding per project' option which</div><div>> > TextMate would stick to no matter what. And also an error message</div><div>> > that tells me that I cannot save my .tex file in Latin1 because</div><div>> > there are some (invisible) characters that prevent it from doing so</div><div>> > (right now, it'll just revert to UTF8 without telling me).</div><div>></div><div>> I have commented on this a few times in the past; the lack of a</div><div>> warning is indeed very unfortunate, and it comes from the code that</div><div>> does this “bumping” of encoding not having access to the UI. A</div><div>> mistake 2.0 will be without -- and as for encoding per project, I</div><div>> can’t recall exactly how much I have said here, but 2.0 does move</div><div>> a lot of things to be more folder-oriented and has another approach</div><div>> to dealing with encodings, basically offloading this to customizable</div><div>> import/export hooks, so non-UTF-8 users should be able to get whatever</div><div>> they want.</div><div><br class="webkit-block-placeholder"></div><div>That's very good news (although the first time I hear of those new </div><div>features). I hope that you don't have to set these encoding hooks </div><div>globally (not 100 % sure what you mean by that), as I mentioned, I use </div><div>UTF8 whenever I can (e. g. for the websites I maintain) and Latin1 </div><div>*when I have to*. Hence different projects, different encodings and </div><div>a per project encoding seems like the best option to me. (I usually </div><div>create a project for my papers (LaTeX) since LaTeX is very noisy and </div><div>creates a phletora of files I almost surely don't need.) :-) </div><br></div><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><br class="Apple-interchange-newline"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div>Max</div><div><br class="khtml-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>UC Berkeley</div>Department of Physics<br class="Apple-interchange-newline"></span></span></span></span> <br></body></html>