Re: [wl@gnu.org: changing line heights]

Re: [wl@gnu.org: changing line heights]

[Werner LEMBERG]

Answering Gerd:

> > Emacs reports that both characters are from the same font.  On
> > emacs-devel someone thinks that the problem is caused by this
> > change:
> >
> >  * international/mule-cmds.el
> >    (standard-display-european-internal): Don't use char code for
> >    Latin-1 NBSP.  <XFree86 4>: Unfrob NBSP display table.  Set
> >    display table to use U+2018, U+2019 for `'.
> >    (select-safe-coding-system): Message fix.
> >
> > I tend to agree since only ` and ' are affected.
>
> Yes, that sounds quite likely.  You could check with
>
>   (setq standard-display-table (make-display-table))

Indeed, this restores the correct behaviour!  So is it a bug?


    Werner

Re: [wl@gnu.org: changing line heights]

[Jason Rumney]

Werner LEMBERG wrote:

>>> * international/mule-cmds.el
>>>   (standard-display-european-internal): ... Set
>>>   display table to use U+2018, U+2019 for `'.

This seems like an individual preference.  It should be left as a user 
customization, not the default behaviour.  Users expect to get ASCII 
characters when they type ASCII I think. And this could lose if the user 
does not have a Unicode font (I guess that is why this is conditional on 
XFree86-4, but someone might delete fonts they don't think they need to 
save disk space).

Re: [wl@gnu.org: changing line heights]

[Gerd Moellmann]

Werner LEMBERG <wl@gnu.org> writes:

> >   (setq standard-display-table (make-display-table))
> 
> Indeed, this restores the correct behaviour!  So is it a bug?

In some sense yes, I think.

 -- Does C-u C-x = show the font being used for characters with a
    display-table entry?  It doesn't look like it does.

 -- Should there be entries for `' in standard-display-table?  If yes,
    should lisp-mode maybe override such an entry so that backquote is
    easier to distinguish from quote?  Or some variation of this.

Re: [wl@gnu.org: changing line heights]

[Werner LEMBERG]

> > >   (setq standard-display-table (make-display-table))
> > 
> > Indeed, this restores the correct behaviour!  So is it a bug?
> 
> In some sense yes, I think.
> 
>  -- Does C-u C-x = show the font being used for characters with a
>     display-table entry?  It doesn't look like it does.

No, Emacs says that the glyphs come from the same font which is not
correct.  IMHO this *must not* happen.


    Werner

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    > >  * international/mule-cmds.el
    > >    (standard-display-european-internal): Don't use char code for
    > >    Latin-1 NBSP.  <XFree86 4>: Unfrob NBSP display table.  Set
    > >    display table to use U+2018, U+2019 for `'.
    > >    (select-safe-coding-system): Message fix.
    > >
    > > I tend to agree since only ` and ' are affected.
    >
    > Yes, that sounds quite likely.  You could check with
    >
    >   (setq standard-display-table (make-display-table))

    Indeed, this restores the correct behaviour!  So is it a bug?

There is a bug, perhaps, but taking out that change is not a very good
fix.  That would make ` and ' look too similar (or so it is said).

How can we fix the one bug without causing another?

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    >>> * international/mule-cmds.el
    >>>   (standard-display-european-internal): ... Set
    >>>   display table to use U+2018, U+2019 for `'.

    This seems like an individual preference.  It should be left as a user 
    customization, not the default behaviour.  Users expect to get ASCII 
    characters when they type ASCII I think.

This code affects only how these characters display; it does not
change what you "get" in the buffer when you type ASCII characters.

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

     -- Does C-u C-x = show the font being used for characters with a
	display-table entry?  It doesn't look like it does.

That would be a good feature.

     -- Should there be entries for `' in standard-display-table?  If yes,
	should lisp-mode maybe override such an entry so that backquote is
	easier to distinguish from quote?  Or some variation of this.

I think there is a confusion here.
There is no need for Lisp mode to override these entries
so that backquote is easier to distinguish, because the purpose
of these entries is specifically to make it easier to distinguish.

Re: [wl@gnu.org: changing line heights]

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

>     >>> * international/mule-cmds.el
>     >>>   (standard-display-european-internal): ... Set
>     >>>   display table to use U+2018, U+2019 for `'.
> 
>     This seems like an individual preference.  It should be left as a user 
>     customization, not the default behaviour.  Users expect to get ASCII 
>     characters when they type ASCII I think.
> 
> This code affects only how these characters display; it does not
> change what you "get" in the buffer when you type ASCII characters.

What I meant then, is that users expect to *see* ASCII characters when
they type ASCII.

