Slicker should do better with local abbreviations

[csilvers]

If you use _p = route_util.params.Param in your file, and slicker moves references to it, it will now use oldfile._p in the new file. Instead it should copy the abbreviation to the new file: _p = route_util.params.Param.

We may want to have a notion of "abbreviation constants" which we effectively move like imports, although it's tricky to tell which are which; we shouldn't do this for things that are actually shared constants.

[benjaminjkraft]

I was thinking a little about how to do this. What if we just say (by default) we copy any assignment whose value is a single symbol from another module? (That is, we copy SOMETHING = other.module.FOO but not SOMETHING = FOO or SOMETHING = other.module.FOO + 17.)

In particular, I don't think there is any real difference that we can draw between a constant with two names and an abbreviation, and the latter is the much more common case, so if we want to do anything here without some complicated mess of configuration, we need to guess this way. Plus, this is all happening to the file being moved, which is where the user is most likely to be paying attention, so they have a good chance of noticing anything funky we do.

[csilvers]

I like it! Figuring out where to copy it to may be tricky though. (I guess we can always just put them first.) And we'd have to do some work to ensure the var didn't already exist on the target, or if it did that it pointed to the same thing.

[benjaminjkraft]

Oh, good point. Yeah I'd say put it after the import block, and verify it doesn't exist or points to the same thing, but it's adding two more bits of guesswork.