Loading ...
Sorry, an error occurred while loading the content.

11943Re: Meta and Option keys simultaneously in MacVim

Expand Messages
  • björn
    Nov 10, 2010
    • 0 Attachment
      On 10 November 2010 17:15, Fabien Cazenave <fabi1.cazenave@...> wrote:
      > 2010/11/9 björn <bjorn.winckler@...>:
      >> On 7 November 2010 16:56, Kazé <fabi1.cazenave@...> 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
    • Show all 11 messages in this topic