From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Minor features and enhancements Date: Sun, 19 Jun 2016 13:56:37 +0000 Message-ID: <20160619135637.GB5875@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1466344635 26752 80.91.229.3 (19 Jun 2016 13:57:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jun 2016 13:57:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 19 15:57:05 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bEdDk-00053T-2W for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 15:57:04 +0200 Original-Received: from localhost ([::1]:38838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEdDj-0008Jl-8I for ged-emacs-devel@m.gmane.org; Sun, 19 Jun 2016 09:57:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEdDC-0008Jf-Ej for emacs-devel@gnu.org; Sun, 19 Jun 2016 09:56:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEdD8-00063u-6c for emacs-devel@gnu.org; Sun, 19 Jun 2016 09:56:29 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:40752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEdD7-00063p-SU for emacs-devel@gnu.org; Sun, 19 Jun 2016 09:56:26 -0400 Original-Received: (qmail 76858 invoked by uid 3782); 19 Jun 2016 13:56:24 -0000 Original-Received: from acm.muc.de (p4FC46D0C.dip0.t-ipconnect.de [79.196.109.12]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 19 Jun 2016 15:56:23 +0200 Original-Received: (qmail 7380 invoked by uid 1000); 19 Jun 2016 13:56:37 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:204510 Archived-At: 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 > [ .... ] > > 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).