bug#14574: prog-prettify-symbols breaks font-locking

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

Package: emacs
Version: 24.3.50

With simple test file test.el having:
(defun test () "This is a test.")

emacs -Q --eval "(setq-default prog-prettify-symbols nil)" test.el    ; correct
emacs -Q --eval "(setq-default prog-prettify-symbols t)" test.el  ; incorrect

[-- Attachment #2: correct.png --]
[-- Type: image/png, Size: 1071 bytes --]

[-- Attachment #3: incorrect.png --]
[-- Type: image/png, Size: 1018 bytes --]

bug#14574: prog-prettify-symbols breaks font-locking

[Glenn Morris]

Fixed.

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Tue, 11 Jun 2013 14:01:18 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Fixed.

Thanks to you and Stefan for looking into this.

Was this a problem for emacs-lisp-mode only or is it general (so I
should fix perl-mode and cfengine3-mode)?  I don't see highlighting
issues there but perhaps I simply have missed them.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Glenn Morris]

Ted Zlatanov wrote:

> Was this a problem for emacs-lisp-mode only or is it general (so I
> should fix perl-mode and cfengine3-mode)? 

Only emacs-lisp-mode AFAICS.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 3986 bytes --]

On Tue, Jun 11, 2013 at 11:03 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Thanks to you and Stefan for looking into this.

I'm seeing another problem with prog-prettify-symbols, but I haven't
filed yet a new bug because for now I can only reproduce it with my
setup.

Sometimes `lambda' gets correctly prettified, and sometimes no (see
attached image).


This is the char info for the correctly prettified lambda:

             position: 55719 of 81109 (69%), column: 11
            character: l (displayed as l) (codepoint 108, #o154, #x6c)
    preferred charset: iso-8859-15 (ISO/IEC 8859/15)
code point in charset: 0x6C
               script: latin
               syntax: w which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x6C
            file code: #x6C (encoded by coding system iso-latin-9-unix)
              display: composed to form "lambda" (see below)

Composed with the following character(s) "ambda" by the rule:
(?λ)
The component character(s) are displayed by these fonts (glyph codes):
 λ: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x301)
See the variable `reference-point-alist' for the meaning of the rule.

Character code properties: customize what to show
  name: LATIN SMALL LETTER L
  general-category: Ll (Letter, Lowercase)
  canonical-combining-class: 0 (Spacing, split, enclosing, reordrant,
and Tibetan subjoined)
  bidi-class: L (Left-to-Right)
  decomposition: (108) ('l')
  mirrored: N
  uppercase: 76 (L)
  titlecase: 76 (L)

There are text properties here:
  charset              iso-8859-15
  composition          [Show]
  face                 font-lock-keyword-face
  fontified            t


and this is the info for the incorrect one:

             position: 55396 of 81109 (68%), column: 11
            character: l (displayed as l) (codepoint 108, #o154, #x6c)
    preferred charset: iso-8859-15 (ISO/IEC 8859/15)
code point in charset: 0x6C
               script: latin
               syntax: w which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x6C
            file code: #x6C (encoded by coding system iso-latin-9-unix)
              display: composed to form "lambda" (see below)

Composed with the following character(s) "ambda" by the rule:
(?l ?a ?m ?b ?d ?a)
The component character(s) are displayed by these fonts (glyph codes):
 l: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x4F)
 a: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
 m: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x50)
 b: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x45)
 d: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x47)
 a: uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
See the variable `reference-point-alist' for the meaning of the rule.

Character code properties: customize what to show
  name: LATIN SMALL LETTER L
  general-category: Ll (Letter, Lowercase)
  canonical-combining-class: 0 (Spacing, split, enclosing, reordrant,
and Tibetan subjoined)
  bidi-class: L (Left-to-Right)
  decomposition: (108) ('l')
  mirrored: N
  uppercase: 76 (L)
  titlecase: 76 (L)

There are text properties here:
  charset              iso-8859-15
  composition          [Show]
  face                 font-lock-keyword-face
  fontified            t


Adding a char before it or otherwise modifying the line makes the
lambda be correctly prettified again. Weird.

[-- Attachment #2: bug.png --]
[-- Type: image/png, Size: 6127 bytes --]

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Tue, 11 Jun 2013 23:29:49 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> I'm seeing another problem with prog-prettify-symbols, but I haven't
JB> filed yet a new bug because for now I can only reproduce it with my
JB> setup.

JB> Sometimes `lambda' gets correctly prettified, and sometimes no (see
JB> attached image).
...
JB> Composed with the following character(s) "ambda" by the rule:
JB> (?l ?a ?m ?b ?d ?a)
...
JB> Adding a char before it or otherwise modifying the line makes the
JB> lambda be correctly prettified again. Weird.

