Insert mode: does not paste the whole register
Hi! Simetimes 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 " 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. Best wishes, Georg ___ 24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com
RE: Svn and patches
> -Original Message- > From: Suresh Govindachar [mailto:[EMAIL PROTECTED] [...] > I recommend getting sources via svn -- it was > really very trivial Could you send some how-to for those of us who never used svn before? Thx. ---Zdenek
RE: Svn and patches
Zdenek asked for "some how-to for those of us who never used svn before?" I am no expert either, but this is what I did on Windows XP: Download the following from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 svn-win32-1.3.1.zip svn-win32-1.3.1_pl.zip svn-win32-1.3.1_dev.zip svn-win32-1.3.1_javahl.zip svn-win32-1.3.1_pdb.zip svn-win32-1.3.1_py.zip and extract into, say, c:\opt\svn. Then, mkdir raw\vim cd raw\vim c:\opt\svn\svn-win32-1.3.1\bin\svn.exe co https://svn.sourceforge.net/svnroot/vim/vim7 You may or may not get a fews lines of messages about "the server's certificate" ending with the question: (R)eject, accept (t)emporarily or accept (p)ermanently? t I would answer t. Once everything is downloaded, xcopy /e /q /i vim7 vim7x Notice no /h flag above. Then compile inside vim7x. xcopy /e /q /i /h vim7x c:\opt\vim\vim70f cd c:\opt\vim\vim70f\src move gvim.exe .. move vimrun.exe .. Free book on svn: http://svnbook.org/ Earlier version of this free book is available for sale but is supposedly full of bugs and outdated. --Suresh
Re: Insert mode: does not paste the whole register
Georg Dahn wrote: > Simetimes 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 " > > 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 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: minor problem with matchparen plugin
On Thu, Apr 27, 2006 at 06:23:30PM -0400, [EMAIL PROTECTED] wrote:
> I noticed that the matchparen plugin sometimes highlighted the wrong
> parenthesis.
>
> If syntax=c and the user types 'A' to start inserting text at the end of
> the following line:
> ((""))
> then the last ')' will be highlighted, but the _second_ (not the first)
> '(' will be highlighted.
>
>
> The following fixes this problem:
> ===
> --- runtime/plugin/matchparen.vim (revision 12)
> +++ runtime/plugin/matchparen.vim (working copy)
> @@ -88,7 +88,7 @@
>endif
>
>" When not in a string or comment ignore matches inside them.
> - let s_skip ='synIDattr(synID(line("."), col(".") - before, 0), "name") ' .
> + let s_skip ='synIDattr(synID(line("."), col("."), 0), "name") ' .
> \ '=~? "string\\|comment"'
>execute 'if' s_skip '| let s_skip = 0 | endif'
> ===
Coincidentally, this problem was reported yesterday (or maybe late
the previous day) on the vim users' list. Bram and I each posted a
patch similar to yours: we also moved the lines shown in your patch
down a few lines.
--Benji Fisher
Re: Insert mode: does not paste the whole register
On Fri, Apr 28, 2006 at 11:44:06AM +0200, Bram Moolenaar wrote: > > Georg Dahn wrote: > > > Simetimes 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 " > > > > 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. It should be possible to test whether you are running out of memory by copying and pasting 3000 lines at a time. If you are *not* running out of memory, but there are some problematic characters on or about Line 3500, you should be able to narrow down the problem. Perhaps :help i_CTRL-R_CTRL-R will help. Bram, is there any way to issue a warning when a copy/paste operation runs out of memory? HTH --Benji Fisher
Re: Insert mode: does not paste the whole register
Benji Fisher wrote: > Bram, is there any way to issue a warning when a copy/paste > operation runs out of memory? There should be a warning, but it might disappear again. -- ROBIN: (warily) And if you get a question wrong? ARTHUR: You are cast into the Gorge of Eternal Peril. ROBIN: Oh ... wacho! "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: Insert mode: 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 . 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
probably known bug
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 ) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? --Matt
Re: probably known bug
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 ) 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. nikolai
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 ) 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: 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 . > 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 characters, right at the point where you say inserting the register stops. Try using CTRL-R CTRL-R " instead 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 ) 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
> Well, this one is more of a trade-off than a bug (speed vs accuracy). > I suggest reading: :help syn-sync . Ah, thanks for pointing that out. --Matt
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 ) 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: Insert mode: does not paste the whole register
Hi! It appears that this file has characters, right at the point where you say inserting the register stops. Try using CTRL-R CTRL-R " instead of CTRL-R " . Ah, yes, that was it! Thank you very much! Best wishes, Georg ___ Switch an email account to Yahoo! Mail, you could win FIFA World Cup tickets. http://uk.mail.yahoo.com
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 ) 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/". Can an autocommand see if that specific message is there and erase it or overwrite it (without eliminating some other message)? --Suresh
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