Re: [wl@gnu.org: changing line heights]

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> There is a bug, perhaps, but taking out that change is not a very good
> fix.  That would make ` and ' look too similar (or so it is said).

I find the opposite. U+2018 and U+2019 look very similar, while ` and
' are noticeably different. From memory, the original change was
proposed for aesthetic reasons because a lot of documentation uses `
and ' as quotation marks, and the original characters are so
different that they look strange in that context to someone used to
double ' or the Unicode quote characters.

Re: [wl@gnu.org: changing line heights]

[Miles Bader]

On Thu, Sep 25, 2003 at 07:21:42PM -0400, Richard Stallman wrote:
> I think there is a confusion here.
> There is no need for Lisp mode to override these entries
> so that backquote is easier to distinguish, because the purpose
> of these entries is specifically to make it easier to distinguish.

I find this isn't true -- with the fonts I use, the `replacement' quotes
installed by this code are _harder_ to distinguish than the defaults.

I think the reason is that the unicode quote characters used as replacments
are the traditional `inverted comma' and `raised comma' glyphs, which at
small point-sizes on a bitmapped display are very hard to distinguish from
one another (there aren't so many pixels available to make the `bulb' of the
glyph noticably bigger than the `tip').

The default ' and ` characters in the XFree86 4.x fonts I looked at*, by
contrast, _are_ fairly easy to distinguish in my font -- the single-quote is
a vertical line, and the back-single-quote is a sharply slanted line.  The
shapes used might be considered ugly when used in the context of english text
because they are not symmetrical, but I thing it's more important that they
be easy to distinguish, as it's very important for programming (e.g., in the
shell).

* I looked at both courier and lucidatypewriter, from the XFree86 4.2.1
  distribution (in the debian package xfonts-100dpi), and my comments above
  seem to hold for both.

My other questions is, why is this part of `standard-display-european'?
Not only is that function documented as `semi deprecated,' but I don't see
how this change is related to that to it, as it involves normal ASCII
characters, not `european' ones.

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: [wl@gnu.org: changing line heights]

[James Clark]

> The default ' and ` characters in the XFree86 4.x fonts I looked at*, by
> contrast, _are_ fairly easy to distinguish in my font -- the single-quote is
> a vertical line, and the back-single-quote is a sharply slanted line.  The
> shapes used might be considered ugly when used in the context of english text
> because they are not symmetrical, but I thing it's more important that they
> be easy to distinguish, as it's very important for programming (e.g., in the
> shell).

There's an excellent discussion of this whole quote problem by Markus 
Kuhn at:

   http://www.cl.cam.ac.uk/~mgk25/ucs/quotes.html

The problem here is that there's a clash between

- Unicode
- established GNU documentation practice

Unicode says that the characters 0x60 and 0x27 are a grave accent and a 
vertical quote, not an open and close quotation mark.  The XFree86 fonts 
are doing the right thing.  However, GNU documentation (info and doc 
strings) use them as open and close quotation marks.  It seems to me 
that the right solution is by default to map 0x60/0x27 to the Unicode 
quotation marks only in buffers displaying documentation (help and 
info); users should also be able to enable this mapping on a per-buffer
basis and globally.

James

Re: [wl@gnu.org: changing line heights]

[Miles Bader]

James Clark <jjc@jclark.com> writes:
> It seems to me that the right solution is by default to map 0x60/0x27
> to the Unicode quotation marks only in buffers displaying
> documentation (help and info); users should also be able to enable
> this mapping on a per-buffer basis and globally.

That seems like a better solution to me.  There could be a
`display-matching-single-quotes' function that various modes could call
to make sure things were setup appropriately for natural-language text
(and it could even be made to work on other platforms if desirable).

I'm still confused by the connection with `standard-display-european'
though...

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: [wl@gnu.org: changing line heights]

[Werner LEMBERG]

> > The default ' and ` characters in the XFree86 4.x fonts I looked
> > at*, by contrast, _are_ fairly easy to distinguish in my font --

Since I use the ETL fonts at a 24x12 resolution, this is true for me
also -- the ` and ' glyphs are *designed* to be used as left and right
quotes.

> Unicode says that the characters 0x60 and 0x27 are a grave accent
> and a vertical quote, not an open and close quotation mark.  The
> XFree86 fonts are doing the right thing.

The ETL fonts aren't XFree86 fonts...

> However, GNU documentation (info and doc strings) use them as open
> and close quotation marks.  It seems to me that the right solution
> is by default to map 0x60/0x27 to the Unicode quotation marks only
> in buffers displaying documentation (help and info); users should
> also be able to enable this mapping on a per-buffer basis and
> globally.

I agree.  Whatever solution is found, there should be an indication
for `C-u C-x =' that those characters (probably) come from a different
font.  Additionally, it should be possible to exactly specify which
font is used for those two characters.


    Werner

