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

[Drew Adams]

> Yes, I know you're arguing that buff-menu.el contains just one
> non-ASCII char and it would be friendlier to use an escape (It's me
> who added the comment line just above the one which is causing you so
> much grief.) Perhaps you're right. But you said yourself your fix
> wouldn't work for packages with lots of Unicode chars. Where do you
> intend to put the line? At ten chars? A thousand? 

I don't intend to establish a line. Judgement is needed, perhaps case by case. 
What I said, in an earlier mail, was this:

 "When Unicode is important for the library in question,
  it makes sense to use it in the code."

That is clearly _not_ the case here. Make that judgement of relative importance 
as you see fit, for any given library. I'll entertain arguments that 
buff-menu.el needs Unicode encoding, but I don't yet have an opinion about the 
use of Unicode in any other particular libraries.

> And how do you
> propose to inform the user, used to "code which displays as plain
> text", that suddenly this other code isn't downloadable with broken
> tools anymore?

Good question, and one that I raised in response to Eli's mail. I suggested 
perhaps providing instructions on the Web site, perhaps drawing attention to 
the -*- coding declaration. But I don't have a good answer. Because many people 
will not be aware of this potential gotcha, it behooves us to somehow draw 
their attention to it. Maybe we should say explicitly that all code should be 
downloaded using a Unicode encoding - I don't know.

As you point out, and I pointed out previously, this is a problem more and 
more, as Unicode is adopted progressively but there are still plenty of tools 
that are not yet there 100%. We will have to live with it, until the world 
(including Emacs ;-)) is Unicode through and through. And even then, things 
might not be so simple.

Our best recourse, at least in this transitional period, is to be aware of the 
potential gotchas and use our best judgement to help users avoid problems. 
That's all; I don't have a better suggestion than that. Maybe someone else does.

My bug report was not aimed at fixing this problem, in any case - this is off 
topic. My report was aimed at preventing this problem from arising for file 
buff-menu.el, and, secondarily, improving the legibility of that library. 
Nothing more.

> I don't care about buff-menu.el, and won't argue for or against
> changing one character; but the fix for the problem you're struggling
> with is educating the users, and pointing them to non-broken tools.

No, the fix for the problem that I reported is to use an escape sequence in 
buff-menu.el. The fix for general Web site, browser, and user error problems, 
is education and fixing and updating tools, but that is not the problem I asked 
that we fix now.

This sideline discussion (this problem that you are apparently struggling with, 
and that you think I am struggling with) arose because someone asked how the 
buff-menu broken character problem could have arisen in the first place. I 
tried to explain that it doesn't matter how it arose, that the bug report is 
about unnecessary em-dash characters - for which explanation I was accused of 
being ungrateful for help offered to solve the ancillary problem of downloading 
etc. So here we are, off track. 

I explained that these characters should be replaced by escape sequences, not 
just because they might cause encoding problems for some users, Web sites, or 
tools, but also because they reduce legibility. And because of Occam's razor: 
there is no need to introduce Unicode characters here, with their potential 
problems for users, because _nothing is gained_ here by doing so. That's three 
reasons: 1) possible encoding gotchas, 2) reduced legibility, 3) unnecessary 
complication for no gain.

We will all be struggling with the problem of not recognizing Unicode and 
properly adjusting to it for quite some time, I'm afraid. I didn't report that 
general problem, and I don't have a general solution for it. We can at least do 
what we can to prevent that problem from arising in no-brainer cases such as 
buff-menu.el. There is no good reason to invite that problem to rear its ugly 
head _in this case_.

> Obviously, we can't (nor should) force anyone to change their ways;
> but I don't see why should we make extraordinary efforts to suit them,
> either.

Preventing a stupid problem, with no loss, and with some gain (legibility) is 
not catering to anyone's underdeveloped ways. It's just common sense. And 
replacing two em-dash characters with \u2014 is hardly making "extraordinary 
efforts".

It does, however, sometimes seem to take extraordinary efforts to get the 
slightest suggestion across to change something, even something trivial, in the 
Emacs code. I don't know why. I don't care so much, for myself, but I'm sad to 
think of others who might have given up helping long ago, when their efforts 
met with stubborn resistance and sidetrack arguments. It really doesn't have to 
be that way, you know.

As with all bug reports, it's up to you whether you want to consider this a bug 
and, if so, whether you want to fix it, and how.