Re: Insert mode: C-R does not paste the whole register
Georg Dahn wrote: Simetimes C-R in Insert mode is very useful. I use it to format articles automatically. I set 'noai' and 'tw=78'. But for texts with many lines this fails. I use the file vimtips.txt I downloaded from vim.org. 1. Open vimtips.txt 2. Do :set noai 3. Do :set tw=78 4. Cut the whole file to a register, for example 5. In Insert mode do C-R Then it stops somewhere near line 3500 (vimtips.txt has over 4 lines at the moment). Just pasting it with 'p' works, this I suppose that the whole file is in the register. Where do you find this vimtips.txt with 4 lines? I only found one with 3543 lines. I tried another file but it worked fine. Perhaps you run out of memory? Also note that text gets formatted if you put it like this. If you have 'autoformat' set the number of lines will change. -- User: I'm having problems with my text editor. Help desk: Which editor are you using? User: I don't know, but it's version VI (pronounced: 6). Help desk: Oh, then you should upgrade to version VIM (pronounced: 994). /// 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: :tabnew gtk-1.2.10 QNX632, NetBSD BUG(?)
Yakov wrote: I'v began testing of VIM 7 rather late, so may be this is fixed already but anyway folks from IRC knows nothing bout that fact. I'v built vim7c04 on QNX632 and NetBSD with --enable-gui=gtk. When i use :tabnew i got several tabs. That works but when im trying to navigate throw the buffer in the tab with -, - cursor navigates over the buffer *and* it naviagtes throw the tabs. That is the problem because when i type SPACE vim7 switchs me to the latest chosen (chosen with -, - keys) tab. I'm afraid I don't understand what you are doing and what you are expecting. Please explain the sequence of commands exactly. -- When I die, I want a tombstone that says GAME OVER - Ton Richters /// 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: vim70f, test49 fails if binary is not named 'vim'
Gregory Margo wrote: test49.vim assumes the binary is named 'vim'. If the --with-vim-name option is used (such as --with-vim-name=vim7) then test49 fails. Here is a minor patch that makes test49 respect the VIMPROG environment variable from the Makefile, falling back to the current value if not found: --- vim70f/src/testdir/test49.vim.00 2006-02-28 05:36:54.0 -0800 +++ vim70f/src/testdir/test49.vim 2006-04-27 16:26:31.677399006 -0700 @@ -454,9 +454,10 @@ pipe are consumed at the debug prompt. Use -N to enable command-line continuation (C in 'cpo'). Add nviminfo to 'viminfo' to avoid messing up the user's viminfo file. +let vimprog = exists($VIMPROG) ? $VIMPROG : ../vim let redirect = a:0 ? \ -c 'au VimLeave * redir END' -c 'redir\\! . a:1 . ' : -exec !echo ' . debug_quits . q' | ../vim -u NONE -N -Xes . redirect . +exec !echo ' . debug_quits . q' | . vimprog . -u NONE -N -Xes . redirect . \ -c 'debuggreedy|set viminfo+=nviminfo' . \ -c 'let ExtraVimBegin = . extra_begin . ' . \ -c 'let ExtraVimResult = \ . resultfile . \' . breakpoints . I see the problem you want to fix. But Vim doesn't always get the $VIMPROG environment variable from make. Another solution is to create a symlink from vim to the target used. Try this patch: --- Makefile24 Apr 2006 19:27:13 - 1.63 +++ Makefile28 Apr 2006 09:28:31 - @@ -1719,6 +1720,9 @@ -if test -n $(MAKEMO) -a -f $(PODIR)/Makefile; then \ cd $(PODIR); $(MAKE) -f Makefile check VIM=../$(VIMTARGET); \ fi + -if test $(VIMTARGET) != vim -a ! -e vim; then \ + ln -s $(VIMTARGET) vim; \ + fi cd testdir; $(MAKE) -f Makefile $(GUI_TESTTARGET) VIMPROG=../$(VIMTARGET) $(GUI_TESTARG) testclean: Would this have any problems? -- LAUNCELOT: Isn't there a St. Arrggghhh's in Cornwall? ARTHUR:No, that's Saint Ives. 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///
Vim thinks a directory is an illegal filename on Windows
run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . Thanks William
Re: Insert mode: C-R does not paste the whole register
Hi! Where do you find this vimtips.txt with 4 lines? I only found one with 3543 lines. http://www.vim.org/tips/tip_download.php?download=download It contains a lot of empty lines, has a sice of a little more then 1,2 MB, and has 40243 lines at the moment. I tried another file but it worked fine. With other files I had no problems, too, but most times these were smaller files. Perhaps you run out of memory? I have 2 GB and had only Outlook and Vim open. Memory should not be a problem. Also note that text gets formatted if you put it like this. If you have 'autoformat' set the number of lines will change. That's the reason for doing that. With 'gqap' for example, the formating is different to what I want when I do C-R. However, the number of lines should increase, but it seems just to stop somewhere. BTW, there is no error message. I am working with Vim 7.0f03 on Windows XP. Best wishes, Georg Send instant messages to your online friends http://uk.messenger.yahoo.com
Re: Vim thinks a directory is an illegal filename on Windows
William S Fulton wrote: run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . I haven't found any way to avoid these messages with netrw, so it sounds like an issue for Bram M. Regards, Chip Campbell
Re: probably known bug
[EMAIL PROTECTED] wrote: All, I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? Well, this one is more of a trade-off than a bug (speed vs accuracy). I suggest reading: :help syn-sync . Regards, Chip Campbell
Re: Insert mode: C-R does not paste the whole register
Georg Dahn wrote: Where do you find this vimtips.txt with 4 lines? I only found one with 3543 lines. http://www.vim.org/tips/tip_download.php?download=download It contains a lot of empty lines, has a sice of a little more then 1,2 MB, and has 40243 lines at the moment. I tried another file but it worked fine. With other files I had no problems, too, but most times these were smaller files. Perhaps you run out of memory? I have 2 GB and had only Outlook and Vim open. Memory should not be a problem. Also note that text gets formatted if you put it like this. If you have 'autoformat' set the number of lines will change. That's the reason for doing that. With 'gqap' for example, the formating is different to what I want when I do C-R. However, the number of lines should increase, but it seems just to stop somewhere. BTW, there is no error message. I am working with Vim 7.0f03 on Windows XP. It appears that this file has Esc characters, right at the point where you say inserting the register stops. Try using CTRL-R CTRL-Rinstead of CTRL-R . -- Permission is granted to read this message out aloud on Kings Cross Road, London, under the condition that the orator is properly dressed. /// 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: probably known bug
Matt Mzyzik wrote: I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? I often see empty plastic cups laying around. Is there an effort to fix this? My point is: Everybody knows display errors should be fixed. Syntax highlighting is different for every language. If you see a problem with one, try contacting the maintainer (mentioned in the syntax file header). -- BRIDGEKEEPER: What is your favorite colour? LAUNCELOT:Blue. BRIDGEKEEPER: Right. Off you go. 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: probably known bug
On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote: On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? The syncing could probably be better, but this problem is sometimes unavoidable. Knowing what filetype the problem occurs for would help in investigating the issue further. I don't know if sometimes it's unavoidable, but definitely sometimes it is avoidable. In my experience, it happened probably at least once with every filetype I've worked with. Just off the top of my head, it happened yesterday in a JSP file, and later in a Perl file. And it seems to happen a lot in HTML files. nikolai
Re: Vim thinks a directory is an illegal filename on Windows
Charles Campbell wrote: William S Fulton wrote: run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . I haven't found any way to avoid these messages with netrw, so it sounds like an issue for Bram M. This is a valid message. At the moment it's given Vim doesn't know yet (for sure) that some autocommand will kick in to handle it. You also get the message on Unix if you do :e dir/. -- BRIDGEKEEPER: What is the air-speed velocity of an unladen swallow? ARTHUR: What do you mean? An African or European swallow? BRIDGEKEEPER: Er ... I don't know that ... Arrggghhh! BRIDGEKEEPER is cast into the gorge. 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: probably known bug
[EMAIL PROTECTED] wrote: On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote: On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? The syncing could probably be better, but this problem is sometimes unavoidable. Knowing what filetype the problem occurs for would help in investigating the issue further. I don't know if sometimes it's unavoidable, but definitely sometimes it is avoidable. In my experience, it happened probably at least once with every filetype I've worked with. Just off the top of my head, it happened yesterday in a JSP file, and later in a Perl file. And it seems to happen a lot in HTML files. Well, I see a number of syn sync statements in syntax/html.vim, so Claudio Feiner has certainly tried to help out with this. Nick Hibma with perl, too. syntax/jsp.vim doesn't have any synchronization; probably the htmlTag and jspCommand regions therein could use them. Contact Rafael Garcia-Suarez about it. On your end, you could increase your syn sync minlines parameter (see :help syn-sync-minlines). Regards, Chip Campbell
Re: Vim thinks a directory is an illegal filename on Windows
Bram Moolenaar wrote: Charles Campbell wrote: William S Fulton wrote: run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . I haven't found any way to avoid these messages with netrw, so it sounds like an issue for Bram M. This is a valid message. At the moment it's given Vim doesn't know yet (for sure) that some autocommand will kick in to handle it. You also get the message on Unix if you do :e dir/. There is also some inconsistency going on here. On windows: gvim C:\WINDOWS gives: C:\WINDOWS\ illegal file name On Linux: gvim /usr gives: /usr is a directory but gvim /usr/ gives /usr/ illegal filename And unfortunately bash command completion results in /usr/ rather than /usr. From a user's point of view it just doesn't seem right if one is using the explorer with a directory list showing and then selecting a directory, the illegal filename message appears. One part of the program knows the directory is a directory and another part thinks it is a bad file :( William
Re: Vim thinks a directory is an illegal filename on Windows
William S Fulton wrote: run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . I haven't found any way to avoid these messages with netrw, so it sounds like an issue for Bram M. This is a valid message. At the moment it's given Vim doesn't know yet (for sure) that some autocommand will kick in to handle it. You also get the message on Unix if you do :e dir/. There is also some inconsistency going on here. On windows: gvim C:\WINDOWS gives: C:\WINDOWS\ illegal file name On Linux: gvim /usr gives: /usr is a directory but gvim /usr/ gives /usr/ illegal filename And unfortunately bash command completion results in /usr/ rather than /usr. From a user's point of view it just doesn't seem right if one is using the explorer with a directory list showing and then selecting a directory, the illegal filename message appears. One part of the program knows the directory is a directory and another part thinks it is a bad file :( Hey, Unix and MS-Windows ARE different. What happens here is that on Unix the shell does the wildcard expansion, while on MS-Windows Vim has to do it by itself. The rules for wildcard expansion are complicated, it's not strange that the results differ. Vim happens to add a slash to a directory name, for various reasons. -- If an elephant is left tied to a parking meter, the parking fee has to be paid just as it would for a vehicle. [real standing law in Florida, United States of America] /// 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///
functions that take much time in load_dummy_buffer() [vimgrep]
I identified which functions are slow and which are fast out of functions called (load_dummy_buffer() + wipe_dummy_buffer()) pair. As I wrote earlier this pair of functions is what slows down vimgrep, not the search. The loop of 1000x (load_dummy_buffer() + wipe_dummy_buffer()) takes 30 seconds per 1000 pairs on my machine (800 MHZ). These tests are on empty files, so data size is not a problem. No regexp searching is performed. Results: check_need_swap() - 50% major contributor to slowdown ml_open()- 30% 2nd contributor setfname() - 19% surprise, surprise The rest of functions are blazingly fast, take 1% of time. Fast functions (negligible overhead) include: - wipe_dummy_buffer() - buf_copy_options() - buflist_new() - aucmd_prepbuf() - aucmd_restbuf() I don't have real results for readfile() because I tested on empty files. But on empty file readfile() works fast. Yakov
Re: functions that take much time in load_dummy_buffer() [vimgrep]
Hi Yakov, On 4/28/06, Yakov Lerner [EMAIL PROTECTED] wrote: I identified which functions are slow and which are fast out of functions called (load_dummy_buffer() + wipe_dummy_buffer()) pair. As I wrote earlier this pair of functions is what slows down vimgrep, not the search. The loop of 1000x (load_dummy_buffer() + wipe_dummy_buffer()) takes 30 seconds per 1000 pairs on my machine (800 MHZ). These tests are on empty files, so data size is not a problem. No regexp searching is performed. Results: check_need_swap() - 50% major contributor to slowdown Maybe the 'noswapfile' option should be set for buffers opened during the :vimgrep operation? - Yegappan ml_open()- 30% 2nd contributor setfname() - 19% surprise, surprise The rest of functions are blazingly fast, take 1% of time. Fast functions (negligible overhead) include: - wipe_dummy_buffer() - buf_copy_options() - buflist_new() - aucmd_prepbuf() - aucmd_restbuf() I don't have real results for readfile() because I tested on empty files. But on empty file readfile() works fast. Yakov
