non-break-space in tutorial

non-break-space in tutorial

[Stefan Monnier]

In a French locale, C-h T shows the French tutorial which includes some NBSP
chars which are rendered as "\ " as in "m\ emacs\ <Entrée>".  The \ are
clearly undesirable here.


        Stefan

Re: non-break-space in tutorial

[Juri Linkov]

> In a French locale, C-h T shows the French tutorial which includes
> some NBSP chars which are rendered as "\ " as in "m\ emacs\ <Entrée>".
> The \ are clearly undesirable here.

This could be fixed by adding `show-nonbreak-escape: nil' to tutorial's
file local variables.  But I think that adding escape characters
before non-breaking spaces and hyphens is undesirable everywhere,
even in files where some indication for non-breaking space is desirable.
Interspersing the text with backslash characters sometimes makes the
text almost unreadable.  Also this changes relative positions of text
characters and the total line lengths, thus breaking text formatting
and truncating right-aligned lines when they become too long after
adding \'s on display.

A better indication for non-breaking spaces and hyphens is the same
as for whitespace highlighting enabled with show-trailing-whitespace,
i.e. displaying non-breaking spaces and hyphens in a special face
with a non-default background color without adding \.

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

Re: non-break-space in tutorial

[Paul Pogonyshev]

Juri Linkov wrote:
> > In a French locale, C-h T shows the French tutorial which includes
> > some NBSP chars which are rendered as "\ " as in "m\ emacs\ <Entrée>".
> > The \ are clearly undesirable here.
>
> [...]
>
> A better indication for non-breaking spaces and hyphens is the same
> as for whitespace highlighting enabled with show-trailing-whitespace,
> i.e. displaying non-breaking spaces and hyphens in a special face
> with a non-default background color without adding \.

This is exactly what I did in my Wikipedia mode before escaping was
added to Emacs.  And I'm too unsatisfied with escaping, so after it
appeared, I made `show-nonbreak-escape' locally set to nil in all my
buffers and kept the custom highlighting.

