No coding system in the modeline for unibyte buffers.

No coding system in the modeline for unibyte buffers.

[Juanma Barranquero]

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)

Re: No coding system in the modeline for unibyte buffers.

[Eli Zaretskii]

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

Re: No coding system in the modeline for unibyte buffers.

[Juanma Barranquero]

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

Re: No coding system in the modeline for unibyte buffers.

[Stefan Monnier]

> 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

Re: No coding system in the modeline for unibyte buffers.

[Juanma Barranquero]

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

Re: No coding system in the modeline for unibyte buffers.

[Stefan Monnier]

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

Re: No coding system in the modeline for unibyte buffers.

[Juanma Barranquero]

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

Re: No coding system in the modeline for unibyte buffers.

[Stefan Monnier]

> 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

Re: No coding system in the modeline for unibyte buffers.

[Juanma Barranquero]

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

Re: No coding system in the modeline for unibyte buffers.

[Richard M Stallman]

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