Re: improving encryption in vim
On Sun, 18 Mar 2007 15:57:33 -0600, Josh [EMAIL PROTECTED] wrote: The main problem that I see is that adding a strong encryption function can have regulation issues. That was the only reason that I thought about using the external library is to get around this. With an algorithm like Rijndael there are no patent issues (and there is even unencumbered public source code available), and the only problem is with countries that forbid the use of encryption software. I imagine that can be solved in the same way as other conditional compilation matters are tacked in Vim: putting the code in a separate file and using a compile-time option to include it where available. How secure does the encryption need to be? Considering that Rijndael offers 128-bit, 192-bit and 256-bit security with very fast and simple code, it's more a matter of: why would you bother with anything less than the best encryption you can get? -- Matthew Winn
Understanding regxp implementation
Hi Bram, Nicolai,
I'm unable to grasp the description ( attachment ) given in the regxp.c
file. For a moment they seem like NFA fragments for operators |,+,* and
so on, but then again I'm in doubt ( specially i don't understand what a
node in this context is ). A little help is greatly appreciated
( perhaps a pointer to some other information ). I believe this is a
very simple thing, sorry for my incompetence...
- Asiri
/*
* Structure for regexp program. This is essentially a linear encoding
* of a nondeterministic finite-state machine (aka syntax charts or
* railroad normal form in parsing technology). Each node is an opcode
* plus a next pointer, possibly plus an operand. Next pointers of
* all nodes except BRANCH and BRACES_COMPLEX implement concatenation; a next
* pointer with a BRANCH on both ends of it is connecting two alternatives.
* (Here we have one of the subtle syntax dependencies: an individual BRANCH
* (as opposed to a collection of them) is never concatenated with anything
* because of operator precedence). The next pointer of a BRACES_COMPLEX
* node points to the node after the stuff to be repeated.
* The operand of some types of node is a literal string; for others, it is a
* node leading into a sub-FSM. In particular, the operand of a BRANCH node
* is the first node of the branch.
* (NB this is *not* a tree structure: the tail of the branch connects to the
* thing following the set of BRANCHes.)
*
* pattern is coded like:
*
*+-+
*| V
* aa\|bb BRANCH aa BRANCH bb -- END
* | ^| ^
* +--++--+
*
*
* +--+
* V |
* aa*BRANCH BRANCH aa -- BACK BRANCH -- NOTHING -- END
* | | ^ ^
* | +---+ |
* +-+
*
*
* +--+
* V |
* aa\+ BRANCH aa -- BRANCH -- BACK BRANCH -- NOTHING -- END
* | | ^ ^
* | +---+ |
* +--+
*
*
* +-+
* V |
* aa\{} BRANCH BRACE_LIMITS -- BRACE_COMPLEX aa -- BACK END
* | |^
* | ++
* +---+
*
*
* aa[EMAIL PROTECTED]bbBRANCH NOMATCH aa -- END bb -- END
* | |^ ^
* | ++ |
* ++
*
*+-+
*| V
* \z[abc] BRANCH BRANCH a BRANCH b BRANCH c BRANCH NOTHING -- END
* | | | | ^ ^
* | | | +-+ |
* | | ++ |
* | +---+ |
* +--+
*
* They all start with a BRANCH for \| alternaties, even when there is only
* one alternative.
*/
Re: Understanding regxp implementation
On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: On 3/19/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... I'm unable to grasp the description ( attachment ) given in the regxp.c file. For a moment they seem like NFA fragments for operators |,+,* Well, yes, that's what they are. The diagrams show you how the different operators are represented. I think the representation can be a bit difficult to grasp at first, because the representation isn't like a state diagram/tree/DAG, but more of a list of assembler instructions.These assembler-like instructions are then executed by an interpreter that executes the appropriate C code for doing the matching. This is (mainly) done in regmatch(). Thanks a bunch, I was completely lost... - Asiri nikolai
Re: Understanding regxp implementation
On 1/1/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: On 3/19/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... Hehe, don't take it too hard, it happens to me all the time. If I had a dime for every misspelling of my name, I'd have...more money than I do now. nikolai
C syntax problem with C99 initializers.
A macro like this:
#define FOO ((fooy) { field: 4 })
causes vim to highlight the braces (in an angry fashion), and seems to
cause it consider all of the remaining braces in the file to be in
error as well.
Any ideas?
Thanks,
David Brown
Re: Understanding regxp implementation
On Mon, Mar 19, 2007 at 01:49:53PM +0100, Nikolai Weibull wrote: On 1/1/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: On 3/19/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... Hehe, don't take it too hard, it happens to me all the time. If I had a dime for every misspelling of my name, I'd have...more money than I do now. Now I know, why Bram said in his Google Talk that he even uses ctrl-n completion for names, as it helps not misspelling names :) -- Martin
Re: C syntax problem with C99 initializers.
David Brown wrote:
A macro like this:
#define FOO ((fooy) { field: 4 })
causes vim to highlight the braces (in an angry fashion), and seems to
cause it consider all of the remaining braces in the file to be in
error as well.
Any ideas?
Highlighting curly braces inside parenthesis is about the only way to
detect a missing closing parenthesis.
You can disable this with:
:let c_no_curly_error = 1
You won't be able to see missing parenthesis then. Blame C99 to make a
syntax that's hard to check.
--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER:'Mm ... very nice castle, Camelot ... very good pig country
Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: C syntax problem with C99 initializers.
Am Montag 19 März 2007 schrieb David Brown:
A macro like this:
#define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What the heck is
this good for?
Martin
--
Martin Krischik
mailto://[EMAIL PROTECTED]
pgpqr1CVAZVlY.pgp
Description: PGP signature
Re: C syntax problem with C99 initializers.
Martin Krischik wrote:
Am Montag 19 März 2007 schrieb David Brown:
A macro like this:
#define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What
the heck is this good for?
It is a constant structure, useful, in this case, as a macro to
indicate a constant value. The field: thing is gcc, the proper C99
syntax is:
{ .field = 4 }
But what is confusing vim is the braces inside of the parens. As Bram
mentioned in another email, this can be disabled, but it makes vim not
able to detect unclosed parens.
Dave
Re: C syntax problem with C99 initializers.
On 19/03/2007 17:39, David Brown wrote:
Martin Krischik wrote:
Am Montag 19 März 2007 schrieb David Brown:
A macro like this:
#define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What
the heck is this good for?
It is a constant structure, useful, in this case, as a macro to
indicate a constant value. The field: thing is gcc, the proper C99
syntax is:
{ .field = 4 }
But what is confusing vim is the braces inside of the parens. As Bram
mentioned in another email, this can be disabled, but it makes vim not
able to detect unclosed parens.
Have you tried the alternate C syntax highlight file here?
http://www.vim.org/scripts/script.php?script_id=234
TTFN
Mike
--
At least the doctors find me fascinating.
Re: improving encryption in vim
On 3/19/07, Matthew Winn [EMAIL PROTECTED] wrote: On Sun, 18 Mar 2007 15:57:33 -0600, Josh [EMAIL PROTECTED] wrote: The main problem that I see is that adding a strong encryption function can have regulation issues. That was the only reason that I thought about using the external library is to get around this. With an algorithm like Rijndael there are no patent issues (and there is even unencumbered public source code available), and the only problem is with countries that forbid the use of encryption software. As far as I know, the problem is not the use of encryption software, but the export of encryption software from US. The problem exists only if the code was originally stored/created on computers in US, and then copies to outside US (exported). If the code was originally created on the computers outside of US, then the problem does not exists in the first place. The Europe is one of places located notably outside of US. AFAIR, the development of openssl happens not in US but mostly in Australia iirc, for the same reason. Yakov
Consistently exit message display with 'q'?
Hi all, I'm a bit frustrated by a particular behaviour of vim, and today I modified the source code to 'fix' it. I'd be very grateful for some opinions if you a) agree with my thoughts, or b) have a better solution. The problem - is when you run a command that outputs messages to vim - over multiple lines. For example, :!ls or :set They scroll messages up the screen, and a kind of Unix 'less' function is effectively invoked (since it steals it's scrolling commands from vi(m)). In Unix less (and also Unix more), a simple, close-to-the-fingers way to exit is to type the letter 'q'. This works no matter whether you're at the start, middle or end of the file. In vim, if only a part of the messages would fit on the screen, you get the prompt '-- More --' - and if you press 'q', it will exit message display. If you press Enter, it will just scroll one line. However, if all the messages would fit on the screen, you get the prompt 'Press ENTER or type command to continue'. Now the 'q' and 'Enter' keys do totally different things - q heads you towards macro recording, and Enter exits message display. Often, the line I want to see is at the top of the message output - and I don't care whether all the messages fitted on the screen, or whether there are more - I just want to exit message display. To me, it makes perfect sense that, just as with the unix 'less' program, pressing 'q' should exit message display - regardless of whether there are more lines to display or not. Sure, I can press Escape, but it's much harder to press than 'q'. Yes, I can press Ctrl-[ - but that's also much harder than 'q'. (Both of these options will also trigger the 'error bell' (audible or visual) - which seems rather unnecessary to me in this situation.) Otherwise - I have to look to the bottom of the screen to see whether vim wants 'q' or Enter to exit message display. Is it just me that finds this open for improvement? I've tried finding good mappings to solve this problem, but it's not at all easy. The source code change I made today was to change line 1004 of message.c from if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C) to if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C c != 'q') It seems to work fine I think. If I'm the only one who finds this a problem, how do all of you exit from message display? Do you do different things depending on the message at the bottom? Use Escape? Otherwise, would anyone else like to see this tiny change accepted into vim? Thanks for your thoughts, John * This e-mail (and any attachments) is confidential and privileged information of Catapult Communications *
Re: How to switch between horizontal split and vertical split?
Peng Yu wrote: Suppose I have horizontal splited window1 and window2, is there any way to change them into vertical split and vice versa? See http://vim.sourceforge.net/tips/tip.php?tip_id=862 How to toggle between all vertical and all horizontal window layout Regards, Chip Campbell
Re: Understanding regxp implementation
Nikolai Weibull wrote: On 1/1/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: On 3/19/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... Hehe, don't take it too hard, it happens to me all the time. If I had a dime for every misspelling of my name, I'd have...more money than I do now. Perhaps this will help: / -,,, ,, || ) ' || || _' ~||---) \\ ||/\ /'\\ || \, \\ ~||---, || ||_ || || || /-|| || ~|| / || || | || || || (( || || |, / \\ \\,\ \\,/ \\ \/\\ \\ -_- --~ (a gothic/ascii version) :) Regards, Chip Campbell
Re: input gets repeated when having a break in input mode
I think you have mischievous colleagues. On Fri, 9 Mar 2007, petern wrote: Hi dear vim lovers. When I type some text in input mode and for example go to make a coffee without leaving the input mode, and then get back to my computer, vim has exited input mode. That's OK. But what confuses me is that some parts of my input has been repeated and been inserted twice to my document. Has anyone experienced such behaviour? How do I get rid of it? -- .
Re: Understanding regxp implementation
On 3/19/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Nikolai Weibull wrote: On 1/1/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: On 3/19/07, Asiri Rathnayake [EMAIL PROTECTED] wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... Hehe, don't take it too hard, it happens to me all the time. If I had a dime for every misspelling of my name, I'd have...more money than I do now. Perhaps this will help: / -,,, ,, || ) ' || || _' ~||---) \\ ||/\ /'\\ || \, \\ ~||---, || ||_ || || || /-|| || ~|| / || || | || || || (( || || |, / \\ \\,\ \\,/ \\ \/\\ \\ -_- --~ My eyes, they burn! ;-) nikolai
highlighting weird characters...
Hi all, I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. Is there a way I can have my Vim highlight these characters so I can see them and replace them with their HTML counterparts? I've searched Google, the Vim e-mail archive, and I've helped Ugandan children :), but I'm no closer to the answer. Any hints? Thanks, Mitch Freeville, NY
Re: highlighting weird characters...
On 3/19/07, Mitch Wiedemann [EMAIL PROTECTED] wrote: Is there a way I can have my Vim highlight these characters so I can see them and replace them with their HTML counterparts? No idea about highlighting, but exactly to replace strange characters with HTML or LaTeX or anything else or to do it in backward direction I've write this plugin: http://www.vim.org/scripts/script.php?script_id=1761 Documentation inside. I hope this helps. -- Cyril Slobin [EMAIL PROTECTED] `When I use a word,' Humpty Dumpty said, http://45.free.net/~slobin `it means just what I choose it to mean'
Re: highlighting weird characters...
On 2007-03-19, Mitch Wiedemann [EMAIL PROTECTED] wrote: Hi all, I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. Is there a way I can have my Vim highlight these characters so I can see them and replace them with their HTML counterparts? I've searched Google, the Vim e-mail archive, and I've helped Ugandan children :), but I'm no closer to the answer. Any hints? One way to do this would be to :set isprint= which will tell vim that only the characters in the range 32 - 126 are printable. Vim will then highlight all the other characters as SpecialKey. You can then search for these non-printable characters with /[^[:print:]] Another, probably better, way would be to simply search for /[^Vx80-^Vxff] where ^V means a literal Ctrl-V. That will search for any character in the range 0x80 - 0xff and will highlight them all with the Search highlight if 'hlsearch' is set. I think this way is better because it preserves vim's rendering of the non-ASCII characters, which may make it easier for you to choose their replacements. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: highlighting weird characters...
I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. Is there a way I can have my Vim highlight these characters so I can see them and replace them with their HTML counterparts? I've searched Google, the Vim e-mail archive, and I've helped Ugandan children :), but I'm no closer to the answer. Well, if you want to highlight them, you can do something like :match Error /[\x7f-\xff]/ which should catch most of the offenders. Or you can search for them with the same regexp. And if you have :set hls, it will highlight them too. :) It does require certain knobs to be set properly in your 'cpoptions' setting, but if you run vim (rather than vi), they should automatically be set unless you had reason to bung with them. Once you're on a particular one, you can use ga to determine the ASCII value of the character in question, and can use that value for searchreplace. Hope this helps, -tim
Re: highlighting weird characters...
On 2007-03-19, Gary Johnson [EMAIL PROTECTED] wrote: On 2007-03-19, Mitch Wiedemann [EMAIL PROTECTED] wrote: Hi all, I use VIM - Vi IMproved 7.0 (2006 May 7, compiled Feb 23 2007 22:17:23) to write mainly XHTML/PHP and I sometimes have to get content from word processed documents and paste it into Vim for HTML markup. This usually results in having non-visually detectable characters (which I assume are high ASCII) which display strangely on the Web. P.S. See :help ga HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Vim Help for deleting text
Hello, I would like to remove everything after a text highlight in a line for all the lines in a file. What are the commands to be used in Vim. I would appreciate your help. 00,000,00 00,000,00 I want to remove everything after , for all the lines. Regards, Auro Ashish Saha.
Re: Vim Help for deleting text
I would like to remove everything after a text highlight in a line for all the lines in a file. What are the commands to be used in Vim. I would appreciate your help. 00,000,00 00,000,00 I want to remove everything after , for all the lines. You have two commas...if you want to delete everything after the first comma, you can use :%s/,.*/, If you want to delete everything after the first comma *including* the comma, you can use :%s/,.* If you want to delete everything after the 2nd comma, you can use :%s/,[^,]*,\zs.*/ And if you want to delete everything after the 2nd comma (but including the comma, you can just use :%s/,[^,]*\zs,.*/ Or, if all your columns align, you can use visual-block mode with control+V to create a block across the characters in question, and then just hit d to delete. I'm sure there are plenty of other ways to do it, but that should get you started. -tim
inserting newlines
Hi all, I was recently discussing some features of vim that I use a lot with a friend and asking if he knew of ways to do certain things better, and one issue that both of us have is that we create newlines with o or O and then go back to normal mode immediately afterwards. So I often end up doing: oesc or Oesc where it would be nice to have a single key that would do this. Is there already such a feature, or should I just do something like nnoremap zj oEsc nnoremap zk OEsc I realize that zk and zj are still two keystrokes, but they are easier to type as it is. Thanks! -- -fREW
Re: Consistently exit message display with 'q'?
John Orr [EMAIL PROTECTED] 写于 2007-03-19 21:23:59: Hi all, I'm a bit frustrated by a particular behaviour of vim, and today I modified the source code to 'fix' it. I'd be very grateful for some opinions if you a) agree with my thoughts, or b) have a better solution. The problem - is when you run a command that outputs messages to vim - over multiple lines. For example, :!ls or :set They scroll messages up the screen, and a kind of Unix 'less' function is effectively invoked (since it steals it's scrolling commands from vi(m)). In Unix less (and also Unix more), a simple, close-to-the- fingers way to exit is to type the letter 'q'. This works no matter whether you're at the start, middle or end of the file. In vim, if only a part of the messages would fit on the screen, you get the prompt '-- More --' - and if you press 'q', it will exit message display. If you press Enter, it will just scroll one line. However, if all the messages would fit on the screen, you get the prompt 'Press ENTER or type command to continue'. Now the 'q' and 'Enter' keys do totally different things - q heads you towards macro recording, and Enter exits message display. Often, the line I want to see is at the top of the message output - and I don't care whether all the messages fitted on the screen, or whether there are more - I just want to exit message display. To me, it makes perfect sense that, just as with the unix 'less' program, pressing 'q' should exit message display - regardless of whether there are more lines to display or not. Sure, I can press Escape, but it's much harder to press than 'q'. Yes, I can press Ctrl-[ - but that's also much harder than 'q'. (Both of these options will also trigger the 'error bell' (audible or visual) - which seems rather unnecessary to me in this situation.) Otherwise - I have to look to the bottom of the screen to see whether vim wants 'q' or Enter to exit message display. Is it just me that finds this open for improvement? I've tried finding good mappings to solve this problem, but it's not at all easy. The source code change I made today was to change line 1004 of message.c from if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C) to if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C c != 'q') It seems to work fine I think. If I'm the only one who finds this a problem, how do all of you exit from message display? Do you do different things depending on the message at the bottom? Use Escape? Otherwise, would anyone else like to see this tiny change accepted into vim? Thanks for your thoughts, John Hi, I don't know how other people quits the message display but I do feel unhappy since the first day I use vim and have no good work around unless having a big screen (so that most messages could fit in my screen)... The more frustrating thing is: if I continuously scroll down in the 'more-prompt' mode, the 'more-prompt' will eventually quits the display and the message are disappeared forever, so I must be careful NOT to press any key when the last line of message are shown. What I expect is: press Enter or space will always do scroll ONLY, and do never quit the message display, this is consistent with the Unix less command. If you just eat the 'q' after the message display, it will work if you want to just quit all message, but when you want to view the last lines of the message, the 'more-prompt' is still inconsistent since it will change into Press Enter or type command to continue on the last line. So I think a better way is to change the code for the 'less' mode, (in Vim document, it is called 'more-prompt'), the 'more-prompt' should always require 'q' 'ESC' to exit, even if the last line of text are shown. And there should be an option to turn the 'more-prompt' always on. i.e. All message will show 'more-prompt' regardless of the message 'lines'. To conclude: 1. an option to always show the 'more-prompt' 2. 'more-prompt' will never fall into Press Enter or type command to continue state even if on the last line, so we always require 'q' or ESC to quit the 'more-prompt'. this is consistent with the Unix 'less' command. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Consistently exit message display with 'q'?
John Orr wrote: Hi all, I'm a bit frustrated by a particular behaviour of vim, and today I modified the source code to 'fix' it. I'd be very grateful for some opinions if you a) agree with my thoughts, or b) have a better solution. The problem - is when you run a command that outputs messages to vim - over multiple lines. For example, :!ls or :set They scroll messages up the screen, and a kind of Unix 'less' function is effectively invoked (since it steals it's scrolling commands from vi(m)). In Unix less (and also Unix more), a simple, close-to-the-fingers way to exit is to type the letter 'q'. This works no matter whether you're at the start, middle or end of the file. In vim, if only a part of the messages would fit on the screen, you get the prompt '-- More --' - and if you press 'q', it will exit message display. If you press Enter, it will just scroll one line. However, if all the messages would fit on the screen, you get the prompt 'Press ENTER or type command to continue'. Now the 'q' and 'Enter' keys do totally different things - q heads you towards macro recording, and Enter exits message display. Often, the line I want to see is at the top of the message output - and I don't care whether all the messages fitted on the screen, or whether there are more - I just want to exit message display. To me, it makes perfect sense that, just as with the unix 'less' program, pressing 'q' should exit message display - regardless of whether there are more lines to display or not. Sure, I can press Escape, but it's much harder to press than 'q'. Yes, I can press Ctrl-[ - but that's also much harder than 'q'. (Both of these options will also trigger the 'error bell' (audible or visual) - which seems rather unnecessary to me in this situation.) Otherwise - I have to look to the bottom of the screen to see whether vim wants 'q' or Enter to exit message display. Is it just me that finds this open for improvement? I've tried finding good mappings to solve this problem, but it's not at all easy. The source code change I made today was to change line 1004 of message.c from if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C) to if (vim_strchr((char_u *)\r\n , c) == NULL c != Ctrl_C c != 'q') It seems to work fine I think. If I'm the only one who finds this a problem, how do all of you exit from message display? Do you do different things depending on the message at the bottom? Use Escape? Otherwise, would anyone else like to see this tiny change accepted into vim? Thanks for your thoughts, John To exit the scrolling display ang go back to plain-vanilla Vim, hit Ctrl-C (or Ctrl-Break) at the More-prompt or Hit-Enter-prompt. On AZERTY/QWERTY/QWERTZ keyboard, the C is near enough to the left Ctrl key to allow hitting the two keys easily with the fingers of a single hand. (I don't know about the Dvorak layout.) To go back in the scrolling display, in Vim 7 (but not in Vim 6 or earlier) you can use Up or PageUp depending on how far you want to go back. Best regards, Tony. -- The assertion that all men are created equal was of no practical use in effecting our separation from Great Britain and it was placed in the Declaration not for that, but for future use. -- Abraham Lincoln
Re: Consistently exit message display with 'q'?
A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-03-20 11:18:06: To go back in the scrolling display, in Vim 7 (but not in Vim 6 or earlier) you can use Up or PageUp depending on how far you want to go back. Best regards, Tony. -- Hi Tony, Anyway to prevent 'more-prompt' from changing into 'hit-enter-prompt' at the last line? When you scroll down and see the 'hit-enter-prompt', anykey will close the message display, and the PageUP does not work under that circumstance. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: inserting newlines
fREW wrote: Hi all, I was recently discussing some features of vim that I use a lot with a friend and asking if he knew of ways to do certain things better, and one issue that both of us have is that we create newlines with o or O and then go back to normal mode immediately afterwards. So I often end up doing: oesc or Oesc where it would be nice to have a single key that would do this. Is there already such a feature, or should I just do something like nnoremap zj oEsc nnoremap zk OEsc I realize that zk and zj are still two keystrokes, but they are easier to type as it is. Thanks! open empty line after: any one of the three below :put = oEsc :normal o open empty line before: any one of the three below :.-1put = OEsc :normal O To do it with a single keystroke: use all four below: :map F3 oEsc :map F2 OEsc :imap F3 EndCR :imap F2 HomeCR Replace F2 and/or F3 by any other keystroke that you would prefer to use instead. Best regards, Tony. -- Enzymes are things invented by biologists that explain things which otherwise require harder thinking. -- Jerome Lettvin
Re: Consistently exit message display with 'q'?
[EMAIL PROTECTED] wrote: A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-03-20 11:18:06: To go back in the scrolling display, in Vim 7 (but not in Vim 6 or earlier) you can use Up or PageUp depending on how far you want to go back. Best regards, Tony. -- Hi Tony, Anyway to prevent 'more-prompt' from changing into 'hit-enter-prompt' at the last line? When you scroll down and see the 'hit-enter-prompt', anykey will close the message display, and the PageUP does not work under that circumstance. -- Sincerely, Pan, Shi Zhu. ext: 2606 In Vim 7.0.219 (and probably in at least some earlier v7 builds) hitting Up (but not PageUp) at the Hit-Enter prompt scrolls the message back by one line (if it's longer than the screen, but if it isn't there's not much purpose in scrolling back). After hitting Up once at the Hit-Enter prompt you're back to the More-prompt so _then_ you can use PageUp again. IMHO it is advantageous to have a different prompt at the end of the message because it tells you that there's nothing to scroll _forward_ to. Best regards, Tony. -- I think that I shall never see A billboard lovely as a tree. Perhaps, unless the billboards fall I'll never see a tree at all. -- Ogden Nash
Re: Consistently exit message display with 'q'?
A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-03-20 11:58:26: After hitting Up once at the Hit-Enter prompt you're back to the More-prompt so _then_ you can use PageUp again. IMHO it is advantageous to have a different prompt at the end of the message because it tells you that there's nothing to scroll _forward_ to. Best regards, Tony. -- It is not hurt to have a different prompt, but in the Hit-Enter prompt, hit *any-key* will close the message display. This is different from the Vim state, we know that press the ESC twice will go into normal mode. If I pressed the ESC 3 times (by mistake) it does not hurt. Press PgDn will scroll down in 'more-prompt', and the prompt may silent change into 'hit-enter-prompt', if I then pressed the PgDn for one more time, the messages may lost forever and I may not have chance to see the message at all. Such kind of unrecoverable destructive command like close the message should be explicitly defined like 'q' and should not be *any-key*. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: Consistently exit message display with 'q'?
Hi Tony, (and others), Thanks for your (tireless) input, yes, Ctrl-C is certainly a good suggestion, that works consistently, with no error bells/flashes, no matter how far through the messages you are. And I totally agree that it's good to make it easy to know when there is more output to come or not, by having a different 'end' message. Thanks also to the other guys who've responded, raising related points. I suppose I'm biased - after getting hooked on vim, it seemed natural to alias unix 'more' to instead use unix 'less' - so I can get the vim style cursor movement commands. Hence I'm rather accustomed to the unix 'less' manner of scrolling text/messages. I guess the current vim approach is a melding of both Unix 'more' and 'less', which certainly has it's own advantages. Eg - unix more exits at the end of the messages in a similar way to vim (the key difference being that with vim, the messages all disappear, whilst with more, you've probably got them scrolled up your terminal window to review). Undoubtedly there would be both more devotees and less devotees using vim - so what we've currently got is probably a good compromise. It may be better, perhaps, to have an option to enable fully compatible versions of one or the other. But that's probably a lot of work. For now, I've got my code patch (not that it's nice to have oddly patched code). When I get some time I'll see if I can't find a similar change to address the other issue raised here, unless someone gets there before me. Thank you all for your responses. John On Tuesday 20 March 2007 14:58, A.J.Mechelynck wrote: [EMAIL PROTECTED] wrote: A.J.Mechelynck [EMAIL PROTECTED] 写于 2007-03-20 11:18:06: To go back in the scrolling display, in Vim 7 (but not in Vim 6 or earlier) you can use Up or PageUp depending on how far you want to go back. Best regards, Tony. -- Hi Tony, Anyway to prevent 'more-prompt' from changing into 'hit-enter-prompt' at the last line? When you scroll down and see the 'hit-enter-prompt', anykey will close the message display, and the PageUP does not work under that circumstance. -- Sincerely, Pan, Shi Zhu. ext: 2606 In Vim 7.0.219 (and probably in at least some earlier v7 builds) hitting Up (but not PageUp) at the Hit-Enter prompt scrolls the message back by one line (if it's longer than the screen, but if it isn't there's not much purpose in scrolling back). After hitting Up once at the Hit-Enter prompt you're back to the More-prompt so _then_ you can use PageUp again. IMHO it is advantageous to have a different prompt at the end of the message because it tells you that there's nothing to scroll _forward_ to. Best regards, Tony. -- I think that I shall never see A billboard lovely as a tree. Perhaps, unless the billboards fall I'll never see a tree at all. -- Ogden Nash
Re: Consistently exit message display with 'q'?
John Orr wrote: Hi Tony, (and others), Thanks for your (tireless) input, yes, Ctrl-C is certainly a good suggestion, that works consistently, with no error bells/flashes, no matter how far through the messages you are. And I totally agree that it's good to make it easy to know when there is more output to come or not, by having a different 'end' message. Thanks also to the other guys who've responded, raising related points. I suppose I'm biased - after getting hooked on vim, it seemed natural to alias unix 'more' to instead use unix 'less' - so I can get the vim style cursor movement commands. Hence I'm rather accustomed to the unix 'less' manner of scrolling text/messages. I guess the current vim approach is a melding of both Unix 'more' and 'less', which certainly has it's own advantages. Eg - unix more exits at the end of the messages in a similar way to vim (the key difference being that with vim, the messages all disappear, whilst with more, you've probably got them scrolled up your terminal window to review). Undoubtedly there would be both more devotees and less devotees using vim - so what we've currently got is probably a good compromise. It may be better, perhaps, to have an option to enable fully compatible versions of one or the other. But that's probably a lot of work. For now, I've got my code patch (not that it's nice to have oddly patched code). When I get some time I'll see if I can't find a similar change to address the other issue raised here, unless someone gets there before me. Thank you all for your responses. John Personally I use both less and more -- for different purposes. For instance, with a long ls listing, using --color makes less stumble, but more shows the colors with no problem. In general, I use: - less - when there is a long listing which I want to be able to scroll back and forth, or to search with a / command - not when there are interspersed ANSI-like escape sequences as in ls --color. - more - if I want to discard the listing after the first screenful, as when I use src/vim --version |more between make and make install of a Vim recompile. - if I know that I won't have to scroll back or search - if I want the last screenful to remain visible above the next shell prompt - if there are ANSI-like color escapes But Vim is more versatile than either. It even allows you to capture the output of a display command like :ver or, with no parameters, :au or :hi; but you have to set up the capture in advance (see :help :redir). Best regards, Tony. -- REPORTER: Senator, are you for or against the MX missile system? SENATOR: Bob, the MX missile system reminds me of an old saying that the country folk in my state like to say. It goes like this: You can carry a pig for six miles, but if you set it down it might run away. I have no idea why the country folk say this. Maybe there's some kind of chemical pollutant in their drinking water. That is why I pledge to do all that I can to protect the environment of this great nation of ours, and put prayer back in the schools, where it belongs. What we need is jobs, not empty promises. I realize I'm risking my political career be being so outspoken on a sensitive issue such as the MX, but that's just the kind of straight-talking honest person I am, and I can't help it. -- Dave Barry, On Presidential Politics