I think `show-nonbreak-escape' should be nil by default.  However,
this has been discussed already and RMS will probably not be willing
to change it.

Paul

Re: non-break-space in tutorial

[Richard Stallman]

    A better indication for non-breaking spaces and hyphens is the same
    as for whitespace highlighting enabled with show-trailing-whitespace,
    i.e. displaying non-breaking spaces and hyphens in a special face
    with a non-default background color without adding \.

Would you like to write a patch do this, so people can try it and see
if they like it better?

Re: non-break-space in tutorial

[Juri Linkov]

>     A better indication for non-breaking spaces and hyphens is the same
>     as for whitespace highlighting enabled with show-trailing-whitespace,
>     i.e. displaying non-breaking spaces and hyphens in a special face
>     with a non-default background color without adding \.
>
> Would you like to write a patch do this, so people can try it and see
> if they like it better?

The patch below eliminates the backslash before non-breaking spaces
and hyphens.  Without the backslash non-breaking spaces need to be
highlighted by background instead of foreground, so foreground colors
were changed to background colors with values not standing out too
much on the default background.  The same face with backgroung color
affects also displaying control characters, for good reason, since
they share the same goal of highlighting dangerous characters.

The user option `show-nonbreak-escape' can be renamed to `show-nonbreak-space'
(by analogy with `show-trailing-whitespace') or removed at all.  Users who
dislike highlighting of control characters and non-breaking space can set
the face to the void value.

Index: src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1014
diff -u -r1.1014 xdisp.c
--- src/xdisp.c	27 May 2005 16:59:55 -0000	1.1014
+++ src/xdisp.c	29 May 2005 15:18:14 -0000
@@ -5165,10 +5165,9 @@
 	      if (it->c == 0x8a0 || it->c == 0x8ad
 		  || it->c == 0xf20 || it->c == 0xf2d)
 		{
-		  XSETINT (it->ctl_chars[0], escape_glyph);
 		  g = it->c;
-		  XSETINT (it->ctl_chars[1], g);
-		  ctl_len = 2;
+		  XSETINT (it->ctl_chars[0], g);
+		  ctl_len = 1;
 		  goto display_control;
 		}
 
Index: lisp/faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.309
diff -u -r1.309 faces.el
--- lisp/faces.el	23 May 2005 18:30:20 -0000	1.309
+++ lisp/faces.el	29 May 2005 15:18:55 -0000
@@ -2079,11 +2079,11 @@
   :group 'whitespace		; like `show-trailing-whitespace'
   :group 'basic-faces)
 
-(defface escape-glyph '((((background dark)) :foreground "cyan")
+(defface escape-glyph '((((background dark)) :background "rosybrown4")
 			;; See the comment in minibuffer-prompt for
 			;; the reason not to use blue on MS-DOS.
-			(((type pc)) :foreground "magenta")
-			(t :foreground "blue"))
+			(((type pc)) :background "magenta")
+			(t :background "rosybrown1"))
   "Face for characters displayed as ^-sequences or \-sequences."
   :group 'basic-faces)
 \f

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

Re: non-break-space in tutorial

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 29 May 2005 19:08:48 +0300
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> -(defface escape-glyph '((((background dark)) :foreground "cyan")
> +(defface escape-glyph '((((background dark)) :background "rosybrown4")
>  			;; See the comment in minibuffer-prompt for
>  			;; the reason not to use blue on MS-DOS.
> -			(((type pc)) :foreground "magenta")
> -			(t :foreground "blue"))
> +			(((type pc)) :background "magenta")
> +			(t :background "rosybrown1"))

You've changed all the colors except the ones for (type pc).  I think
it doesn't make sense to use the same color for background as we did
for foreground.

Re: non-break-space in tutorial

[Juri Linkov]

>> -(defface escape-glyph '((((background dark)) :foreground "cyan")
>> +(defface escape-glyph '((((background dark)) :background "rosybrown4")
>>  			;; See the comment in minibuffer-prompt for
>>  			;; the reason not to use blue on MS-DOS.
>> -			(((type pc)) :foreground "magenta")
>> -			(t :foreground "blue"))
>> +			(((type pc)) :background "magenta")
>> +			(t :background "rosybrown1"))
>
> You've changed all the colors except the ones for (type pc).  I think
> it doesn't make sense to use the same color for background as we did
> for foreground.

I can't find a better color among other 8 values for (type pc) than magenta.
Maybe this is not a bad choice.

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

Re: non-break-space in tutorial

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 30 May 2005 11:48:34 +0300
> 
> I can't find a better color among other 8 values for (type pc) than magenta.
> Maybe this is not a bad choice.

I think it's a bad choice because the default foreground color is
barely visible against magenta background.

I suggest brown or yellow as the background for the escape-glyph face
on (type pc) displays.

Re: non-break-space in tutorial

[Richard Stallman]

I tried the patch you wrote, and I think that using a background to
highlight NBSP looks somewhat loud.  The foreground color on backslash
is much less loud.

However, if users prefer this way, I won't object.

Re: non-break-space in tutorial

[Miles Bader]

On 5/31/05, Richard Stallman <rms@gnu.org> wrote:
> I tried the patch you wrote, and I think that using a background to
> highlight NBSP looks somewhat loud.  The foreground color on backslash
> is much less loud.
> 
> However, if users prefer this way, I won't object.

I suppose it's a matter of taste; I rather like the old behavior, and
think Juri's solution is much worse (I tried his patch).  Having
spaces with only a background color different looks more like a
display glitch than anything else, and I think escaped spaces are a
much more intuitive representation for a typical Emacs user.

Regardless, the `escape-glyph' face should not be changed to
accomodate this special case, as the new colors are awful for the
majority of escape sequences which don't need a background color
change.  _If_ it's decided to treat NBSP specially in this manner,
then it should have its own new face, and `escape-glyph' should be
left alone.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I tried the patch you wrote, and I think that using a background to
> highlight NBSP looks somewhat loud.  The foreground color on backslash
> is much less loud.
>
> However, if users prefer this way, I won't object.

Maybe we could add an extra slot to the display table for "non break space".
Then people could have it anyway they like.

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

Re: non-break-space in tutorial

[Richard Stallman]

    Maybe we could add an extra slot to the display table for "non break space".
    Then people could have it anyway they like.

Others have suggested that some major modes should highlight NBSP
while others should not.  The convenient way to implement that would
be with a variable, not with a slot in the display table.

Re: non-break-space in tutorial

[Juri Linkov]

With all opinions taken into account I installed a patch, so all
people can try it.

A new special face was added for highlighting non-breaking spaces.
By default, it uses the underline attribute.  Underline appropriately
represents the meaning of non-breaking space in a similar way as
underscore character is used in some programming language identifiers,
and it is less annoying than an additional backslash.  The color of
underline is not loud but still distinguishable from the default
foreground color.  I believe this is a good solution.

After a testing period (say, 1 week) I could remove the variable
`show-non-break'.  There seems to be no need for this variable since
highlighting can be disabled by inheriting `no-break-space' face
from the default face.

PS: I also changed NBSP with space in remaining tutorial files.
This shows that accidentally typed NBSP is quite a common case.

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

Re: non-break-space in tutorial

[Stefan Monnier]

> After a testing period (say, 1 week) I could remove the variable
> `show-non-break'.  There seems to be no need for this variable since
> highlighting can be disabled by inheriting `no-break-space' face
> from the default face.

When displaying text where NBSP are a completely normal occurrence
(e.g. email), there should be no special highlighting whatsoever, but
inheriting from the default face won't do that because it removes the
hilighting globally (also, inheriting from default is probably not what you
want to do, instead you want to set all fields to nil).

I.e. as long as we don't have buffer-local face-specs show-non-break
is necessary.

> PS: I also changed NBSP with space in remaining tutorial files.
> This shows that accidentally typed NBSP is quite a common case.

AFAICT, the NBSP in the French tutorial were not accidental.


        Stefan


PS: Hopefully you've replaced the uses of show-nonbreak-escape with uses of
show-non-break.

Re: non-break-space in tutorial

[Miles Bader]

On 6/6/05, Juri Linkov <juri@jurta.org> wrote:
> After a testing period (say, 1 week) I could remove the variable
> `show-non-break'.  There seems to be no need for this variable since
> highlighting can be disabled by inheriting `no-break-space' face
> from the default face.

No.  This is wrong for several reasons

1) Faces are global, but it's extremely desirable to disable special
treatment of NBSP (etc) on a per-buffer basis.  So we can't get rid of
`show-nonbreak-escape'.

2) The original treatment of NBSP -- displaying it like a normal
escape character, with backslash prefix and in the normal escape
character face -- is IMO better than your method, so _at the least_ it
should be user selectable, but it seems that your patch makes this
impossible.  [And I personally think it should be the default.]

3) Your patch treats "soft hyphens" in the same way as NBSP, and I'm
not sure this is desirable; it at least seems worthy of discussion.

Furthermore, we're supposed to be in some sort of pre-release state,
so please don't just install changes you _know_ to be controversial
without at least mentioning what you're going to do on the mailing
list first

BTW, something funny I noticed while testing, though I'm not sure
whether it is caused by your patch or not, is that when displaying on
a tty with `terminal-coding-system' set to nil, both NBSP and
soft-hyphen are show as "?".  Since most fonts simply display these
character in the same way as their non-special brothers, wouldn't be
good for emacs to do the translation itself so that they show up ok on
simple ascii terminals?

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Juri Linkov]

