GNU bug report logs - #23783
Emacs 25: Changing font-lock-maximum-decoration doesn't work.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23783 in the body.
You can then email your comments to 23783 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 25: Changing font-lock-maximum-decoration doesn't work.
Date: Fri, 17 Jun 2016 10:25:00 +0000

Hello, Emacs.

In GNU Emacs 25.0.94.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.7)
 of 2016-06-07 built on acm
Repository revision: 9d5ccebeba0506f7280662630f0ee85a52c8a327
Configured using:
 'configure --with-tiff=no --with-gif=no --with-gpm'

Do this:
1. emacs -Q
2. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
   o - set the level to 1 (minimum decoration) and apply the new
     setting.
3. C-x C-f .../src/xdisp.c
4. Note that font locking is indeed at level 1.  Note, indeed, how fast
   scrolling works.  ;-)
5. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
   o - set the level to t (maximum decoration) and apply.
6. (In the xdisp.c window) M-x font-lock-mode, twice.
7. Note that the font locking remains at level 1.

This last is surely a bug.  Enabling font locking in a buffer should use
the current valid setting of font-lock-maximum-decoration.

Discussion:
-----------

There are no instructions in the Emacs manual which tell you how to
change decoration levels.  It merely states on page "Font Lock Mode"
that "You can customize the variable `font-lock-maximum-decoration' to
alter the amount of fontification applied by Font Lock mode, for major
modes that support this feature.".  This doesn't then say what is to be
done after doing such customization, for it to take effect.

There is a non-interactive function `font-lock-refresh-defaults' which
works, but this function isn't called from anywhere in Emacs.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #10 received at 23783-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 23783-done <at> debbugs.gnu.org
Subject: Re: bug#23783: Emacs 25: Changing font-lock-maximum-decoration doesn't
 work.
Date: Sat, 18 Jun 2016 12:56:10 +0300

> Date: Fri, 17 Jun 2016 10:25:00 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> 
> 1. emacs -Q
> 2. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
>    o - set the level to 1 (minimum decoration) and apply the new
>      setting.
> 3. C-x C-f .../src/xdisp.c
> 4. Note that font locking is indeed at level 1.  Note, indeed, how fast
>    scrolling works.  ;-)
> 5. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
>    o - set the level to t (maximum decoration) and apply.
> 6. (In the xdisp.c window) M-x font-lock-mode, twice.
> 7. Note that the font locking remains at level 1.
> 
> This last is surely a bug.  Enabling font locking in a buffer should use
> the current valid setting of font-lock-maximum-decoration.

It's quite clear from the code that this is the intended behavior.
The comments for font-lock-set-defaults (the function and the
variable) and for font-lock-refresh-defaults are especially revealing.

> There are no instructions in the Emacs manual which tell you how to
> change decoration levels.  It merely states on page "Font Lock Mode"
> that "You can customize the variable `font-lock-maximum-decoration' to
> alter the amount of fontification applied by Font Lock mode, for major
> modes that support this feature.".  This doesn't then say what is to be
> done after doing such customization, for it to take effect.
> 
> There is a non-interactive function `font-lock-refresh-defaults' which
> works, but this function isn't called from anywhere in Emacs.

I have added to the Emacs manual explanation of how to make the
customization of font-lock-maximum-decoration effective in a file
buffer.  In a nutshell, you need to either customize before visiting
the file, or kill the buffer and revisit the file after the
customization.

I think this fixes this bug, so I'm closing it.

Thanks.

Message #13 received at 23783 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23783 <at> debbugs.gnu.org
Subject: Re: bug#23783: Emacs 25: Changing font-lock-maximum-decoration
 doesn't work.
Date: Sat, 18 Jun 2016 17:19:03 +0000

Hello, Eli.

On Sat, Jun 18, 2016 at 12:56:10PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 17 Jun 2016 10:25:00 +0000
> > From: Alan Mackenzie <acm <at> muc.de>

> > 1. emacs -Q
> > 2. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
> >    o - set the level to 1 (minimum decoration) and apply the new
> >      setting.
> > 3. C-x C-f .../src/xdisp.c
> > 4. Note that font locking is indeed at level 1.  Note, indeed, how fast
> >    scrolling works.  ;-)
> > 5. M-x customize-variable <CR> font-lock-maximum-decoration <CR>
> >    o - set the level to t (maximum decoration) and apply.
> > 6. (In the xdisp.c window) M-x font-lock-mode, twice.
> > 7. Note that the font locking remains at level 1.

> > This last is surely a bug.  Enabling font locking in a buffer should use
> > the current valid setting of font-lock-maximum-decoration.

> It's quite clear from the code that this is the intended behavior.
> The comments for font-lock-set-defaults (the function and the
> variable) and for font-lock-refresh-defaults are especially revealing.

I haven't read them yet, but I will.  It is not user friendly to have to
set an option before visiting a file.  In this case, a natural use case
would be to want to reduce the decoration level after finding things
being too slow at the default level.

> > There are no instructions in the Emacs manual which tell you how to
> > change decoration levels.  It merely states on page "Font Lock Mode"
> > that "You can customize the variable `font-lock-maximum-decoration' to
> > alter the amount of fontification applied by Font Lock mode, for major
> > modes that support this feature.".  This doesn't then say what is to be
> > done after doing such customization, for it to take effect.

