[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding refactoring capabilities to Emacs

From: João Távora
Subject: Re: Adding refactoring capabilities to Emacs
Date: Thu, 7 Sep 2023 18:24:12 +0100

On Thu, Sep 7, 2023 at 6:06 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> Going back from there to the actual source code can be a fair bit more
> >> tricky,
> > Exactly.
> >> but Alan's symbols-with-positions should provide just what we need.
> > Great! but how?
> > Some years ago I presented a full source-tracking reader for Common Lisp
> > with just Lisp to a conference ;-) Needs a programmable reader though :-(
> > As you may remember, I then paired it with a full code walker to create
> > a stepper.
> We do have a "full source-tracking reader" writen in ELisp inside `edebug.el`.
> It's not 100% faithful to `lread.c`, but it seems to work well enough
> that we haven't heard too many bug reports about it over the years.
> Still, can't be used with `cconv` because the the "sexp with
> source-tracking info" don't have the shape expected by macros.
> > Is lread.c used for symbols-with-positions, or is code read in some
> > other completely new way?
> Yes, the symbols-with-positions thingy was done by extending `lread.c`.
> It keeps track of the source position only for symbols rather than for
> all Lisp objects, but it does it in a way which can survive
> macro-expansion.

Great!  Indeed that's exactly what's needed.   Might as well
plug my paper here: https://zenodo.org/record/3742759
where I gave it the pompous name of "mnesic macroexpansion".
There I used an existing codewalker with hook support and a
simple 'eq' lookup table.

Though when I used that for a stepper I run into some ambiguities
with atoms after macro expansion (described in section 4.1).  Might
not be a problem here, as that problem was related to knowing
which manifestations a given atom is actually evaluated.  And I'd
say that's not a problem for the "rename" refactoring action.

> It's what's used in the byte-compiler to provide position info in
> the warnings.

Hmmm, and we know it doesn't always get things right... :-/ Namely
it fails when there is more than one manifestation of the warning.
But then again, maybe that's a problem of compilation, not
reading, source-tracking or macro-expansion.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]