> 1) Faces are global, but it's extremely desirable to disable special
> treatment of NBSP (etc) on a per-buffer basis.  So we can't get rid of
> `show-nonbreak-escape'.

I've already thought about the need to retain `show-nonbreak-escape'.
That is why I used the renamed variable name in my previous mail.
So with the lack of support for buffer-local faces and with changed
treatment of `show-nonbreak-escape' we should rename this variable
to something like `show-no-break-space'.

> 2) The original treatment of NBSP -- displaying it like a normal
> escape character, with backslash prefix and in the normal escape
> character face -- is IMO better than your method, so _at the least_ it
> should be user selectable, but it seems that your patch makes this
> impossible.  [And I personally think it should be the default.]

I've seen various texts with a lot of non-breaking spaces.
Additional backslashes render such texts almost unreadable.
Since we can't predict in which context and modes users might
encounter non-breaking spaces, we should make their default
highlighting as least annoying as possible.

> 3) Your patch treats "soft hyphens" in the same way as NBSP, and I'm
> not sure this is desirable; it at least seems worthy of discussion.

It treats soft hyphens as NBSP only in regard of not adding a escape
character.  Their faces are different: soft hyphens are displayed in
`escape-glyph', but NBSP in `no-break-space'.  I think from the user's
POV this should be fine.  I'm still not sure about the need for a
separate user option (e.g. `show-soft-hyphen') for configuring the
display of soft hypens.

> BTW, something funny I noticed while testing, though I'm not sure
> whether it is caused by your patch or not, is that when displaying on
> a tty with `terminal-coding-system' set to nil, both NBSP and
> soft-hyphen are show as "?".  Since most fonts simply display these
> character in the same way as their non-special brothers, wouldn't be
> good for emacs to do the translation itself so that they show up ok on
> simple ascii terminals?

It is caused by the 2005-03-24 change in xdisp.c:

 		{
 		  XSETINT (it->ctl_chars[0], escape_glyph);
-		  g = it->c == 0x8ad ? '-' : ' ';
+		  g = it->c;
 		  XSETINT (it->ctl_chars[1], g);
 		  ctl_len = 2;
 		  goto display_control;

which now doesn't replace the NBSP by an SPC.  Maybe this line should
be restored for ascii terminals?

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

Re: non-break-space in tutorial

[Daniel Brockman]

Juri Linkov <juri@jurta.org> writes:

> So with the lack of support for buffer-local faces and with 
> changed treatment of `show-nonbreak-escape' we should rename 
> this variable to something like `show-no-break-space'.

You might as well make it `show-non-breaking-spaces' if you're 
going to rename it anyway.  The current name is ugly, and I think 
the name you're proposing is unnecessarily confusing.  It makes 
you wonder what the ``break space'' is.

[...]

> Since we can't predict in which context and modes users might 
> encounter non-breaking spaces, we should make their default 
> highlighting as least annoying as possible.

I read that as a typo for ``at least as annoying as possible.'' 
:-)
But now that I think about it, ``as little annoying as possible'' 
sounds slightly awkward too.  What is the correct way to say it?
                                   
-- 
Daniel Brockman <daniel@brockman.se>

Re: non-break-space in tutorial

[Juri Linkov]

>> So with the lack of support for buffer-local faces and with changed
>> treatment of `show-nonbreak-escape' we should rename this variable
>> to something like `show-no-break-space'.
>
> You might as well make it `show-non-breaking-spaces' if you're 
> going to rename it anyway.  The current name is ugly, and I think 
> the name you're proposing is unnecessarily confusing.  It makes 
> you wonder what the ``break space'' is.

According to the official Unicode Character Database the name of NBSP
is NO-BREAK SPACE, and its _old_ name is NON-BREAKING SPACE.

IMO we should use the new Unicode character name in variable names,
possibly with omitting the hyphen inside the `no-break' word.
Is `show-nobreak-space' is clearer than `show-no-break-space'?

>> Since we can't predict in which context and modes users might
>> encounter non-breaking spaces, we should make their default
>> highlighting as least annoying as possible.
>
> I read that as a typo for ``at least as annoying as possible.'' 
> :-)
> But now that I think about it, ``as little annoying as possible'' 
> sounds slightly awkward too.  What is the correct way to say it?

Maybe ``as unannoying as possible'' :-)

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

