392254 - Implement all NSResponder's action messages such as 'insertLineBreak' and 'insertTab'

Status: NEW

(Core :: Widget: Cocoa, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

this is spun off from bug 276093.

We should implement 'insertLineBreak' and 'insertTab'. But I don't know that what applications are using them.

http://developer.apple.com/documentation/Cocoa/Conceptual/Strings/Articles/stringsParagraphs.html#//apple_ref/doc/uid/TP40005016-SW1

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I'm resetting bugs which are assigned to me but I'm not working on them and I don't have plan for fixing them in near future.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Doing this kind of thing has the potential to resolve problems with OS-level customizations of keyboard shortcuts (e.g. bug 429824).  I've been thinking about this for a couple of years ... though I've never found the time to work on it.

So I'm going to provisionally assign this bug to myself, though I have no idea when I'll have time to get to it.

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

smichaud:

Yes, this is necessary for integrating the OS-level key customization. However, I think it's not enough.

I think that we need to do:

1. All DOM keypress events should be dispatched from insertText or each command handler. If some key events don't trigger both of them, we should dispatch it in keyDown after called interpretKeyEvents:
2. We need to implement more content command events for all action messages of NSResponder, and if the handler is called when we're not handling a native key event, we should dispatch the content command event instead.
3. We should add a member such as |command| to nsKeyEvent, and which should have the content command event ID if these action handler dispatches the keypress event.
4. We need to remove all shortcut key definition for editor only on Mac.
5. We need to make editors reference nsKeyEvent::command.

Maybe, I'll have time for working on these issues in November or December because I don't have any plans which change cocoa widget. So, I might be able to work on them with other bugs. If you don't have much time, I'll take this when I have time. Is it ok? If you start working on this bug before me, please mark this bug as "ASSIGNED".

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, there is another issue. We *cannot* call interpretKeyEvents when IME is disabled because interpretKeyEvents always sends the key event to IME. For the IME disabled situation, we need to read two dictionaries ourselves. They are:

/System/Library/Frameworks/AppKit.framework/Resources/StandardKeyBinding.dict
~/Library/KeyBindings/DefaultKeyBinding.dict

I'm worry the performance of this...

Comment 5

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #3)

> Maybe, I'll have time for working on these issues in November or
> December because I don't have any plans which change cocoa
> widget. So, I might be able to work on them with other bugs. If you
> don't have much time, I'll take this when I have time. Is it ok? If
> you start working on this bug before me, please mark this bug as
> "ASSIGNED".

Feel free to take this bug back whenever you want :-)

In the unlikely	event that I get close to finding a full-scale fix for
this bug, I'll mark it ASSIGNED	to myself.

(In reply to comment #4)

This is very unfortunate, and not just for performance reasons.

If I have some time (not very likely), I'll try to find some other way
to work around this problem.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I still think it'd be worthwhile to do this, but I'll almost certainly never have the time.