Re: vim scrolling painfully slow
On Nov 18, 2007 8:26 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I connect from windows xp to solaris using telnet. I was scrolling > using vim editor and saw something strange. If I do a Ctrl-F twice > in succession, the first screen gets updated quickly (almost in > no time) but the second screen takes very long time (about 8 > seconds). > > To eliminate problems in network, keyboard, memory on windows > side, I tried the vi editor. It scrolls so fast, I barely see the > refresh > happening. > > Any ideas ? You may want to try different tips explained in ":help slow-terminal". -- Dominique --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Charles E Campbell wrote: > Any good way to get > the vim process's pid? How about under Windows? Maybe a patch to add getpid() function to vimscript is not bad idea ? Even without relation to Charles ciphering troubles. Can this be added to the todo ? Yakov --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
> > On unixes that have /proc, you can get pid of vim examining > > /proc/self. > [...] Does not work on Solaris. -- Vlad pgpEOQ3yOhAtN.pgp Description: PGP signature
Re: vim scrolling painfully slow
> > Do you have syntax highlighting enabled? If so, try turning it off > > and see if that helps. It can take vim a long time to highlight > > files with long lines. > Did not notice differences with syntax on/off. Both were equally slow. I guess that cat-ing file, or viewing it in less is faster than vim, isn't it ? That would probably mean that we use the terminal somehow in-efficiently ? I haven't red the source code at all, but I would guess that vim is re-drawing whole screen even if you shift down by one line. Just out of curiosity, could you try opening file in less, and scroll line by line down and up ? Is it also slow ? -- Vlad pgpuZvQJ3YMuZ.pgp Description: PGP signature
Re: `match()` with branches [and a patch]
Nico Weber wrote: > > I wonder how often the detection will fail. "@interface" and "@end" > > could appear in a comment of a C or C++ file, at least. Esp. when > > using > > something like doxygen. > > What about '[EMAIL PROTECTED]|[EMAIL PROTECTED]' (and maybe throw in a > '\|[EMAIL PROTECTED]' at > the end for good measure)? That's a good restriction. Suppose a .h file is C++ and recognized as objective C, how bad would the effect be? I assume that objective C is quite similar to C++. There are a few mistakes, you can use this to try out: http://www.google.com/codesearch?hl=en&q=+file:%5C.h+%5E%40(interface%7Cclass%7Cend)&sa=N Note that you need to look at the file to verify the type. Google Code Search also makes mistakes. -- hundred-and-one symptoms of being an internet addict: 173. You keep tracking down the email addresses of all your friends (even childhood friends). /// 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/// --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: (bug) vim freezes and loops forever (uses 100% CPU) in syntax.c
Dominique Pelle wrote:
> Hi
>
> I can reproduce a vim bug filed in Ubuntu launchpad using the latest
> vim-7.1 (Patches 1-166). Here is a link to the original bug description:
>
> https://bugs.launchpad.net/ubuntu/+source/vim/+bug/68960
>
> Here is how I can reproduce it. I did not use '-u NONE', because
> standard plugins need to be loaded to reproduce that bug.
> ".vimrc" file only needs to contain "syntax on" to reproduce it:
>
>$ cat ~/.vimrc
>syntax on
>
>$ vim +89 vim_testcase # file "vim_testcase" is attached
>
> ... then, when moving cursor around closing parentheses at
> line 89, observe that vim freezes and takes 100% of CPU (it
> can be interrupted with Ctrl-C).
>
> Trying to debug, I found that vim loops forever in a while(...)
> loop in syntax.c in function syntax_start():
>
> syntax.c:
>
> 562 while (current_lnum < lnum)
> 563 {
> ...
> ...
> 596 load_current_state(prev);
> ...
> ...
> 609 line_breakcheck();
> 610 if (got_int)
> 611 {
> 612 current_lnum = lnum;
> 613 break;
> 614 }
> 615 }
>
> This while loop never ends with attached "vim_testcase" file.
> Adding some printf(), I can see that:
>
> - Before entering above while loop:
> - current_lnum == 65
> - lnum == 80
>
> - Then when iterating in the while loop:
> - lnum remains unchanged (80)
> - current_lnum becomes:
>
> 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
> 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
> 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
> etc.
>
> current_lnum never reaches lnum (80) so loop never ends.
>
> current_lnum goes back from 78 to 65 when calling
> load_current_state(prev) at line 596.
>
> I do not understand the idea behind load_current_state() and
> store_current_state() to go beyond and come up with fix for this.
>
> I'm using vim-7.1 (Patches 1-166) on Linux x86, built with
> 'configure --with-features=huge'.
I can reproduce it. Looks like a problem with the matchparen plugin
when getting a syntax ID, combined with the syntax stack being wrong.
This will be difficult to figure out, I'll put it in the todo list.
--
hundred-and-one symptoms of being an internet addict:
172. You join listservers just for the extra e-mail.
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: `match()` with branches [and a patch]
> I wonder how often the detection will fail. "@interface" and "@end"
> could appear in a comment of a C or C++ file, at least. Esp. when
> using
> something like doxygen.
What about '[EMAIL PROTECTED]|[EMAIL PROTECTED]' (and maybe throw in a
'\|[EMAIL PROTECTED]' at
the end for good measure)?
> The check could be turned into a one liner:
>
> " .h files can be C, Ch C++, ObjC or ObjC++.
> " Set c_syntax_for_h if you want C, ch_syntax_for_h if you want Ch.
> ObjC is
> " detected automatically.
> au BufNewFile,BufRead *.h call s:FTheader()
>
> func! s:FTheader()
> if match(getline(1, min([line("$"), 200])), '@interface\|@end') > -1
If we add the '^'s and '\|[EMAIL PROTECTED]', this line would be > 80 chars.
>
>setf objc
> elseif exists("c_syntax_for_h")
>setf c
> elseif exists("ch_syntax_for_h")
>setf ch
> else
>setf cpp
> endif
> endfunc
Nico
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: `match()` with branches [and a patch]
Nico Weber wrote:
> Attached is a patch to filetype.vim that adds objc detection for .h
> files. I don't know if this is of general interest, but I think so.
I wonder how often the detection will fail. "@interface" and "@end"
could appear in a comment of a C or C++ file, at least. Esp. when using
something like doxygen.
Is there any way to make it a bit more specific?
The check could be turned into a one liner:
" .h files can be C, Ch C++, ObjC or ObjC++.
" Set c_syntax_for_h if you want C, ch_syntax_for_h if you want Ch. ObjC is
" detected automatically.
au BufNewFile,BufRead *.h call s:FTheader()
func! s:FTheader()
if match(getline(1, min([line("$"), 200])), '@interface\|@end') > -1
setf objc
elseif exists("c_syntax_for_h")
setf c
elseif exists("ch_syntax_for_h")
setf ch
else
setf cpp
endif
endfunc
--
hundred-and-one symptoms of being an internet addict:
169. You hire a housekeeper for your home page.
/// 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
(bug) vim freezes and loops forever (uses 100% CPU) in syntax.c
Hi
I can reproduce a vim bug filed in Ubuntu launchpad using the latest
vim-7.1 (Patches 1-166). Here is a link to the original bug description:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/68960
Here is how I can reproduce it. I did not use '-u NONE', because
standard plugins need to be loaded to reproduce that bug.
".vimrc" file only needs to contain "syntax on" to reproduce it:
$ cat ~/.vimrc
syntax on
$ vim +89 vim_testcase # file "vim_testcase" is attached
... then, when moving cursor around closing parentheses at
line 89, observe that vim freezes and takes 100% of CPU (it
can be interrupted with Ctrl-C).
Trying to debug, I found that vim loops forever in a while(...)
loop in syntax.c in function syntax_start():
syntax.c:
562 while (current_lnum < lnum)
563 {
...
...
596 load_current_state(prev);
...
...
609 line_breakcheck();
610 if (got_int)
611 {
612 current_lnum = lnum;
613 break;
614 }
615 }
This while loop never ends with attached "vim_testcase" file.
Adding some printf(), I can see that:
- Before entering above while loop:
- current_lnum == 65
- lnum == 80
- Then when iterating in the while loop:
- lnum remains unchanged (80)
- current_lnum becomes:
65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78,
etc.
current_lnum never reaches lnum (80) so loop never ends.
current_lnum goes back from 78 to 65 when calling
load_current_state(prev) at line 596.
I do not understand the idea behind load_current_state() and
store_current_state() to go beyond and come up with fix for this.
I'm using vim-7.1 (Patches 1-166) on Linux x86, built with
'configure --with-features=huge'.
-- Dominique
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
vim_testcase
Description: Binary data