Re: non-break-space in tutorial

[Henrik Enberg]

Juri Linkov <juri@jurta.org> writes:

>> I read that as a typo for ``at least as annoying as possible.'' 
>> :-)
>> But now that I think about it, ``as little annoying as possible'' 
>> sounds slightly awkward too.  What is the correct way to say it?
>
> Maybe ``as unannoying as possible'' :-)

»as unobtrusive as possible«

Re: non-break-space in tutorial

[Miles Bader]

On 6/8/05, Juri Linkov <juri@jurta.org> wrote:
> > 2) The original treatment of NBSP -- displaying it like a normal
> > escape character, with backslash prefix and in the normal escape
> > character face -- is IMO better than your method, so _at the least_ it
> > should be user selectable, but it seems that your patch makes this
> > impossible.  [And I personally think it should be the default.]
> 
> I've seen various texts with a lot of non-breaking spaces.
> Additional backslashes render such texts almost unreadable.

This is your _opinion_, which I disagree with.  I think dIsplaying
them with a modified background, if anything, looks worse, and is more
confusing to users than making them look like an "escape character",
which is already a familiar concept.

In your post, you said you had "taken everybody's opinion into
account", which is clearly not true.  Despite the initial objections
to your proposed changes, you simply went ahead and made them anyway.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Gaëtan LEURENT]

