Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     + (or standard-display-table
>     +     ;; avoid using autoloaded make-display-table here
>     +     (setq standard-display-table (make-char-table 'display-table nil)))
>     + 
>     + (let* ((face (lsh (face-id 'escape-glyph) 19))
>     +        (backslash (+ face ?\\))
>     +        (dot (+ face ?.)))
>     +   (set-char-table-extra-slot standard-display-table 2 backslash)
>     +   (aset standard-display-table 2208 (vector backslash ?\s))
>     +   (aset standard-display-table 2221 (vector backslash ?-))
>     +   (set-char-table-extra-slot standard-display-table 3 (+ face ?^))
>     +   (set-char-table-extra-slot standard-display-table 4 (vector dot dot dot)))
>
> This code, like Pfeiffer's change, has the effect of
> setting up a non-nil display table in Emacs at build time.

True, but with my change, it doesn't use fixed values which
may only be correct for some installations.

> A change like that ought to be discussed.
>
> Why do we want that?  Why not go back to the old code
> so that a display tabel was set up only if we WANT one?

IIRC, you said this was a good idea, so I thought Daniel
had installed it on approval from you -- I just fixed the
technical problems with it.

I have no opinion on whether this should be enabled by default or not.

If it should be off by default, we should move all of it (including
the defface) to disp-table.el and create a simple autoloaded
defcustom to enable it.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    IIRC, you said this was a good idea, so I thought Daniel
    had installed it on approval from you -- I just fixed the
    technical problems with it.

I don't recall saying I liked the idea of defining a display table by
default, and I can't see any such message that I sent him in the past
few months.  Can you find what I actually said about this?

What is the goal of this feature?

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     IIRC, you said this was a good idea, so I thought Daniel
>     had installed it on approval from you -- I just fixed the
>     technical problems with it.
>
> I don't recall saying I liked the idea of defining a display table by
> default, and I can't see any such message that I sent him in the past
> few months.  Can you find what I actually said about this?
>
> What is the goal of this feature?

This is a very useful feature which makes visually more noticeable
all potentially dangerous control characters or other special glyphs
which doesn't correspond to a character.

Without such feature, to check whether a glyph displays a real
characters or not, one needs to undertake special actions like
e.g. to put the cursor to the position in question, then move
the point to the right, and see if it moves to one position or more
(that's what I usually do).

What I don't in this feature is the color of its glyph face. 
It is too bright, and so too distracting.

And there is also a bug with new feature: C-u C-x = typed on
no-break spaces or soft hyphens causes `describe-char' to fail
with "Invalid character: 054000134, 11534428, 0xb0005c" error
on (format "?%c" 11534428) function call.

Otherwise, this is a good feature.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

Juri Linkov wrote:

>Richard Stallman <rms@gnu.org> writes:
>  
>
>>    IIRC, you said this was a good idea, so I thought Daniel
>>    had installed it on approval from you -- I just fixed the
>>    technical problems with it.
>>
>>I don't recall saying I liked the idea of defining a display table by
>>default, and I can't see any such message that I sent him in the past
>>few months.  Can you find what I actually said about this?
>>    
>>
On Thu, 7 Oct 2004 07:13:05 +0200 I wrote:

> Apart from this diplay bug, I find this feature so useful, it should be on by
> default with a dedicated face.  Otherwise it's so obscure, few people will
> find out about it.

In Kim F. Storm's reply of 07.10.2004 00:00 he cites you as:

> Daniel, I agree this is a nice feature.

I apparently did not get your mail myself, but took this as an approval, 
once Kim fixed the display bugs.

As for the colour or brightness, feel free to make it anything you like. 
Secondary-selection is just what I've long been using for this. Using a 
background is useful however, since it combines nicely with most 
font-locking, which tends to set foregrounds, boldness, etc.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    This is a very useful feature which makes visually more noticeable
    all potentially dangerous control characters or other special glyphs
    which doesn't correspond to a character.

Ok, I can see that that could be useful.  But implementing it
by setting up a default display table is a kludge.  The right way
is to change the code that implements the standard display conventions,
to make it use the desired face when it generates these glyphs.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

Richard Stallman wrote:

>    This is a very useful feature which makes visually more noticeable
>    all potentially dangerous control characters or other special glyphs
>    which doesn't correspond to a character.
>
>Ok, I can see that that could be useful.  But implementing it
>by setting up a default display table is a kludge.  The right way
>is to change the code that implements the standard display conventions,
>to make it use the desired face when it generates these glyphs.
>
A lot of things in Emacs have default faces on by default. Why should 
these strange multiglyph characters not also?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Stefan Monnier]

>> This is a very useful feature which makes visually more noticeable
>> all potentially dangerous control characters or other special glyphs
>> which doesn't correspond to a character.
>> 
>> Ok, I can see that that could be useful.  But implementing it
>> by setting up a default display table is a kludge.  The right way
>> is to change the code that implements the standard display conventions,
>> to make it use the desired face when it generates these glyphs.
>> 
> A lot of things in Emacs have default faces on by default. Why should these
> strange multiglyph characters not also?

Actually I just saw it in action in a buffer that was outline-minor-mode'd
(an elisp buffer where every function is folded on a single line) and the
grey background face on the "..." looks really ugly.

I don't mind it on ^L and \201 kind of things (which aren't pretty anyway
and do deserve some kind of warning), but I think that on the ellipsis
glyph, it's a sin.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

Stefan Monnier wrote:

>>>This is a very useful feature which makes visually more noticeable
>>>all potentially dangerous control characters or other special glyphs
>>>which doesn't correspond to a character.
>>>
>>>Ok, I can see that that could be useful.  But implementing it
>>>by setting up a default display table is a kludge.  The right way
>>>is to change the code that implements the standard display conventions,
>>>to make it use the desired face when it generates these glyphs.
>>>
>> lot of things in Emacs have default faces on by default. Why should these
>>strange multiglyph characters not also?
>>    
>>
>
>Actually I just saw it in action in a buffer that was outline-minor-mode'd
>(an elisp buffer where every function is folded on a single line) and the
>grey background face on the "..." looks really ugly.
>
>I don't mind it on ^L and \201 kind of things (which aren't pretty anyway
>and do deserve some kind of warning), but I think that on the ellipsis
>glyph, it's a sin.
>
The ellipsis glyph, magically hiding a lot of text, is something very 
different from 3 points that may happen to be at the end of the line...

To keep them apart at first sight, some markup is very welcome! I've 
been happy with this colour for ages, but anybody is welcome to propose 
a more suitable face — or several if you want to go so far.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Stefan Monnier]

>> Actually I just saw it in action in a buffer that was outline-minor-mode'd
>> (an elisp buffer where every function is folded on a single line) and the
>> grey background face on the "..." looks really ugly.
>> 
>> I don't mind it on ^L and \201 kind of things (which aren't pretty anyway
>> and do deserve some kind of warning), but I think that on the ellipsis
>> glyph, it's a sin.
>> 
> The ellipsis glyph, magically hiding a lot of text, is something very
> different from 3 points that may happen to be at the end of the line...

I never claimed otherwise.

> To keep them apart at first sight, some markup is very welcome! I've been
> happy with this colour for ages, but anybody is welcome to propose a more
> suitable face — or several if you want to go so far.

I'm not opposed to having a feature to make the ellipsis a bit more
different from three dots for those users who like it, but in my experience
ellipsis only happens in circumstances where the user has specifically asked
for it (she turned on outline-minor-mode or some such optional feature), so
it very rarely causes confusion.
So I think it's better to keep the default ellipsis non-highlighted.

Also, the NEWS file should be updated to describe this new highlighting on
..., ^X, and \NNN, as well as explain how to change it.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    >Ok, I can see that that could be useful.  But implementing it
    >by setting up a default display table is a kludge.  The right way
    >is to change the code that implements the standard display conventions,
    >to make it use the desired face when it generates these glyphs.
    >
    A lot of things in Emacs have default faces on by default. Why should 
    these strange multiglyph characters not also?

I'm not talking about WHETHER to do it; I've agreed to that
(although I think the face used needs to be changed).

I'm talking about HOW to implement this.  I don't like the idea
of implementing it by having a display table all the time.
It ought to be implemented in the code that generates the ^ and \
characters.

I reimplemented it in the way I think is cleaner.
I also turned off use of this for ellipses, and changed the face
definition to be less loud.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    I don't mind it on ^L and \201 kind of things (which aren't pretty anyway
    and do deserve some kind of warning), but I think that on the ellipsis
    glyph, it's a sin.

I agree with you, more or less.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

Richard Stallman schrieb:

>    >Ok, I can see that that could be useful.  But implementing it
>    >by setting up a default display table is a kludge.  The right way
>    >is to change the code that implements the standard display conventions,
>    >to make it use the desired face when it generates these glyphs.
>    >
>    A lot of things in Emacs have default faces on by default. Why should 
>    these strange multiglyph characters not also?
>
>I'm not talking about WHETHER to do it; I've agreed to that
>(although I think the face used needs to be changed).
>
>I'm talking about HOW to implement this.  I don't like the idea
>of implementing it by having a display table all the time.
>It ought to be implemented in the code that generates the ^ and \
>characters.
>  
>
I don't understand the point of having a mechanism, if it's not supposed 
to used. But, well, it's your choice...

>I reimplemented it in the way I think is cleaner.
>I also turned off use of this for ellipses, and changed the face
>definition to be less loud.
>
What have you done to this??? Kim had such pains to get it working right 
and now it's all broken again! For one thing setting a that foreground 
is hardly visible, but that can be customized, so it's ok. Alas they no 
longer combine with other faces, such as selection, which is a giant 
step backwards.

For another you make all parts of the glyph the same, instead of just 
the escape, such that they become hard to tell apart. This also runs 
counter to the new name of the face.

And you forgot sticky space and soft hyphen, which now again look 
identical to their non-special counterparts. As for ellipses, there 
should at least be a simple option. I hate it, when some wizardry can't 
be told apart at first sight.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

dapfy@t-online.de (Daniel Pfeiffer) writes:
> And you forgot sticky space and soft hyphen, which now again look
> identical to their non-special counterparts.

It is important to highlight no-break spaces and soft hyphens.
I had several problems caused by space-looking no-break spaces
(?\xa0 and ?\x8a0) accidentally typed with AltGr-SPC, until I
rebound it to M-SPC in .emacs.

> As for ellipses, there should at least be a simple option. I hate
> it, when some wizardry can't be told apart at first sight.

Highlighted ellipses are useful too.

I think there should be a simple option for turning it on and off
(like e.g. show-trailing-whitespace) with a list of desired glyphs
to highlight.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Stefan Monnier]

>> As for ellipses, there should at least be a simple option.  I hate
>> it, when some wizardry can't be told apart at first sight.

Then you'll also want a simple option to make fully invisible text visible
(or add some visual marker), and you'll also want visual markers for
text-compositions.  And you'll also want to highlight TABs, trailing
whitespace, ...

There are already packages that do some kind of "show markup", and they
could easily be extended to highlight ellipsis and do such things.

But when a package marks some text as "invisible", the default behavior of
Emacs should be to make the text invisible full stop.  Similarly, when
a package makes a piece of text "invisible with ellipsis", then the default
behavior should be to put an ellipsis full stop.  If those things confuse
the user it's a problem with the package, not with the default way to handle
invisible text.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    I don't understand the point of having a mechanism, if it's not supposed 
    to used.

That is not what I said.  Using a display table is somewhat costly
so I don't want to use it *by default all the time.*

    For another you make all parts of the glyph the same, instead of just 
    the escape, such that they become hard to tell apart.

Yes, I think it makes more sense that way.  In \208, all four of the
characters are part of a single escape sequence.  I think it is better
to highlight them all the same way.

However, if lots of people prefer to highlight just the first
char, I won't insist.

    And you forgot sticky space and soft hyphen, which now again look 
    identical to their non-special counterparts.

I don't know what you're talking about, here.  This feature was
supposed to be for escape sequences, characters not actually in the
text.

     As for ellipses, there 
    should at least be a simple option.

I agree with the person who didn't want them highlighted.

    Alas they no 
    longer combine with other faces, such as selection, which is a giant 
    step backwards.

I do not understand.  What do you mean?

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

la 13.12.2004 20:51 Richard Stallman skribis:

>    I don't understand the point of having a mechanism, if it's not supposed 
>    to used.
>
>That is not what I said.  Using a display table is somewhat costly
>so I don't want to use it *by default all the time.*
>  
>
Well, ok, if the new way is cheaper.

>    For another you make all parts of the glyph the same, instead of just 
>    the escape, such that they become hard to tell apart.
>
>Yes, I think it makes more sense that way.  In \208, all four of the
>characters are part of a single escape sequence.  I think it is better
>to highlight them all the same way.
>  
>
I guess I can cope with the new behaviour (which was never that of the 
display table, however). But then you must rename the face once more.

>However, if lots of people prefer to highlight just the first
>char, I won't insist.
>  
>
Nevertheless I would prefer this ;-)

>    And you forgot sticky space and soft hyphen, which now again look 
>    identical to their non-special counterparts.
>
>I don't know what you're talking about, here.  This feature was
>supposed to be for escape sequences, characters not actually in the
>text.
>  
>
Display tables offered a convenient way to tell apart two very different 
kinds of spaces/hyphens. As DEL is ^?, I made these to be '\ ' and '\-' 
(make that '^ ' and '^-' if you prefer), to see at the first look that 
they are not space or hyphen. The leading escape would then have this face.

>     As for ellipses, there 
>    should at least be a simple option.
>
>I agree with the person who didn't want them highlighted.
>  
>
Including mine, there are already two votes for highlighting.

>    Alas they no 
>    longer combine with other faces, such as selection, which is a giant 
>    step backwards.
>
>I do not understand.  What do you mean?
>
Open a binary file, and apply some face (like mouse drag) to a region 
with intermittent special glyphs. Even though selection or bold do not 
collide with the default face you chose, only the normal characters get 
this face. That way it is impossible to see where the bounds of the 
selection are.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     For another you make all parts of the glyph the same, instead of just 
>     the escape, such that they become hard to tell apart.
>
> Yes, I think it makes more sense that way.  In \208, all four of the
> characters are part of a single escape sequence.  I think it is better
> to highlight them all the same way.

I think this looks better too -- but the current escape-glyph face doesn't
stand out very much -- what about "red" foreground instead?

>
> However, if lots of people prefer to highlight just the first
> char, I won't insist.

There seems to be a problem with ^X and \nnn if you have setup a
display table to show the ^ or \ -- in that case, the X and nnn is
still shown in the escape-glyph face (rather than the face from the
display property).

I will fix that.

>
>     And you forgot sticky space and soft hyphen, which now again look 
>     identical to their non-special counterparts.
>
> I don't know what you're talking about, here.  This feature was
> supposed to be for escape sequences, characters not actually in the
> text.

Indeed -- if someone whats to highlight anything else, they should
use a display vector.

>
>      As for ellipses, there 
>     should at least be a simple option.
>
> I agree with the person who didn't want them highlighted.

Actually, I liked the highlight for ellipses.   And to continue your
argument, the ellises are "characters not actually in the text" too.

>
>     Alas they no 
>     longer combine with other faces, such as selection, which is a giant 
>     step backwards.
>
> I do not understand.  What do you mean?

The escape-glyph face is not merged with the underlaying base face of
the character, so eg. region highlight (background color) or other
face properties are not shown on the escape glyphs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    I guess I can cope with the new behaviour (which was never that of the 
    display table, however). But then you must rename the face once more.

It applies to escape sequences, so I think the name fits.  I will see
if the doc string should be changed.

    Open a binary file, and apply some face (like mouse drag) to a region 
    with intermittent special glyphs. Even though selection or bold do not 
    collide with the default face you chose, only the normal characters get 
    this face. That way it is impossible to see where the bounds of the 
    selection are.

That sounds like a bug.  I am not sure I understand the current
display or face code enough to fix it, but I will try.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
> It applies to escape sequences, so I think the name fits.  I will see
> if the doc string should be changed.

It applies not only to escape sequences, but also to control characters.
So the name is too specific.  A better name should indicate the purpose
of the face, for instance, `warning' face.

storm@cua.dk (Kim F. Storm) writes:
> I think this looks better too -- but the current escape-glyph face
> doesn't stand out very much -- what about "red" foreground instead?

"red" is too strong color and usually used to highlight errors.
Better colors are "dark red" or even "OrangeRed3".

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Kim F. Storm]

Juri Linkov <juri@jurta.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>> It applies to escape sequences, so I think the name fits.  I will see
>> if the doc string should be changed.
>
> It applies not only to escape sequences, but also to control characters.
> So the name is too specific.  A better name should indicate the purpose
> of the face, for instance, `warning' face.

I think escape-glyph is ok.

There is nothing wrong with embedded control codes, so "warning" would
be worse.


>
> storm@cua.dk (Kim F. Storm) writes:
>> I think this looks better too -- but the current escape-glyph face
>> doesn't stand out very much -- what about "red" foreground instead?
>
> "red" is too strong color and usually used to highlight errors.
> Better colors are "dark red" or even "OrangeRed3".

I don't really care.

How does dark red look on a dark background -- I suggested red because
it works equally well in both cases.   If people don't like it, they
can customize the face...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Robert J. Chassell]

    I think escape-glyph is ok.

   There is nothing wrong with embedded control codes, so "warning"
   would be worse.

Yes.  Indeed, "warning" would be misleading.

In my .emacs file, I use an escape glyph, control-L, as a page
separator.  The command `C-x [' (backward-page) moves to a page
boundary.  This use of an escape is what you are supposed to do.

Also, I think of control-L as one character.  Not only is this a good
way of thinking, since it really is one character, but a command such
as `C-f' (forward-char) reliably acts on it as one character.  It
looked weird to me to highlight only the first part of the glyph.  It
was as if someone marked half of an `A'.  I felt I was living in a
world of bad, 1960s pop artists, the kinds of people who would write
`TECO!' and color the halves of each letter differently.

Moreover, with my background color, dodgerblue4, RMS' choice of
default foreground, cyan, is excellent.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    I think this looks better too -- but the current escape-glyph face doesn't
    stand out very much -- what about "red" foreground instead?

I think it should not stand out very much.

The aim isn't to help the user quickly find all the escape sequences,
merely to confirm that they are escape sequences.  For this purpose, a
font that is merely visible is ideal.  If it stands out, it tends to
be distracting.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I think this looks better too -- but the current escape-glyph face doesn't
>     stand out very much -- what about "red" foreground instead?
>
> I think it should not stand out very much.
>
> The aim isn't to help the user quickly find all the escape sequences,
> merely to confirm that they are escape sequences.  For this purpose, a
> font that is merely visible is ideal.  If it stands out, it tends to
> be distracting.

Ok.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

la 15.12.2004 17:14 Kim F. Storm skribis:

>Richard Stallman <rms@gnu.org> writes:
>  
>
>>    I think this looks better too -- but the current escape-glyph face doesn't
>>    stand out very much -- what about "red" foreground instead?
>>
>>I think it should not stand out very much.
>>
>>The aim isn't to help the user quickly find all the escape sequences,
>>merely to confirm that they are escape sequences.  For this purpose, a
>>font that is merely visible is ideal.  If it stands out, it tends to
>>be distracting.
>>    
>>
>Ok.
>
I hardly find the current choice visible. When I look hard, I can see 
two different colours, but at every individual spot, I can hardly tell, 
which of the two it is.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    Open a binary file, and apply some face (like mouse drag) to a region 
    with intermittent special glyphs. Even though selection or bold do not 
    collide with the default face you chose, only the normal characters get 
    this face. That way it is impossible to see where the bounds of the 
    selection are.

I see the problem.  It looks like the same problem happens with
display tables, too, using your old code.  Didn't this happen for you
with the old code?

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

la 17.12.2004 01:54 Richard Stallman skribis:

>    Open a binary file, and apply some face (like mouse drag) to a region 
>    with intermittent special glyphs. Even though selection or bold do not 
>    collide with the default face you chose, only the normal characters get 
>    this face. That way it is impossible to see where the bounds of the 
>    selection are.
>
>I see the problem.  It looks like the same problem happens with
>display tables, too, using your old code.  Didn't this happen for you
>with the old code?
>
I almost certain it didn't.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    >I see the problem.  It looks like the same problem happens with
    >display tables, too, using your old code.  Didn't this happen for you
    >with the old code?
    >
    I almost certain it didn't.

Could you try it again?

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Daniel Pfeiffer]

la 21.12.2004 12:21 Richard Stallman skribis:

>    >I see the problem.  It looks like the same problem happens with
>    >display tables, too, using your old code.  Didn't this happen for you
>    >with the old code?
>    >
>    I almost certain it didn't.
>  
>
Ok, this isn't quite true, as I could check meanwhile on a machine at 
work with an older version. The escape glyphs themselves didn't get a 
face other than the magic one. But they were only one out of two or four 
characters composing the glyph. The others took on any face. So we had 
the best of both worlds, very visible escapes, and fontified rest-of-glyph.

>Could you try it again?
>
I can't see that anything changed. When I load the Linux kernel and mark 
across it with the mouse, only the few normal characters get 
highlighted. Likewise when I do M-g b.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / lär dig / ucz się    Esperanto:
                              http://lernu.net/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

Richard Stallman <rms@gnu.org> writes:
>     I think this looks better too -- but the current escape-glyph face doesn't
>     stand out very much -- what about "red" foreground instead?
>
> I think it should not stand out very much.
>
> The aim isn't to help the user quickly find all the escape sequences,
> merely to confirm that they are escape sequences.  For this purpose, a
> font that is merely visible is ideal.  If it stands out, it tends to
> be distracting.

The current `blue' is one of the most unsuitable colors.  It stand out
very much.  Blue is mostly used for highlighting the important parts
of the buffer: in programming modes it highlights function names,
in Dired - file names.  Using it for escape sequences makes them
too distracting.

I highly recommend `dark red' for numerous reasons:

1. It does not stand out very much, but still differs from the black
color on light backgrounds.

2. ^L page separators in the source buffers will look like red comments,
but still can be distinguished from the red since it is darker.

3. In rose strings it does not stand out too, but it's visible that
dark red is not the same as rose.

4. The red color tells the user to turn attention to potentially
dangerous codes, but a darker shade makes it not too noticeable.

The same dark red color is also suitable for dark backgrounds.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Robert J. Chassell]

   The current `blue' is one of the most unsuitable colors.  It stand
   out very much.

As I said early, the default cyan for escape glyphs is wonderful for
me.

Please suggest values for each of the most likely various color formats
For example, 

    (custom-set-faces
     '(escape-glyph ((((class color) (background dark)) 
                      (:foreground "cyan"))))
     '(escape-glyph ((((class color) (background light)) 
                      (:foreground "dark red")))))

Or perhaps custom themes could be generated from `custom-set-faces'
expressions: one for green backgrounds, one for white backgrounds, one
for blue backgrounds, etc., in X, something else for an audio desktop,
and something else for the various consoles.  (In my .emacs file, I
set 98 different faces to various colors and heights.  Weights, other
than normal, don't work for me.)

By the way, how do you list the complete contents of a theme?  I could
not find mention in the Emacs manual, the Emacs Lisp Reference manual,
or with `help-for-help'.  I know about `C-h v' (describe-variable),
`list-colors-display', and `list-faces-display'.  (Normally, I look in
my .emacs file.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    The current `blue' is one of the most unsuitable colors.  It stand out
    very much.  Blue is mostly used for highlighting the important parts
    of the buffer: in programming modes it highlights function names,
    in Dired - file names.  Using it for escape sequences makes them
    too distracting.

    I highly recommend `dark red' for numerous reasons:

If people generally agree with you, I'll change it.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
>    The current `blue' is one of the most unsuitable colors.  It stand
>    out very much.
>
> As I said early, the default cyan for escape glyphs is wonderful for me.

Cyan stands out very much.  OTOH, I see that dark red is not good
for dark backgrounds either.  For dark backgrounds the most suitable
would be a light color with the value between the color values
of font-lock-comment-face and font-lock-string-face, which are
"chocolate1" and "LightSalmon", respectively.  And at the same
time it should be closer to white.

> Please suggest values for each of the most likely various color formats

I suggest "burlywood2", "sandy brown" or "tan1".

> For example, 
>
>     (custom-set-faces
>      '(escape-glyph ((((class color) (background dark)) 
>                       (:foreground "cyan"))))
>      '(escape-glyph ((((class color) (background light)) 
>                       (:foreground "dark red")))))

You can type M-C-x on the following forms in emacs-lisp mode
with evaluated (put 'escape-glyph 'saved-face nil) before that:

(defface escape-glyph '((((background dark)) :foreground "burlywood2")
			(((type pc)) :foreground "magenta")
			(t :foreground "dark green"))
  "Face for characters displayed as ^-sequences or \\-sequences."
  :group 'basic-faces)

(defface escape-glyph '((((background dark)) :foreground "sandy brown")
			(((type pc)) :foreground "magenta")
			(t :foreground "dark red"))
  "Face for characters displayed as ^-sequences or \\-sequences."
  :group 'basic-faces)

(defface escape-glyph '((((background dark)) :foreground "tan1")
			(((type pc)) :foreground "magenta")
			(t :foreground "dark red"))
  "Face for characters displayed as ^-sequences or \\-sequences."
  :group 'basic-faces)

> Or perhaps custom themes could be generated from `custom-set-faces'
> expressions: one for green backgrounds, one for white backgrounds, one
> for blue backgrounds, etc., in X, something else for an audio desktop,
> and something else for the various consoles.

That's an interesting idea.  Do you suggest face conditions like this:

    (((background "green")) :foreground "yellow")

> (In my .emacs file, I set 98 different faces to various colors and
> heights.  Weights, other than normal, don't work for me.)

Different weights don't work for me too, but I reset all them in
with a function in a custom face define hook.

(defun my-faces-set (&optional frame)
  (interactive)
  ;; Check if this function is called by `custom-define-hook' from
  ;; `custom-declare-face' where the variable `face' is bound locally.
  (if (boundp 'face)
      (mapc (lambda (face)
              (when (face-italic-p face frame)
                (if (equal (face-foreground face frame) "black")
                    (set-face-foreground face "gray50" frame)))
              (when (face-bold-p face frame)
                (set-face-bold-p face nil frame)
                (set-face-underline-p face t frame))
              (when (numberp (face-attribute face :height frame))
                (set-face-attribute face frame :height 'unspecified))
              (when (numberp (face-attribute face :width frame))
                (set-face-attribute face frame :width 'unspecified))
              (when (numberp (face-attribute face :weight frame))
                (set-face-attribute face frame :weight 'unspecified)))
            (face-list))))

(add-to-list 'custom-define-hook 'my-faces-set)

> By the way, how do you list the complete contents of a theme?  I could
> not find mention in the Emacs manual, the Emacs Lisp Reference manual,
> or with `help-for-help'.  I know about `C-h v' (describe-variable),
> `list-colors-display', and `list-faces-display'.  (Normally, I look in
> my .emacs file.)

There is a good package at http://www.emacswiki.org/cgi-bin/wiki/ColorTheme
color-theme.el which has the command `color-theme-print' to print the
current color theme as a Lisp function.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 26 Dec 2004 21:42:36 +0200
> Cc: emacs-devel@gnu.org
> 
> (defface escape-glyph '((((background dark)) :foreground "burlywood2")
> 			(((type pc)) :foreground "magenta")
> 			(t :foreground "dark green"))
>   "Face for characters displayed as ^-sequences or \\-sequences."
>   :group 'basic-faces)

Please don't use `(type pc)' in face definitions; we now have the
min-colors feature to express the same color selection in a more
device-independent way (e.g., it will also be right for a 16-color
xterm).

Also, I think "magenta" is a bad color choice for 16-color terminals,
as its definition in tty-colors.el will produce a color that is very
different from "burlywood2".  How about "brown" or "yellow" instead?

The 8-color terminals will also need a separate definition (yellow?):
"burlywood2" translates there to "green", believe it or not.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> Please don't use `(type pc)' in face definitions; we now have the
> min-colors feature to express the same color selection in a more
> device-independent way (e.g., it will also be right for a 16-color
> xterm).

OK.  But then `minibuffer-prompt' face whose definition was copied to
`escape-glyph' should be fixed too:

diff -u -w -b -r1.297 faces.el
-(defface minibuffer-prompt '((((background dark)) :foreground "cyan")
-			     (((type pc)) :foreground "magenta")
-			     (t :foreground "dark blue"))
+(defface minibuffer-prompt
+  '((((class color) (min-colors 88) (background light))
+     :foreground "dark blue")
+    (((class color) (min-colors 8) (background light))
+     :foreground "blue")
+    (((class color) (min-colors 8) (background dark))
+     :foreground "cyan"))
   "Face for minibuffer prompts."
   :version "21.4"
   :group 'basic-faces)

There will be no default, because it's not necessary to highlight
minibuffer prompts (in inverse-video or with other non-color
properties) on non-color displays.  And cyan for dark backgrounds
exists even on 8-color terminals.
 
> Also, I think "magenta" is a bad color choice for 16-color terminals,
> as its definition in tty-colors.el will produce a color that is very
> different from "burlywood2".  How about "brown" or "yellow" instead?
>
> The 8-color terminals will also need a separate definition (yellow?):
> "burlywood2" translates there to "green", believe it or not.

The idea was to make escape-glyph to look like comments because most
frequent control character ^L in the source files will look like
comments (it is also similar to comments syntaxically, since it is
skipped by the reader together with comments).  So a better choice
for the color of escape-glyph on 8-color terminals would be red,
regardless of background mode:

diff -u -w -b -r1.297 faces.el
-(defface escape-glyph '((((background dark)) :foreground "cyan")
-			(((type pc)) :foreground "magenta")
-			(t :foreground "blue"))
-  "Face for characters displayed as ^-sequences or \-sequences."
+(defface escape-glyph
+  '((((class color) (min-colors 88) (background light))
+     :foreground "dark red")
+    (((class color) (min-colors 88) (background dark))
+     :foreground "tan1")
+    (((class color) (min-colors 8))
+     :foreground "red"))
+  "Face for characters displayed as ^-sequences or \\-sequences."
   :group 'basic-faces)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Eli Zaretskii]

> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Mon, 27 Dec 2004 21:53:43 +0200
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> > Please don't use `(type pc)' in face definitions; we now have the
> > min-colors feature to express the same color selection in a more
> > device-independent way (e.g., it will also be right for a 16-color
> > xterm).
> 
> OK.  But then `minibuffer-prompt' face whose definition was copied to
> `escape-glyph' should be fixed too:

No, the minibuffer-prompt face is one of the few cases where the
literal `pc' is deliberate.  It so happens that many users of the
MS-DOS port use blue as their default foreground color.

Sorry for not mentioning such exceptions in my original message.

> The idea was to make escape-glyph to look like comments

I'm not sure that was a good idea, since comments normally have a face
that makes them stand out.  I thought that several people complained
about ^L being too glaring.  But I didn't follow the discussion
closely, so perhaps I missed the reason for selecting such a color for
escape-glyph.

> +(defface escape-glyph
> +  '((((class color) (min-colors 88) (background light))
> +     :foreground "dark red")
> +    (((class color) (min-colors 88) (background dark))
> +     :foreground "tan1")
> +    (((class color) (min-colors 8))
> +     :foreground "red"))
> +  "Face for characters displayed as ^-sequences or \\-sequences."
>    :group 'basic-faces)

This is okay with me, assuming that the consensus is indeed to have
escape-glyph stand out in color.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Stefan Monnier]

> No, the minibuffer-prompt face is one of the few cases where the
> literal `pc' is deliberate.  It so happens that many users of the
> MS-DOS port use blue as their default foreground color.

> Sorry for not mentioning such exceptions in my original message.

Such mention would be better in the source code than in an email message.


        Stefan

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> No, the minibuffer-prompt face is one of the few cases where the
> literal `pc' is deliberate.  It so happens that many users of the
> MS-DOS port use blue as their default foreground color.

Aha.  But then a condition like ((class color) (background "blue"))
would be mode appropriate.  Not for this release, though.

>> The idea was to make escape-glyph to look like comments
>
> I'm not sure that was a good idea, since comments normally have a face
> that makes them stand out.  I thought that several people complained
> about ^L being too glaring.

For light background color "dark red" does not stand out.  The color
for dark background for (min-colors 88) perhaps does not stand out too
(if bright colors which don't stand out are possible at all).

But there is no color for 8-color terminals which does not stand out.
Thus, there is red for (min-colors 8).  Another choice would be
not to highlight escape sequences 8-color terminals.

>> +(defface escape-glyph
>> +  '((((class color) (min-colors 88) (background light))
>> +     :foreground "dark red")
>> +    (((class color) (min-colors 88) (background dark))
>> +     :foreground "tan1")
>> +    (((class color) (min-colors 8))
>> +     :foreground "red"))
>> +  "Face for characters displayed as ^-sequences or \\-sequences."
>>    :group 'basic-faces)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Tue, 28 Dec 2004 04:38:14 +0200
> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> > No, the minibuffer-prompt face is one of the few cases where the
> > literal `pc' is deliberate.  It so happens that many users of the
> > MS-DOS port use blue as their default foreground color.
> 
> Aha.  But then a condition like ((class color) (background "blue"))
> would be mode appropriate.

Maybe it would, but: (a) `(background SOMETHING)' looks at the
`background-mode' frame parameter, not at the background color; and
(b) I was talking about foreground color, not background.  If your
default face foreground is blue, having the minibuffer-prompt in blue
will defeat the reason for the minibuffer-prompt face.

> But there is no color for 8-color terminals which does not stand out.

I think blue and green do not stand out on 8-color terminals as much
as the red color.

Also note that the way you defined the face, 16-color terminals will
also use red, although there are some more colors there that do not
stand out.  In fact, any terminal with fewer than 88 colors will use
red.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    I'm not sure that was a good idea, since comments normally have a face
    that makes them stand out.  I thought that several people complained
    about ^L being too glaring.

Yes, we do not want this font to call too much attention to itself.
It should be just different enough from the usual color that you can
easily tell the difference.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> > No, the minibuffer-prompt face is one of the few cases where the
>> > literal `pc' is deliberate.  It so happens that many users of the
>> > MS-DOS port use blue as their default foreground color.
>> 
>> Aha.  But then a condition like ((class color) (background "blue"))
>> would be mode appropriate.
>
> Maybe it would, but: (a) `(background SOMETHING)' looks at the
> `background-mode' frame parameter, not at the background color;

That was the idea for a new feature that if the argument of
`(background SOMETHING)' is a string it would look at the
background color.

> (b) I was talking about foreground color, not background.

Ah, I misread foreground as background, because I remember those
blue DOS screens.  It seems DOS users don't like blue screens nowadays.

>> But there is no color for 8-color terminals which does not stand out.
>
> I think blue and green do not stand out on 8-color terminals as much
> as the red color.

Blue and green are no less noticeable than red.

> Also note that the way you defined the face, 16-color terminals will
> also use red, although there are some more colors there that do not
> stand out.  In fact, any terminal with fewer than 88 colors will use
> red.

There are no too much colors among 16 colors to select from.
Brightred is even worse than red.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    > No, the minibuffer-prompt face is one of the few cases where the
    > literal `pc' is deliberate.  It so happens that many users of the
    > MS-DOS port use blue as their default foreground color.

    > Sorry for not mentioning such exceptions in my original message.

    Such mention would be better in the source code than in an email message.

Yes.  Eli, could you add a comment about this?

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Eli Zaretskii]

> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
> From: Juri Linkov <juri@jurta.org>
> Date: Tue, 28 Dec 2004 09:52:19 +0200
> 
> >> But there is no color for 8-color terminals which does not stand out.
> >
> > I think blue and green do not stand out on 8-color terminals as much
> > as the red color.
> 
> Blue and green are no less noticeable than red.

They are noticable, but less annoying.

> > Also note that the way you defined the face, 16-color terminals will
> > also use red, although there are some more colors there that do not
> > stand out.  In fact, any terminal with fewer than 88 colors will use
> > red.
> 
> There are no too much colors among 16 colors to select from.
> Brightred is even worse than red.

I was thinking about brown or lightblue, not the reddish ones.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
>> > I think blue and green do not stand out on 8-color terminals as much
>> > as the red color.
>> 
>> Blue and green are no less noticeable than red.
>
> They are noticable, but less annoying.

If you say that red is more annoying, then I agree.  And I don't like
that comments are highlighted in red.  But when ^L will be highlighted
in red too, then it will be less noticeable since it will look like comment.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Wed, 29 Dec 2004 02:22:57 +0200
> Cc: bob@rattlesnake.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> >> > I think blue and green do not stand out on 8-color terminals as much
> >> > as the red color.
> >> 
> >> Blue and green are no less noticeable than red.
> >
> > They are noticable, but less annoying.
> 
> If you say that red is more annoying, then I agree.  And I don't like
> that comments are highlighted in red.  But when ^L will be highlighted
> in red too, then it will be less noticeable since it will look like comment.

We've made a full circle: I already said that comments _should_ stick
out, since they've been fontified in reddish color since day one.  By
contrast, people do not want ^L to stand out like comments do.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Juri Linkov]

"Eli Zaretskii" <eliz@gnu.org> writes:
> By contrast, people do not want ^L to stand out like comments do.

Do people want ^L highlighted at all?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Alex Schroeder]

Juri Linkov <juri@jurta.org> writes:

> "Eli Zaretskii" <eliz@gnu.org> writes:
>> By contrast, people do not want ^L to stand out like comments do.
>
> Do people want ^L highlighted at all?

I would like there to be something telling me the difference between
the two ASCII characters ^L and the corresponding control character.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

RE: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Drew Adams]

    >> By contrast, people do not want ^L to stand out like comments do.

    > Do people want ^L highlighted at all?

    I would like there to be something telling me the difference between
    the two ASCII characters ^L and the corresponding control character.

In some text buffers, it might be appropriate to have ^L displayed as, say,
a horizontal line (dotted or otherwise) to indicate a page boundary - as in
some word processors. Such a disply option should be just that: an option,
in any case.

In other kinds of buffers, where ^L does not signify a page boundary, such a
display option would not be appropriate.

Re: [Emacs-trunk-diffs] Changes to emacs/lisp/faces.el

[Richard Stallman]

    Do people want ^L highlighted at all?

^L is a control character.  If control characters in general are
highlighted in some way, it doesn't seem to make sense to make an
exception only for ^L.