make-glyph-code incompatibility

make-glyph-code incompatibility

[Stefan Monnier]

The new make-glyph-code is a good change, but it introduces
an incompatibility.  It seems that it makes previously working code
fail silently.  Can we make it fail with an informative message?


        Stefan

Re: make-glyph-code incompatibility

[Kim F. Storm]

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

> The new make-glyph-code is a good change, but it introduces
> an incompatibility.  It seems that it makes previously working code
> fail silently.  Can we make it fail with an informative message?

The new encoding still merges a face id and char code into
an integer if the face id is < 64.  So an integer value may
still carry a face id in the upper bits.

Of course, I could make it always use a cons cell for non-default face.
Then we could check (and warn) if an integer value is >= 1^22, but
even if we do that, it can fail:

For example, how do you differentiate

    1 << 19 + ?a    (emacs 22 glyph code for 'a' in mode-line face)

and the unicode character with the same numeric value in emacs 23 ?

Also, issuing warnings during redisplay is a mess!


We introduced make-glyph-code in 22.1 in preparation for the unicode
merge in 23.1 - to give people time to adjust their code.

Perhaps emacs 23 NEWS file should repeat the description of make-glyph-code
from NEWS.22 - this time saying it is the only way to do it:


Maybe write something like (incompatible lisp changes):

** The functions `make-glyph-code', `glyph-char', and `glyph-face'
must be used to create and decode glyph codes in display tables.

The old method of creating a display table element by combining a face
number and a character code into a numeric glyph code is no longer
supported; using it may cause arbitrary characters and faces to be
displayed.

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

Re: make-glyph-code incompatibility

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 04 Mar 2008 01:08:22 +0100
> Cc: emacs-devel@gnu.org
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > The new make-glyph-code is a good change, but it introduces
> > an incompatibility.  It seems that it makes previously working code
> > fail silently.  Can we make it fail with an informative message?
> 
> For example, how do you differentiate
> 
>     1 << 19 + ?a    (emacs 22 glyph code for 'a' in mode-line face)
> 
> and the unicode character with the same numeric value in emacs 23 ?
> 
> Also, issuing warnings during redisplay is a mess!

Yes.  But you could make the new code use different symbols, and make
old symbols be unbound.  That would cause error messages early enough.

Re: make-glyph-code incompatibility

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes.  But you could make the new code use different symbols, and make
> old symbols be unbound.  That would cause error messages early enough.

What symbols?  The display table slots?  

That would break more code - including code properly written to use
make-glyph-code in emacs 22...

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

Re: make-glyph-code incompatibility

[Stefan Monnier]

>> The new make-glyph-code is a good change, but it introduces
>> an incompatibility.  It seems that it makes previously working code
>> fail silently.  Can we make it fail with an informative message?

> The new encoding still merges a face id and char code into
> an integer if the face id is < 64.  So an integer value may
> still carry a face id in the upper bits.

Is it worth the trouble?

> Of course, I could make it always use a cons cell for
> non-default face.

I thought that's what we did.  It would seem preferable because simpler.

> Then we could check (and warn) if an integer value is >= 1^22, but
> even if we do that, it can fail:

> For example, how do you differentiate

>     1 << 19 + ?a    (emacs 22 glyph code for 'a' in mode-line face)

> and the unicode character with the same numeric value in emacs 23 ?

Yes, it's a limitation to our ability to detect the problem.

> Also, issuing warnings during redisplay is a mess!

I was thinking maybe we could display such invalid glyphs as a string
"invalid-glyph".

But I definitely do not want to expand a lot of effort into
this checking.  I just figured that maybe there's a cheap way to detect
the problem and make the failure easier to diagnose (compared to "my
vertical tab line doesn't show any more" which is harder to debug
unless we know that the vertical tab line is using glyphs).


        Stefan

Re: make-glyph-code incompatibility

[Kim F. Storm]

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

>>> The new make-glyph-code is a good change, but it introduces
>>> an incompatibility.  It seems that it makes previously working code
>>> fail silently.  Can we make it fail with an informative message?
>
>> The new encoding still merges a face id and char code into
>> an integer if the face id is < 64.  So an integer value may
>> still carry a face id in the upper bits.
>
> Is it worth the trouble?

Maybe not, but it's already done...
And the code overhead is neglible.

> I was thinking maybe we could display such invalid glyphs as a string
> "invalid-glyph".

Wouldn't fit nicely in the vertical bar or as "truncation marker"...

> But I definitely do not want to expand a lot of effort into
> this checking.  I just figured that maybe there's a cheap way to detect
> the problem and make the failure easier to diagnose (compared to "my
> vertical tab line doesn't show any more" which is harder to debug
> unless we know that the vertical tab line is using glyphs).

I think a notice in NEWS is sufficient...

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

Re: make-glyph-code incompatibility

[Eli Zaretskii]

> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> From: storm@cua.dk (Kim F. Storm)
> Date: Tue, 04 Mar 2008 10:58:19 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Yes.  But you could make the new code use different symbols, and make
> > old symbols be unbound.  That would cause error messages early enough.
> 
> What symbols?  The display table slots?  

No, I meant make-glyph-code and other related functions/variables.
Sorry for being unclear.

> That would break more code - including code properly written to use
> make-glyph-code in emacs 22...

IMO, it's better to break code clearly and loudly than do that subtly
and silently.  This is an incompatible change; if we cannot make it
backwards compatible, let's not sweep the incompatibility under the
carpet.

Re: make-glyph-code incompatibility

[Stefan Monnier]

>> Eli Zaretskii <eliz@gnu.org> writes:
>> > Yes.  But you could make the new code use different symbols, and make
>> > old symbols be unbound.  That would cause error messages early enough.
>> 
>> What symbols?  The display table slots?  

> No, I meant make-glyph-code and other related functions/variables.
> Sorry for being unclear.

I still don't understand: the problem is with code that does *not* use
make-glyph-code and builds the code "by hand" with operations such as
lsh and +.


        Stefan

Re: make-glyph-code incompatibility

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> > Yes.  But you could make the new code use different symbols, and make
>> > old symbols be unbound.  That would cause error messages early enough.
>> 
>> What symbols?  The display table slots?  
>
> No, I meant make-glyph-code and other related functions/variables.
> Sorry for being unclear.

Code using those should still work, it's code _not_ using them that's
the problem...

-Miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: make-glyph-code incompatibility

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: storm@cua.dk (Kim F. Storm), emacs-devel@gnu.org
> Date: Tue, 04 Mar 2008 17:35:10 -0500
> 
> > No, I meant make-glyph-code and other related functions/variables.
> > Sorry for being unclear.
> 
> I still don't understand: the problem is with code that does *not* use
> make-glyph-code and builds the code "by hand" with operations such as
> lsh and +.

Then I misunderstood the whole issue, and you should ignore me.

Sorry.