#1935 Mac OS X key handling is incorrect (and easy to fix)
The change log for 4.2 prerelease indicates that Alt-key
shortcuts have been disabled for Mac OS X. While this
allows high-bit ASCII characters to be typed from the
keyboard without accidentally invoking a shortcut, it causes
major issues with standard Mac OS X text navigation.
The standard behavior on Mac OS X is for the caret to skip
over the previous or next word when Alt-Left or Alt-Right is
pressed. This is a commonly-used feature in all Mac OS X
text editors. Previously, this behavior was available in jEdit
by mapping the Previous Word and Next Word shortcuts to
Alt-Left and Alt-Right.
Although you can set ALT_KEY_PRESSED_DISABLED to
"false" to restore Alt shortcuts, you can't type high-bit
ASCII characters using the Alt key if you do (you could do
both in the previous version of jEdit).
The "best-of-both-worlds" solution is to allow the Alt
modifier to pass through to the shortcut handler for keys
that don't generate characters (function keys, arrow keys,
home/end keys, page keys, etc.). In all other cases, just
insert the high-bit ASCII character that was typed.
The Alt key is a useful and necessary modifier for shortcuts,
and it shouldn't be disabled. Also, the Control and Alt
mapping shouldn't be switched for Mac OS X - this is bad.
Logged In: YES
user_id=57630
this bug was submitted 10 months ago, and is unassigned / open?
i will be happy to test anyone's fixes, but can PLEASE this
be addressed? not being able to use such simple your
OS-standard features as "fwd-word" and "goto-end-of-line"
completely hamstrings an editor.
i'm hoping that this bug hasn't sat here for nearly a year
because it was submitted anonymously -- i'll happily
resubmit it under my sf.net ID if need be...
Logged In: YES
user_id=1160749
I'd like to submit my vote for prioritizing this issue as well: this is a
major inconvenience for OS X users. I've been waiting patiently for ages,
and nothing appears to have been done to resolve this.
I don't mean to sound like I'm giving an empty threat, but I'm coming to
the end of my patience and will probably break down and find a new
editor soon if this continues to go unresolved.
Logged In: YES
user_id=918212
Is this still an issue with 4.3preX?
Logged In: YES
user_id=1645264
Originator: NO
Yes, this is still and issue with 4.3pre8.
If you set
Debug.ALT_KEY_PRESSED_DISABLED = false;
you can get Alt key shortcuts, but you lose the Alt key combinations used by the keyboard layout.
Contrary to the original post, the correct behavior is to first look for a shortcut bound to the Alt + keycode combination and if found swallow the key event, otherwise
let the key event's character code pass through to the edit buffer. This is the way Apple's Xcode editor and all other Mac editors I can think of work.
Furthermore, if you set
Debug.ALT_KEY_PRESSED_DISABLED = false;
but you don't set
Debug.ALTERNATIVE_DISPATCHER = false;
there is another bug: the shortcuts preference pane displays shortcut key combinations involving Alt with the Unicode character code instead of the raw key code. For
example, if with a US keyboard layout I bind Alt-d to a command, it displays as M+<lowercase delta glyph> instead of M+<d glyph>
Logged In: YES
user_id=918212
Originator: NO
Xuan as you are familiar with the keyboard handling, could you look at this please? :-)
Logged In: YES
user_id=2280
Originator: NO
This is what the 'new keyboard handling' feature does.