Re: [wl@gnu.org: changing line heights]

[James Clark]

> Since I use the ETL fonts at a 24x12 resolution, this is true for me
> also -- the ` and ' glyphs are *designed* to be used as left and right
> quotes.
...
> Additionally, it should be possible to exactly specify which
> font is used for those two characters.

I wonder whether we should divide the problem into two parts:

- One part is whether in a particular buffer 0x60/0x27 should be 
displayed so that they look like grave/vertical quote or like open/close 
quote.  This is determined by mode and individual user preference; this 
problem is specific to quotes.

- One part is whether the glyphs at index 0x60/0x27 in a particular font 
display as grave/vertical quote or like open/close quote.  This has 
nothing to do with user preference or mode. Emacs could be configured so 
that it knows about common free fonts. This part seems like it would be 
best tackled in a general way by allowing per-font control over 
character to glyph index mapping (or is there some way to do this in 
Emacs do this already?).

James

Re: [wl@gnu.org: changing line heights]

[Jason Rumney]

James Clark <jjc@jclark.com> writes:

> It seems to me that the right solution is by default to map
> 0x60/0x27 to the Unicode quotation marks only in buffers displaying
> documentation (help and info)

I initially thought this too, then it occured to me that there are a
lot of lisp examples in the documentation, so the mapping could cause
confusion.

Re: [wl@gnu.org: changing line heights]

[James H.Cloos Jr.]

>>>>> "James" == James Clark <jjc@jclark.com> writes:

James> It seems to me that the right solution is by default to
James> map 0x60/0x27 to the Unicode quotation marks only in
James> buffers displaying documentation (help and info);

GNU documentation is not the only user of `' for ‘’ and
``'' for “”, that is also the way TeX specifies quotes.
And apostrophes.

Not to mention their use in source code.

James> users should also be able to enable this mapping
James> on a per-buffer basis and globally.

As Miles wrote, some fonts make the glyphs hard to distinguish.
A few years ago I used to use 75dpi/lutRS08.bdf for xterms and
emacs.  (Really. :)  There is no where there to tell apart the
open and close glyphs.  OTOH, I now use misc/9x18.bdf and that
makes the glyphs easy to distinguish.  It is important to give
the users a single defcustom that the default behavior depends
on, as well as per mode and per buffer controls.

-JimC

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    > This code affects only how these characters display; it does not
    > change what you "get" in the buffer when you type ASCII characters.

    What I meant then, is that users expect to *see* ASCII characters when
    they type ASCII.

It shows them ASCII characters with or without this particular
feature.  The question is what is the best way to display them.

Re: [wl@gnu.org: changing line heights]

[Kenichi Handa]

In article <86r8259ooh.fsf@gerd.free-bsd.org>, gerd.moellmann@t-online.de (Gerd Moellmann) writes:
> Werner LEMBERG <wl@gnu.org> writes:
>>  >   (setq standard-display-table (make-display-table))
>>  
>>  Indeed, this restores the correct behaviour!  So is it a bug?

> In some sense yes, I think.

>  -- Does C-u C-x = show the font being used for characters with a
>     display-table entry?  It doesn't look like it does.

No.  I'm now working on improving it.  Please wait for a while.

>  -- Should there be entries for `' in standard-display-table?  If yes,
>     should lisp-mode maybe override such an entry so that backquote is
>     easier to distinguish from quote?  Or some variation of this.

I think `' should not be displayed by U+2018 and U+2019.
Unicode defines them not as balanced quotes.  Using them as
balanced quotes is abuse of characters as far as we follow
Unicode.

Considering the long standing convention, I don't suggest to
stop this abuse.  But, at least, we should not disturb
people who use those characters correctly in the sense of
Unicode by displaying them with characters of different
semantics.

---
Ken'ichi HANDA
handa@m17n.org

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    I'm still confused by the connection with `standard-display-european'
    though...

There isn't really any connection.  standard-display-european-internal
is called in various cases, not just when standard-display-european is
used.

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    I wonder whether we should divide the problem into two parts:

    - One part is whether in a particular buffer 0x60/0x27 should be 
    displayed so that they look like grave/vertical quote or like open/close 
    quote.  This is determined by mode and individual user preference; this 
    problem is specific to quotes.

This seems like a clean approach, assuming we need to offer more than one
way to do it.  But it would be better to find one way that satisfies
all the problems.

