> non-nil here, even with emacs -Q.
Non-nil on Windows (both MinGW and MSVC).
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
Richard Stallman <[EMAIL PROTECTED]> 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 wi
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.
___
Emacs-devel mailing list
Em
> 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 m
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
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailma
>> 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 b
Stefan Monnier <[EMAIL PROTECTED]> 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
> 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 sess
> 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
I'd like chocolate on mine...
-Miles
--
Do not taunt Happy Fun Ball.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
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 fo
On 6/8/05, Juri Linkov <[EMAIL PROTECTED]> 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
Juri Linkov <[EMAIL PROTECTED]> 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'' :-)
> 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 und
>> 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
On 6/8/05, Juri Linkov <[EMAIL PROTECTED]> 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 s
On 6/8/05, Luc Teirlinck <[EMAIL PROTECTED]> 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 Bal
> 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 p
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.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http:/
On 6/8/05, Gaëtan LEURENT <[EMAIL PROTECTED]> 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
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 conce
On 6/8/05, Juri Linkov <[EMAIL PROTECTED]> 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 i
Juri Linkov <[EMAIL PROTECTED]> 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 rena
> 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 previou
On 6/6/05, Juri Linkov <[EMAIL PROTECTED]> 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
> 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
(
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 c
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 slo
Richard Stallman <[EMAIL PROTECTED]> 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
On 5/31/05, Richard Stallman <[EMAIL PROTECTED]> 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 matte
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.
___
Emacs-devel mailing list
Emacs-devel@gn
> From: Juri Linkov <[EMAIL PROTECTED]>
> 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 vis
>> -(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.
>> -
> From: Juri Linkov <[EMAIL PROTECTED]>
> Date: Sun, 29 May 2005 19:08:48 +0300
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> -(defface escape-glyph 'background dark)) :foreground "cyan")
> +(defface escape-glyph 'background dark)) :background "rosybrown4")
> ;; Se
> 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 lik
In a French locale, C-h T shows the French tutorial which includes some NBSP
chars which are rendered as "\ " as in "m\ emacs\ ". The \ are
clearly undesirable here.
I fixed these.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://li
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
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\ ".
> > The \ are clearly undesirable here.
>
> [...]
>
> A better indication for non-breaking spaces and hyphens is the same
> as for whitespace
> In a French locale, C-h T shows the French tutorial which includes
> some NBSP chars which are rendered as "\ " as in "m\ emacs\ ".
> 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
39 matches
Mail list logo
