[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minor features and enhancements
Minor features and enhancements
Sun, 19 Jun 2016 13:56:37 +0000
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
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
> 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).
- Minor features and enhancements,
Alan Mackenzie <=