> > 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
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