Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Alan Mackenzie <acm@muc.de>]

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 <rudalics@gmx.at>
> > Cc: michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>,
> > 	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).