Community
Participate
Working Groups
Build I20070418-1012. Consider the following code (using pipe character to materialize the insertion point): public class X { void foo() { String s| = ""; System.out.println(s); } } Place the insertion point behind s in the declaration and press Alt-Shit-R. The in-place refactoring hover appears. Press backspace once. s is erased and an error marker appears. The code looks like: public class X { void foo() { String | = ""; System.out.println(s); } } Press backspace a second time. No visible change except that the refactoring hover gets away and the code now looks like: public class X { void foo() { String| = ""; System.out.println(); } } Especially, no change around the System.out.println(); line. Add a whitespace and s again... And you get: public class X { void foo() { String s| = ""; System.out.println(); } } The meaning of the code changed, unnoticed. Note that I detected the behavior on a case where many compile errors resulted from the blanking of the variable name at the other places it was used. This is a bit less annoying in such cases because you get a strong signal that you'd better revert the file. But still, it happens quite often to me to strike backspace just one extra time while renaming, and the current behavior does not help me. Also, the behavior on a longer variable name is not that much better: backspace once more than needed, and the refactoring happens sooner than expected, leaving you no chance to reinsert characters in front of the name. Maybe blocking extra backspaces in some way would help?
What is the difference to local rename? Do any linked mode operation? 1. select 's' 2. Ctrl-1 3. Rename in File 4. Backspace, backspace
I see the problem. If we do something, then we should block backspace (and delete) at the border of all linked positions (be it refactoring, rename in file, template mode, ...). Possible workarounds for now: - use Edit > Expand Selection To > Enclosing Element (Alt+Shift+Up) to select the whole identifier - use (Ctrl+)Shift+Left/Right to select the characters to replace and start typing when the selection looks good - use Ctrl+Z to undo after you've fallen out of linked mode
I'll try to practice workaround 1 above until it becomes automatic for me. Already using workaround 3, but this is a pain (because then I have to restart from scratch).
The linked mode usually tries to give the user maximum freedom of doing what he wants in the editor, but I agree that this case could deserve special treatment. See bug 81790 and bug 96490 for more enhancement requests for navigation in linked mode.
Created attachment 64876 [details] Patch Here's a patch that blocks Backspace at the beginning and Delete at the end for zero-length selections. With a selection, it's hard to guess correctly what to do, and if we start intervening with non-zero selections, then we would not only have to handle this for delete operations, but also for replace (e.g. select something and then start typing).
The patches causes failing tests.
We cannot release this. The correct fix will need new API so that clients can configure the behavior. You might want to check whether you can hack this in via exit policy.
The problem is with examples such as - typing '(', which inserts () and starts linked mode or - content assist in 5.0 after 'new HashMap', which inserts 'new HashMap<K, V>' There, it is unexpected that the parentheses or angle brackets cannot be deleted.
We should only block Backspace and Delete in renames (Refactoring and Rename in file), but not in other cases where linked mode is started. In content assist etc., we often also insert characters outside of the linked positions, and the user sometimes really wants to delete those characters. In the rename case, the user already explicitly started an action to rename the selected identifier, so it is a safer bet that deleting characters before or after the linked identifier is unwanted in most cases.
Fixed in HEAD for 'Refactor > Rename' and 'Quick Fix > Rename in file'.
