GNU bug report logs - #1935
describe-char does not show raw bytes as such

Previous Next

Package: emacs;

Reported by: Juanma Barranquero <lekktu <at> gmail.com>

Date: Sat, 17 Jan 2009 02:30:03 UTC

Severity: normal

Done: Kenichi Handa <handa <at> m17n.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Emacs developers <emacs-devel <at> gnu.org>,
        Emacs Bug Tracker <submit <at> debbugs.gnu.org>
Subject: bug#1935: No coding system in the modeline for unibyte buffers.
Date: Sat, 17 Jan 2009 03:24:41 +0100
On Sat, Jan 17, 2009 at 03:11, Stefan Monnier <monnier <at> 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




This bug report was last modified 16 years and 130 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.