Weird.  I don't know what's happening, and it works well for me.  Does
turning `font-lock-mode' off and back on fix it?

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Tue, Jun 11, 2013 at 11:35 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Weird.  I don't know what's happening, and it works well for me.  Does
> turning `font-lock-mode' off and back on fix it?

No.

BTW, shouldn't turning font-lock-mode off disable the pretiffication?

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

> On Tue, Jun 11, 2013 at 11:35 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>
>> Weird.  I don't know what's happening, and it works well for me.  Does
>> turning `font-lock-mode' off and back on fix it?
>
> No.

Or really, not always. I just tried with startup.el (which has lots of
lambdas), and in some cases M-x font-lock-mode M-x font-lock-mode
fixed the faulty lambda composition, and sometimes it didn't.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Tue, Jun 11, 2013 at 11:35 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Weird.  I don't know what's happening, and it works well for me.

I can repeat it, so I'll file a new bug report.

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Tue, 11 Jun 2013 23:50:18 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Tue, Jun 11, 2013 at 11:35 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Weird.  I don't know what's happening, and it works well for me.  Does
>> turning `font-lock-mode' off and back on fix it?

JB> No.

JB> BTW, shouldn't turning font-lock-mode off disable the pretiffication?

They are entirely implemented by font-lock keywords, so I would assume so.

At least for me, that works every time.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Ted Zlatanov <tzz@lifelogs.com>
> Date: Sat, 15 Jun 2013 04:23:34 -0400
> 
> On Tue, 11 Jun 2013 23:50:18 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 
> 
> JB> On Tue, Jun 11, 2013 at 11:35 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> >> Weird.  I don't know what's happening, and it works well for me.  Does
> >> turning `font-lock-mode' off and back on fix it?
> 
> JB> No.
> 
> JB> BTW, shouldn't turning font-lock-mode off disable the pretiffication?
> 
> They are entirely implemented by font-lock keywords, so I would assume so.
> 
> At least for me, that works every time.

From Juanma's data, it is clear that the composition list is sometimes
created incorrectly, to include the list of all the characters in
"lambda".  The way to debug this is to catch the circumstances when
this happens.  One possible way of doing that (a.k.a. "printf
debugging") is to instrument prog--prettify-font-lock-compose-symbol
so that it logs a message with values of important variables when
the composition is incorrect, i.e. when the rule is (?l ?a ?m ?b ?d ?a).
That should give enough hints to find the villain.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

On Sat, Jun 15, 2013 at 10:23 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Tue, 11 Jun 2013 23:50:18 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:
>
> JB> BTW, shouldn't turning font-lock-mode off disable the pretiffication?
>
> They are entirely implemented by font-lock keywords, so I would assume so.
>
> At least for me, that works every time.

That's not what I see. M-x font-lock-mode turns off font-locking, but
the compositions to λ remain. Is that another bug?

[-- Attachment #2: bug.png --]
[-- Type: image/png, Size: 6114 bytes --]

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 15 Jun 2013 18:57:13 +0200
> 
> > JB> BTW, shouldn't turning font-lock-mode off disable the pretiffication?
> >
> > They are entirely implemented by font-lock keywords, so I would assume so.
> >
> > At least for me, that works every time.
> 
> That's not what I see. M-x font-lock-mode turns off font-locking, but
> the compositions to λ remain.

Probably because turning off font-lock removes the font-lock text
properties, but doesn't remove the 'composition' text property.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Sat, Jun 15, 2013 at 8:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Probably because turning off font-lock removes the font-lock text
> properties, but doesn't remove the 'composition' text property.

Yes. But IIUC what Ted said, turning off font-lock mode is removing
the prettification for him. ??

As for the composition text property, I suppose it could be possible
to mark the prettified text during font-locking and use some font-lock
-hook or -function to remove it at turn-off time?

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Sun, 16 Jun 2013 00:48:34 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Sat, Jun 15, 2013 at 8:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Probably because turning off font-lock removes the font-lock text
>> properties, but doesn't remove the 'composition' text property.

JB> Yes. But IIUC what Ted said, turning off font-lock mode is removing
JB> the prettification for him. ??

Sorry for the misunderstanding.  I read your question incorrectly.
Turning off font-lock in the same buffer does not remove the
prettification.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Sun, Jun 16, 2013 at 2:07 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Sorry for the misunderstanding.  I read your question incorrectly.
> Turning off font-lock in the same buffer does not remove the
> prettification.

Aha. Well, perhaps it shoud... :-)

I have a few more questions about prog-prettify-symbols, but I'll ask
them in emacs-devel.

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Sun, 16 Jun 2013 03:52:43 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Sun, Jun 16, 2013 at 2:07 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Sorry for the misunderstanding.  I read your question incorrectly.
>> Turning off font-lock in the same buffer does not remove the
>> prettification.

JB> Aha. Well, perhaps it shoud... :-)

Yes, I agree.  Maybe we can add a `prog-prettify-uninstall' function
that expects the buffer-local `prog-prettify-symbols-alist' to be
unchanged and removes all compositions named in it?  And that can be
added to the font-lock unload hook when `prog-mode' is installed?