> > There is a non-interactive function `font-lock-refresh-defaults' which
> > works, but this function isn't called from anywhere in Emacs.

> I have added to the Emacs manual explanation of how to make the
> customization of font-lock-maximum-decoration effective in a file
> buffer.  In a nutshell, you need to either customize before visiting
> the file, or kill the buffer and revisit the file after the
> customization.

Thanks!

> I think this fixes this bug, so I'm closing it.

OK.  I'll think about trying to fix the code in the near future.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #16 received at 23783 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 23783 <at> debbugs.gnu.org
Subject: Re: bug#23783: Emacs 25: Changing font-lock-maximum-decoration
 doesn't work.
Date: Sat, 18 Jun 2016 20:37:32 +0300

> Date: Sat, 18 Jun 2016 17:19:03 +0000
> Cc: 23783 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > I think this fixes this bug, so I'm closing it.
> 
> OK.  I'll think about trying to fix the code in the near future.

I don't think we should change anything in the code, so maybe you
shouldn't try.

In general, I find that lately we make too frequently the mistake of
messing with low-level infrastructure for some marginal improvement,
and then have to invest/waste lots of time and releases to deal with
the fallout of unintended consequences, broken use cases, etc.  I
intend to object to such changes in the future.  This seems just such
a case: a minor annoyance whose "fixing" runs a very real risk of
breaking a lot of important functionalities.

Message #19 received at 23783 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23783 <at> debbugs.gnu.org
Subject: Minor feature fixes and enhancements [Was: bug#23783: Emacs 25:
 Changing font-lock-maximum-decoration doesn't work.]
Date: Sat, 18 Jun 2016 20:03:05 +0000

Hello, Eli.

On Sat, Jun 18, 2016 at 08:37:32PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 18 Jun 2016 17:19:03 +0000
> > Cc: 23783 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> muc.de>

[ .... ]

> In general, I find that lately we make too frequently the mistake of
> messing with low-level infrastructure for some marginal improvement,
> and then have to invest/waste lots of time and releases to deal with
> the fallout of unintended consequences, broken use cases, etc.  I
> intend to object to such changes in the future.  This seems just such
> a case: a minor annoyance whose "fixing" runs a very real risk of
> breaking a lot of important functionalities.

I'd ask you to consider things very carefully indeed before adopting
such a policy.  It is minor changes like these, a very great number of
them, that have made Emacs as usable as it is.

Sometime, fire up Emacs-21, and compare with a modern Emacs just how
usable it isn't.  Perhaps even more dramatic, fire up XEmacs.  I predict
you would find it irritating, and the things that would irritate you
would be just the lack of the little improvements that you are proposing
now to object to.

For example, in XEmacs, the C-x 4 bindings split the screen with the
windows above eachother, which is suboptimal on a modern wide screen.
Yes, it's nothing earth-shatteringly bad, it's just not quite right.  If
you do a batch-byte-compile, the error and warning messages are partially
drowned out by low-content messages about "compiling foo.el" and "Writing
foo.elc".  Again, nothing you can't get around, but Emacs doesn't do that
any more.  These are just two of the many, many, marginal improvements
Emacs has made in the last decade or so.

I don't think we should stop making these small improvements.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #22 received at 23783 <at> debbugs.gnu.org (full text, mbox):

From: John Wiegley <jwiegley <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 23783 <at> debbugs.gnu.org
Subject: Re: bug#23783: Minor feature fixes and enhancements [Was: bug#23783:
 Emacs 25: Changing font-lock-maximum-decoration doesn't work.]
Date: Sat, 18 Jun 2016 14:21:30 -0700

[Message part 1 (text/plain, inline)]

>>>>> Alan Mackenzie <acm <at> muc.de> writes:

>> In general, I find that lately we make too frequently the mistake of
>> messing with low-level infrastructure for some marginal improvement, and
>> then have to invest/waste lots of time and releases to deal with the
>> fallout of unintended consequences, broken use cases, etc. I intend to
>> object to such changes in the future. This seems just such a case: a minor
>> annoyance whose "fixing" runs a very real risk of breaking a lot of
>> important functionalities.

> I'd ask you to consider things very carefully indeed before adopting such a
> policy. It is minor changes like these, a very great number of them, that
> have made Emacs as usable as it is.

While I hear you, Alan, I very much agree with Eli here, and also intend to
increase my objections to such changes. We've accumulated a HUGE amount of
state, that to some extent is validated by the sheer number of users we have.
But there is no human alive who can forsee what the consequences of a core
change will be, however minor -- there're just too many ramifications to
consider.

Thus, we should avoid such changes only to fix annoyances. They really need to
become quite vocal objections for us to be motivated to apply the fix. I think
too many of these "little here, little there" type changes have happened over
the past several years, and it has not been good for the stability of our
foundation. One imagines a bowl of spaghetti.

Also, too often these little fixes are hacks meant to be harmless band-aids,
that only postpone the discussion of how we should really fix the problem,
which in some cases could mean rethinking our design.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 23783 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 23783 <at> debbugs.gnu.org
Subject: Re: Minor feature fixes and enhancements [Was: bug#23783: Emacs 25:
 Changing font-lock-maximum-decoration doesn't work.]
Date: Sun, 19 Jun 2016 05:34:51 +0300

> Date: Sat, 18 Jun 2016 20:03:05 +0000
> Cc: 23783 <at> debbugs.gnu.org
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > In general, I find that lately we make too frequently the mistake of
> > messing with low-level infrastructure for some marginal improvement,
> > and then have to invest/waste lots of time and releases to deal with
> > the fallout of unintended consequences, broken use cases, etc.  I
> > intend to object to such changes in the future.  This seems just such
> > a case: a minor annoyance whose "fixing" runs a very real risk of
> > breaking a lot of important functionalities.
> 
> I'd ask you to consider things very carefully indeed before adopting
> such a policy.

I did.

> I don't think we should stop making these small improvements.

This is not about small improvements per se.  This is about minor
improvements that are implemented by non-trivial changes in basic
functionality.  I think we've had enough incidents of this kind to be
able to draw conclusions for future development.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.