Miles Bader wrote on 08 Jun 2005 00:31:20 +0200:

> This is your _opinion_, which I disagree with.  I think dIsplaying
> them with a modified background, if anything, looks worse, and is more
> confusing to users than making them look like an "escape character",
> which is already a familiar concept.

As far as I'm concerned, I like to have the NBSP highlighted in some
way, but having them prefixed by some character is really annoying when
you want to cut and paste from a xterm, and it sometimes make lines
being more than 80 characters. So I guess underlining them is a
good option (I haven't tried the patch, though).

-- 
Gaëtan LEURENT

Re: non-break-space in tutorial

[Miles Bader]

On 6/8/05, Gaëtan LEURENT <gaetan.leurent@ens.fr> wrote:
> As far as I'm concerned, I like to have the NBSP highlighted in some
> way, but having them prefixed by some character is really annoying when
> you want to cut and paste from a xterm, and it sometimes make lines
> being more than 80 characters. So I guess underlining them is a
> good option (I haven't tried the patch, though).

It should be possible to have both representations, but Luc's patch
tosses out one.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Luc Teirlinck]

Miles Bader wrote:

   It should be possible to have both representations, but Luc's patch
   tosses out one.

I have not followed this thread.  Which patch are you talking about?

Sincerely,

Luc.

Re: non-break-space in tutorial

[Miles Bader]

On 6/8/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>    It should be possible to have both representations, but Luc's patch
>    tosses out one.
> 
> I have not followed this thread.  Which patch are you talking about?

Sorry, my mistake; it was Juri's patch.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Gaëtan LEURENT]

By the way, having NBSP and soft-hyphen escaped breaks alignment in the
character table in M-x describe-input-method latin-1-prefix (and surely
some others)

-- 
Gaëtan LEURENT

Re: non-break-space in tutorial

[Juri Linkov]

> By the way, having NBSP and soft-hyphen escaped breaks alignment in the
> character table in M-x describe-input-method latin-1-prefix (and surely
> some others)

This is not the worst example.  It breaks alignment on any formatted text
using NBSP extensively.  Such texts are not rare, and users may encounter
them in many unexpected places.

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

Re: non-break-space in tutorial

[Juri Linkov]

> This is your _opinion_, which I disagree with.  I think dIsplaying
> them with a modified background, if anything, looks worse, and is more
            =====================
> confusing to users than making them look like an "escape character",
> which is already a familiar concept.
>
> In your post, you said you had "taken everybody's opinion into
> account", which is clearly not true.  Despite the initial objections
> to your proposed changes, you simply went ahead and made them anyway.

Perhaps, you missed something.  It was your opinion about
unsuitability of a modified background that I've taken into account
before I started to think about a different solution.  I fully
agree with you that a modified background is a bad solution.
That's why I installed for people to try a completely different
patch which I think is much better than anything proposed so far.
A new solution puts the underline attribute on non-breaking spaces.
This appropriately reflects the purpose of non-breaking spaces
("gluing" words together) and is not as annoying as anything else.

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

Re: non-break-space in tutorial

[Miles Bader]

On 6/8/05, Juri Linkov <juri@jurta.org> wrote:
> Perhaps, you missed something.  It was your opinion about
> unsuitability of a modified background that I've taken into account
> before I started to think about a different solution.  I fully
> agree with you that a modified background is a bad solution.
> That's why I installed for people to try a completely different
> patch which I think is much better than anything proposed so far.
> A new solution puts the underline attribute on non-breaking spaces.
> This appropriately reflects the purpose of non-breaking spaces
> ("gluing" words together) and is not as annoying as anything else.

Then you mis-interpreted the objections to your original proposal. 
The strength of the old display method is that it uses a familiar
notation (backslash escape and common escape highlighting) to show
that NBSP/soft-hyphen are "funny" characters, rather than adding yet
another ad-hoc notation.

Now, you may dislike this representation, but the fact that you think
your preferred solution "is better than anything proposed so far"
doesn't make that some kind of undisputed fact.  [Clearly, because I'm
here disputing it.]

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Juri Linkov]

