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

[martin rudalics <rudalics@gmx.at>]

Hello, Alan

 >> There are around 50 issues in current Emacs that annoy me at least as
 >> much as wrong positions reported by the byte compiler.
 >
 > Likely, none of them are as difficult to address as the byte compiler
 > bug.

Running an incremental copying collector in a separate thread is, for
example.

 > But who's going to address them, if they can expect the reaction
 > I'm getting at the moment?

I've been following this thread since its beginning and I've not seen
an unjustified reaction so far, including mine.  I've kept quiet when
the 'open-paren-in-column-0-is-defun-start' convention was abolished
recently.  And I would have kept quiet in the case at hand as well.
But Eli once said that people should complain _before_ a change is
made and so I did.

 >> If, on the average, solving any such issue took away just 2% of the
 >> performance of my Emacs, I'd experience an overall slowdown of 100%
 >> when solving all of them.  So please note that Paul is not alone with
 >> his concerns.
 >
 > On average, solving these other bugs will cost 0% in performance.
 > You're positing a completely unrealistic scenario.

Right.  But mainly so because many of these 50 problems should have a
solution in the opposite direction.  They aim at improving performance
rather than degrading it.  For example, I spent quite some time on
reducing the overhead associated with creating Emacs tooltip frames -
largely unnoticed, but it saves me an entire GC cycle for every
tooltip displayed here.  Why should I spend my time on such things if
any gains are annihilated by solutions like yours.

 > Have you even tried scratch/accurate-warning-pos?  You've said in the
 > past that you have a slow machine, so if that's still true, you would
 > probably be the person to notice perceptible slowdown, should there be
 > any.  Do you notice any slowdown with it?

I haven't tried it.  As a rule, I bootstrap each of my Emacs instances
once a year, after Glenn changed the file headers.  Here a bootstrap
means that I can't use my machine for more than an hour.  And that I
have to either make a separate copy of my Emacs tree or do another
bootstrap to return to the previous version.  This year I already made
one extra bootstrap for the portable dumper and that consumed enough
of my remaining energy for such endeavours.  You have to live with the
fact that people like me live in a different world.

 > The byte compiler bug is extremely unusual, possibly unique, in its
 > resistance to being resolved.  Just about every possible approach has
 > been tried (along with several which are not possible), and only one
 > approach, the one in scratch/accurate-warning-pos, has got anywhere at
 > all.
 >
 > If you still object to this fix, even after trying it, what you are
 > saying is that you prefer fast buggy software over slightly slower
 > functional software.

I don't say that.  IMO the "byte compiler bug" has a simple fix which,
however, nobody but me would accept: When there is the slightest doubt
do not print position indications.  Also I don't understand why it
should be the byte compiler's task to check the syntax of expressions
for correctness.  If the byte compiler raises an error or new Lisp
code should be compiled, run a separate syntax checker that gets as
close as possible to the source of any error in the code.  And it can
spend as much time on that as it needs.  But enough heresy here.

martin