Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. Nor was I implying that. If you were not implying that, then I don't see how your argument is relevant to the question at hand. But there is no need to argue. The change has been installed. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Drew Adams [EMAIL PROTECTED] writes: And replacing two em-dash characters with \u2014 is hardly making extraordinary efforts. I think if you're going to fix two of them you may as well go the extra mile and replace all three of them to prevent us having to have this argument at a later point about the remaining em-dash character. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
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? Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Richard Stallman [EMAIL PROTECTED] wrote: Who cares? This sort of argument is no reason not to install a simple change that will avoid problems. Nor was I implying that. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:48:29 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. For the same reason Emacs doesn't do that with non-ASCII text: it doesn't treat it as a byte stream, it treats it as an encoded text. Yes, and I guess they do that for a reason, see below. If I understand things correctly here this thread was mostly about downloading an elisp file. It looks to me like if you are trying to save what the web browser shows then it will save something it can show again, not the original downloaded file. When the web browser downloads the file it usually has some extra information from the mime headers. That information helps it display the file. My guess is that when the web browser saves the file that is displayed it tries to merge that information with the downloaded file. Therefore the file changed in this way is different from the downloaded file. So instead of saving what is viewed in the browser the user need to download the file directly to his disk. There use to be something like right click and choose Save Link As or something similar in the web browsers for this. Would it suffice to tell the users how to download the files? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Web servers don't change anything (at least, no web server I've ever seen does, and I've worked with most of them). I don't know what happened in Drew's case, but I don't think this a real life problem that is worth making the code less readable over. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Jason Rumney wrote: I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Web servers don't change anything (at least, no web server I've ever seen does, and I've worked with most of them). Thanks, that makes things more clear to me. Then the things that differ is the mime headers sent and the interpretation of those. I think that is where the problem arise as I said in a later message. I don't know what happened in Drew's case, but I don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
I don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) In 1), the code is straightforward (a fact obscured in the e-mail because em dash got changed to hyphen-minus), and the comment clearly says what's happening, and even identifies *both* characters involved. In 2), \u2014 does not mean anything per se, so the user hasn't the foggiest idea why some random unicode char would be used instead of -. You'll need the same comment as before to clarify that (and, in fact, Stefan didn't remove the comment when changing the code). You can convince me that 2) will get less trouble than 1) for people with broken tools; but not that 2) is more legible. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
I don't think this a real life problem that is worth making the code less readable over. I agree. There are more simple solutions. Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) Check the current code. It's a mix of the two. I changed it not because of any web server/client issue, but simply because the resulting code is more readable. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please explain why 1) is more readable than 2): 1) ;; Use U+2014 (EM DASH) to underline if possible, else U+002D (HYPHEN-MINUS) (if (char-displayable-p ?-) ?- ?-))) 2) (if (char-displayable-p ?\u2014) ?\u2014 ?-))) Check the current code. It's a mix of the two. I changed it not because of any web server/client issue, but simply because the resulting code is more readable. Yes, thank you. That's in fact what I meant. It helps that the two characters appear different, and the comment makes it clear what the intention is. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. However it is that the characters got messed up (Web site, browser, user error, cosmic rays, CIA, Al Qaeda), there is no reason not to use the escape sequence, for portability and better code legibility. I did it twice with two different methods: . Clicked the download link and saved the file to disk. . Clicked the view link; then, after seeing that the Unicode characters are displayed incorrectly, clicked View-Encoding from the menu bar, selected Unicode UTF-8, which fixed the display; then File-Save As, selected Text files and made sure the encoding is set to UTF-8; clicked OK. Both methods gave me a valid UTF-8 encoded file that displayed correctly in Emacs 22. I used the view link, clicking mouse-1 on it, because I wanted to look at the code before saving it. I did not scan the entire file to notice that two of the characters were displayed incorrectly, so I did not change my browser encoding - after all, this is code, which displays as plain text. And how would one know that those two characters were in fact displayed incorrectly? How would you know what they were supposed to be? Did you read all of the code comments, and analyze the code, to come to the conclusion that the browser encoding for those two characters was incorrect? Or did you in fact know just what to look for, because you had read my bug report? That's cheating ;-). Or did you notice the -*- coding: utf-8 -*- in the header, and realize that your current browser encoding didn't correspond to that? You said, however, that you noticed that the (two) Unicode characters were displayed incorrectly - a much harder thing to spot. Some other methods a user might use to try to retrieve the code: - Right-click the download link, and use Save As (as I assume you meant by clicked the 'download' link). Here, you can Save as type All Files. This works. - Right-click the view link, use Save Target As, and Save as type All Files, changing the suffix to el. For some reason, this does nothing, for me - no file is saved. - Click mouse-1 on the download link, and use Save As. This does default to the Unicode encoding, but, at least in my IE6 browser, there is no filter option for All Files at that point, and you must choose Save as type Text File (*.txt) (the other options involving saving as HTML pages). When I open the resulting file in Emacs 22, C-h C shows raw-text-unix, not Unicode, and the buffer is filled with null bytes (^@) - every other byte. C-x RET r utf-8 does not change what I see. The -*- coding never takes effect because each of its characters is preceded by a null character. There are multiple ways a user might try to retrieve this code from that site, and there will be other sites that also offer the code, perhaps in other ways. As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. You might not care about the Emacs Wiki, but you might care that such a problem exists there, because other sites might present similar problems. The real point is that there is no good reason *not* to use the escape sequence in this case, and there are good reasons to use it: easier file exchange using email and Internet, and better code legibility. The only reason given so far not to use the escape sequence was code legibility, and I pointed out that the code is in fact less legible without the escape sequence, because the em-dash and hyphen characters are indistinguishable in a fixed font. They both appear as ?-, making it impossible to tell which is which (without a comment). This seems a no-brainer, to me. Further resistance to using the escape sequence in this case seems to me to reflect only unwillingness to see the obvious. If, on the other hand, your concern was the Web site and how to ensure that users download Unicode code correctly, then I share that concern. You might want to include explicit instructions for how to download, and explicit mention that view of code that includes Unicode characters might require that you change your browser encoding to Unicode. Or something like that. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Drew Adams wrote: As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. You might not care about the Emacs Wiki, but you might care that such a problem exists there, because other sites might present similar problems. I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
From: Drew Adams [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Sun, 18 Feb 2007 14:15:14 -0800 Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. [] Well, you did say I don't know whether this represents a browser problem or a Web site problem, however. All I did was try to help you find out what went wrong. No good deed goes unpunished, sigh... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
As I mentioned, I first ran into this problem on the Emacs Wiki (with the same em-dash character, in a library that is derived from buff-menu.el). Simply uploading or downloading the code on the Wiki changes the characters (in the same way, BTW). Here, the downloading user has no choice. If the normal page-edit means of uploading is used, then the characters are messed up in the file on the wiki, so regardless of how you download it, you get garbage. AFAIK, this has nothing to do with the browser. I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? Dunno. Perhaps it has to do with the scripts used on the Wiki. The problem here is more general than Unicode, in fact. For example, it also strips out control characters (e.g. ^L) inserted in the code. In one library, for instance, I use escape sequences instead of embedded ^G and ^J characters. However, the loss of ^L page separators is regrettable. You can upload a file to the wiki using the alternative method, instead of editing a wiki page, and in that case there is no problem. But in that case there is also no syntactic highlighting of the code on the page. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. Or is that not possible here for some reason? Could it be that IE6 cashes the page and then misread the cache? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Drew Adams wrote: You can upload a file to the wiki using the alternative method, instead of editing a wiki page, and in that case there is no problem. But in that case there is also no syntactic highlighting of the code on the page. It seems to me you have to know a lot here to be able to understand what is going on. For example the EmacsWiki pages for elisp modules does not tell anything about encoding. What does that mean in this case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
Please tell the details about how you downloaded and saved the file to disk. It is impossible to know what went wrong without these details. What went wrong is not the point. [] Well, you did say I don't know whether this represents a browser problem or a Web site problem, however. All I did was try to help you find out what went wrong. No good deed goes unpunished, sigh... It was not clear to me that that was all you were doing. It seemed to me that you were also arguing that the real problem was browser, Web site, or user error, not the file contents, and that therefore the file need not be fixed. This was the main point of my last message: What went wrong in downloading the file is not the real point of my bug report. I would like the file itself to be fixed, so that no such problem can possibly arise, regardless of how the file might be downloaded. Yes, a possible problem with the Web site is a secondary concern. It was not obvious to me that you were not also arguing for not fixing the file. So, I argued again for fixing it, and I argued that Web site or user error is not a good reason not to fix the bug. It did occur to me that you might *only* be trying to help find out what went wrong, which is why I also wrote If, on the other hand, your concern was the site and how to ensure that users download Unicode code correctly, then I share that concern... I tried to understand your intent and your message, but I was not sure what your point was. My main concern is the file's Unicode characters. Arguments against fixing the file are the first thing I wanted to rebut. And my interpretation #1 of your response was that you were essentially saying that the real problem is one of correctly downloading the file: just download correctly; no need to fix the file. Not knowing quite what you meant, I tried to reply to both of my interpretations of your good deed, with priority to what I think is most important: fixing the file. If you had made it clear that you supported fixing the file and you were only offering help to find out what went wrong with the download, then I wouldn't have said anything about interpretation #1. Sorry if I misunderstood you. I was only trying to separate the bug report from a possible Web-page download problem. No good deed goes unpunished, it seems... ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: please use ?\u2014 instead of the unicode character inbuff-menu.el
I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. I didn't think so, but I just made a test on the wiki, and I think you are probably right. I was able to insert Unicode characters in a new lisp-file page, and they were retained properly after saving - so what I said before is apparently wrong. I don't know if there was a change to the wiki recently or if this was always the case. I do know that, with the same browser and the same browser encoding, I ran into a problem before, but perhaps it was something I did. FWIW, I just noticed that my browser is set to Unicode for the encoding, and it was when I picked up the file with the broken characters. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/18/07, Drew Adams [EMAIL PROTECTED] wrote: [...] so I did not change my browser encoding - after all, this is code, which displays as plain text. That assumption is just wrong, and more and more with each passing day. elisp is not the only language where you can have source that contains non-ASCII chars (it is perfectly legal in Ada, for example, and Perl). 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? 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? 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. 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. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
On 2/19/07, Drew Adams [EMAIL PROTECTED] wrote: I don't intend to establish a line. Judgement is needed, perhaps case by case. That still doesn't help the user who doesn't know what your decision was. What I said, in an earlier mail, was this: I know. I've said that I know what you were arguing for. Good question, and one that I raised in response to Eli's mail. Excuse me for not reading the threads in the order that would be more convenient to you ;-) Maybe we should say explicitly that all code should be downloaded using a Unicode encoding - I don't know. I'm not sure *we* should do it, in the sense that people who downloads code from their browser is bound to learn sooner or later that it is a bad idea to ignore encodings. We will have to live with it, until the world (including Emacs ;-)) is Unicode through and through. Not doing anything is a way to live wit it. Making it easier for the user to continue to ignore the issue is not helpful, long term. 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. I agree. I just don't think the problem of people downloading a wrong copy of buff-menu.el is really pressing. I'd say most people gets Emacs in full, either from a source tarball, a binary package or CVS. No, the fix for the problem that I reported is to use an escape sequence in buff-menu.el. I was referring, obviously, to the general problem, not the specific buff-menu.el issue. You say that you weren't talking about the general problem, so let's leave it at that. This sideline discussion (this problem that you are apparently struggling with, and that you think I am struggling with) Oh, I assure you that I'm not struggling with any Emacs problem right now, other than restlessly waiting for Emacs 22 to be released. We can at least do what we can to prevent that problem from arising in no-brainer cases such as buff-menu.el. No comment, as I already said I don't mind this specific case. It's just common sense. And replacing two em-dash characters with \u2014 is hardly making extraordinary efforts. No. Taking the time to discuss a change that should, in an ideal world, be unnecessary and even ill-advised, and also the time do think where to draw the line, is an extraordinary (beyond what is ordinary or usual, not highly unusual or exceptional or remarkable) effort. 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. Your (everybody's) trivial is other people's bad idea, sometimes. 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. I bow to others in that collective you. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: please use ?\u2014 instead of the unicode character inbuff-menu.el
Date: Sun, 18 Feb 2007 23:48:29 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Sun, 18 Feb 2007 23:32:01 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Eli Zaretskii [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wonder if this has something to do with the mime codes? I do not know anything about it, but could it be that the web server changes something in the output? I think the problem is simply that IE, like Emacs, needs to be told the encoding explicitly, when its defaults are wrong. There's no magic wand here. Maybe, I just do not understand why IE6 just does not save the bytestream it recieves. For the same reason Emacs doesn't do that with non-ASCII text: it doesn't treat it as a byte stream, it treats it as an encoded text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