> The strength of the old display method is that it uses a familiar
> notation (backslash escape and common escape highlighting) to show
> that NBSP/soft-hyphen are "funny" characters, rather than adding yet
> another ad-hoc notation.

The new display method uses no less familiar notation.  The underlined
space looks very like the underscore character used in programming
languages to represent a space between inseparable words inside identifiers.

> Now, you may dislike this representation, but the fact that you think
> your preferred solution "is better than anything proposed so far"
> doesn't make that some kind of undisputed fact.  [Clearly, because I'm
> here disputing it.]

I never claimed it to be undisputed fact.  On the contrary, in the
mail I sent after installing the patch I asked all people to try the
new highlighting for some time period with the intention to hear all
opinions about it afterwards.

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

Re: non-break-space in tutorial

[Miles Bader]

On 6/8/05, Juri Linkov <juri@jurta.org> wrote:
> The new display method uses no less familiar notation.  The underlined
> space looks very like the underscore character used in programming
> languages to represent a space between inseparable words inside identifiers.

Huh?  Such a representation is hardly "familiar" as a way of
representing funny characters in Emacs.  It may not be unreasonable
once it's explained, but that's not what I'm disputing.

> I never claimed it to be undisputed fact.  On the contrary, in the
> mail I sent after installing the patch I asked all people to try the
> new highlighting for some time period with the intention to hear all
> opinions about it afterwards.

The standard method for dealing with potentially controversial changes
is to suggest a change, and solicit feedback until a reasonable
concensus is reached, or the maintainer makes a decision.  This is
annoying, I know, but there's a reason for it:  if everyone just
installed their disputed patches "for people to try out", there would
be chaos, something which we especially want to avoid at the moment. 
Changes once made have a way of sticking around even if they were
originally deemed temporary.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Kim F. Storm]

I'm sure there is no single way to please everybody:

