Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects]

[Alan Mackenzie]

Hello, Andrea.

On Thu, Mar 19, 2020 at 20:43:15 +0000, Andrea Corallo wrote:
> Alan Mackenzie <address@hidden> writes:

> > "More precise line numbers" is a misconstruction, even though I've used
> > such language myself in the past.  Line numbers don't come from a
> > physical instrument which measures with, say +-1% accuracy.  CORRECT
> > line (and column) numbers are what we need.

> > You will recall that the output of correct line/column numbers for byte
> > compiler messages is a solved problem.  I solved it and presented the
> > fix in December 2018.  This fix was rejected because it made Emacs
> > slightly slower.

> > In the 3½ years I've been grappling with this problem, I've tried all
> > sorts of things like "fat cons cells".  They don't work, and can't work.
> > They can't work because large chunks of our software chew up and spit
> > out cons cells with gay abandon (I'm talking about the byte compiler and
> > things like cconv.el here).  More to the point, users' macros chew up and
> > spit out cons cells, and we have no control over them.  So whilst we
> > could, with a lot of tedious effort, clean up our own software to
> > preserve cons cells (believe me, I've tried), this would fail in users'
> > macros.

> > Since then I've worked a fair bit on creating a "double" Emacs core, one
> > core being for normal use, the other for byte compiling.  There's a fair
> > amount of work still to do on this, but I know how to do it.  The problem
> > is that I have been discouraged by the prospect of having this solution
> > vetoed too, since it will make Emacs quite a bit bigger.

> > I don't think it is fair to give this problem to a group of summer
> > coders.  It is too hard a problem, both technically and politically.


> Hi Alan,

> Sorry I'm new to Emacs development, where can be found the code of your
> attempt?  Is it in a feature branch?

It's in the branch scratch/accurate-warning-pos.  The commit which
converted the unfinished work to a bug fix was:

    commit 2e04ddadab266d245a3bd0f6c19223ea515bdb90
    Author: Alan Mackenzie <address@hidden>
    Date:   Fri Nov 30 14:55:48 2018 +0000

        Sundry amendments to branch scratch/accurate-warning-pos.

(except, I think it still outputs two positions for each warning
message: the traditional one, and the new correct one).

> Thanks

>   Andrea

> -- 
> address@hidden

-- 
Alan Mackenzie (Nuremberg, Germany).