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

Re: Proposal for "v:cmdmodifiers" (and a patch)

Expand Messages
  • Bob Hiestand
    ... If you change that to: exec v:cmdmodifiers[ split ] split s:windowName ... then you have what I requested. The split entry of v:cmdmodifiers would
    Message 1 of 8 , Oct 2, 2009
    • 0 Attachment
      On Thu, Oct 1, 2009 at 5:20 PM, Hari Krishna Dara <hari.vim@...> wrote:
      >
      > On Thu, Oct 1, 2009 at 7:41 AM, Bob Hiestand <bob.hiestand@...> wrote:
      >> I'd prefer to see a separate way to access each modifier, though maybe
      >> that could be something like v:cmdmodifier["split"].  In any event, I
      >> would love this feature.
      >
      > That is not convenient for most of the use cases. E.g., to modify the
      > window split behavior, the user could have specified any of "top",
      > "vertical", "leftabove", "rightbelow", "topleft" etc., so would you
      > search for each of the flags to compose the modifiers to pass down to
      > the final split your plugin is going to perform, instead of a simple
      > pass through like this?
      >
      >  exec v:cmdmodifiers 'split' s:windowName
      >
      > I think the sweet spot is a single string, but with any modifiers
      > expanded to their full name, as it serves all the needs.

      If you change that to:

      exec v:cmdmodifiers['split'] 'split' s:windowName

      ... then you have what I requested. The 'split' entry of
      v:cmdmodifiers would contain all the split-specific modifiers. I
      can't think of other command-modifying commands off-hand; :silent and
      :verbose already are available in variable form.

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Hari Krishna Dara
      ... There would also be v:cmdmodifiers[ tab ] that is of use here. And also :keepalt and may be others in the future. I think a string that has all expanded
      Message 2 of 8 , Oct 2, 2009
      • 0 Attachment
        On Fri, Oct 2, 2009 at 1:26 PM, Bob Hiestand <bob.hiestand@...> wrote:
        >
        > On Thu, Oct 1, 2009 at 5:20 PM, Hari Krishna Dara <hari.vim@...> wrote:
        >>
        >> On Thu, Oct 1, 2009 at 7:41 AM, Bob Hiestand <bob.hiestand@...> wrote:
        >>> I'd prefer to see a separate way to access each modifier, though maybe
        >>> that could be something like v:cmdmodifier["split"].  In any event, I
        >>> would love this feature.
        >>
        >> That is not convenient for most of the use cases. E.g., to modify the
        >> window split behavior, the user could have specified any of "top",
        >> "vertical", "leftabove", "rightbelow", "topleft" etc., so would you
        >> search for each of the flags to compose the modifiers to pass down to
        >> the final split your plugin is going to perform, instead of a simple
        >> pass through like this?
        >>
        >>  exec v:cmdmodifiers 'split' s:windowName
        >>
        >> I think the sweet spot is a single string, but with any modifiers
        >> expanded to their full name, as it serves all the needs.
        >
        > If you change that to:
        >
        > exec v:cmdmodifiers['split'] 'split' s:windowName
        >

        There would also be v:cmdmodifiers['tab'] that is of use here. And
        also :keepalt and may be others in the future. I think a string that
        has all expanded modifiers is simpler to use than a dictionary for
        most plugins.

        Would v:cmdmodifiers['split'] return a string of all modifiers or just
        the internal flag cmdmod_T.split? What about others that are just
        boolean flags? Would v:cmdmodifiers['keepjumps'] either return a blank
        string or the string 'keepjumps' depending on whether the flag is set
        or not? What about tab? Would it return the tab number, or the
        "[count]tab" string?

        --
        Thanks,
        Hari


        > ... then you have what I requested.  The 'split' entry of
        > v:cmdmodifiers would contain all the split-specific modifiers.  I
        > can't think of other command-modifying commands off-hand; :silent and
        > :verbose already are available in variable form.
        >
        > >
        >

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Bram Moolenaar
        ... To avoid overhead for each executed command, the information about which modifiers are active should only be handled when needed. It s hardly ever used,
        Message 3 of 8 , Oct 4, 2009
        • 0 Attachment
          Hari Krishna Dara wrote:

          > I would like to propose a new v: variable that makes any command
          > modifiers specified to the current user-command available to the
          > scripts as a string. This I think is very useful to create
          > user-defined commands that are more "flush" with the built-in commands
          > and in general work as a newbie would expect. Currently any modifiers
          > specified before a user-defined command are ignored. From the source,
          > I noticed that they are actually processed but there is no way to
          > expose them to the scripts, so there is no way to take advantage of
          > them.
          >
          > As one use case, let us say you create a replacement for a built-in
          > command to enhance the functionality, but as a result, you loose the
          > ability to recognize modifiers. I.e., you can say "vert diffsplit" or
          > "confirm q" but you can't say "vert DiffSplit" or "confirm Q".
          >
          > As another use case, plugins have to create multiple variants of a
          > user-defined command, to different modifiers, or global variables (as
          > settings) that can't change for each command. While these are useful
          > by themselves, in most cases they are trying to solve the inability to
          > read modifiers from the script.
          >
          > As a first cut approach, I tried this below change and it seems to
          > work nicely. One big drawback with this simplistic change is that the
          > same string that user specified is exposed, so if required, the burden
          > to parse falls on the script (especially that Vim allows typing
          > partial command, as long as it is unambiguous). However, it is still
          > useful for most cases when the modifiers will be literally passed down
          > to one of the built-in commands that the script executes, something
          > like this:
          >
          > command! UDC call UDC()
          > func! UDC()
          > .
          > .
          > exec v:cmdmodifiers 'split' s:windowName
          > .
          > .
          > endfunc
          >
          > Ideally, the internal "cmdmod" is exposed such a way that the
          > individual flags are accessible, or we can even try to expose each one
          > of the flags as a separate v: variable (which should be easier
          > compared to the former), but I will leave this discussion to the
          > exerts (in which case the below change can still serve as a
          > prototype). I am not too comfortable programming in c, so please
          > excuse me if I missed any obvious things.

          To avoid overhead for each executed command, the information about which
          modifiers are active should only be handled when needed. It's hardly
          ever used, thus setting v:cmdmodifiers on each command is not a good
          idea.

          A function could be used, which can then also handle the "silent" flag,
          which doesn't appear in cmdmod and handle other border cases.

          getmodifier("silent")
          getmodifier("vertical")

          It's easy to extend when more modifiers might be added.

          How about that?

          --
          E M A C S
          s e l o h
          c t t n i
          a a t f
          p r t
          e o
          l

          /// 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
          -~----------~----~----~----~------~----~------~--~---
        Your message has been successfully submitted and would be delivered to recipients shortly.