Minor features and enhancements

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: 23783@debbugs.gnu.org
> > > From: Alan Mackenzie <acm@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).

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

Re: Minor features and enhancements

[Paul Eggert]

> > This is not about small improvements per se.  This is about minor
> >improvements that are implemented by non-trivial changes in basic
> >functionality.

The need to improve Emacs in minor ways can help us discover and fix 
problems in basic functionality. Whether a basic function should change 
is obviously a more important issue than a minor fix elsewhere, and so 
needs more discussion and review. When evaluating proposed improvements 
to basic functions, stability is an important merit but it's not the 
only one.

Any general policy of avoiding changes to basic functions that only fix 
annoyances would be hard to distinguish from a policy that simply avoids 
changes to basic functions -- after all, what one person considers 
important another can easily say is only an annoyance.

Re: Minor features and enhancements

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 20 Jun 2016 01:27:47 +0200
> 
> The need to improve Emacs in minor ways can help us discover and fix problems in basic functionality. Whether a basic function should change is obviously a more important issue than a minor fix elsewhere, and so needs more discussion and review. When evaluating proposed improvements to basic functions, stability is an important merit but it's not the only one.

These are general principles with which I fully agree.

> Any general policy of avoiding changes to basic functions that only fix annoyances would be hard to distinguish from a policy that simply avoids changes to basic functions

I didn't declare any policy -- I'm not authorized for that in the
first place, and based on past experience won't expect the crowd to
accept even if I was.  It was just a heads-up -- that's my conclusion
from the past few years of watching Emacs development and
participating in it.  When reviewing proposed changes of this nature,
my tendency will be to object to changes in core that aim at minor
improvements.  IMO, the rule should be: minor improvements should be
accomplished by minor changes outside of the core, or not at all.

> after all, what one person considers important another can easily say is only an annoyance. 

Assuming we all are reasonable people, the above is indeed a judgment
call, but only up to a point.  E.g., I wouldn't expect anyone here to
claim in good faith that non-support for bidirectional scripts was
merely an "annoyance".