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

Re: MacVim.app - snapshot r231

Expand Messages
  • björn
    ... If only it were that simple! Part of the reason that I managed to implement client/server in such a relatively short amount of time is because of the way
    Message 1 of 3 , Sep 10 7:00 AM
    • 0 Attachment
      > > I've been hard at work trying to finish the client/server feature and
      > > now it is finally done...all the remote_* script functions (as well as
      > > server2client(), serverlist(), etc.) are supported, as is the 'wait'
      > > flag from the command line (e.g. --remote-wait now works). However, I
      > > have never used +clientserver functionality myself, so I need people
      > > to test that it actually works. Please, if you use +clientserver,
      > > then test the various aspects of it and let me know if it works or
      > > not.
      > You could put this into a separate patch that could be committed to
      > vim mainline (I guess these changes are all changes to vim code).
      > This might give you a few additional testers :-)

      If only it were that simple! Part of the reason that I managed to
      implement client/server in such a relatively short amount of time is
      because of the way MacVim works. This means that the client/server
      code is kind of MacVim specific...I say "kind of" because in theory it
      could be used for the Carbon port as well, but it would require some
      work. I apologize for not making it directly available to the Carbon
      port, but by specializing it to MacVim I could simplify the code quite
      a bit (and only with the benefit of hindsight did I realize how the
      code could have been made more general).

      I encourage anybody wanting to "port" the client/server code...I will
      gladly answer questions/give hints about the code to anybody taking on
      this task.

      By the way, I forgot to mention that as it stands only a GUI vim can
      become server, but both terminal&GUI vim can be clients...so maybe the
      implementation isn't as "complete" as I announced it to be. If
      anybody objects to this then speak up! (or fix it yourself...see the
      previous paragraph ;-))

      > > The only other change this week is to the shift-key mappings that
      > > enter visual or selection mode. I have decided to follow the HIG by
      > > default (so <S-Right> starts/expands selection and pressing Right
      > > without shift will stop selection).
      > This feels weird to me for a couple of reasons:
      > 1. Pressing shift-arrow in normal mode changes to selection mode. But
      > if I know press one of hjkl to expand the selection (I can't use the
      > arrow keys), the selected text is actually replaced -- this means
      > shift-arrow also enters insert mode.
      > 2. But it uses the "normal mode cursor" (box instead of caret)
      > 3. If I use shift-arrow in insert mode, it stays in insert mode (with
      > selection), but uses the "normal mode cursor" as well.
      > 4. It's not possible to select multiple lines by hitting shift-right
      > for a long time
      > 5. Even worse, if I select a word that goes until the end of the
      > screen with opt-shift-arrow, the word is selected and the cursor is
      > placed at the beginning of the next line. Hitting shift-right doesn't
      > move the selection further to the right (because the cursor really is
      > at the end of the previous line) and hitting shift-left does not move
      > the cursor to the left in the previous line (!) (hitting opt-shift-
      > left works, but...)
      > I don't like this change. I never use shift-arrows, so I don't really
      > care either. But this is really not intuitive or HIG-compliant. I
      > guess this is simply the default vim behaviour with your 'selectmode'
      > and 'keymodel' settings, but... :-\ Just saying.

      A lot of the above 'weirdness' is because it enters selection mode as
      opposed to visual mode (see 'h select-mode'). You can change this by
      clearing 'selectmode' (it is set to 'key,mouse'). I agree that the
      behaviour is a bit strange sometimes (particularly shift-right at the
      end of a line), but like you said: this is how Vim works with those
      'keymodel' and 'selectmode' settings. To actually make it HIG
      compliant the points you brought up (and maybe more) will have to be
      looked into. Still, it does make things behave a bit more like
      TextEdit so I don't think it is too bad as default behaviour (for the
      moment). Or is it?

      I don't know how important it is to fix things like these, since
      probably nobody uses them anyway (right?). So I could of course just
      take all that stuff out of the system gvimrc and be done with it. Is
      that less objectionable than having a semi-HIG default behaviour and
      having to set a variable to get default vim behaviour? I can't

      I generally try to stay away from the Vim codebase and just add things
      to MacVim where I can...so changing the 'keymodel'&'selectmode' code
      isn't something I really feel up to.

      > As for feature requests: (Transparent) session saving ;-)

      I like the idea too...will be thinking about that next.


      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.