From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Sat, 1 Dec 2018 11:08:17 +0000 Message-ID: <20181201110817.GA5102@ACM> References: <20181128120443.GA4036@ACM> <20181129220552.GI12576@ACM> <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> <20181130185503.GA16256@ACM> <20181130220218.GB16256@ACM> <138d56b7-53df-1ea5-377c-8502245f1b6b@cs.ucla.edu> <5C0239DA.4030907@gmx.at> <831s71d566.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543662668 25687 195.159.176.226 (1 Dec 2018 11:11:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 11:11:08 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: cpitclaudel@gmail.com, eggert@cs.ucla.edu, michael_heerdegen@web.de, emacs-devel@gnu.org, martin rudalics , monnier@IRO.UMontreal.CA To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 12:11:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gT3As-0006Un-41 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 12:11:02 +0100 Original-Received: from localhost ([::1]:40812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT3Cy-0003BG-Ag for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 06:13:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36791) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT3CK-0003Ay-AY for emacs-devel@gnu.org; Sat, 01 Dec 2018 06:12:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gT3CF-0006YQ-Fs for emacs-devel@gnu.org; Sat, 01 Dec 2018 06:12:32 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:41263 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gT3CF-0006TR-72 for emacs-devel@gnu.org; Sat, 01 Dec 2018 06:12:27 -0500 Original-Received: (qmail 68259 invoked by uid 3782); 1 Dec 2018 11:12:15 -0000 Original-Received: from acm.muc.de (p2E5D5B13.dip0.t-ipconnect.de [46.93.91.19]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 01 Dec 2018 12:12:13 +0100 Original-Received: (qmail 5154 invoked by uid 1000); 1 Dec 2018 11:08:17 -0000 Content-Disposition: inline In-Reply-To: <831s71d566.fsf@gnu.org> 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 [fuzzy] X-Received-From: 193.149.48.1 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:231549 Archived-At: Hello, Eli. On Sat, Dec 01, 2018 at 10:25:53 +0200, Eli Zaretskii wrote: > > Date: Sat, 01 Dec 2018 08:35:54 +0100 > > From: martin rudalics > > Cc: michael_heerdegen@web.de, Eli Zaretskii , > > cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > So please note that Paul is not alone with his concerns. > No, he certainly isn't. > In fact, there's an overwhelming majority here that considers any > slowdown above 1% unacceptable. The fact that CPUs get faster, albeit > not at the same rate as 10 years ago, is not perceived as an > opportunity to perform more expensive processing in newer Emacs > versions, it is perceived as an opportunity to do the same tasks > faster. The bit you're glossing over is that we're not talking about adding some marginal feature, we're talking about fixing a bug which has been reported by users many times, a bug which is in a central part of Emacs's functionality. I'm shocked over people's preference for buggy software. > If that were not the majority view, we would have had Emacs without > dumping many moons ago. So the community clearly prefers performance > over features, even very important features. We're not talking about features, we're talking about a bug. > Actually, I'm surprised how 10 years ago was I given a go-ahead to > make the Emacs display engine bidi-aware: that definitely slows down > redisplay, sometimes by as much as 50%. Maybe I was just lucky. > Alan, unless your changes cause more than 1% slowdown, there's no hope > of them being accepted. Eli, I think it's up to you to accept or reject this bug fix. It's your personal responsibility. I'd be grateful if you would make the decision and explicitly state it. I will accept and respect it. If you reject the fix, the bug is highly unlikely ever to be fixed. > And even for 1%, expect to hear quite a few negative opinions. You > *have* been warned. And there's no indication that any of these people complaining, with the exception of Gemini Lasswell, have actually fired up the software and tried it out. There's no indication any of these people have even understood the bug and the attempts to fix it, let alone tried out the fix to evaluate it. The views of those who took the trouble to report the bug haven't been heard. Suppose we don't fix this bug. Then we should close all the pertinent bug reports as "won't fix". Additionally, the documentation of the byte compiler needs to be amended to match the reality. I propose the following patch to .../doc/lispref/compile.texi: diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi index 6d21ca3e6a..c4b47dbfdc 100644 --- a/doc/lispref/compile.texi +++ b/doc/lispref/compile.texi @@ -438,8 +438,12 @@ Compiler Errors Error and warning messages from byte compilation are printed in a buffer named @file{*Compile-Log*}. These messages include file names -and line numbers identifying the location of the problem. The usual -Emacs commands for operating on compiler output can be used on these +and line numbers which try to identify the location of the problem. +Frequently a wrong line number is indicated, but it is rarely very far +away from the actual problem@footnote{A fix for this problem was +worked out in 2018, but since it would have caused a slight slowdown +in Emacs, it was decided not to incorporate it.}. The usual Emacs +commands for operating on compiler output can be used on these messages. When an error is due to invalid syntax in the program, the byte -- Alan Mackenzie (Nuremberg, Germany).