RE: please use ?\u2014 instead of the unicode character in buff-menu.el

[Drew Adams]

> > 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.