[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-breaking spaces in view-mode

From: Stefan Monnier
Subject: Re: non-breaking spaces in view-mode
Date: Wed, 26 Jan 2005 18:14:03 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

> About a year ago I unintentionally changed my setup so that Emacs
> used multibyte mode instead of unibyte mode.  I was rather surprised
> that suddenly VM produced many strange results -- till I figured out
> that it was the multibyte mode.  So I switched back to unibyte mode.
> I haven't had any problems with VM since then.

Hmm... That's bad.  We should get VM to fix their multibyte support.

>> > - If EMACS_UNIBYTE is set, "emacs --no-init-file --no-site-file"
>> >   displays non-breaking space as `\240'.
>> What did it do in Emacs-21.3?
> No matter whether it is unibyte mode or multibyte mode (or `emacs -nw'),
> Emacs-21.3 displays `\240' as a white space, which is what I expect to see.

Thanks.  Do you remember approximately when this changed?

BTW, I cannot reproduce your problem: when I try the following (with the
latest Emacs-CVS):

   LANG=fr_CH.ISO8859-1 emacs --unibyte -Q ~/tmp/foo

The code \240 in the file ~/tmp/foo is displayed as a space.
Same thing of course if I set EMACS_UNIBYTE instead of passing
the --unibyte argument.

>> >   character:   (0240, 160, 0xa0)
>> Did you actually see this 2-char sequence " " in the buffer or
>> is it some problem with your mail?
> This seems to be a mail problem. I have never seen such a 2-char
> sequence when visiting a file which contains non-breaking spaces.

Good, thank you.

> Recently I was annoyed that copying from some other X application
> into emacs produced such strange 2-char sequences.

It's when the application sends a utf-8 sequence, I guess.

>> Any reason why you keep using the unibyte mode? (seems like
>> masochism to me, at this point in the evolution of Emacs).

> I am just curious here: Is unibyte mode not supported anymore?
> Well, when one uses packages like vm one needs the backward
> compatibilty (though I know it makes maintanance of emacs much more
> difficult).

It is still supported, but we're discouraging its use.  It was useful back
when most packages hadn't been adapted to Mule, but nowadays there is rarely
any reason to use unibyte mode and so we're making less effort to try and
make sure that unibyte mode works "as best it can" (it often uses
guesses and so necessarily breaks down in some cases).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]