Or should it be lower level, where font-lock mode remembers "prettify"
compositions as a text property?  That would work regardless of
`prog-prettify-symbols-alist' and would not require an unload hook.  It
would also work if we add prettification in other modes, not just
`prog-mode'.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Dmitry Gutov]

Juanma Barranquero <lekktu@gmail.com> writes:

> As for the composition text property, I suppose it could be possible
> to mark the prettified text during font-locking and use some font-lock
> -hook or -function to remove it at turn-off time?

I have some custom code in my init directory that does something very
similar, and I've settled on adding `composition' to
`font-lock-extra-managed-props'. IIRC, the problem I was solving is that
otherwise removing a few chars from the composed symbol did not make it
un-composed.

Maybe we should make a font-lock-specific alias for `composition', like
`font-lock-face' is for `face', and use that.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Sun, Jun 16, 2013 at 11:34 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> Or should it be lower level, where font-lock mode remembers "prettify"
> compositions as a text property?  That would work regardless of
> `prog-prettify-symbols-alist' and would not require an unload hook.  It
> would also work if we add prettification in other modes, not just
> `prog-mode'.

Yes, that's better IMHO. In fact, I like Dmitry's suggestion:

> Maybe we should make a font-lock-specific alias for `composition', like
> `font-lock-face' is for `face', and use that.

Seems the saner alternative if we are piggybacking into font-lock to
do composition...

   J

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Sun, Jun 16, 2013 at 12:03 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> Maybe we should make a font-lock-specific alias for `composition', like
> `font-lock-face' is for `face', and use that.

Yes, I like that idea.

But, will it complicate and/or slow redisplay?

    J

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Sun, 16 Jun 2013 12:11:20 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Sun, Jun 16, 2013 at 11:34 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> Or should it be lower level, where font-lock mode remembers "prettify"
>> compositions as a text property?  That would work regardless of
>> `prog-prettify-symbols-alist' and would not require an unload hook.  It
>> would also work if we add prettification in other modes, not just
>> `prog-mode'.

JB> Yes, that's better IMHO. In fact, I like Dmitry's suggestion:

>> Maybe we should make a font-lock-specific alias for `composition', like
>> `font-lock-face' is for `face', and use that.

JB> Seems the saner alternative if we are piggybacking into font-lock to
JB> do composition...

OK.  Unfortunately I don't know font-lock well at all, so I would
appreciate it if someone else could implement this.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 16 Jun 2013 12:12:56 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 14574@debbugs.gnu.org
> 
> On Sun, Jun 16, 2013 at 12:03 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> > Maybe we should make a font-lock-specific alias for `composition', like
> > `font-lock-face' is for `face', and use that.
> 
> Yes, I like that idea.
> 
> But, will it complicate and/or slow redisplay?

