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

Re: Defining new visual-mode motions?

Expand Messages
  • Andy Wokula
    ... You could also try this: function VisualMove() call search( u ) return endfunction vmap ,w @=VisualMove() ... Entering Cmdline mode with ... turns
    Message 1 of 8 , Jun 2, 2007
      Joseph Barker schrieb:
      > On Friday 01 June 2007 13:11:50 you wrote:
      >> Joseph Barker schrieb:
      >>> Hello, all.
      >>>
      >>> I was recently helping someone out with a vim script
      >>> (camelcasemotion.vim) which adds additional motion commands (they treat
      >>> camel-cased words (WordsLikeThis) as separate words, rather than as a
      >>> single word). This is easy enough to do in normal and operator-pending
      >>> mode. It seems to be very complicated to do this in visual mode, though
      >>> -- calling a function (or anything that lets you move the cursor) seems
      >>> to force you to leave visual mode (i.e., doing `vmap ,w :<C-U>call
      >>> MoveCursor()` will move the cursor to the right place, but you're no
      >>> longer in visual mode).
      >>>
      >>> My approach to this was to call the movement function, set a mark,
      >>> select the previous visual block (with gv) and then jump to the mark
      >>> that was previously set. The mapping that I created to deal with this
      >>> is the following:
      >>>
      >>> vmap <silent> ,w @="\33:\25call
      >>> <SID>CamelCaseMotion('w',1,'v')"<CR><CR>m`gvg``
      >>>
      >>> This seems somewhat inelegant, and also clobbers a mark to be able to
      >>> accomplish its magic. Is there an easier way to accomplish the same
      >>> thing? It seems like there should be, but I was unable to figure one
      >>> out.

      You could also try this:

      function VisualMove()
      call search('\u')
      return ""
      endfunction

      vmap ,w @=VisualMove()<cr>

      >> The following is possible:
      >>
      >> function VisualMove()
      >> normal! gv
      >> call search('\u')
      >> " visual mode still on
      >> endfunction
      >>
      >> vmap ,w :<c-u>call VisualMove()<cr>
      >
      > That works perfectly, although I have no idea why. Can you explain? I would
      > think that calling `normal! gv` would have no effect, since that should
      > reselect the current selection. But for some reason it allows you to call
      > search() while staying in visual mode, which makes no sense to me. Perhaps
      > I'm not looking at the right place in the documentation.

      Entering Cmdline mode with
      :<c-u>call ...
      turns Visual mode off, therefore
      normal! gv
      reselects the visual area.

      Within a function (or script or Ex-mode), the visual area is not turned off
      between ex commands, because there is no actual mode switching
      ... IMHO.

      I don't know if this is mentioned in the help.

      --
      Regards,
      Andy
    • Yegappan Lakshmanan
      Hi, ... According to :help mode-switching , it is not possible to enter visual mode from Ex or command-line mode. Either the table under :help i_esc needs
      Message 2 of 8 , Jun 2, 2007
        Hi,

        On 6/2/07, Andy Wokula <anwoku@...> wrote:
        > Joseph Barker schrieb:
        >
        > >> The following is possible:
        > >>
        > >> function VisualMove()
        > >> normal! gv
        > >> call search('\u')
        > >> " visual mode still on
        > >> endfunction
        > >>
        > >> vmap ,w :<c-u>call VisualMove()<cr>
        > >
        > > That works perfectly, although I have no idea why. Can you explain? I would
        > > think that calling `normal! gv` would have no effect, since that should
        > > reselect the current selection. But for some reason it allows you to call
        > > search() while staying in visual mode, which makes no sense to me. Perhaps
        > > I'm not looking at the right place in the documentation.
        >
        > Entering Cmdline mode with
        > :<c-u>call ...
        > turns Visual mode off, therefore
        > normal! gv
        > reselects the visual area.
        >
        > Within a function (or script or Ex-mode), the visual area is not turned off
        > between ex commands, because there is no actual mode switching
        > ... IMHO.
        >
        > I don't know if this is mentioned in the help.
        >

        According to ":help mode-switching", it is not possible to enter visual mode
        from Ex or command-line mode. Either the table under ":help i_esc" needs
        to be updated or this needs to be fixed.

        According to that table, you can enter visual mode only from either normal or
        select modes.

        - Yegappan
      • Andy Wokula
        ... The following is possible: Q enter Ex mode normal v normal eee extend visual area visual quit Ex mode, enter Visual mode Hmm, seems the table needs
        Message 3 of 8 , Jun 2, 2007
          Yegappan Lakshmanan schrieb:
          > Hi,
          >
          > On 6/2/07, Andy Wokula <anwoku@...> wrote:
          >>
          >> Within a function (or script or Ex-mode), the visual area is not
          >> turned off
          >> between ex commands, because there is no actual mode switching
          >> ... IMHO.
          >>
          >> I don't know if this is mentioned in the help.
          >>
          >
          > According to ":help mode-switching", it is not possible to enter visual
          > mode
          > from Ex or command-line mode. Either the table under ":help i_esc" needs
          > to be updated or this needs to be fixed.
          >
          > According to that table, you can enter visual mode only from either
          > normal or
          > select modes.
          >
          > - Yegappan

          The following is possible:
          Q
          " enter Ex mode
          normal v
          normal eee
          " extend visual area
          visual
          " quit Ex mode, enter Visual mode

          Hmm, seems the table needs an update.
          Unfortunately, :visual is ambigious.

          --
          Regards,
          Andy
        Your message has been successfully submitted and would be delivered to recipients shortly.