Minor features and enhancements

[Alan Mackenzie]

Hello, Emacs.

The following conversation has taken place on an "obscure bug report"
(bug#23783: Emacs 25: Changing font-lock-maximum-decoration doesn't
work.)  It seems to me important enough to put in front of a wider
audience.

The first section was a post from me to Eli, yesterday:

> On Sat, Jun 18, 2016 at 08:37:32PM +0300, Eli Zaretskii wrote:
> > > Date: Sat, 18 Jun 2016 17:19:03 +0000
> > > Cc: address@hidden
> > > From: Alan Mackenzie <address@hidden>

> [ .... ]

> > 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).

.  Here is John's response:

> 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

.  And here is Eli's response:

> > 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.

.

-- 
Alan Mackenzie (Nuremberg, Germany).