> 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. _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug