Xcode 4 doesn't treat the Enter key properly

Originator:tempelmann
Number:rdar://10729741 Date Originated:20-Jan-2012
Status:Open Resolved:
Product:Xcode Product Version:4.2.1
Classification:Bug Reproducible:always
 
20-Jan-2012 05:58 PM Thomas Tempelmann:
Summary:
Practically all edit fields and dialogs that Xcode provides do not react to the Enter key as it's commonly expected.

To clarify: The Enter key is the one that's on extended kbds within the number block at the right, and is also reached on smaller kbds by pressing fn-Return.

In general, the Enter key should act like the Return key, with a few exceptions.

Exceptions are, for instance, when there's a edit field in a modal dialog that accepts multi-line input. Here, the Return key would add a new line in the edit field, while Enter would press the default button (usually labelled "OK" or "Done").

The rules in other words:
- In modal dialogs, Enter always presses the Default button, just like Esc always presses the Cancel button.
- In edit fields, it is used to _end_ an entry, not add a new line.

Example:
Use "Find in Workspace...", enter text to search, and finish with the Enter key. Result: Instead of starting the search, it adds a invisible character, which is hard to spot.

In fact, the adding of an invisble character is causing a lot of trouble for those of us used to the Enter key for ending inputs. I've had it happen quite a few times where I had entered a property value in the Nib or Storyboard editor, then getting compile errors or other warnings telling me that I need to enter a number or a valid identifier - while I could not even spot the invisible char causing the errors.

-----------------------------

26-Jan-2012 09:45 PM Apple Developer Bug Reporting Team :
Engineering has requested the following information in order to further investigate this issue:

Please attach the following items to this bug report:

1.  ~/Library/Developer/Xcode/UserData/KeyBindings/*.idekeybindings files
2. Screenshot of Xcode->Preferences...->Key Bindings->Conflicts pane
3. ~/Library/KeyBindings/DefaultKeyBinding.dict (if you have it)

-----------------------------

26-Jan-2012 10:28 PM Thomas Tempelmann:
OK, I had no idea that this was due to my customization.

Turns out that the customization didn't really act out as I had intended and expected.

Here's what I had tried to accomplish:

I did not like the fact that pressing the Enter key would add a newline in the code editor.
So I removed the Enter key from the setting for "Insert Newline".

However, this had two unwanted effects:

1. Instead of the Enter now doing NOTHING in the code editor as I had hoped, it inserts some unprintable character instead. (Many other editors before Xcode would simply ignore the Enter key when editing text, or even scroll the text so that the cursor moves to the center of the view - I wished Xcode would do the same).

2. And instead of this change affecting only the code editor, it apparently works everywhere in Xcode, not just in the code editor. Thats also something other editors that provide customizations (BBEdit, CodeWarrior) didn't do, and which was good.

So, you can claim this is a user error. I would, however, still claim that the Enter key should default to the behavior I had described above in my first submission of this bug report: Instead of "typing" the EXT char (chr code 3), which is a very old school way which VI and DOS users might appreciate, it is not something Mac users have ever been used to - while Xcode might do it the Unix way here, it's not the Mac way. The Enter key should not output a control char, just as the Esc should not output the ESC char, because that's of NO USE in a GUI app that Xcode is. The cursor keys, Backspace, Tab, Esc, Return and Enter are supposed to be handled like meta keys, i.e. never should end up inserting their old Char codes into any text field. That's just nonsense nowadays.

So, I beg you to fix the behavior of the Enter key like this:

If it's assigned to "Insert Newline", then, yes, let Enter act like Return, i.e. feed a CR to Xcode and have it act like that. But when it's not assigned anywhere, then it should act like it act on any other typical Mac app, for 20 years: Press the default key in a dialog, act as the "accept" key in single line edit fields, do nothing else in multi-line edit fields including the code editor.

Attached is the keybindings file that contains my "Newline" assignment causing this trouble. There was no DefaultKeyBinding.dict, and the conflicts are of no matter to this issue, either.


26-Jan-2012 10:28 PM Thomas Tempelmann:
'TTsKeys.idekeybindings' was successfully uploaded

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!