Incompatibilities between ns-option-modifier and standard Cocoa TextView shortcuts

Incompatibilities between ns-option-modifier and standard Cocoa TextView shortcuts

[Grégory Guyomarc'h]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Hi,

I was wondering if it would be possible to have all standard Cocoa TextView key bindings working with Emacs (for example the one listed in http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html) and still be able to input dead keys like the €  sign (option+$ on a french keyboard). 

Now, I can do:

  (setq ns-option-modifier nil)

and have the dead keys work but then for example option + right arrow is map as [right] and I have no way to map the sequence to forward-word.

I can tell in nsterm.m (emacs 23.3 and bzr trunk)  that when the modifier is set to nil, the resulting emac event will always get the characters interpreted by the input manager without any modifiers set.

I guess it makes sense most of the time but looking at the Cocoa TextView key binding list, it seems that when the option key is used with:
 - arrow keys
 - return/enter
 - tab/backtab
 - page up/down/home/end
 - space/backspace/delete
and optionally with other modifiers that emacs could default to set a modifier on the emacs event (at first sight, it seems there is no risk to interfere with dead keys).

In short, wouldn't it makes sense to have something like:

  (setq ns-option-modifier 'alt-special) ;; and 'meta-special, etc

that would act like (setq ns-option-modifier nil) except when the character is one of the above.

Sincerely,
Grégory.

PS:

It seems there used to be an option that did something similar to what I wish for (mac-pass-option-to-system, but only when another modifier was used along with option key which does not cover cases like option + right arrow):
 
http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00661.html

That was some times ago, no trace of it in the current documentation.

[-- Attachment #2: Type: text/html, Size: 2566 bytes --]