Why do you think it could do that?

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Sun, Jun 16, 2013 at 6:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Why do you think it could do that?

Because I know nothing about redisplay, and because checking
composition plus some other property sounds like more work than just
checking on composition. OTOH, I don't know what I'm talking about, so
I will be very happy to know that we could add a font-lock specific
composition property alias and not affect performance...

    J

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 16 Jun 2013 18:18:03 +0200
> Cc: dgutov@yandex.ru, 14574@debbugs.gnu.org
> 
> On Sun, Jun 16, 2013 at 6:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Why do you think it could do that?
> 
> Because I know nothing about redisplay, and because checking
> composition plus some other property sounds like more work than just
> checking on composition. OTOH, I don't know what I'm talking about, so
> I will be very happy to know that we could add a font-lock specific
> composition property alias and not affect performance...

The best way is just try it and see.

bug#14574: prog-prettify-symbols breaks font-locking

[Stefan Monnier]

> Yes, I agree.  Maybe we can add a `prog-prettify-uninstall' function
> that expects the buffer-local `prog-prettify-symbols-alist' to be
> unchanged and removes all compositions named in it?  And that can be
> added to the font-lock unload hook when `prog-mode' is installed?

The simpler solution is to make prog-prettify-install add `composition'
to the extra-managed properties.


        Stefan

bug#14574: prog-prettify-symbols breaks font-locking

[Stefan Monnier]

> Maybe we should make a font-lock-specific alias for `composition', like
> `font-lock-face' is for `face', and use that.

