Re: obscure new display features

2005-04-12 Thread Dave Love
Miles Bader [EMAIL PROTECTED] writes: The point of similarity is not break-vs-non-break, but that they're both characters which can be displayed identically to some more common character in display contexts, but which should be distinguished visually (e.g., with an escape prefix [\]) in

Re: obscure new display features

2005-04-05 Thread Dave Love
Richard Stallman [EMAIL PROTECTED] writes: Unicode is entitled to its opinion, but we do not necessarily follow Unicode's opinion. It's not an opinion, it's a statement of fact about line breaking in general even if you don't accept the semantics of U+00AD as a format character. Even if you

Re: obscure new display features

2005-03-30 Thread Richard Stallman
I guess it should be visible at the end of the line. Well Unicode says that guess is wrong... Unicode is entitled to its opinion, but we do not necessarily follow Unicode's opinion. If the opinion is based on reasons, those reasons may be valid. It would be useful for us to look at

Re: obscure new display features

2005-03-29 Thread Dave Love
Miles Bader [EMAIL PROTECTED] writes: I've no idea why non-breaking characters should be displayed like this, but U+00AD isn't one -- it's SOFT HYPHEN. If you're going to change its display, the issue (see Unicode) is whether or not it should be displayed at all -- not that I think it

Re: obscure new display features

2005-03-29 Thread Dave Love
Juri Linkov [EMAIL PROTECTED] writes: I agree. ^L fontified as a keyword looks horrible. That's why I suggested to change its color to dark red to look more like comments. The point isn't the specific colour, but the fact that there is mysterious highlighting at all. I've no idea why

Re: obscure new display features

2005-03-29 Thread Dave Love
Stefan Monnier [EMAIL PROTECTED] writes: in either case, standard-display-table is not nil, so this let's make sure the standard-display-table default is nil argument doesn't hold much water. It would be better if it _was_ nil rather than having the misleading display of eight-bit characters

Re: obscure new display features

2005-03-28 Thread Stefan Monnier
I don't know about you, but when I do here emacs -Q or emacs -nw -Q in either case, standard-display-table is not nil, Why is that? It is nil for me. Probably the locale. I have LANG=fr_CH.ISO-8859-1. Admittedly, the fr_CH population is small, but the

Re: obscure new display features

2005-03-28 Thread Luc Teirlinck
Stefan Monnier wrote: I don't know about you, but when I do here emacs -Q or emacs -nw -Q in either case, standard-display-table is not nil, Why is that? It is nil for me. Probably the locale. I have LANG=fr_CH.ISO-8859-1. After `emacs

Re: obscure new display features

2005-03-28 Thread Juri Linkov
I don't know about you, but when I do here emacs -Q or emacs -nw -Q in either case, standard-display-table is not nil, Why is that? It is nil for me. Probably the locale. I have LANG=fr_CH.ISO-8859-1. Admittedly, the fr_CH population is small, but the

Re: obscure new display features

2005-03-27 Thread Juri Linkov
I find the new display features concerning `escape-glyph' and `show-nonbreak-escape' annoying, but also they're obscure and partly inconsistent. This is roughly what I went through on encountering them. First you wonder why, say, ^L in your source files is apparently being font-locked as a

Re: obscure new display features

2005-03-27 Thread Miles Bader
On Mon, 28 Mar 2005 02:59:33 +0300, Juri Linkov [EMAIL PROTECTED] wrote: I agree. ^L fontified as a keyword looks horrible. That's why I suggested to change its color to dark red to look more like comments. We already had this argument. In other buffers I think that instead of adding escape