It looks like the problem is that the appearances for 0x27 and 0x60
don't look right for open and close quote, but the others that look
right for open/close quote are at the same time too similar to each
other.  Is that correct?

If so, is there a way that avoids both problems?

What about displaying 0x60 as accent grave, and 0x27 as close quote?
They would not "match" in style, but they would be better as
open quote and close quote than the standard font images for
0x60 and 0x27.  Meanwhile, they would not look similar either.

    - One part is whether the glyphs at index 0x60/0x27 in a particular font 
    display as grave/vertical quote or like open/close quote.  This has 
    nothing to do with user preference or mode. Emacs could be configured so 
    that it knows about common free fonts. This part seems like it would be 
    best tackled in a general way by allowing per-font control over 
    character to glyph index mapping (or is there some way to do this in 
    Emacs do this already?).

If we need to offer multiple options, this is a good way to make them
default more correctly.  At the same time, it might be a substantial
amount of work just to enter and maintain data about lots of fonts.

Re: [wl@gnu.org: changing line heights]

[Werner LEMBERG]

> It looks like the problem is that the appearances for 0x27 and 0x60
> don't look right for open and close quote, but the others that look
> right for open/close quote are at the same time too similar to each
> other.  Is that correct?

Not really.  It depends on the used fonts.  `Classical' fonts like the
ETL bitmap fonts which provide only glyphs for ISO 8859 characters
normally don't have U+2018/U+2019 at all -- the exception is
greek-iso8859-7, but this is broken currently (see my other mail).
For such fonts, the ` and ' characters are almost exclusively used for
left and right quotes -- there is hardly a need to have a stand-alone
version of the grave accent.  [I know this is hard to avoid on
e.g. German keyboards which use dead-keys to create accented
characters.]

In case someone wants to use U+2018 and U+2019 instead of 0x27 and
0x60, there must be a possibility to select the font.  In my case, I
would select the ETL iso-8859-7 fonts for *some* modes, not for all.

> If we need to offer multiple options, this is a good way to make
> them default more correctly.  At the same time, it might be a
               ^^^^^^^^^^^^^^
[Can't resist: Either something is correct, or it isn't -- what does
 `more correctly' then mean? :-)]

> substantial amount of work just to enter and maintain data about
> lots of fonts.

I think this is unavoidable.  IMHO you shouldn't combine glyphs from
different fonts without asking the user.  Perhaps some standard fonts
can be covered in a table, but in general this won't work.

A suggestion: If the user types `C-u C-x =' while being on a left or
right quote, a string like

  This glyph is probably taken from another font and thus looks ugly!
  Please use `M-x configure-quotation-glyphs' to set up replacement
  glyphs for the left and right quotation characters.

could appear in the pop-up window.


    Werner

Re: [wl@gnu.org: changing line heights]

[Kai Grossjohann]

James Clark <jjc@jclark.com> writes:

> - One part is whether in a particular buffer 0x60/0x27 should be
> displayed so that they look like grave/vertical quote or like
> open/close quote.  This is determined by mode and individual user
> preference; this problem is specific to quotes.

Maybe it is also an idea to display them thingies as open/close quote
only in cases where we know they are meant that way.  One example is
in docstrings.  There is highlighting in docstrings (and a hyperlink
in *Help* buffers) that kicks in for cases where the characters are
used as open/close quote.

Maybe it is strange that the same character is displayed differently
in different locations of the same file/buffer, but OTOH, font-lock is
all about doing this.  It normally just changes the color or weight,
but why can't it also change the glyph if that seems to be a good
idea?

WDYT?
-- 
Two cafe au lait please, but without milk.

Re: [wl@gnu.org: changing line heights]

[Richard Stallman]

    > If we need to offer multiple options, this is a good way to make
    > them default more correctly.  At the same time, it might be a
		   ^^^^^^^^^^^^^^
    [Can't resist: Either something is correct, or it isn't -- what does
     `more correctly' then mean? :-)]

When you're talking about selecting a function to decide what to do in
various cases, changing the function could make it correct in more
cases or fewer cases.  That is more or less correct.  In this case
there is no perfection.

Re: [wl@gnu.org: changing line heights]

[Kenichi Handa]

In article <200309270215.LAA26333@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:
>>   -- Does C-u C-x = show the font being used for characters with a
>>      display-table entry?  It doesn't look like it does.

> No.  I'm now working on improving it.  Please wait for a while.

I've just commited a change for C-u C-x =.  Now, if a
display table is used for a character, a proper information
should be shown.

---
Ken'ichi HANDA
handa@m17n.org