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

Re: Patch for mode() function

Expand Messages
  • Bram Moolenaar
    ... 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
    Message 1 of 3 , Jun 2 12:45 PM
    • 0 Attachment
      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.

      --
      The acknowledged parents of reengineering are Michael Hammer and James Champy.
      When I say they're the "parents" I don't mean they had sex - and I apologize
      for making you think about it. I mean they wrote the best-selling business
      book _Reengineering the Corporation_, which was published in 1993.
      Businesses flocked to reengineering like frat boys to a drunken
      cheerleader. (This analogy wasn't necessary, but I'm trying to get my mind
      off that Hammer and Champy thing.)
      (Scott Adams - The Dilbert principle)

      /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Ben Schmidt
      ... 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
      Message 2 of 3 , Jun 2 7:10 PM
      • 0 Attachment
        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.

        Ben.





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