On 10 November 2010 17:15, Fabien Cazenave <[email protected]> wrote:
> 2010/11/9 björn <[email protected]>:
>> On 7 November 2010 16:56, Kazé <[email protected]> wrote:
>>> Hello,
>>>
>>> with MacVim, the "macmeta" currently allows to use both "Option" keys
>>> either as "Meta" or "AltGr". Like a lot of European users, I'd prefer
>>> the "macmeta" pref to set only one "Option" key as "Meta" (e.g. the
>>> left one, as it works on Windows and GNU/Linux) and keep the other one
>>> for special characters on non-English keyboard layouts.
>>>
>>> In case someone is interested if having both a Meta key *and* an
>>> Option key when "macmeta" is set, here's a quick and dirty patch:
>>>
>>> diff --git a/src/MacVim/MMTextViewHelper.m b/src/MacVim/
>>> MMTextViewHelper.m
>>> index 4d10432..42f311b 100644
>>> --- a/src/MacVim/MMTextViewHelper.m
>>> +++ b/src/MacVim/MMTextViewHelper.m
>>> @@ -22,6 +22,9 @@
>>> #import "MMWindowController.h"
>>> #import "Miscellaneous.h"
>>>
>>> +// asymetric meta keys
>>> +#define NSLeftAlternateKeyMask (0x000020 | NSAlternateKeyMask)
>>> +#define NSRightAlternateKeyMask (0x000040 | NSAlternateKeyMask)
>>>
>>> // The max/min drag timer interval in seconds
>>> static NSTimeInterval MMDragTimerMaxInterval = 0.3;
>>> @@ -165,7 +168,8 @@ KeyboardInputSourcesEqual(TISInputSourceRef
>>> a,TISInputSourceRef b)
>>> // ASCII chars in the range after space (0x20) and before
>>> backspace (0x7f).
>>> // Note that this implies that 'mmta' (if enabled) breaks input
>>> methods
>>> // when the Alt key is held.
>>> - if ((flags & NSAlternateKeyMask) && [mmta boolValue] && [unmod
>>> length] == 1
>>> + if (((flags & NSLeftAlternateKeyMask) == NSLeftAlternateKeyMask)
>>> + && [mmta boolValue] && [unmod length] == 1
>>> && [unmod characterAtIndex:0] > 0x20
>>> && [unmod characterAtIndex:0] < 0x7f) {
>>> ASLogDebug(@"MACMETA key, don't interpret it");
>>>
>>> This is just a trivial adaptation of this iTerm patch:
>>> http://swissarmyhammer.wordpress.com/2010/06/07/osx-terminal-meta-key-national-characters/
>>> I think a proper MacVim integration would require to modify the
>>> 'macmeta' stuff, e.g. by using a string pref instead of a boolean one:
>>>
>>> * set macmeta=l => left Option key is Meta
>>> * set macmeta=r => right Option key is Meta
>>> * set macmeta=rl => both Option keys are Meta
>>> * set macmeta= => no Meta key
>>>
>>> Thoughts?
>>
>> Hi,
>>
>> I can see that this sort of behavior would be useful for non-english
>> keyboard layouts. Perhaps an easier solution (implementation-wise)
>> than modifying the 'macmeta' option (and one that doesn't break
>> backwards compatibility) would be to have a user default to set which
>> key is used as meta when 'macmeta' is enabled. This way it would be
>> an app-level setting so all windows would use the same setting -- I
>> don't know if this is a disadvantage or not (perhaps it is a bit
>> confusing?).
>>
>> Anyway, that was just a though...I don't know which solution is better
>> (making 'macmeta' a string option, or adding a user default). Does
>> anybody else have any comments about this?
>>
>> I'm not against merging such a patch...
>>
>> Björn
>
> I think it won't make a big difference to the user if we keep a
> boolean pref for "macmeta" and add a string pref (e.g. "macmetakeys")
> to define which Option keys should be handled as Meta. The only
> problem I can see is that it could be a little confusing if "macmeta"
> is set to "true" but "macmetakeys" is empty -- though that could be
> partly avoided if "macmetakeys" is set to "l" or "rl" by default.
This sounds bad. My suggestion was to have a user default, e.g.
MMWhichMeta with values 0=both (default), 1=left, 2=right. This avoid
cluttering the core Vim source code (something I try hard to avoid)
and the patch would not require much source code.
Alternately turn 'macmeta' into a string option ("lr","l","r") but I
was under the impression that you'd once and for all decide which
option key works as meta and then set 'macmeta' on/off per buffer. If
this is true then this alternative seems worse to me.
> However, if we have two prefs for the Meta keys we might want to add a
> third one to define whether the Meta key sets the 8th bit (= current
> behavior, like on gVim and xterm) or if it sends Escape instead (=
> like on most modern terminal emulators like *rxvt by default):
> * set nomacmetaescape => map <M-a> :exe "myFunc()"<CR>
> * set macmetaescape => map <Esc>a :exe "myFunc()"<CR>
> With such a setting, Meta-* shortcuts wouldn't be easy to use in
> insert mode but it could be appreciated by users who want an 8-bit
> clean MacVim *and* an Option key *and* a Meta key (if I'm the only one
> in this category, please don't tell me :-/). That's what has been
> implemented in the final iTerm patch I mentioned in my first message.
You are losing me now. All I see is "let's add LOTS more options!
(tm)". The general philosophy here should be "avoid adding more
(Vim-) options at all cost".
I don't really understand the issue with setting the 8th bit or
sending escape, but since Vim already sets the 8th bit it seems like a
very bad idea to change this behavior for the Mac only. Remember that
Vim is not a terminal emulator (as opposed to iTerm which you
mentioned in passing).
Björn
--
You received this message from the "vim_mac" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
