On Mon, Sep 18, 2017 at 5:53 PM, Helmut Eller <eller.helmut@gmail.com>
wrote:

> The following message is a courtesy copy of an article
> that has been posted to gmane.emacs.devel as well.
>
> On Mon, Sep 18 2017, Rocky Bernstein wrote:
>
> > I've been looking at Emacs Lisp code and the C source. I don't see
> > how/where execution position is stored.
>
> I suppose you want to know how Emacs stores the source position
> (filename and line number) of Lisp code


Not really file name and line number. I meant it in the broadest possible
way.
Position could be a pointer to a structure, an offset in some bytecode, or
something else.



> and in particular how the
> debugger can take you from a stack frame in the backtrace to the source
> position.
>

 I see that edebug munges function definitions for its own tracking. The
calls
to enter and leave pass the position, I think a byte offset.

That's okay too, but even there I don't see something that stacks prior
positions. It doesn't take much effort to do that, so I might consider
doing it.



> Emacs doesn't store such information in a nice uniform table -- sorry to
> disappoint you -- instead Emacs has a bunch of heuristics to
> guess/search the source position.  One heuristic goes like this: first
> determine the filename by searching the name of the function in the list
> `load-history' or for subrs use the file etc/DOC.  The line number is
> not stored anywhere and is usually determined by some regexp search in
> the source file.
>
> Those heuristics work quite well for "normal" code, but are too limited
> if lambdas or complex macros are involved.
>

Right. Although it is a long ways from being usable. bytecode deparsing
would
handle all of the the complex cases (for bytecode) very naturally without
hackery.
It only needs information about where the interpreter is.


> There is also no nice API for this.  E.g. look at
> `elisp--xref-find-definitions' for the messy code that is needed for
> this kind of task.
>
> Ideally, the compiler/intepreter would generate source maps and attach
> them to functions/lambdas in some way.  But it seems that the motivation
> for doing that (I guess it would be quite a big project) is limited,
> given that the current heuristics work good enough for the simple cases.
> Actually, the current approach works suprisingly well, considering how
> little information is kept around.
>

And I think with just a little more information, position information, I
think the situation would be
much better.



>
> Helmut
>