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

Re: FW: Select-mode mappings

Expand Messages
  • A. J. Mechelynck
    ... Hello Luc, I confess I haven t thought this thing out. Maybe not including smap in vmap by default would be better after all. The reason I sent that post
    Message 1 of 3 , Nov 14, 2005
    • 0 Attachment
      hermitte@... wrote:
      > Hello Zdenek.
      > Hello Tony.
      >
      > Tony, Zdenek pointed me to your RFE. If you do not mind, I have a few
      > comments -- a little bit disordered. Tonight, I'll try to find a moment
      > to register to the vimdev list and post them there if you are ok with
      > it.
      >
      > To replace the context, Zdenek knew I wish there was s-mapping as it
      > would have eased the definition of the bracketing system I'm maintening
      > and all the ftplugins that rely on it. BTW, vim-latex and mu-template
      > that use similar bracketing systems, may also take advantage of
      > s-mappings ; in other words, it does not only concern matchit -- which
      > is a very good example, as it is "standard" one.
      >
      > Zdenek Sekera <Zdenek.Sekera@...> wrote:
      >
      >> was it about what you wanted also? Maybe it's a good time to add your
      >> ideas to it. Bram will be back soon...!
      >> (H may of course reject any of it anyway, hmmm...)
      >
      > That is indeed a good start. Thanks you for pointing me to Tony's RFE.
      >
      > Tony wrote:
      >> [...]
      >> (assuming that, for downwards compatibility, "vmap" would still mean
      >> "mapping for Visual and Select mode").
      >
      > I think it would be definitively better that the default :vmap does not
      > imply a :smap.
      > May be it could be interresting to have an option that tells whether we
      > want a downwards compatibility with previous versions of vim for those
      > who only work in select mode and are not aware of the visual mode.
      > The default value of this version could enforce the downwards
      > compatibility. Or even better, the default value could break the
      > downwards compatibility, while mswin.vim and cream-project enforce it.
      > Those among us not sourcing mswin.vim, but still using select-mode are
      > more likely, IMHO, to need the distinction.
      > (I also though of banging vmap, but it would definitivelly be too
      > complex)
      >
      > For those using both modes, like I do, having the default vmap to imply
      > smap complexify things as we may need to explicitly :sunmap all the
      > v-mappings when there is no i-mappings -- in case of i-mappings, we
      > (ftplugins developpers) need to bind the s-mappings to the corresponding
      > i-mappings. I do not know if I am very clear. If not, I have plenty
      > examples directly coming from my ftplugins.
      >
      > Moreover, what if we bind, in the order,
      > :snoremap <leader>foo <c-\><c-n>gvsfoo
      > :vnoremap <leader>foo <c-\><c-n>:call Surround(...)<cr>
      > Will the v-mapping override the s-mapping ?
      >
      >
      > --
      > Luc Hermitte
      >
      >
      >

      Hello Luc,

      I confess I haven't thought this thing out. Maybe not including smap in
      vmap by default would be better after all. The reason I sent that post
      was that I got bugged by those mappings from matchit preventing letters
      like a or g from replacing the selection. (And yes, I use matchit and I
      use both visual and select modes depending on whether I want printable
      keys to replace the selection or to act as in Normal mode.)

      Best regards,
      Tony.
    • A. J. Mechelynck
      Message 2 of 3 , Nov 15, 2005
      • 0 Attachment
        slicebabies wrote:
        > I just want to reaffirm that this is an important issue. Definitely
        > there should be a way to prevent v-mappings to interfere with
        > behavior in select mode, which should basically be the behavior of
        > selection in almost every editor (replace this text).
        >
        > There are many v-mappings I have that mess up the functionality of
        > select mode for me.
        >
        > V-mappings are useful in select mode if they are complicated
        > sequences (ex. C-M-f; which for me, inserts "//" in front of every
        > selected line (useful for coding)). But for regular characters, there
        > definitely needs to be an sunmap feature.
        >
        > I don't believe there HAS to be an smap. The reason being there's
        > little need to want to map something separately for select mode, as
        > it's obscuring the idea and purpose behind select mode. Of course,
        > there's the other issue that smap followed by vmap... what happens
        > then? The backwards compatibility is annoying.
        >
        > So basically, there simply should be an sunmap. And whatever location
        > it appears in (above or below vmaps), it should still work and
        > effectively disable the particular vmap in select mode.
        >
        > Without a doubt this is an important issue. Vim is a modal editor.
        > Its modes should work well.
        >
        > --- In vimdev@yahoogroups.com, "A. J. Mechelynck"
        > <antoine.mechelynck@s...> wrote:
        >> hermitte@f... wrote:
        >>> Hello Zdenek.
        >>> Hello Tony.
        >>>
        >>> Tony, Zdenek pointed me to your RFE. If you do not mind, I have a
        > few
        >>> comments -- a little bit disordered. Tonight, I'll try to find a
        > moment
        >>> to register to the vimdev list and post them there if you are ok
        > with
        >>> it.
        >>>
        >>> To replace the context, Zdenek knew I wish there was s-mapping as
        > it
        >>> would have eased the definition of the bracketing system I'm
        > maintening
        >>> and all the ftplugins that rely on it. BTW, vim-latex and mu-
        > template
        >>> that use similar bracketing systems, may also take advantage of
        >>> s-mappings ; in other words, it does not only concern matchit --
        > which
        >>> is a very good example, as it is "standard" one.
        >>>
        >>> Zdenek Sekera <Zdenek.Sekera@c...> wrote:
        >>>
        >>>> was it about what you wanted also? Maybe it's a good time to add
        > your
        >>>> ideas to it. Bram will be back soon...!
        >>>> (H may of course reject any of it anyway, hmmm...)
        >>> That is indeed a good start. Thanks you for pointing me to Tony's
        > RFE.
        >>> Tony wrote:
        >>>> [...]
        >>>> (assuming that, for downwards compatibility, "vmap" would still
        > mean
        >>>> "mapping for Visual and Select mode").
        >>> I think it would be definitively better that the default :vmap
        > does not
        >>> imply a :smap.
        >>> May be it could be interresting to have an option that tells
        > whether we
        >>> want a downwards compatibility with previous versions of vim for
        > those
        >>> who only work in select mode and are not aware of the visual mode.
        >>> The default value of this version could enforce the downwards
        >>> compatibility. Or even better, the default value could break the
        >>> downwards compatibility, while mswin.vim and cream-project
        > enforce it.
        >>> Those among us not sourcing mswin.vim, but still using select-
        > mode are
        >>> more likely, IMHO, to need the distinction.
        >>> (I also though of banging vmap, but it would definitivelly be too
        >>> complex)
        >>>
        >>> For those using both modes, like I do, having the default vmap to
        > imply
        >>> smap complexify things as we may need to explicitly :sunmap all
        > the
        >>> v-mappings when there is no i-mappings -- in case of i-mappings,
        > we
        >>> (ftplugins developpers) need to bind the s-mappings to the
        > corresponding
        >>> i-mappings. I do not know if I am very clear. If not, I have
        > plenty
        >>> examples directly coming from my ftplugins.
        >>>
        >>> Moreover, what if we bind, in the order,
        >>> :snoremap <leader>foo <c-\><c-n>gvsfoo
        >>> :vnoremap <leader>foo <c-\><c-n>:call Surround(...)<cr>
        >>> Will the v-mapping override the s-mapping ?
        >>>
        >>>
        >>> --
        >>> Luc Hermitte
        >>>
        >>>
        >>>
        >> Hello Luc,
        >>
        >> I confess I haven't thought this thing out. Maybe not including
        > smap in
        >> vmap by default would be better after all. The reason I sent that
        > post
        >> was that I got bugged by those mappings from matchit preventing
        > letters
        >> like a or g from replacing the selection. (And yes, I use matchit
        > and I
        >> use both visual and select modes depending on whether I want
        > printable
        >> keys to replace the selection or to act as in Normal mode.)
        >>
        >> Best regards,
        >> Tony.
        >>
        >
        >
        >
        >
        >
        >
        >
      • Luc Hermitte
        Hello, ... I won t say the sunmap is enough. Moreover, I d rather have :vmap to not imply :smap when we :behave xterm (instead of mswin). For non-printable
        Message 3 of 3 , Nov 15, 2005
        • 0 Attachment
          Hello,

          slicebabies wrote:
          > I just want to reaffirm that this is an important issue. Definitely
          > there should be a way to prevent v-mappings to interfere with
          > behavior in select mode, which should basically be the behavior of
          > selection in almost every editor (replace this text).
          >
          > There are many v-mappings I have that mess up the functionality of
          > select mode for me.
          >
          > V-mappings are useful in select mode if they are complicated sequences
          > (ex. C-M-f; which for me, inserts "//" in front of every selected line
          > (useful for coding)). But for regular characters, there definitely
          > needs to be an sunmap feature.

          I won't say the sunmap is enough. Moreover, I'd rather have :vmap to not
          imply :smap when we :behave xterm (instead of mswin). For non-printable
          sequence, (ft)plugin-writter can still bind explicitly to :vmap and to
          :smap.

          IHMO, It is neater this way than the other way.

          > I don't believe there HAS to be an smap. The reason being there's
          > little need to want to map something separately for select mode, as
          > it's obscuring the idea and purpose behind select mode. Of course,
          > there's the other issue that smap followed by vmap... what happens
          > then?

          Actually, I do need in my plugins & ftplugins to be able to write some
          :smap that are not :vmap.

          It is all tied to the "hijacking" of the select-mode that is beeing done
          in my bracketing-system. When code-snippets are inserted, markers
          (/placeholders) are placed at points where we are likely to insert
          things. Then pressing <c-j>, we jump from one marker to the other. The
          marker we jump to is selected (as in SELECT-mode). This way, inserting
          "int i=0" or "()<+another_marker+>" is strait forward.
          (vim-latex and mu-template have similar behaviours).

          At this point, I have some mappings (that could not be abbreviations).
          Like for instance:
          - An imap on "(" that inserts "()<+marker+>"
          - A vmap on "(" that surrounds the selection with parenthesis.
          Here I would like to have a :smap that would do exactly the same thing
          as the :imap.
          Something like -> :smap ( <c-\><c-n>gvs(

          Of course, I could have chosen other bindings that would have alleviate
          my need for :smap, or not hijack the select-mode.
          Note: Actually, today all my surrounding mappings test for what is
          selected in order to guess the current mode (visual or select). However,
          is it impossible to patch every other vmappings loaded.

          > The backwards compatibility is annoying.

          It is indeed. However, I think we may rely on :behave to tell whether
          the backwards compatibility must be kept the time (ft)plugins writers
          update their plugins.

          > So basically, there simply should be an sunmap. And whatever location
          > it appears in (above or below vmaps), it should still work and
          > effectively disable the particular vmap in select mode.

          But how can we tell, we want it to behave almost like a :imap ?

          Best regards.

          PS: sorry for the thread being broken, I missed the message-id of
          slicebabies' email.
          --
          Luc Hermitte
          http://hermitte.free.fr/vim/
        Your message has been successfully submitted and would be delivered to recipients shortly.