Re: Adding refactoring capabilities to Emacs

[João Távora]

On Thu, Sep 7, 2023 at 6:54 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > 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.
>
> The symbols-with-position approach avoids this problem (for symbols,
> tho not for other data without identity list fixnums) because every
> occurrence of a symbol returns a different "symbol with position" (and
> then we need a hack to allow those different symbol-with-positions to
> be `eq` nevertheless because that's what is needed at too many places
> we can't control).

Making different things 'eq' is a possibility, but won't it
slow down 'eq'?

Again, I don't know if this is actually a problem specifically
when refactoring.

In that simple example

  (lambda (x) x)

The ambiguity is a problem when stepping, but it's no problem when
refactoring.

A trickier problem is

  (lambda (x) (let (x) x) x)

where renaming one of the symbols should not rename the others.  But
I think I implemented  a solution to that (at least in my model),
because symbols have parent forms, and the forms also have
source information.

Anyway, you seem to have envisioned a good strategy for this,  so
I won't bother you more with my vague memories of alternatives.

> >> 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.
>
> [ I can already hear Alan prepare his reply :-)  ]
> Seriously, tho, the position is pretty damn exactly right almost every
> time nowadays.  When it's not, it's not because the
> "symbol-with-position" info is wrong but because it's missing, or
> something else like that.

I didn't say it was :-) I just meant cases like this (this is the
simplest one)

   (defun foo () bar bar baz)

Only the first bar and the baz gets the warning.  If there was a lot
of code between the two 'bar's, it's not easy for the user to spot
(say in a Flymake overlay) that the bar isn't defined.

In contrast, a code analyzer like clangd gets this case correctly
(in C/C++ of course) and highlights the two occurances of the
undeclared identifier.

But this is a "diagnostics" problem and here we're concerned with
refactorings.  There, I'm really not sure at all it will be a problem.

João