On Thu, Jul 16, 2009 at 03:41, StarWingweasley...@sina.com wrote:
Of course I am not pretending to add a c++ compiler for the highlighting.
That would be against the basic principle vim is the fastest editor. Any
feature
no, IMHO vim is not the fastest editor. you can try use Vim open a 2GB
On 7月17日, 上午12时11分, Nikolai Weibull n...@bitwi.se wrote:
On Thu, Jul 16, 2009 at 03:41, StarWingweasley...@sina.com wrote:
Of course I am not pretending to add a c++ compiler for the highlighting.
That would be against the basic principle vim is the fastest editor. Any
feature
no, IMHO
On 7月17日, 上午1时22分, StarWing weasley...@sina.com wrote:
yes, it's a big long line. and you know what Vim do? in my Vim
7.2.228, it dead. just lost respond. and take 100% CPU usage.
just I finish the mail above, My Gvim get respond again with full
screen of text, but after I try to select a
On 7月17日, 上午2时19分, Marc Weber marco-owe...@gmx.de wrote:
system (since history issue, Vim's undo system is more or less
terrible), and a flesh new parser-base highlight system. all in all,
Have you seenhttp://www.vim.org/soc/ideas.php?
About your long line use case: I don't think you
Vim crash when writing a file in BufRead event while vimgrep search.
I tested with vim7.2.234 on Ubuntu9.04 and Windows Vista.
This problem appeared at 7.2.203.
Steps To Reproduce:
$ echo x foo.txt
$ vim -u NONE
:au BufRead *.txt w bar (this is what gzip plugin do for .gz)
And, Can you help me to resolve this problem?
http://groups.google.com/group/vim_dev/t/890db4346d17ad0b
I use it in my script...
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit http://www.vim.org/maillist.php
Hi StarWing,
I just treat it as a practise. there are a amount of reasons to
improve Vim, not really full rewriting it.
for long line. I used to edit bookmark.htm generated by Firefox, it
Ok. I guess we have the cause of your mails now: Vim crashes for you in
some use cases and doesn't do
On Jul 15, 5:33 am, StarWing weasley...@sina.com wrote:
OKay, changenr() is more or less enough. but in doc, it says After
undo it is one less than the number of the undone change.
so, how can I get the exactly serial number of current buffer? the one
I can use in undo command. (changenr()
