unicode-2 branch: ^O goes missing

[Tom Rauchenwald]

To reproduce:
Create an empty File.
Do C-q C-o in it. A sequence that looks like ^O should appear.
Save the File and kill the buffer.
Open the file again. ^O is not there anymore.
With emacs22 this works.

Background is that i tried a elisp-program that parses color-sequences in IRC, and tried to match ^O, but with the unicode-2 branch this doesn't work anymore because the ^O goes missing somewhere.

Tom

In GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, GTK+ Version 2.10.13)
 of 2007-07-17 on walter
Windowing system distributor `The X.Org Foundation', version 11.0.10300000
configured using `configure  '--with-gtk' '--enable-font-backend' '--with-xft''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: de_AT.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
M-x s t a r <tab> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> s p l a <tab> s h <tab> - s
c r <tab> M-x m e n u - b a r <return> <backspace>
- m o <tab> <return> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu>
<about> <help-echo> <return> <backspace> C-x k <return>
<help-echo> M-x r e p o r t <tab> <return>

Recent messages:
("emacs" "-Q")
For information about the GNU Project and its goals, type C-h C-p.
Quit
Menu-Bar mode enabled
Buffer is read-only: #<buffer *About GNU Emacs*>
call-interactively: Beginning of buffer
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Kenichi Handa]

In article <E1IDoSt-0001rV-Lc@walter>, Tom Rauchenwald <its.sec@...> writes:

> To reproduce:
> Create an empty File.
> Do C-q C-o in it. A sequence that looks like ^O should appear.
> Save the File and kill the buffer.
> Open the file again. ^O is not there anymore.
> With emacs22 this works.

> Background is that i tried a elisp-program that parses color-sequences in IRC, and tried to match ^O, but with the unicode-2 branch this doesn't work anymore because the ^O goes missing somewhere.

^O is a locking shift code of ISO-2022, and iso-2022
detector of emacs-unicode-2 was too strong compared with
that of Emacs 22.  I've just installed a fix.

But, it is in general safer to specify a proper coding
system (in your case, iso-safe or no-conversion?) if you are
reading a file that contains some binary data (for instance
by let-binding coding-system-for-read).  Another way is to
let-bind inhibit-iso-escape-detection to t.

---
Kenichi Handa
handa@...


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Tom Rauchenwald]

Kenichi Handa <handa@...> writes:

> In article <E1IDoSt-0001rV-Lc@walter>, Tom Rauchenwald <its.sec@...> writes:
>
>> To reproduce:
>> Create an empty File.
>> Do C-q C-o in it. A sequence that looks like ^O should appear.
>> Save the File and kill the buffer.
>> Open the file again. ^O is not there anymore.
>> With emacs22 this works.
>
>> Background is that i tried a elisp-program that parses
>> color-sequences in IRC, and tried to match ^O, but with the
>> unicode-2 branch this doesn't work anymore because the ^O goes
>> missing somewhere.
>
> ^O is a locking shift code of ISO-2022, and iso-2022 detector of
>emacs-unicode-2 was too strong compared with that of Emacs 22.  I've
>just installed a fix.

Thanks, I'll try it out soon and report back.

> But, it is in general safer to specify a proper coding
> system (in your case, iso-safe or no-conversion?) if you are
> reading a file that contains some binary data (for instance
> by let-binding coding-system-for-read).  Another way is to
> let-bind inhibit-iso-escape-detection to t.

In my case I was trying out circe, an IRC client for emacs. So I
didn't write the file myself.

Thanks for looking into this.

Tom


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Tom Rauchenwald]

Kenichi Handa <handa@...> writes:

> In article <E1IDoSt-0001rV-Lc@walter>, Tom Rauchenwald <its.sec@...> writes:
>
>> To reproduce:
>> Create an empty File.
>> Do C-q C-o in it. A sequence that looks like ^O should appear.
>> Save the File and kill the buffer.
>> Open the file again. ^O is not there anymore.
>> With emacs22 this works.
>
>> Background is that i tried a elisp-program that parses color-sequences in IRC, and tried to match ^O, but with the unicode-2 branch this doesn't work anymore because the ^O goes missing somewhere.
>
> ^O is a locking shift code of ISO-2022, and iso-2022
> detector of emacs-unicode-2 was too strong compared with
> that of Emacs 22.  I've just installed a fix.
>
> But, it is in general safer to specify a proper coding
> system (in your case, iso-safe or no-conversion?) if you are
> reading a file that contains some binary data (for instance
> by let-binding coding-system-for-read).  Another way is to
> let-bind inhibit-iso-escape-detection to t.

Okay, I rebuilt Emacs, and everything is fine now.

Thanks again,

Tom

> ---
> Kenichi Handa
> handa@...


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug