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

[Andrea Corallo <akrl@sdf.org>]

Alan Mackenzie <acm@muc.de> 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?

Thanks

  Andrea

-- 
akrl@sdf.org