>>>>> Alan Mackenzie <acm@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