Let's not bother.


        Stefan

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 16 Jun 2013 19:14:45 -0400
> 
> The simpler solution is to make prog-prettify-install add `composition'
> to the extra-managed properties.

Won't that remove _all_ composition properties, not just those added
by prog-prettify-symbols?

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Mon, Jun 17, 2013 at 4:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Won't that remove _all_ composition properties, not just those added
> by prog-prettify-symbols?

Yes. So if someone is editing with a programming mode that uses
prettifying, *and* has enabled prettifying, *and* has other,
unrelated, composed chars in the buffer, *and* turns off font-locking,
s/he will have a bit of trouble. Seems bearable to me, pending real
user complains.

   J

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Mon, 17 Jun 2013 04:49:57 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Mon, Jun 17, 2013 at 4:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Won't that remove _all_ composition properties, not just those added
>> by prog-prettify-symbols?

JB> Yes. So if someone is editing with a programming mode that uses
JB> prettifying, *and* has enabled prettifying, *and* has other,
JB> unrelated, composed chars in the buffer, *and* turns off font-locking,
JB> s/he will have a bit of trouble. Seems bearable to me, pending real
JB> user complains.

IIUC, that would be pretty annoying when editing Perl or other languages
with Unicode (e.g. Cyrillic) data in the script.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Mon, Jun 17, 2013 at 9:25 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:

> IIUC, that would be pretty annoying when editing Perl or other languages
> with Unicode (e.g. Cyrillic) data in the script.

Not many scripts (relatively speaking) use the kind of character
variation that needs composition (mostly arabic and many indic
scripts, but not cyrilic, I think).

But in any case, it is really common to deactivate font-locking while
programming? I think I've never done it unless I was specifically
trying to debug some problem with font-locking. Also, we're still a
long way from another release, I suppose. Plenty of time to receive
user complains and implement a more thorough fix, IMHO.

   J

bug#14574: prog-prettify-symbols breaks font-locking

[Ted Zlatanov]

On Mon, 17 Jun 2013 11:22:33 +0200 Juanma Barranquero <lekktu@gmail.com> wrote: 

JB> On Mon, Jun 17, 2013 at 9:25 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
>> IIUC, that would be pretty annoying when editing Perl or other languages
>> with Unicode (e.g. Cyrillic) data in the script.

JB> Not many scripts (relatively speaking) use the kind of character
JB> variation that needs composition (mostly arabic and many indic
JB> scripts, but not cyrilic, I think).

I didn't UC then :)  Yes, I agree it's probably not going to be a problem.

JB> But in any case, it is really common to deactivate font-locking while
JB> programming? I think I've never done it unless I was specifically
JB> trying to debug some problem with font-locking. Also, we're still a
JB> long way from another release, I suppose. Plenty of time to receive
JB> user complains and implement a more thorough fix, IMHO.

I'm OK with the change.

Ted

bug#14574: prog-prettify-symbols breaks font-locking

[Stefan Monnier]

> IIUC, that would be pretty annoying when editing Perl or other languages
> with Unicode (e.g. Cyrillic) data in the script.

They don't use the composition text property, AFAIK.


        Stefan

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 17 Jun 2013 11:22:33 +0200
> 
> On Mon, Jun 17, 2013 at 9:25 AM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> 
> > IIUC, that would be pretty annoying when editing Perl or other languages
> > with Unicode (e.g. Cyrillic) data in the script.
> 
> Not many scripts (relatively speaking) use the kind of character
> variation that needs composition

If you are the user of those particular scripts, removing the
compositions will be rather nasty for you, because it makes the text
barely legible, sometimes not at all.

> (mostly arabic and many indic scripts, but not cyrilic, I think).

Arabic uses automatic compositions, not static compositions produced
by text properties.  If you want to see which scripts use the
'composition' properties, search Lisp files for compose-region.

Perhaps Handa-san could tell if having 'composition' properties in
comments and strings is something that can happen in real life for
some scripts used in those comments/strings.  If it can (and I don't
know one way or the other), then I don't think we should remove all of
the 'composition' properties just because font-lock was turned off.

> we're still a long way from another release, I suppose. Plenty of
> time to receive user complains and implement a more thorough fix,
> IMHO.

You assume that representatives of affected communities track Emacs
development.  But that assumption is not really guaranteed to be true.

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Mon, Jun 17, 2013 at 5:00 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Arabic uses automatic compositions, not static compositions produced
> by text properties.  If you want to see which scripts use the
> 'composition' properties, search Lisp files for compose-region.

Ethiopic, indian languages, Lao, Thai, Tibetan and Tai languages, currently.

> Perhaps Handa-san could tell if having 'composition' properties in
> comments and strings is something that can happen in real life for
> some scripts used in those comments/strings.  If it can (and I don't
> know one way or the other), then I don't think we should remove all of
> the 'composition' properties just because font-lock was turned off.

I don't disagree (or at least, not strongly), but I think is an
unlikely problem because, as I said, the set of conditions under which
can happen is not that big. Currently only Perl (but not Cperl),
(e)lisp and CFEngine buffers will be affected, and only if the user
choses to enable prettification, which is off by default. And then
s/he would have to need to turn off font-locking, which I don't think
it is really a common operation while editing code, is it? So it seems
to me like we have a two line fix for 95% of use cases (were 95% is a
number just invented out of thin air, but you catch my meaning), where
covering 100% of cases is likely to be much more complex.

> You assume that representatives of affected communities track Emacs
> development.  But that assumption is not really guaranteed to be true.

No, I'm assuming that we usually go for fixing real problems versus
perceived ones. Even if we are mistaken and the affected communities
discover after the fact, is not like there are no workarounds or we
cannot implement a 100% fix later.

But don't take that as that I'm opposing a better fix. I'm not. I just
don't see the point yet.

   J

bug#14574: prog-prettify-symbols breaks font-locking

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 17 Jun 2013 18:24:11 +0200
> Cc: Kenichi Handa <handa@gnu.org>, 14574@debbugs.gnu.org
> 
> I'm assuming that we usually go for fixing real problems versus
> perceived ones.

Let's see...  You examine a bridge and discover that one of its
supports is shaky, and will probably not hold when the next storm
comes.  Is that a real problem or a perceived one?  ;-)

bug#14574: prog-prettify-symbols breaks font-locking

[Juanma Barranquero]

On Mon, Jun 17, 2013 at 6:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Let's see...  You examine a bridge and discover that one of its
> supports is shaky, and will probably not hold when the next storm
> comes.  Is that a real problem or a perceived one?  ;-)

That depends on whether the bridge is the Golden Gate, or some small
wooden bridge over a dry river in the middle of the desert :-)

   J