Re: Thoughts on getting correct line numbers in the byte compiler's warning messages

[Alan Mackenzie]

Hello, Michael.

On Thu, Nov 08, 2018 at 05:47:15 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <address@hidden> writes:

> > The third idea is to amend the reader so that whereas it now produces a
> > form, in a byte compiler special mode, it would produce the cons (form .
> > offset).  So, for example, the text "(not a)" currently gets read into
> > the form (not . (a . nil)).  The amended reader would produce (((not . 1)
> > . ((a . 5) . (nil . 6))) . 0) (where 0, 1, 5, and 6 are the textual
> > offsets of the elements coded).

> BTW, an amended version of `read' might be beneficial for other stuff,
> too.  When I designed el-search, I wanted something like that.

As it turned out, the above scheme would not be useful, because a macro
could not manipulate such a form.

The ideas are currently in flux, in a discussion between Stefan and me,
and we've come up with several ideas, all bad.  ;-)  We're currently
trying to select the least bad idea.

> I'm not sure which kind of position info data I would like to have.  I
> think it would be good to have additionally starting positions of
> conses, for example.

I came up with a way of doing this, using the spare value of Lisp_Type
in a Lisp_Object to indicate an indirection to a structure of two
Lisp_Objects.  The first would be the actual object, the second would be
position information.

The trouble with this is it would slow down Emacs performance
significantly (possibly as much as ~10%).  It would also be difficult to
implement, since at each transformation of the form being compiled,
position information would need to be copied to the new version of form.

Stefan's latest suggestion is to use the above approach just on symbol
occurrences.  (Sorry!).  These are preserved through transformations
much more than cons cells are.  Also, the existing approach in the
compiler only tracks symbol occurrences, so we will not lose anything by
tracking only symbols, but more accurately.

Even so, this will be a lot of work.

If some code wants to get the starting position of a cons, the source
code will surely be in a buffer somewhere.  As long as there is a symbol
in the cons (i.e., we don't have ()), surely the cons position can be
found from the contained symbol, together with backward-up-list in the
source buffer.  Or something like that.

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).