(setq show-nobreak-space 'escape) => the Miles way
(setq show-nobreak-space t)       => the Juri way


Here is a generic approach (similar to using a display table,
but without the overhead):

(setq show-nobreak-space STRING)  => show STRING for NBSP.

Value of STRING can cover both Miles and Juri style:

(propertize "\\ " 'face 'escape) => the Miles way
(propertize " " 'face 'underline) => the Juri way

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

Re: non-break-space in tutorial

[Miles Bader]

I'd like chocolate on mine...

-Miles

-- 
Do not taunt Happy Fun Ball.

Re: non-break-space in tutorial

[Stefan Monnier]

> I'm sure there is no single way to please everybody:

> (setq show-nobreak-space 'escape) => the Miles way
> (setq show-nobreak-space t)       => the Juri way

The display-table allows you to do just that, even more flexibly.

> Here is a generic approach (similar to using a display table,
> but without the overhead):

What overhead?  Just for the record, could all you people check the value of
`standard-display-table' in your current Emacs session?  My bet is that most
of you have it non-nil already.

> (setq show-nobreak-space STRING)  => show STRING for NBSP.

> Value of STRING can cover both Miles and Juri style:

> (propertize "\\ " 'face 'escape) => the Miles way
> (propertize " " 'face 'underline) => the Juri way

There's still the problem that we currently only handle latin-1 NBSP but not
latin-2 NBSP, latin-3 NBSP, ...


        Stefan

Re: non-break-space in tutorial

[Juri Linkov]

> The display-table allows you to do just that, even more flexibly.
>
>> Here is a generic approach (similar to using a display table,
>> but without the overhead):
>
> What overhead?  Just for the record, could all you people check the value of
> `standard-display-table' in your current Emacs session?  My bet is that most
> of you have it non-nil already.

I don't know the reasons for not using the display table by default
neither what overhead it causes, but among other benefits using the
standard display table would be more user-friendly.  Currently users
unaware about the new faces for NBSP and escape characters have
difficulties in finding ways to configure them.  With display tables
and the patch below it will be possible to find used faces by typing
C-u C-x = directly on NBSP and escape characters.  It will display
a clickable button with the face name leading to the face configuration,
e.g.:

  The display table entry is displayed by these fonts (glyph codes):
   : -Misc-Fixed-Medium-R-Normal--10-100-75-75-C-60-ISO8859-1 (0x20)
   face: [escape-glyph]

Index: lisp/descr-text.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/descr-text.el,v
retrieving revision 1.35
diff -u -r1.35 descr-text.el
--- lisp/descr-text.el	26 May 2005 12:41:52 -0000	1.35
+++ lisp/descr-text.el	8 Jun 2005 19:16:48 -0000
@@ -619,7 +625,21 @@
 			      (format "%s (0x%02X)" (cadr (aref disp-vector i))
 				      (cddr (aref disp-vector i)))
 			    "-- no font --")
-			  "\n ")))
+			  "\n")
+		  (when (> (car (aref disp-vector i)) #x7ffff)
+		    (let* ((face-id (lsh (car (aref disp-vector i)) -19))
+			   (face (car (delq nil (mapcar (lambda (face)
+							  (and (eq (face-id face)
+								   face-id) face))
+							(face-list))))))
+		      (when face
+			(insert (propertize " " 'display '(space :align-to 5))
+				"face: ")
+			(widget-create
+			 'link
+			 :notify `(lambda (&rest ignore) (describe-face ',face))
+			 (format "%S" face))
+			(insert "\n"))))))
 	    (insert "these terminal codes:\n")
 	    (dotimes (i (length disp-vector))
 	      (insert (car (aref disp-vector i))

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

Re: non-break-space in tutorial

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Here is a generic approach (similar to using a display table,
>> but without the overhead):
>
> What overhead?  Just for the record, could all you people check the value of
> `standard-display-table' in your current Emacs session?  My bet is that most
> of you have it non-nil already.

It is non-nil here, indeed, but...

the whole mess with the C-level escape glyph support code was because RMS
rejected the original approach that used the display table...

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

Re: non-break-space in tutorial

[Stefan Monnier]

>> What overhead?  Just for the record, could all you people check the value of
>> `standard-display-table' in your current Emacs session?  My bet is that most
>> of you have it non-nil already.

> It is non-nil here, indeed, but...

> the whole mess with the C-level escape glyph support code was because RMS
> rejected the original approach that used the display table...

I know that, but I think it's based on the mistaken idea that the display
table is always nil by default, whereas it's been non-nil for many
(probably most) users at least since Emacs-21, AFAIK.  So any overhead it
may introduce has been incurred without complaint.


        Stefan

Re: non-break-space in tutorial

[Richard Stallman]

    What overhead?  Just for the record, could all you people check the value of
    `standard-display-table' in your current Emacs session?  My bet is that most
    of you have it non-nil already.

It is nil in my Emacs.

Re: non-break-space in tutorial

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What overhead?  Just for the record, could all you people check
>     the value of `standard-display-table' in your current Emacs
>     session?  My bet is that most of you have it non-nil already.
>
> It is nil in my Emacs.

non-nil here, even with emacs -Q.

This is
GNU Emacs 22.0.50.7 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2005-06-03 on lola

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: non-break-space in tutorial

[Juanma Barranquero]

> non-nil here, even with emacs -Q.

Non-nil on Windows (both MinGW and MSVC).

-- 
                    /L/e/k/t/u

Re: non-break-space in tutorial

[Richard Stallman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 203 bytes --]

    In a French locale, C-h T shows the French tutorial which includes some NBSP
    chars which are rendered as "\ " as in "m\ emacs\ <Entrée>".  The \ are
    clearly undesirable here.

I fixed these.