Bram Moolenaar wrote:
> Ben Schmidt wrote:
>> I started this patch as it seemed a while ago some aspects it may be
>> helpful for MacVim. Recently I have dug it up and further revised it,
>> as I was coming across some other troubles using --remote-expr when
>> Vim is running in different modes. It extends the mode() function to
>> return a more full set of modes.
>> The one bearing most comment is the one for when a shell is running
>> (:shell in the GUI). I'm not entirely convinced having this as a
>> separate 'mode' is really the best thing. Hoewver, the alternative
>> would be somehow delaying a server's processing and reply to
>> --remote-expr et al. and I suspect this is pretty non-trivial. Having
>> mode() return something different is a good step even if it isn't the
>> final one, I think.
>> Would you be able to include this?
> Problem with this change is that it's not backwards compatible. E.g.,
> currently Vim would return "n" in operator-pending mode, after the
> change it would return "o".
> How about giving mode() an argument? When present and non-zero it would
> switch to return more information. I would then return both the "major"
> mode and the detail. E.g., for Vim Ex mode it would be "cv", normal Ex
> mode "ce" and for command-line mode "c". Then for those places where it
> doesn't matter what kind of command-line mode is being used you would
> only check the first letter. Also makes it easier for future changes,
> so long as it fits in the current "major" modes.
Yep, sounds good. Here's a revised patch.
I made the '-- more --' prompt a separate minor mode, as that seemed
sensible--can't really see any use for the distinction, but better to have it than
try to add it later once we figure out what it's for and then have more
compatibility issues (no pun intended!).
I kept '!' as a major mode as really none of the other modes apply--even though
the function used to return 'n', it's not necessarily true that you will be in
normal mode after an external command finishes. So I'd view that change as a
bugfix not a breaking of compatibility. If you think that's a bad call, it could
be changed to 'n!' I suppose.
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php