Re: adding modes
Saluton Tony :)
Tony Mechelynck a...@gmail.com 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
-~--~~~~--~~--~--~---
Re: adding modes
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 -~--~~~~--~~--~--~---
Re: adding modes
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 -~--~~~~--~~--~--~---
Re: adding modes
Saluton Roald :) Roald d...@gmail.com 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 -~--~~~~--~~--~--~---
Re: adding modes
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 -~--~~~~--~~--~--~---
adding modes
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? --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: adding modes
Saluton Roald :) Roald d...@gmail.com 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. 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). 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. 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 ;) If not: is there any chance of it being implemented? I can't speak for Bram, but I would bet that it won't ;) -- 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 -~--~~~~--~~--~--~---
Re: adding modes
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-wj etc. If CTRL isn't placed convenient, you can also use ALT/META. -- regards, ingo --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: adding modes
On 13/07/09 18:00, Raúl Núñez de Arenas Coronado wrote: Saluton Roald :) Roaldd...@gmail.com 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 :wqEnter (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|wvCR , 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 :mapF5C-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
Re: adding modes
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: nnoremapC-j C-wj 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 -~--~~~~--~~--~--~---
Re: adding modes
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: nnoremapC-j C-wj 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 james...@jamessan.com --~--~-~--~~~---~--~~ You received this message from the vim_dev maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: adding modes
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: nnoremapC-j C-wj 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 XBS Y instead ofC-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 areC-h andC-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 -~--~~~~--~~--~--~---
Re: adding modes
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: nnoremapC-j C-wj 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 areC-h andC-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 -~--~~~~--~~--~--~---
Re: adding modes
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 :wqEnter (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|wvCR , 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 -~--~~~~--~~--~--~---
Re: adding modes
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 :wqEnter (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|wvCR , 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 -~--~~~~--~~--~--~---
