Re: Emacs text bug

[Peter Dyballa]

Am 26.01.2013 um 23:48 schrieb Drew Adams:

> While it is always better to base a bug report on more information, even just
> reporting a problem can sometimes help.  At the very least it gives Emacs core
> developers and other users a heads-up to look further wrt the problem and its
> details (e.g. "why and when").

This happens as far as I can see rarely. Just some days ago it happened again 
and I was very soon there. C-h l did not show anything. While the compilation 
was still going on and showed UTF-8 encoding in the mode-line I tried to fix 
the way the buffer contents was presented by invoking 
revert-buffer-with-coding-system, C-x RET r, but it did not change anything. 
All other buffers (I visited) containing non-US ASCII characters showed the 
same fault: the UTF-8 encoding bytes were displayed.

This could be a Mac OS X problem. Here I can see that 'find … -ls' inserts 
ASCII NULs, ^@, into *shell* buffer at the transition from the column with the 
file size to the next one, the one with the date. Or it happens between the 
date column and the file name column – I am not completely sure about it. 
Something like these extra characters or bytes could be inserted into the 
*compilation* buffer as well and then the binary byte sequence gets out of 
sequence and order. But why does it hit all buffers and not only the faulty one 
with the extraneous bytes?

There seems to be one more indication: the hardware is PowerPC, 32-bit. The Mac 
OS X version is also close to ancient: Mac OS X 10.4 or 10.5 (Tiger or 
Leopard). On intel hardware it did occur yet…

--
Greetings

  Pete

A blizzard is when it snows sideways.