* No coding system in the modeline for unibyte buffers. @ 2009-01-16 15:59 Juanma Barranquero 2009-01-16 16:36 ` Eli Zaretskii 2009-01-16 16:42 ` Stefan Monnier 0 siblings, 2 replies; 12+ messages in thread From: Juanma Barranquero @ 2009-01-16 15:59 UTC (permalink / raw) To: Emacs developers Obviously, not a bug: 1997-07-29 Richard Stallman <rms@psilocin.gnu.ai.mit.edu> * xdisp.c (decode_mode_spec_coding): If multibyte chars disabled. display only the eol flag. But, why? Currently, C-x C-b new <RET> -*- coding: raw-text-unix -*- <RET> C-x C-s new.txt <RET> ;; -t(Unix)--- new.txt [etc] C-x C-k C-x C-f new.txt <RET> ;; -(Unix)--- new.txt [etc] which works as expected but it's weird. Is there any downside to just removing the code that forces that behavior? Juanma Index: src/xdisp.c =================================================================== RCS file: /sources/emacs/emacs/src/xdisp.c,v retrieving revision 1.1275 diff -u -2 -r1.1275 xdisp.c --- src/xdisp.c 10 Jan 2009 18:41:07 -0000 1.1275 +++ src/xdisp.c 16 Jan 2009 12:24:56 -0000 @@ -18238,5 +18238,4 @@ { Lisp_Object val; - int multibyte = !NILP (current_buffer->enable_multibyte_characters); const unsigned char *eol_str; int eol_str_len; @@ -18249,6 +18248,5 @@ if (!VECTORP (val)) /* Not yet decided. */ { - if (multibyte) - *buf++ = '-'; + *buf++ = '-'; if (eol_flag) eoltype = eol_mnemonic_undecided; @@ -18263,6 +18261,5 @@ eolvalue = AREF (val, 2); - if (multibyte) - *buf++ = XFASTINT (CODING_ATTR_MNEMONIC (attrs)); + *buf++ = XFASTINT (CODING_ATTR_MNEMONIC (attrs)); if (eol_flag) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 15:59 No coding system in the modeline for unibyte buffers Juanma Barranquero @ 2009-01-16 16:36 ` Eli Zaretskii 2009-01-16 16:42 ` Juanma Barranquero 2009-01-16 16:42 ` Stefan Monnier 1 sibling, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2009-01-16 16:36 UTC (permalink / raw) To: Juanma Barranquero; +Cc: emacs-devel > Date: Fri, 16 Jan 2009 16:59:48 +0100 > From: Juanma Barranquero <lekktu@gmail.com> > > Obviously, not a bug: > > 1997-07-29 Richard Stallman <rms@psilocin.gnu.ai.mit.edu> > > * xdisp.c (decode_mode_spec_coding): If multibyte chars disabled. > display only the eol flag. > > But, why? Because there's no encoding to display. But maybe I don't understand what you mean, please feel free to elaborate. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 16:36 ` Eli Zaretskii @ 2009-01-16 16:42 ` Juanma Barranquero 0 siblings, 0 replies; 12+ messages in thread From: Juanma Barranquero @ 2009-01-16 16:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Fri, Jan 16, 2009 at 17:36, Eli Zaretskii <eliz@gnu.org> wrote: > Because there's no encoding to display. > > But maybe I don't understand what you mean, please feel free to > elaborate. In my example C-x C-f new.txt <ENT> C-h v buffer-file-coding-system <RET> buffer-file-coding-system is a variable defined in `C source code'. Its value is raw-text-unix Local in buffer new.txt; global value is iso-latin-1-dos Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 15:59 No coding system in the modeline for unibyte buffers Juanma Barranquero 2009-01-16 16:36 ` Eli Zaretskii @ 2009-01-16 16:42 ` Stefan Monnier 2009-01-16 16:46 ` Juanma Barranquero 2009-01-17 17:03 ` No coding system in the modeline for unibyte buffers Richard M Stallman 1 sibling, 2 replies; 12+ messages in thread From: Stefan Monnier @ 2009-01-16 16:42 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers > 1997-07-29 Richard Stallman <rms@psilocin.gnu.ai.mit.edu> > * xdisp.c (decode_mode_spec_coding): If multibyte chars disabled. > display only the eol flag. > But, why? So as to indicate if the buffer is unibyte or multibyte? Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 16:42 ` Stefan Monnier @ 2009-01-16 16:46 ` Juanma Barranquero 2009-01-16 20:45 ` Stefan Monnier 2009-01-17 17:03 ` No coding system in the modeline for unibyte buffers Richard M Stallman 1 sibling, 1 reply; 12+ messages in thread From: Juanma Barranquero @ 2009-01-16 16:46 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs developers On Fri, Jan 16, 2009 at 17:42, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > So as to indicate if the buffer is unibyte or multibyte? Hmm. I suppose that is useful (though, if the coding system is on the modeline, its toltip will tell you that). Knowing the encoding is useful, too, if you deal with unibyte data from various encodings. Perhaps both things could be shown. Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 16:46 ` Juanma Barranquero @ 2009-01-16 20:45 ` Stefan Monnier 2009-01-16 23:47 ` Juanma Barranquero 0 siblings, 1 reply; 12+ messages in thread From: Stefan Monnier @ 2009-01-16 20:45 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers >> So as to indicate if the buffer is unibyte or multibyte? > Hmm. I suppose that is useful (though, if the coding system is on the > modeline, its toltip will tell you that). Knowing the encoding is > useful, too, if you deal with unibyte data from various encodings. > Perhaps both things could be shown. Maybe the problem is that you don't realize that a unibyte buffer is different from a multibyte buffer using raw-text (or binary) encoding? Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 20:45 ` Stefan Monnier @ 2009-01-16 23:47 ` Juanma Barranquero 2009-01-17 2:11 ` Stefan Monnier 0 siblings, 1 reply; 12+ messages in thread From: Juanma Barranquero @ 2009-01-16 23:47 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs developers On Fri, Jan 16, 2009 at 21:45, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Maybe the problem is that you don't realize that a unibyte buffer is > different from a multibyte buffer using raw-text (or binary) encoding? I wouldn't dismiss it. IIUC, a unibyte buffer should contain raw bytes, while a raw-text multibyte buffer would contain the same contents, converted to the internal utf-8 based Emacs representation. But I confess I'm puzzled why M-x find-file-binary test.txt <RET> M-: enable-multibyte-characters <RET> => nil C-u C-x = ; over ñ character: (241, #o361, #xf1) preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) code point: 0xF1 syntax: w which means: word category: j:Japanese l:Latin buffer code: #xC3 #xB1 file code: #xC3 #xB1 (encoded by coding system no-conversion) If I'm hopelessly wrong, I'm quite ready to be enlightened (and perhaps the docs will need work). Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 23:47 ` Juanma Barranquero @ 2009-01-17 2:11 ` Stefan Monnier 2009-01-17 2:24 ` bug#1935: " Juanma Barranquero 2009-01-17 2:24 ` Juanma Barranquero 0 siblings, 2 replies; 12+ messages in thread From: Stefan Monnier @ 2009-01-17 2:11 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Emacs developers > IIUC, a unibyte buffer should contain raw bytes, while a raw-text > multibyte buffer would contain the same contents, converted to the > internal utf-8 based Emacs representation. Actually the raw-text part of a multibyte buffer only affects operation when it is saved and loaded, so it can contain characters that are not bytes. > But I confess I'm puzzled why > M-x find-file-binary test.txt <RET> > M-: enable-multibyte-characters <RET> => nil > C-u C-x = ; over ñ > character: (241, #o361, #xf1) > preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) > code point: 0xF1 > syntax: w which means: word > category: j:Japanese l:Latin > buffer code: #xC3 #xB1 > file code: #xC3 #xB1 (encoded by coding system no-conversion) > If I'm hopelessly wrong, I'm quite ready to be enlightened (and > perhaps the docs will need work). Indeed that's a bug in C-u C-x =. It should pay attention to the buffer's enable-multibyte-characters and then present #xf1 not as a latin-1 char but as a raw-byte. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1935: No coding system in the modeline for unibyte buffers. 2009-01-17 2:11 ` Stefan Monnier @ 2009-01-17 2:24 ` Juanma Barranquero 2009-01-17 2:24 ` Juanma Barranquero 1 sibling, 0 replies; 12+ messages in thread From: Juanma Barranquero @ 2009-01-17 2:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs Bug Tracker, Emacs developers On Sat, Jan 17, 2009 at 03:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Actually the raw-text part of a multibyte buffer only affects operation > when it is saved and loaded, so it can contain characters that are > not bytes. Yes, I understand that. >> But I confess I'm puzzled why > >> M-x find-file-binary test.txt <RET> >> M-: enable-multibyte-characters <RET> => nil >> C-u C-x = ; over ñ > >> character: (241, #o361, #xf1) >> preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) >> code point: 0xF1 >> syntax: w which means: word >> category: j:Japanese l:Latin >> buffer code: #xC3 #xB1 >> file code: #xC3 #xB1 (encoded by coding system no-conversion) > >> If I'm hopelessly wrong, I'm quite ready to be enlightened (and >> perhaps the docs will need work). > > Indeed that's a bug in C-u C-x =. It should pay attention to the > buffer's enable-multibyte-characters and then present #xf1 not as > a latin-1 char but as a raw-byte. Well, that makes sense. I'm filing the bug report. Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-17 2:11 ` Stefan Monnier 2009-01-17 2:24 ` bug#1935: " Juanma Barranquero @ 2009-01-17 2:24 ` Juanma Barranquero 2009-01-20 6:15 ` bug#1935: marked as done (describe-char does not show raw bytes as such) Emacs bug Tracking System 1 sibling, 1 reply; 12+ messages in thread From: Juanma Barranquero @ 2009-01-17 2:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: Emacs Bug Tracker, Emacs developers On Sat, Jan 17, 2009 at 03:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Actually the raw-text part of a multibyte buffer only affects operation > when it is saved and loaded, so it can contain characters that are > not bytes. Yes, I understand that. >> But I confess I'm puzzled why > >> M-x find-file-binary test.txt <RET> >> M-: enable-multibyte-characters <RET> => nil >> C-u C-x = ; over ñ > >> character: (241, #o361, #xf1) >> preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) >> code point: 0xF1 >> syntax: w which means: word >> category: j:Japanese l:Latin >> buffer code: #xC3 #xB1 >> file code: #xC3 #xB1 (encoded by coding system no-conversion) > >> If I'm hopelessly wrong, I'm quite ready to be enlightened (and >> perhaps the docs will need work). > > Indeed that's a bug in C-u C-x =. It should pay attention to the > buffer's enable-multibyte-characters and then present #xf1 not as > a latin-1 char but as a raw-byte. Well, that makes sense. I'm filing the bug report. Juanma ^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#1935: marked as done (describe-char does not show raw bytes as such) 2009-01-17 2:24 ` Juanma Barranquero @ 2009-01-20 6:15 ` Emacs bug Tracking System 0 siblings, 0 replies; 12+ messages in thread From: Emacs bug Tracking System @ 2009-01-20 6:15 UTC (permalink / raw) To: Kenichi Handa [-- Attachment #1: Type: text/plain, Size: 885 bytes --] Your message dated Tue, 20 Jan 2009 15:08:33 +0900 with message-id <E1LP9mr-0007Br-L0@etlken.m17n.org> and subject line Re: [EMACS] categories in output of `describe-char' has caused the Emacs bug report #1935, regarding describe-char does not show raw bytes as such to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com immediately.) -- 1935: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1935 Emacs Bug Tracking System Contact owner@emacsbugs.donarmstrong.com with problems [-- Attachment #2: Type: message/rfc822, Size: 3777 bytes --] From: Juanma Barranquero <lekktu@gmail.com> To: Stefan Monnier <monnier@iro.umontreal.ca> Cc: Emacs developers <emacs-devel@gnu.org>, Emacs Bug Tracker <submit@emacsbugs.donarmstrong.com> Subject: Re: No coding system in the modeline for unibyte buffers. Date: Sat, 17 Jan 2009 03:24:41 +0100 Message-ID: <f7ccd24b0901161824i605beb1draa915148daca34d4@mail.gmail.com> On Sat, Jan 17, 2009 at 03:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > Actually the raw-text part of a multibyte buffer only affects operation > when it is saved and loaded, so it can contain characters that are > not bytes. Yes, I understand that. >> But I confess I'm puzzled why > >> M-x find-file-binary test.txt <RET> >> M-: enable-multibyte-characters <RET> => nil >> C-u C-x = ; over ñ > >> character: (241, #o361, #xf1) >> preferred charset: iso-8859-1 (Latin-1 (ISO/IEC 8859-1)) >> code point: 0xF1 >> syntax: w which means: word >> category: j:Japanese l:Latin >> buffer code: #xC3 #xB1 >> file code: #xC3 #xB1 (encoded by coding system no-conversion) > >> If I'm hopelessly wrong, I'm quite ready to be enlightened (and >> perhaps the docs will need work). > > Indeed that's a bug in C-u C-x =. It should pay attention to the > buffer's enable-multibyte-characters and then present #xf1 not as > a latin-1 char but as a raw-byte. Well, that makes sense. I'm filing the bug report. Juanma [-- Attachment #3: Type: message/rfc822, Size: 2525 bytes --] From: Kenichi Handa <handa@m17n.org> To: Juanma Barranquero <lekktu@gmail.com> Cc: 1935-done@emacsbugs.donarmstrong.com, handa@m17n.org Subject: Re: [EMACS] categories in output of `describe-char' Date: Tue, 20 Jan 2009 15:08:33 +0900 Message-ID: <E1LP9mr-0007Br-L0@etlken.m17n.org> In article <f7ccd24b0901190754m1a319ad2m97a9d0072a29da40@mail.gmail.com>, Juanma Barranquero <lekktu@gmail.com> writes: > On Mon, Jan 19, 2009 at 12:12, Juanma Barranquero <lekktu@gmail.com> wrote: > > OK, I'll work on it. > Applied. Thank you. > Somewhat related: did you see bug#1935? Ah, I've just installed a fix. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: No coding system in the modeline for unibyte buffers. 2009-01-16 16:42 ` Stefan Monnier 2009-01-16 16:46 ` Juanma Barranquero @ 2009-01-17 17:03 ` Richard M Stallman 1 sibling, 0 replies; 12+ messages in thread From: Richard M Stallman @ 2009-01-17 17:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, emacs-devel > * xdisp.c (decode_mode_spec_coding): If multibyte chars disabled. > display only the eol flag. > But, why? So as to indicate if the buffer is unibyte or multibyte? That is one reason. Also, displaying them when they are meaningless could mislead people. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-01-20 6:15 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-16 15:59 No coding system in the modeline for unibyte buffers Juanma Barranquero 2009-01-16 16:36 ` Eli Zaretskii 2009-01-16 16:42 ` Juanma Barranquero 2009-01-16 16:42 ` Stefan Monnier 2009-01-16 16:46 ` Juanma Barranquero 2009-01-16 20:45 ` Stefan Monnier 2009-01-16 23:47 ` Juanma Barranquero 2009-01-17 2:11 ` Stefan Monnier 2009-01-17 2:24 ` bug#1935: " Juanma Barranquero 2009-01-17 2:24 ` Juanma Barranquero 2009-01-20 6:15 ` bug#1935: marked as done (describe-char does not show raw bytes as such) Emacs bug Tracking System 2009-01-17 17:03 ` No coding system in the modeline for unibyte buffers Richard M Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.