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

Re: Fwd:Fwd:Select-mode mappings

Expand Messages
  • 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 1 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.