Re: GNU Emacs 21.2.1 kill-line bug ?

Re: GNU Emacs 21.2.1 kill-line bug ?

[Kevin Rodgers]

Besam Khidhir wrote:
 > So, running Emacs 21.2.1 on Mac OS X 10.3.4, base emacs install, I'm
 > in a buffer with some binary characters, I do a kill-line (C-k) and
 > then switch to another buffer and yank, and guess what, my characters
 > come out different... it looks like some characters such as \366 get
 > replaced with '?'.
 >
 > When I do a save I get prompted for what encoding I want to
 > use... which doesn't change anything because vi sees the characters as
 > '?'.
...
 > Any ideas?

C-h v buffer-file-coding-system [in both buffers]
C-h v selection-coding-system

See the "Coding Systems" node of the Emacs manual, and the preceding
nodes under "International [Character Set Support]".

`C-h n' will show you all the user-visible changes since the venerable
Emacs 19.34 (released almost 8 years ago!).

 > If this is a "feature" is there anyway to turn it off: ie. get emacs
 > back to the good old days when a character was a character and there
 > wasn't any "hiding" of characters (noticed how ^M characters don't
 > appear any more when you edit DOS files) or "replacing" of characters
 > with '?'.

The "Enabling Multibyte Characters" node of the Emacs manual explains:

|    To turn off multibyte character support by default, start Emacs with
| the `--unibyte' option (*note Initial Options::), or set the
| environment variable `EMACS_UNIBYTE'.  You can also customize
| `enable-multibyte-characters' or, equivalently, directly set the
| variable `default-enable-multibyte-characters' to `nil' in your init
| file to have basically the same effect as `--unibyte'.

 > I mean I used to rely on emacs to show me everything but these days I
 > trust vi more than emacs and that's saying something...

You are confused.  Trust the One True Editor, and deliver yourself from
eVIl.

-- 
Kevin Rodgers

GNU Emacs 21.2.1 kill-line bug ?

[Besam Khidhir]

Hi,

Not sure if this is a bug but it sure acts like one AND in previous versions
of emacs (circa 19.x) this never happened, but who knows, one man's bug is
another man's feature...

So, running Emacs 21.2.1 on Mac OS X 10.3.4, base emacs install, I'm in
a buffer with some binary characters, I do a kill-line (C-k) and then
switch to another buffer and yank, and guess what, my characters come
out different... it looks like some characters such as \366 get replaced
with '?'.

When I do a save I get prompted for what encoding I want to use... which
doesn't change anything because vi sees the characters as '?'.

Here's a cut-and-paste of what I'm seeing:

H\211\214TkTSW^V\276777A\204\360\274@n\340&^A[m^Um%*^H\250\370^@[^DF^Q^Q(E\204\\
200<\302[\261Nx\312 ^LR^U\265jPQ\221\326\370D\243
\240Ea\206A^PE^]\307wUpj^U\35\
5\260D\3357\335q\246q\2345k\326\262?f\235s\366:\347\354\363\255u\326\267\277o\2\
23\204P@\220$)^M^K^L^H\231?{|\250:?(>==%>'\321sQ\246&>\343mr^VoC\3602\222w^U\36\
0n^T/^U\242\265^U\325f%\344]\255\234p>n\373E\373\213\232\346\366\220\377\252\25\
2z^W\255\304^Pl^Ki6\260\323\256\327\225^[eOP$9q\346\347\213\324\253Rr\325\211\2\
12@\365r\205\217\267"%\303<^S2s\2622s\342\363\324

Gets translated to:

H\211\214TkTSW^V?777A\204??@n?&^A[m^Um%*^H??^@[^DF^Q^Q(E\204\200<?[?Nx?
^LR^U?j\
PQ\221??D?
?Ea\206A^PE^]?wUpj^U??D?7?q?q\2345k???f\235s?:????u???o\223\204P@\22\
0$)^M^K^L^H\231?{|?:?(>==%>'?sQ?&>?mr^VoC?2\222w^U?n^T/^U??^U?f%?]?\234p>n?E?\2\
13\232??\220???z^W??^Pl^Ki6????\225^[eOP$9q??\213??Rr?\211\212@?r\205\217?"%?<^\
S2s?2s???

Any ideas?

If this is a "feature" is there anyway to turn it off: ie. get emacs back
to the good old days when a character was a character and there wasn't any
"hiding" of characters (noticed how ^M characters don't appear any more when
you edit DOS files) or "replacing" of characters with '?'. I mean I used to
rely on emacs to show me everything but these days I trust vi more than emacs
and that's saying something...

Anyway, thanks!

Besam

P.S. I'm still waiting to get list-approved so can you please send a
     copy of your emails to this address as well as the mailing list.
     Thanks!