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

Patch for mode() function

Expand Messages
  • Ben Schmidt
    Hi, Bram, 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
    Message 1 of 3 , Jun 2, 2008
    • 0 Attachment
      Hi, Bram,

      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?

      Ben.




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