> > Downloading buff-menu.el from > > http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/, at least in > > some common Web browsers, leads to incorrect characters in the > > code. This > > problem goes away if you use the escape sequence ?\u2014 instead of > > embedding the equivalent unicode character in the source file. > > Complete disagreement. The coding system is clearly written in the -*- > coding -*- tag, so there's no ambiguity, and seeing the actual char rather > than some arcane escape sequence for it makes the code more readable. > > > IMO, this should be the standard practice for such characters in the > > source code: use escape sequences. > > 100% disagreement.
The coding system is written in the -*- coding tag. Fine. But if the character in the file, as pulled from the Web, is wrong, then the -*- coding tag doesn't help. The coding tag is for use inside Emacs; it doesn't help outside Emacs. What I'm referring to is the ability to pass the file around the Web and via email easily, as will be done - as is already being done. The escape sequence is perfect for that; it allows for plain ASCII communication. Tools such as scripts and wikis that might, today at least, choke on some characters, are perfectly happy to handle the string of ASCII characters "?\u2014". I first noticed this problem with a minor enhancement that I use for this same file. On Emacs Wiki, the Unicode em dash is not transferred correctly, so my enhancement code was broken, simply by uploading or downloading. Sure, it's the fault of the wiki scripts or the browser or my local system's language support, but so what? I didn't report the problem at that time (a year or so ago), figuring that you folks might not care much about code exchange via Emacs Wiki. I reported the problem only when I ran into it again, but this time at http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/. I expected you might care about that. It's a general problem, and I see no reason why GNU wouldn't want to maximize the ease of communication and exchange of its code by using ASCII - when possible and other things being equal. In this case, in particular, nothing special is gained by resisting using the escape sequence, and something is lost by not using it - lots of people will be unable to use the code, and many will not figure out why or how to correct the problem. For a library that deals heavily in Unicode characters, and for which the legibility of the code itself would be hampered by using escape sequences, I would agree with you - no reason to deprive the code of legibility, when it really matters. But for a library like buff-menu.el, for which the use of Unicode is completely incidental (only to simulate underlining when the header line is not used - not even the default case), I think the library is shooting itself in the foot. It could even be argued that it was silly to use em-dash characters for this in the first place. It is all the more silly to reduce the transfer and exchange of the code, just for the sake of showing two em dash characters in the code. We're not even talking about a string of em-dash characters, to show a visible line in the code; we're talking about an isolated character: ?- (but with an em dash, not a hyphen). Here's how it appears in the code on http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/lisp/, as shown by my browser: (if (char-displayable-p ?a?") ?a?" ?-))). So much for legibility and WYSIWYG, but more importantly, that code is broken: the em-dash character has been replaced in the code by stuff that makes it impossible to even load the library. This is the fault of the Web site or the browser (in my case, IE6) or the language support on the user's machine, perhaps, but it is Emacs and Emacs users that suffer, IMO. Why make users jump through hoops, just so we can show off that we can now put a Unicode character in an Emacs library? We go to incredible lengths in Emacs to make sure that Emacs still works without a window manager, on slow machines, over slow connections, without colors, and so on. There are many, many more people and tools that will not be able to digest this single Unicode character than there are users with such limited hardware, to whom we (rightfully) still cater. Please humor those of us who aren't yet 100% Unicode-able, at least when the cost is trivial, as it is in buff-menu.el. Anyway, you will do as you like. I'm just letting you know that fewer people and fewer Web sites will digest this file easily, because of those two em-dash characters and your refusal to use Emacs's fine escape sequence mechanism. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
