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

Re: adding modes

Expand Messages
  • Tony Mechelynck
    ... Command-LINE mode. Command mode is an older synonym, still used in parts of the help, for Normal mode . See :help command-mode if you don t believe
    Message 1 of 16 , Jul 13, 2009
      On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote:
      >
      > Saluton Roald :)
      >
      > Roald<d...@...> dixit:
      >> Questions: can I add modes?
      >
      > Not exactly, but using mappings and some scripting you can achieve what
      > you want. Just define mappings for normal mode.
      >
      >> If not: is there a good reason for that?
      >
      > Current design, I suppose. Moreover, if you think about it, there's
      > plenty of things that doesn't belong to an editor (browsing files, for
      > example) but that you can add to an editor and that in fact are present
      > in Vim: if you add a mode for each and every of them you will end up
      > with dozens of modes, and it doesn't make sense.
      >
      > The usage pattern you explained in your message doesn't make sense as a
      > mode for me, because those actions belong to "normal" mode.
      >
      > Current design is, IMHO, perfect. You have normal mode for performing
      > editing tasks, visual mode to visually perform editing tasks and
      > command mode for ex commands.

      Command-LINE mode. "Command mode" is an older synonym, still used in
      parts of the help, for "Normal mode". See ":help command-mode" if you
      don't believe me.

      > Operator pending mode is not exactly a
      > mode, but a helper to be able to fine tune normal mode mappings, and
      > insert mode is not a mode at all (although it is treated like that to
      > make defining maps easier), but the result of a command in normal mode
      > (namely the "i" or "a" commands, for example).

      About Insert mode, I believe the opposite. Vim has two great families of
      modes, namely some in which the letters you type appear on the screen
      and can be removed in a different sequence (mainly Insert mode, Replace
      mode and Command-line mode -- with its Ex-command, Search-before and
      Search-back variants) and those in which they act immediately, possibly
      after you press several keys in succession, but in that case you cannot
      edit the sequence, you can either abort it, or, in some cases, remove
      only the last keys hit, by backspacing over them in LIFO sequence --
      these are Normal mode, Visual mode (including its characterwise,
      linewise and blockwise variants, as well as Select mode), and
      Operator-pending which is where you are when entering the movement or
      object after an action command.

      >
      > Usually Vim is called "modal" because it can be in "insert mode" or
      > "normal mode". I don't consider things like that. I prefer to consider
      > Vim as a command-driven application, one of the commands insert text,
      > other allows for visual selections, other runs ex commands etc. It's all
      > about commands, just that.

      If "insert text" is just "one command" until you leave Insert mode...
      well, I won't deny that to part of the Vim C code it is that, but
      thinking that, when I enter a new file, I'll be partway inside "one long
      command" for I don't know how long until, after having hit Esc (which is
      part of that long command but signals it end) I'll finally hit
      ":wq<Enter>" (a second command) to quit Vim... well, that's just
      impractical for a flesh-and-blood person who can hardly conceive that
      the long job of typing all the data in one file is "the same kind of
      stuff" as ":wq" and that he used exactly two commands during that long
      session. (And when I hit F3 in Insert mode, which is imapped to
      <C-O>:wa|wv<CR> , to me it isn't ending one command, doing two other
      commands, and starting a fourth one, it's just one action to save the
      file, and that is "part" of Insert mode. I might admit that after I
      previously went "down" from Normal to Insert, this goes "down" one
      further level to Normal mode, and from there to Command-line mode, as
      part of a mapping --which, on other programs, might be called a
      macro-instruction-- but I'll hold steadfastly that Insert-mode hasn't
      been abandoned, it is "pending" all the while that that mapping
      executes, and finally the mapping goes back to it the way a subroutine
      returns to its caller.)

      >
      > In you case you want commands that are easier to type than Ctr-w w for
      > changing windows, not a new mode with a new set of mappings.
      >
      > My suggestion is that you can use unmapped keys to perform the actions
      > you use the most with just one keypress, or even use already mapped keys
      > you don't use, or use a mapleader, etc. For example, I use "gqip" a lot,
      > so I've mapped "çç" to do that ("ç" is my mapleader), I've mapped "çc"
      > to comment a block of visually selected lines, etc. Mappings are your
      > friends, not new modes ;)

      Yes, here I agree. If you find that you don't like using Ctrl-W all the
      time, you can map it to something else, and if your keyboard is a
      US-QWERTY with no accented letters, you can still use

      :map <F5> <C-W>

      and hit F5 (with one finger) wherever the help says to hit Ctrl-W (which
      requires two fingers).

      >
      >> If not: is there any chance of it being implemented?
      >
      > I can't speak for Bram, but I would bet that it won't ;)
      >

      Actually, you could say that Ctrl-W starts a "new mode" with a duration
      of just one keypress, then goes back to Normal mode -- reminds me of
      "three-shift" alphabets I knew on the mainframes of some decades ago,
      but let's not delve into that. i_Ctrl-X also starts a kind of "new mode"
      (autocompletion) with a somewhat longer duration; it ends (by going back
      to Insert mode) as soon as you hit a key that it doesn't recognise. And
      i_CTRL-O "embeds" exactly one Normal-mode command into Insert mode.

      The reason that Bram -- reluctantly, I'm sure, since he doesn't like
      Emacs ;-) -- had to recruit these control keys, was that all or almost
      all "ordinary" keys already did something, and that he intentionally
      wanted to leave the F keys (other than F1 = Help and, on some systems,
      F10 = Menu) to "the user's choice". Fn and Shift-Fn keys are your "best
      choices" as {lhs} for mappings. (On Windows, but not on the Linux system
      I'm using now, Ctrl-Fn and Alt-Fn may also be used, I think. And if I
      can't use them, it isn't gvim's fault but the fault of the window
      manager, which snaps them away before Vim has a chance to see them.)


      Best regards,
      Tony.
      --
      History, n.:
      Papa Hegel he say that all we learn from history is that we
      learn nothing from history. I know people who can't even learn from
      what happened this morning. Hegel must have been taking the long
      view.
      -- Chad C. Mulligan, "The Hipcrime Vocab"

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Tony Mechelynck
      ... The problem with that is that you re masking existing (and useful) functions. For instance, I constantly use Ctrl-K as the digraph prefix (the option to
      Message 2 of 16 , Jul 13, 2009
        On 13/07/09 18:08, Ingo Karkat wrote:
        >
        > On 13-Jul-09 15:04, Roald wrote:
        >> I'm using vim for about half a year now, so no expert yet. I like the
        >> modal idea, and not needing to do control-anything all the time. But I
        >> also think this could be taken further. For example: switching between
        >> windows now requires C-w j etcetera - not so convenient, especially
        >> not on my macbook keyboard. I would like to be able to add an extra
        >> mode for browsing through files (switching windows, buffers and
        >> scrolling). But modes seem to be hard-coded in vim.
        >>
        >> Questions: can I add modes? If not: is there a good reason for that?
        >> If not: is there any chance of it being implemented?
        >
        > The default window navigation commands are a bit tedious, I mapped CTRL-JKHL to
        > go to the window in that direction:
        > nnoremap<C-j> <C-w>j
        > etc.

        The problem with that is that you're "masking" existing (and useful)
        functions. For instance, I constantly use Ctrl-K as the digraph prefix
        (the option to use X <BS> Y instead of <C-K> X Y is more trouble than it
        is useful IMO); Ctrl-L is the "redraw" key, very useful when something
        goes "half wrong", and so forth.

        > If CTRL isn't placed convenient, you can also use ALT/META.

        and Alt/Meta means "set the high bit" which means that it conflicts with
        accented letters -- even in English (as spelled by the Oxford
        Dictionary), words like risqué, résumé (as in "summary" or "curricumum
        vitæ", not "continue after a halt"), garçon, señorita, and others, are
        written with such accented letters -- yeah, I know they are "foreign
        words" which haven't yet fully "made their way" into the language, but
        if you map Alt-i to something you'll get a bad surprise if someday you
        want to write the word risqué the way it ought to be written. To Vim,
        é-acute and Alt-i are undistinguishable from each other.

        >
        > -- regards, ingo

        Best regards,
        Tony.
        --
        hundred-and-one symptoms of being an internet addict:
        72. Somebody at IRC just mentioned a way to obtain full motion video without
        a PC using a wireless protocol called NTSC, you wonder how you never
        heard about it



        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • James Vega
        ... That s in insert mode not normal mode. Therefore, not a conflict. ... I find that doing :syn sync fromstart is usually a better fix. only fixes
        Message 3 of 16 , Jul 13, 2009
          On Tue, Jul 14, 2009 at 12:46:37AM +0200, Tony Mechelynck wrote:
          >
          > On 13/07/09 18:08, Ingo Karkat wrote:
          > > The default window navigation commands are a bit tedious, I mapped CTRL-JKHL to
          > > go to the window in that direction:
          > > nnoremap<C-j> <C-w>j
          > > etc.
          >
          > The problem with that is that you're "masking" existing (and useful)
          > functions. For instance, I constantly use Ctrl-K as the digraph prefix
          > (the option to use X <BS> Y instead of <C-K> X Y is more trouble than it
          > is useful IMO);

          That's in insert mode not normal mode. Therefore, not a conflict.

          > Ctrl-L is the "redraw" key, very useful when something goes "half
          > wrong", and so forth.

          I find that doing ":syn sync fromstart" is usually a better fix. <C-l>
          only fixes the issue sometimes and in the cases it doesn't, ":syn sync
          fromstart" would be necessary anyway.

          The other two key combos being masked are <C-h> and <C-j> which don't
          override anything. They're simply alternatives for other keys.

          --
          James
          GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tony Mechelynck
          ... Ah, yes. Sorry. ... I don t mean that. :syn sync fromstart is for times when redrawing wouldn t be useful but syntax highlighting has to be recomputed
          Message 4 of 16 , Jul 13, 2009
            On 14/07/09 01:08, James Vega wrote:
            >
            > On Tue, Jul 14, 2009 at 12:46:37AM +0200, Tony Mechelynck wrote:
            >>
            >> On 13/07/09 18:08, Ingo Karkat wrote:
            >>> The default window navigation commands are a bit tedious, I mapped CTRL-JKHL to
            >>> go to the window in that direction:
            >>> nnoremap<C-j> <C-w>j
            >>> etc.
            >>
            >> The problem with that is that you're "masking" existing (and useful)
            >> functions. For instance, I constantly use Ctrl-K as the digraph prefix
            >> (the option to use X<BS> Y instead of<C-K> X Y is more trouble than it
            >> is useful IMO);
            >
            > That's in insert mode not normal mode. Therefore, not a conflict.

            Ah, yes. Sorry.

            >
            >> Ctrl-L is the "redraw" key, very useful when something goes "half
            >> wrong", and so forth.
            >
            > I find that doing ":syn sync fromstart" is usually a better fix.<C-l>
            > only fixes the issue sometimes and in the cases it doesn't, ":syn sync
            > fromstart" would be necessary anyway.

            I don't mean that. ":syn sync fromstart" is for times when redrawing
            wouldn't be useful but syntax highlighting has to be recomputed from
            higher than it was (much higther, sometimes). Ctrl-L is for when Vim
            forgot to redraw the screen and it isn't displaying what it thinks it is.

            >
            > The other two key combos being masked are<C-h> and<C-j> which don't
            > override anything. They're simply alternatives for other keys.
            >

            Best regards,
            Tony.
            --
            Magnet, n.: Something acted upon by magnetism

            Magnetism, n.: Something acting upon a magnet.

            The two definition immediately foregoing are condensed from the works
            of one thousand eminent scientists, who have illuminated the subject
            with a great white light, to the inexpressible advancement of human
            knowledge.
            -- Ambrose Bierce, "The Devil's Dictionary"

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Matt Wozniski
            ... You could always do :redraw! instead of though - but, who wants that? I m also against remapping CTRL + h/j/k/l ... Yes, but remapping them *would*
            Message 5 of 16 , Jul 13, 2009
              On Mon, Jul 13, 2009 at 7:31 PM, Tony Mechelynck wrote:
              >
              > On 14/07/09 01:08, James Vega wrote:
              >>
              >> On Tue, Jul 14, 2009 at 12:46:37AM +0200, Tony Mechelynck wrote:
              >>>
              >>> On 13/07/09 18:08, Ingo Karkat wrote:
              >>>> The default window navigation commands are a bit tedious, I mapped CTRL-JKHL to
              >>>> go to the window in that direction:
              >>>>        nnoremap<C-j>   <C-w>j
              >>>>        etc.
              >>
              >>> Ctrl-L is the "redraw" key, very useful when something goes "half
              >>> wrong", and so forth.
              >>
              >> I find that doing ":syn sync fromstart" is usually a better fix.<C-l>
              >> only fixes the issue sometimes and in the cases it doesn't, ":syn sync
              >> fromstart" would be necessary anyway.
              >
              > I don't mean that. ":syn sync fromstart" is for times when redrawing
              > wouldn't be useful but syntax highlighting has to be recomputed from
              > higher than it was (much higther, sometimes). Ctrl-L is for when Vim
              > forgot to redraw the screen and it isn't displaying what it thinks it is.

              You could always do :redraw! instead of <C-L> though - but, who wants
              that? I'm also against remapping CTRL + h/j/k/l

              >> The other two key combos being masked are<C-h>  and<C-j>  which don't
              >> override anything.  They're simply alternatives for other keys.

              Yes, but remapping them *would* affect those keys. If, for example,
              your terminal sent ^H for <BS> then pressing <BS> would suddenly move
              one window left - which I suppose is as sane as moving one character
              left, it's default behavior - but it does still change things. Not
              sure if there's any setup where pressing a <Return> key (as distinct
              from <Enter>) on the keyboard actually sends a ^J but I bet there's
              one out there somewhere.

              ~Matt

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Matt Wozniski
              ... Maybe that s how you choose to look at it, but it *is* ending insert mode, executing some commands, and starting a new insert command. ... when you try to
              Message 6 of 16 , Jul 13, 2009
                On Mon, Jul 13, 2009 at 6:17 PM, Tony Mechelynck wrote:
                >
                > On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote:
                >>
                >> Usually Vim is called "modal" because it can be in "insert mode" or
                >> "normal mode". I don't consider things like that. I prefer to consider
                >> Vim as a command-driven application, one of the commands insert text,
                >> other allows for visual selections, other runs ex commands etc. It's all
                >> about commands, just that.
                >
                > If "insert text" is just "one command" until you leave Insert mode...
                > well, I won't deny that to part of the Vim C code it is that, but
                > thinking that, when I enter a new file, I'll be partway inside "one long
                > command" for I don't know how long until, after having hit Esc (which is
                > part of that long command but signals it end) I'll finally hit
                > ":wq<Enter>" (a second command) to quit Vim... well, that's just
                > impractical for a flesh-and-blood person who can hardly conceive that
                > the long job of typing all the data in one file is "the same kind of
                > stuff" as ":wq" and that he used exactly two commands during that long
                > session. (And when I hit F3 in Insert mode, which is imapped to
                > <C-O>:wa|wv<CR> , to me it isn't ending one command, doing two other
                > commands, and starting a fourth one, it's just one action to save the
                > file, and that is "part" of Insert mode.

                Maybe that's how you choose to look at it, but it *is* ending insert
                mode, executing some commands, and starting a new insert command.
                :help ins-special-special explains this, and it's painfully obvious
                when you try to type, say, i)<Left>(<Esc>. and get (() instead of ()()

                I have to agree with Raúl in his interpretation - insert mode is
                really only a "mode" in the sense of a mode being a place that has its
                own mappings and keybindings, but in all other senses - for instance,
                what counts as "beginning" and "ending" a command, or repeating a
                command, or counting how many changes have been made, or any number of
                other metrics - it's only a command.

                ~Matt

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_dev" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Tony Mechelynck
                On 14/07/09 05:21, Matt Wozniski wrote: [...] ... Some papertape terminals had separate return and linefeed keys. I remember than in 1968 or so, when
                Message 7 of 16 , Jul 13, 2009
                  On 14/07/09 05:21, Matt Wozniski wrote:
                  [...]
                  > Yes, but remapping them *would* affect those keys. If, for example,
                  > your terminal sent ^H for<BS> then pressing<BS> would suddenly move
                  > one window left - which I suppose is as sane as moving one character
                  > left, it's default behavior - but it does still change things. Not
                  > sure if there's any setup where pressing a<Return> key (as distinct
                  > from<Enter>) on the keyboard actually sends a ^J but I bet there's
                  > one out there somewhere.
                  >
                  > ~Matt

                  Some papertape terminals had separate "return" and "linefeed" keys. I
                  remember than in 1968 or so, when General Electric did (in universities
                  and fairs) demos of its "time-sharing" system in BASIC (which operated
                  with teletypewriters equipped with forward-only paper display, keyboard,
                  and papertape reader-punch), when you pre-punched a source tape it was
                  better to separate lines by <Return> <Linefeed> <Rubout> <Rubout>
                  <Rubout> rather than just <Return> (which would work all right, but give
                  you, when sending, an ugly listing with maybe two or three characters
                  printed wrong at the start of each line).

                  However I haven't seen any such papertape teletypewriter in a long, long
                  time. Maybe there are still some in operation on Unix machines (I
                  wouldn't bet either way) but it's certainly not the kind of terminal
                  where Vim would be "at home". Maybe it could be used in "ex mode", but I
                  suppose I'd prefer a "simpler" editor on that kind of terminals, maybe a
                  line-editor like the EDLIN I used (rarely) in my MS-DOS days.


                  Best regards,
                  Tony.
                  --
                  hundred-and-one symptoms of being an internet addict:
                  73. You give your dog used motherboards instead of bones

                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_dev" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Tony Mechelynck
                  ... Well, thinking of a long typing session as one little command is still foreign to my way of thinking -- and, the word modal in fact refers to the fact
                  Message 8 of 16 , Jul 13, 2009
                    On 14/07/09 05:27, Matt Wozniski wrote:
                    >
                    > On Mon, Jul 13, 2009 at 6:17 PM, Tony Mechelynck wrote:
                    >>
                    >> On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote:
                    >>>
                    >>> Usually Vim is called "modal" because it can be in "insert mode" or
                    >>> "normal mode". I don't consider things like that. I prefer to consider
                    >>> Vim as a command-driven application, one of the commands insert text,
                    >>> other allows for visual selections, other runs ex commands etc. It's all
                    >>> about commands, just that.
                    >>
                    >> If "insert text" is just "one command" until you leave Insert mode...
                    >> well, I won't deny that to part of the Vim C code it is that, but
                    >> thinking that, when I enter a new file, I'll be partway inside "one long
                    >> command" for I don't know how long until, after having hit Esc (which is
                    >> part of that long command but signals it end) I'll finally hit
                    >> ":wq<Enter>" (a second command) to quit Vim... well, that's just
                    >> impractical for a flesh-and-blood person who can hardly conceive that
                    >> the long job of typing all the data in one file is "the same kind of
                    >> stuff" as ":wq" and that he used exactly two commands during that long
                    >> session. (And when I hit F3 in Insert mode, which is imapped to
                    >> <C-O>:wa|wv<CR> , to me it isn't ending one command, doing two other
                    >> commands, and starting a fourth one, it's just one action to save the
                    >> file, and that is "part" of Insert mode.
                    >
                    > Maybe that's how you choose to look at it, but it *is* ending insert
                    > mode, executing some commands, and starting a new insert command.
                    > :help ins-special-special explains this, and it's painfully obvious
                    > when you try to type, say, i)<Left>(<Esc>. and get (() instead of ()()
                    >
                    > I have to agree with Raúl in his interpretation - insert mode is
                    > really only a "mode" in the sense of a mode being a place that has its
                    > own mappings and keybindings, but in all other senses - for instance,
                    > what counts as "beginning" and "ending" a command, or repeating a
                    > command, or counting how many changes have been made, or any number of
                    > other metrics - it's only a command.
                    >
                    > ~Matt

                    Well, thinking of a long typing session as "one little command" is still
                    foreign to my way of thinking -- and, the word "modal" in fact refers to
                    the fact that the same keys don't always do the same things in Vim. Of
                    course, in that sense all editors are modal -- when you're typing into a
                    dialog your keypresses don't go into your editfile -- but in most of
                    them there is one mode which you use a huge majority of the time, while
                    in Vim, you use the same (alphabetic) keys for very different purposes
                    when creating a file from top to bottom and when looking at an existing
                    file and maybe (or maybe not) making some changes in it, and neither of
                    these, yes, modes is always predominant.


                    Best regards,
                    Tony.
                    --
                    "Dying is a very dull, dreary affair. And my advice to you is to have
                    nothing whatever to do with it."
                    -- W. Somerset Maugham

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Raúl Núñez de Arenas Coronado
                    Saluton Tony :) ... I believe you, I made a typo ;) ... [...] ... I suppose that the OP knows that mappings can solve his problem, but nonetheless he was
                    Message 9 of 16 , Jul 13, 2009
                      Saluton Tony :)

                      Tony Mechelynck <a...@...> dixit:
                      > On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote:
                      >> Current design is, IMHO, perfect. You have normal mode for performing
                      >> editing tasks, visual mode to visually perform editing tasks and
                      >> command mode for ex commands.
                      >
                      > Command-LINE mode. "Command mode" is an older synonym, still used in
                      > parts of the help, for "Normal mode". See ":help command-mode" if you
                      > don't believe me.

                      I believe you, I made a typo ;)

                      >>> If not: is there any chance of it being implemented?
                      >>
                      >> I can't speak for Bram, but I would bet that it won't ;)
                      [...]
                      >
                      > The reason that Bram -- reluctantly, I'm sure, since he doesn't like
                      > Emacs ;-) -- had to recruit these control keys, was that all or almost
                      > all "ordinary" keys already did something, and that he intentionally
                      > wanted to leave the F keys (other than F1 = Help and, on some systems,
                      > F10 = Menu) to "the user's choice". Fn and Shift-Fn keys are your
                      > "best choices" as {lhs} for mappings.

                      I suppose that the OP knows that mappings can solve his problem, but
                      nonetheless he was interested in adding new modes (which, in the end,
                      would make available plenty of "ordinary" keys, one set for each new
                      mode). The key here is not if "Insert mode" is a mode or not, or if
                      mappings can solve OP's problem. The key here is, IMHO, is a good idea
                      to add new modes for certain operations (like moving between windows,
                      etc.). I still think it is not a good idea, but I must confess that
                      maybe it would make sense to have a new mode for moving between windows
                      or tabs. The problem is: how do you go to that mode? If going to that
                      mode requires pressing (for example) Ctrl-W, then you are not gaining
                      much unless you will be moving between windows for a long time. If you
                      make just one move... well, then the "mode" is already there: press
                      Ctrl-W to enter "window mode" and press "w" to move to the next window.
                      If, on the other hand, you spend ages moving between windows, adding a
                      mode is not the best thing, because you will have to enter "Window Mode"
                      for moving and doing other "window" things and you will probably go back
                      to Normal Mode and use "i" to enter text, which is worse (IMHO) than
                      just having some mappings for moving between windows in any mode. Not
                      having to switch modes is faster than switching because you save
                      keypresses.

                      In the end the main problem is that the current mode scheme (and I still
                      don't think there's such thing as "Insert mode", for me that's just a
                      command) is good because it uses a single keypress to go to the "main"
                      mode (Normal Mode) and you usually spend a lot of time being in Normal
                      Mode or using some insert command. Adding modes is, IMHO, not a good
                      thing.

                      --
                      Raúl "DervishD" Núñez de Arenas Coronado
                      Linux Registered User 88736 | http://www.dervishd.net
                      It's my PC and I'll cry if I want to... RAmen!

                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_dev" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Ingo Karkat
                      ... I fully agree. Adding (custom) modes would require a lot of new mappings, e.g. to execute one normal mode command from mode X (like i_CTRL-O). There is
                      Message 10 of 16 , Jul 13, 2009
                        On 14-Jul-09 8:36, Raúl Núñez de Arenas Coronado wrote:
                        > The key here is, IMHO, is a good idea
                        > to add new modes for certain operations (like moving between windows,
                        > etc.). I still think it is not a good idea, but I must confess that
                        > maybe it would make sense to have a new mode for moving between windows
                        > or tabs. The problem is: how do you go to that mode? If going to that
                        > mode requires pressing (for example) Ctrl-W, then you are not gaining
                        > much unless you will be moving between windows for a long time. If you
                        > make just one move... well, then the "mode" is already there: press
                        > Ctrl-W to enter "window mode" and press "w" to move to the next window.
                        > If, on the other hand, you spend ages moving between windows, adding a
                        > mode is not the best thing, because you will have to enter "Window Mode"
                        > for moving and doing other "window" things and you will probably go back
                        > to Normal Mode and use "i" to enter text, which is worse (IMHO) than
                        > just having some mappings for moving between windows in any mode. Not
                        > having to switch modes is faster than switching because you save
                        > keypresses.
                        >
                        > In the end the main problem is that the current mode scheme (and I still
                        > don't think there's such thing as "Insert mode", for me that's just a
                        > command) is good because it uses a single keypress to go to the "main"
                        > mode (Normal Mode) and you usually spend a lot of time being in Normal
                        > Mode or using some insert command. Adding modes is, IMHO, not a good
                        > thing.

                        I fully agree. Adding (custom) modes would require a lot of new mappings, e.g.
                        to execute one normal mode command from mode X (like i_CTRL-O).
                        There is quite a bunch of CTRL-W commands, so one can already go to the top /
                        bottom / preview / whatever window with a single CTRL-W mapping. And you can
                        always add custom CTRL-W commands if need be (e.g. to go to a window named "foo"
                        which you use all the time). And finally, you can still reach for the mouse and
                        click into the window to activate it ;-)

                        -- regards, ingo

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Roald
                        Raúl wrote: The usage pattern you explained in your message doesn t make sense as a mode for me, because those actions belong to normal mode. I m no
                        Message 11 of 16 , Jul 14, 2009
                          Raúl wrote: "The usage pattern you explained in your message doesn't
                          make sense as a
                          mode for me, because those actions belong to "normal" mode."

                          I'm no psychologist, but I think my mind is modal - with more modes
                          than vim. Sometimes I want to browse files, then I'm in a 'browse-
                          file' state of mind, and want to use a browse mode. Sometimes I want
                          to write loads of text, and I'm in an according state of mind, and I
                          want to use insert mode. Sometimes I want to edit (rather than really
                          create) text, and want to use a different insert mode. And if I have a
                          (tab separated) table in my text, again another mode would be useful.

                          "I suppose that the OP knows that mappings can solve his problem, but
                          nonetheless he was interested in adding new modes (which, in the end,
                          would make available plenty of "ordinary" keys, one set for each new
                          mode). The key here is not if "Insert mode" is a mode or not, or if
                          mappings can solve OP's problem. The key here is, IMHO, is a good idea
                          to add new modes for certain operations (like moving between windows,
                          etc.)."

                          Indeed! Not having to press Ctrl's and not having to move away from
                          the keyboard (as with F's) would be much faster.

                          "If you make just one move... well, then the "mode" is already there"

                          Yes, but in that mode I would also have keys for switching between
                          buffers and for scrolling in that mode, and maybe for following links.

                          "The problem is: how do you go to that mode?"

                          I think that's the biggest problem: finding an unused key in normal
                          mode. That can be used as a leader, followed by a (programmable) mode
                          specifier.
                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_dev" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Raúl Núñez de Arenas Coronado
                          Saluton Roald :) ... I understand your point, and I don t know if your mental schemes are frequent or not between Vim users, but even if they are we are facing
                          Message 12 of 16 , Jul 14, 2009
                            Saluton Roald :)

                            Roald <d...@...> dixit:
                            > Raúl wrote: "The usage pattern you explained in your message doesn't
                            > make sense as a mode for me, because those actions belong to "normal"
                            > mode."
                            >
                            > I'm no psychologist, but I think my mind is modal - with more modes
                            > than vim. Sometimes I want to browse files, then I'm in a 'browse-
                            > file' state of mind, and want to use a browse mode. Sometimes I want
                            > to write loads of text, and I'm in an according state of mind, and I
                            > want to use insert mode. Sometimes I want to edit (rather than really
                            > create) text, and want to use a different insert mode. And if I have a
                            > (tab separated) table in my text, again another mode would be useful.

                            I understand your point, and I don't know if your mental schemes are
                            frequent or not between Vim users, but even if they are we are facing a
                            practical problem too: adding a new mode would mean adapting a whole lot
                            of mappings, changing (well, extending) the mapping system, checking for
                            all possible side-effects, specially in scripts, addons, etc. A whole
                            lot of work, implying a lot of changes in the code. So don't expect it
                            to happen anytime soon ;)

                            The problem here is that the modes already present in Vim pervade the
                            entire code, the entire design, because they are the keypoints of the
                            Vim design.

                            > "I suppose that the OP knows that mappings can solve his problem, but
                            > nonetheless he was interested in adding new modes (which, in the end,
                            > would make available plenty of "ordinary" keys, one set for each new
                            > mode). The key here is not if "Insert mode" is a mode or not, or if
                            > mappings can solve OP's problem. The key here is, IMHO, is a good idea
                            > to add new modes for certain operations (like moving between windows,
                            > etc.)."
                            >
                            > Indeed! Not having to press Ctrl's and not having to move away from
                            > the keyboard (as with F's) would be much faster.

                            Sorry, my last sentence above should read "if is a good idea", not "is a
                            good idea": I was asking myself if the idea of adding modes was good or
                            not. I mistyped, sorry.

                            I think that if you choose appropriate mappings you can do what you want
                            without having to add new modes. That's one of the functions of
                            mappings: assign frequent tasks to keys easier to press.

                            > "If you make just one move... well, then the "mode" is already there"
                            >
                            > Yes, but in that mode I would also have keys for switching between
                            > buffers and for scrolling in that mode, and maybe for following links.

                            Your special mode looks a lot like normal mode ;) You want to do almost
                            anything not related with inserting text in that mode: why not using
                            some Normal mode mappings?

                            > "The problem is: how do you go to that mode?"
                            >
                            > I think that's the biggest problem: finding an unused key in normal
                            > mode. That can be used as a leader, followed by a (programmable) mode
                            > specifier.

                            In my keyboard (Spanish) the "ç" is a perfect leader, because I don't
                            use it while typing (usually) and is very near to my right little
                            finger, making it easy to press it fast.

                            I think that your best course of action would be to use a mapleader,
                            make some mappings for the things you want to do fast without having to
                            use "Ctrl-whatever" and imagine that those mappings enter some magic
                            mode allowing you to move between windows, buffers, links, scrolling,
                            etc.

                            Of course, you can try to convince Bram to add a new mode if you
                            describe exactly what kind of things that new mode should do ;)

                            --
                            Raúl "DervishD" Núñez de Arenas Coronado
                            Linux Registered User 88736 | http://www.dervishd.net
                            It's my PC and I'll cry if I want to... RAmen!

                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_dev" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • kana
                            ... How about this plugin? http://www.vim.org/scripts/script.php?script_id=2467 --~--~---------~--~----~------------~-------~--~----~ You received this message
                            Message 13 of 16 , Jul 14, 2009
                              > Questions: can I add modes? If not: is there a good reason for that?
                              > If not: is there any chance of it being implemented?

                              How about this plugin?
                              http://www.vim.org/scripts/script.php?script_id=2467
                              --~--~---------~--~----~------------~-------~--~----~
                              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.