* Minor features and enhancements
@ 2016-06-19 13:56 Alan Mackenzie
2016-06-19 23:27 ` Paul Eggert
0 siblings, 1 reply; 3+ messages in thread
From: Alan Mackenzie @ 2016-06-19 13:56 UTC (permalink / raw
To: emacs-devel
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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Minor features and enhancements
2016-06-19 13:56 Minor features and enhancements Alan Mackenzie
@ 2016-06-19 23:27 ` Paul Eggert
2016-06-20 14:22 ` Eli Zaretskii
0 siblings, 1 reply; 3+ messages in thread
From: Paul Eggert @ 2016-06-19 23:27 UTC (permalink / raw
To: Alan Mackenzie, emacs-devel
> > 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Minor features and enhancements
2016-06-19 23:27 ` Paul Eggert
@ 2016-06-20 14:22 ` Eli Zaretskii
0 siblings, 0 replies; 3+ messages in thread
From: Eli Zaretskii @ 2016-06-20 14:22 UTC (permalink / raw
To: Paul Eggert; +Cc: acm, emacs-devel
> 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".
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-06-20 14:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-06-19 13:56 Minor features and enhancements Alan Mackenzie
2016-06-19 23:27 ` Paul Eggert
2016-06-20 14:22 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.