From: Eli Zaretskii <eliz@gnu.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: acm@muc.de, emacs-devel@gnu.org
Subject: Re: Minor features and enhancements
Date: Mon, 20 Jun 2016 17:22:07 +0300 [thread overview]
Message-ID: <83eg7s7xf4.fsf@gnu.org> (raw)
In-Reply-To: <57672A73.7000109@cs.ucla.edu> (message from Paul Eggert on Mon, 20 Jun 2016 01:27:47 +0200)
> 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".
prev parent reply other threads:[~2016-06-20 14:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83eg7s7xf4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).