Feature Request: rename by keeping existing text

[jewfro-cuban]

Current implementation deletes the entire name to be renamed and user has to enter the entire new name.
Often, especially with long name, we want to have a small modification like fixing a typo or adding a letter/word.
PyCharm has a nice implementation that keeps the previous text, allowing to edit/overwrite it and then re-factor the code.

[davidhalter]

I agree this would be nicer. However rename is pretty broken anyway :/ First need to fix the jedi stuff.

It's also not that easy to implement this kind of stuff with VIM.

[blueyed]

I think this is supported by now, please re-open otherwise.

[jewfro-cuban]

Nope, I don't see it.
Have a version from 10 day ago.

Can't re-open an issue closed by a collaborator. Please re-open.

https://stackoverflow.com/questions/21333654/how-to-re-open-an-issue-in-github

Github has very simple rights/privileges (and even simpler management for them).

If you are not a collaborator of a repo, then (in regards to issues)

you can open issues
you can comment on all existing issues (open or closed)
you can close your own issues
you can re-open your own issues *if you closed them yourself
you cannot close or re-open issues opened by someone else
you cannot re-open your own issues if a repo collaborator closed them

[blueyed]

you can re-open your own issues *if you closed them yourself

Interesting - thought you could always re-open your own ones.

Ok, thought like improvements to usages would have addressed that, but it replaces the whole word.

I've remembered that there is a visual mode I've added a while ago, but it also works not as expected, and appears to be broken even currently.

How would you expect this to work then?
Via visual mode, e.g. by selecting what should get replaced?
This could also support operator-pending mode probably, so that with the cursor before bar in foobar, <leader>rw would change it to foo and typing baz would result in foobaz then, which then gets used for renaming.

I've looked into it a bit already, and think this could be improved.

What might not be possible though is having both operator-pending mode (i.e. <leader>rw to rename to the end of the word) and <leader>r (rename current word, like it is done now) working in parallel.

I think we could have <leader>R then for operator-pending mode (less often used I guess).

[jewfro-cuban]

How about this:

Currently if I mark the word for renaming using visual mode (vw) and then < leader >r I get at the bottom command line:
Rename to: ______

(This does not work for me if I enter a new name and hit enter btw.
I get:

jedi-vim: No usages found here. │
jedi-vim: Jedi did 0 renames!

Maybe that's what you were referring to...)

But if we assume that can be fixed...
Is it possible to get the word string copied and ready for editing:
Rename to: WORD_TO_RENAME

I think that would be an easy and elegant solution.

I would keep the key < leader >r.
This way for renaming the entire word: normal mode + < leader >r
Renaming with editing option: visual mode marked word + < leader >r
When r will be used on visual mode marked word then

[blueyed]

I worked on this a bit, and I think it could work just by jedi-vim getting all the usages at the current cursor position when it starts (visual, normal, or operator mode), then let the user rename it (without the extra input that is currently being done with visual mode), and then replace all usages (gathered in the first step) with the new name.
The new name would be retrieved from the cursor position again (when leaving insert mode/finishing the editing) via usages, looking at the name at the cursor (not sure if that is the first one always).
@davidhalter
Or is there an easier method to get the name of the identifier at the cursor (apart from using usages, which is not really necessary to get only the current one).

[davidhalter]

@blueyed There's currently no easier way than this, but if this is really a requirement and would help us, I'd be willing to implement it. It has been planned for a long time to give Jedi users a context helper (for questions like this).

---

In general I agree with your approach that we just don't delete the current name and let the user rename it. This could work very well. However I'm not sure about all the edge cases. It might be hard to deal with user skipping in and out of normal mode. Maybe do it in a way that if a user hits the command a second time that it starts renaming? I don't know.

Generally I would introduce a <leader>R for this, while the current functionality could remain on <leader>r.

[blueyed]

@davidhalter
Yes, a simple context API would be very useful I think.

It worked quite well already, until I got side-tracked by all the improvements to the tests etc.. ;)

I think there is no edge case regarding skipping in and out of normal mode: we prepare the rename when it gets triggered, then go into insert mode (the visual mapping returns "c", while the normal mode mapping would trigger "ciw").
By then we gather the current usages already (might be bad for performance reasons though), and handle them when insert mode is left.
We should likely abort though for example (at the least) if newlines are being added etc.

It might be better to only store the current script when preparing for the rename (going into insert mode), but not get usages already for the case where it gets aborted, and to not block the initial editing. This then would be used to get the original usages.