Hello..
I know the trick with the swapfile, I created a small .vimrc that sets
noswapfile. This was used in my example...
On Jun 16, 3:33 am, John Beckett [EMAIL PROTECTED] wrote:
misi wrote:
would like to use vim to edit large files (600mb).
The best way to tune Vim for large files is
I like the idea of reading in the background... As I know there is no
threading so far in vim, isn,t it? But few things probably could be
done in threads like syntax parsing for highlighting. Sometimes this
is also an issue, for eg. when opening a huge xml file etc.
yes thanks for the
The current syn match for cssPseudoClass :\S* would eat away tokens after
it, such as the comma , after a:link and the curly bracelet { after
a:visited in:
.selected_section_title a:link,.selected_section_title a:visited{ ...
The simple patch to syntax/css.vim attached should fix the above issue.
Hello, Vimmers.
I noticed that runtime/doc/ada.txt contains encoding=latin1 in its modelines.
It must change 'fileencoding' instead of 'encoding', because changing 'encoding'
is troublesome for most users who don't use Vim with encoding=latin1.
The following is a simple patch to fix the problem.
Pádraig Brady wrote:
Currently for /bin/sh scripts, $(command) and $((1+1))
are marked as errors. These constructs are POSIX compliant
and supported by dash and bash at least.
I contend that erroneously warning users away from these valid
constructs is much worse than not flagging them as
Charles E. Campbell, Jr. wrote:
Pádraig Brady wrote:
Currently for /bin/sh scripts, $(command) and $((1+1))
are marked as errors. These constructs are POSIX compliant
and supported by dash and bash at least.
I contend that erroneously warning users away from these valid
constructs is
On Monday 16 June 2008 07:11, Kana Natsuno wrote:
Hello, Vimmers.
I noticed that runtime/doc/ada.txt contains encoding=latin1 in its
modelines.
It must change 'fileencoding' instead of 'encoding', because changing
'encoding'
is troublesome for most users who don't use Vim with
Tony Mechelynck wrote:
#!/bin/sh scripts are supposed to be for sh (the old Bourne shell),
not bash or ksh. If you want them to be highlighted as bash scripts,
then replace #!/bin/sh by #!/bin/bash. Quoting lines 2431 to 2435 of
syntax.txt:
If there's no #! ... line, and the user hasn't
Kana Natsuno wrote:
Hello, Vimmers.
I noticed that runtime/doc/ada.txt contains encoding=latin1 in its
modelines.
It must change 'fileencoding' instead of 'encoding', because changing
'encoding'
is troublesome for most users who don't use Vim with encoding=latin1.
The following is a
hello,
you almost convinced me with the disk time...
but that is not true. Reading the same file with a command like grep,
takes 567msecs.
try
time grep XXX ./all3.c #this will not find anything, but will
process all the file.. and no mmap is used!
the result is:
real0m0.466s
Hi,
but that is not true. Reading the same file with a command like grep,
takes 567msecs.
is it faster if you do `set swapsync=` and `set nofsync` before
reading the file? If so, ext3 is to blame:
http://taint.org/2008/03/12/122601a.html
Nico
Pádraig Brady wrote:
Perhaps you just need to change the default now so that is_posix=1
and if one really wants to write old bourne shell script they can
set is_posix=0 in their .vimrc
Note I think this is important as by default, the very useful
$(..) and $((..)) constructs are
On 17/06/08 01:41, Pádraig Brady wrote:
Pádraig Brady wrote:
Perhaps you just need to change the default now so that is_posix=1
and if one really wants to write old bourne shell script they can
set is_posix=0 in their .vimrc
Note I think this is important as by default, the very useful
On Tue, 17 Jun 2008 03:49:19 +0900, Bram Moolenaar wrote:
The current version of this file doesn't set 'encoding' at all.
Should work fine.
Really? I checked with the following steps and environment, it
does set 'encoding' to latin1.
$ vim -u NONE -U NONE --noplugin
:set nocompatible
:set
Kana Natsuno wrote:
On Tue, 17 Jun 2008 03:49:19 +0900, Bram Moolenaar wrote:
The current version of this file doesn't set 'encoding' at all.
Should work fine.
Really? I checked with the following steps and environment, it
does set 'encoding' to latin1.
$ vim -u NONE -U NONE --noplugin
On Tue, Jun 17, at 01:57 Tony Mechelynck wrote:
On 17/06/08 01:41, Pádraig Brady wrote:
p.s. shouldn't the flag have been called is_posix_sh ?
It might have been called sh_is_posix, but it's too late for that --
upwards compatibility again.
As for erroneously -- I agree with Bram
16 matches
Mail list logo
