Re: Is it possible to do spelling check for comments only?
Thank you very much, Swaroop! This is (almost) the answer to my unrequested feature for spell checking, specially for gettext message catalogs (po files). I tried editing the improved po.vim syntax script (http://www.vim.org/scripts/script.php?script_id=913) and figured out a 95% good solution, which is adding ",@Spell" to the end of line 35. Now only the translations are checked, not the original messages. This is great, because I can really stop and look at what is marked as misspelled. The catch is: accelerator keys, like "F" in _File or &File, aren't included in the word as far as it concerns the spell checking. I.e., vim will try to check the spelling of "ile" instead of "File". The syntax file defines a different color for the accelerator keys, to make them more easily recognizable. Could I have the best of both worlds, highlighting the accelerator keys differently and still counting them as part of the word for spell checking? I'm sorry to ask for assistance, but I don't know vimscript (would learn, but don't have the time to) and the syntax file author said he won't have time for it. (The last update was more than a year ago.) Thanks! Leonardo Fontenelle 2007/5/21, Swaroop C H <[EMAIL PROTECTED]>: > When programming, I have to turn the spelling check off. Or it will > show a lot of spelling "mistakes" in the code. I'd like to apply > spelling check for sentences within the comment blocks only. Is it > possible to configure VIM to do this? See :help spell-syntax Best, Swaroop --- www.ion.co.in
Re: How to write a map for gcc?
Hi TJ, On Tue, 2007-05-22 at 21:56 -0500, Ting Jiang wrote: > Hi, everyone: > > I am a beginner user of vim and I use it to write my C/C++ code in > Ubuntu. Every time I finished a C code and I want to compile it, I have > to type: > > :gcc -o mycfile.out mycfile.c > > How can I map this command to a shortcut key like F12? > > Thanks a lot. > > TJ > To compile: nnoremap :!cc -o %:t:r.out % To run: nnoremap :!./%:t:r.out cheers, -- Mark
Re: Really stupid question...
> I am trying to write a simple function, which searches through
> the whole buffer to fund a certain pattern and stops searching
> when found the first match. I also want the function to
> return a matched/not matched return code and given the caller
> the line/column of the match if found.
You might try with the built-in search() function. There are
some nuances to finding a match on the first line, but these can
be overcome by going to *end* of the file, and then searching
with wrapscan. Something like this untested function might do
the trick:
function! first(pat)
let old_line = line('.')
$
let result=search(a:pat, 'w')
exec old_line
return result
endfunc
You can read up on the nuances and flags of search() at
:help search()
-tim
Re: How to write a map for gcc?
I am a beginner user of vim and I use it to write my C/C++ code in Ubuntu. Every time I finished a C code and I want to compile it, I have to type: :gcc -o mycfile.out mycfile.c How can I map this command to a shortcut key like F12? See `:help :make` and `:help compiler-select` and `:help :map`
How to write a map for gcc?
Hi, everyone: I am a beginner user of vim and I use it to write my C/C++ code in Ubuntu. Every time I finished a C code and I want to compile it, I have to type: :gcc -o mycfile.out mycfile.c How can I map this command to a shortcut key like F12? Thanks a lot. TJ
Really stupid question...
Hi, I may become blinded by to often looking for too long onto my monitor, but... I am trying to write a simple function, which searches through the whole buffer to fund a certain pattern and stops searching when found the first match. I also want the function to return a matched/not matched return code and given the caller the line/column of the match if found. But all I are errors... Thank you very much for any helpful hint... Slightly frustrated, mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: Vim to Vi (Was: weird defaults in Feisty)
[EMAIL PROTECTED] wrote: > It seems nature to have vim behave like vi, if the Linux distribution > choose to do so. The distribution decides everything and it is non-related > to vim developers themselves. > > All you need to do is to: sudo apt-get install vim-gtk, which installs a > Big version of vim, and the vim will be replaced with that version. Well... not replaced. They will both be installed. You'll probably need to run update-alternatives to ensure that /usr/bin/vim points at the one you want. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: A performance question
AFAIK Vim 7 has a different way of handling undo levels. Have you tried with Vim 6 instead? I had used Vim 6 to edit a text file (3Gbytes) and do things within seconds. -- Sincerely, Pan, Shi Zhu. ext: 2606 Robert Maxwell Robinson <[EMAIL PROTECTED]> 写于 2007-05-23 05:59:20: > > ":set undolevels=-1" caused my test to run in less than 15 sec, with no > other options fiddled with. Thanks Tim, now I have a work-around! > > Now, does having the undo facility available _necessarily_ mean deleting a > large chunk of a file takes so long, or can that be added to the list of > desired performance enhancements? > > Max > > On Tue, 22 May 2007, Tim Chase wrote: > > > The issue of editing large files comes up occasionally. A few settings can > > be tweaked to vastly improve performance. Notably, the 'undolevels' > > setting can be reduced to -1 or 0 for improved performance. If your lines > > are long, it can also help to disable syntax highlighting as well. You can > > drop in on one such thread here: > >
Re: Vim to Vi (Was: weird defaults in Feisty)
fREW <[EMAIL PROTECTED]> 写于 2007-05-23 08:15:55: > Yeah, the really big problem is that the guy I am working with who I > am helping admin a few servers is at exactly step 1. In fact, it > wasn't until recently that he figured out (I told him) that Ctrl-Z is > not the same as :q!. And like you said, we upgraded and he was just > like, "vi got totally weird and now I use nano!" But after having > explained to him a couple things that might help him out (r for > replacing single characters and whatnot) I think he might start the > path to enlightenment ;-) > > -fREW It seems nature to have vim behave like vi, if the Linux distribution choose to do so. The distribution decides everything and it is non-related to vim developers themselves. All you need to do is to: sudo apt-get install vim-gtk, which installs a Big version of vim, and the vim will be replaced with that version. I don't see any problem now, in Feisty, I just run "vi" and everything is okay, I do *never* use command "vim" to run vim, runing vim with the command "vi" feels much better for me. Anyway, I don't think any experienced vim users will still think he need a plain "vi" after he had get used to "vim". So it is wield for me to have two different versions of vim on my single computer. -- Sincerely, Pan, Shi Zhu. ext: 2606
Re: A performance question
On 5/22/07, Gary Johnson <[EMAIL PROTECTED]> wrote: On 2007-05-22, Robert Maxwell Robinson <[EMAIL PROTECTED]> wrote: > Hmm, interesting. I've noticed before that the CPU is pegged when I'm > deleting, but I don't think my machine's behavior is due to CPU load; the > machine has two CPUs, I'm typically the only (serious) user, as "top" has > confirmed is the case now, and I get the same behavior whether I'm running > another large job or not. My other large job takes about 1 Gb leaving > almost 2 Gb of memory free, so I don't think I'm running out of physical > memory, either. > > Given the difference between your results and mine, I finally checked my > software versions, which are old: Red Hat 3.4.6, vim 6.3.82. Unfortunately > I don't have permission to update this system, and the administrator hasn't > been willing to do so in the past. It turns out that this Red Hat installation also has vim 6.3.82 in /usr/bin/vim, so I tried that, too. /usr/bin/vim -u NONE two_million_lines 50% :.,$d 2 minutes 30 seconds! Eureka! According to the System Monitor CPU bar color, that was almost all User time, whereas with vim 7.1, it was a more balanced mix of User and Kernel time. (Kudos to Bram for such a performance improvement from vim 6 to 7!) I'm not allowed to update anything under /usr on this system, either, so I build the latest and greatest versions of tools under $HOME/src and put the binaries in $HOME/bin. Building vim under Linux is really easy. I do the following. mkdir ~/src/Linux/vim-7.1 cd ~/src/Linux/vim-7.1 Download vim-7.1.tar.bz2 from vim.sf.net. tar jxf vim-7.1.tar.bz2 cd vim71 ./configure --prefix=$HOME/src/Linux/vim-7.1 --enable-cscope make make install ln -s $HOME/src/Linux/vim-7.1/bin/vim ~/bin/Linux/vim My PATH includes $HOME/bin/Linux and that directory contains most of the symbolic links to vim that you will find in $HOME/src/Linux/vim-7.1/bin; the ones I use. That is, $ cd ~/bin/Linux $ ls -l | grep vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvim -> vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvimdiff -> vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vi -> vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 view -> vim lrwxrwxrwx 1 garyjohn fw 40 May 17 18:45 vim -> /home/garyjohn/src/Linux/vim-7.1/bin/vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vimdiff -> vim That makes it really easy to update and to test different versions of vim with only a change to one symbolic link. But that's just a matter of taste. The point is that however you choose to install it, it's easy to build and maintain your own vim installation without having to bother or bother with your system administrator. > I went looking for release notes for vim, but the announcements I found > didn't go into detail about what bugs were fixed in which version. Can > someone point me in the right direction? Go to the vim home page, vim.sf.net, click on the link to Documentation, then "help files online", then "main help file", and finally, "version7.txt". Or you can just go that page directly, http://vimdoc.sourceforge.net/htmldoc/version7.html This describes all the changes from version 6 to version 7, including bug fixes. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA Another thing that might help with speed that was mentioned a month or so ago is the following script specifically aimed at increasing speed for large files: http://www.vim.org/scripts/script.php?script_id=1506. -fREW
Re: Vim to Vi (Was: weird defaults in Feisty)
On 5/22/07, Tobia <[EMAIL PROTECTED]> wrote:
David Nečas (Yeti) wrote:
> it's a bit strange when a vim user describes vi as `crazy' and `so
> weird'...
It may sound strange to us Vim veterans, but it's what I would expect.
My path to learning Vi/Vim (which took place at the same time as my
learning of GNU/Linux, by the way) was as follows:
1. Use it as a Notepad with weird save/quit commands (:w ...)
Always in insert mode, only using the arrows, Del, BS, Home, End, and
hitting Esc and 'u' like crazy whenever something weird happened.
2. Learn "copy & paste", first line-wise (dd yy p P), then selection-wise
(v V ^V y d, still only using the arrow keys.
At this point (a few months?) I was already as productive as with my
former Windows editor of choice! (something like TextEdit™ or TextPad™)
3. Learn that command mode is actually useful for moving around in the
file (gg, G, {, }) and opening two files at a time (:e, C-^)
4. Other stuff (complex movements, buffers/windows/tabs, registers,
macros, mappings, autocommands, folding, custom syntax files...)
This timeline might look non-linear, in fact I believe that learning Vim
is an exponential task to the engaged user, and that's a very good thing!
The point is: I don't consider my learning path in any way peculiar, and
if Vim had suddenly reverted to Vi while I was in phases 1 to 3, I would
have looked at my computer with a blank, baffled expression on my face.
Tobia
Yeah, the really big problem is that the guy I am working with who I
am helping admin a few servers is at exactly step 1. In fact, it
wasn't until recently that he figured out (I told him) that Ctrl-Z is
not the same as :q!. And like you said, we upgraded and he was just
like, "vi got totally weird and now I use nano!" But after having
explained to him a couple things that might help him out (r for
replacing single characters and whatnot) I think he might start the
path to enlightenment ;-)
-fREW
Re: Right click = toggle fold
I just wanted to share this little mapping I've come up with: :map za I find using the keyboard more useful, so I use the space bar to toggle the opening/closing of the folds: :map za So, it becomes 'j/k/c-f/c-b', space (expand), read, space (collapse), j/k some more... Best, Swaroop
Re: A performance question
On 2007-05-22, Robert Maxwell Robinson <[EMAIL PROTECTED]> wrote: > Hmm, interesting. I've noticed before that the CPU is pegged when I'm > deleting, but I don't think my machine's behavior is due to CPU load; the > machine has two CPUs, I'm typically the only (serious) user, as "top" has > confirmed is the case now, and I get the same behavior whether I'm running > another large job or not. My other large job takes about 1 Gb leaving > almost 2 Gb of memory free, so I don't think I'm running out of physical > memory, either. > > Given the difference between your results and mine, I finally checked my > software versions, which are old: Red Hat 3.4.6, vim 6.3.82. Unfortunately > I don't have permission to update this system, and the administrator hasn't > been willing to do so in the past. It turns out that this Red Hat installation also has vim 6.3.82 in /usr/bin/vim, so I tried that, too. /usr/bin/vim -u NONE two_million_lines 50% :.,$d 2 minutes 30 seconds! Eureka! According to the System Monitor CPU bar color, that was almost all User time, whereas with vim 7.1, it was a more balanced mix of User and Kernel time. (Kudos to Bram for such a performance improvement from vim 6 to 7!) I'm not allowed to update anything under /usr on this system, either, so I build the latest and greatest versions of tools under $HOME/src and put the binaries in $HOME/bin. Building vim under Linux is really easy. I do the following. mkdir ~/src/Linux/vim-7.1 cd ~/src/Linux/vim-7.1 Download vim-7.1.tar.bz2 from vim.sf.net. tar jxf vim-7.1.tar.bz2 cd vim71 ./configure --prefix=$HOME/src/Linux/vim-7.1 --enable-cscope make make install ln -s $HOME/src/Linux/vim-7.1/bin/vim ~/bin/Linux/vim My PATH includes $HOME/bin/Linux and that directory contains most of the symbolic links to vim that you will find in $HOME/src/Linux/vim-7.1/bin; the ones I use. That is, $ cd ~/bin/Linux $ ls -l | grep vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvim -> vim lrwxrwxrwx 1 garyjohn fw 3 Nov 14 2005 gvimdiff -> vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vi -> vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 view -> vim lrwxrwxrwx 1 garyjohn fw 40 May 17 18:45 vim -> /home/garyjohn/src/Linux/vim-7.1/bin/vim lrwxrwxrwx 1 garyjohn fw 3 Sep 23 2005 vimdiff -> vim That makes it really easy to update and to test different versions of vim with only a change to one symbolic link. But that's just a matter of taste. The point is that however you choose to install it, it's easy to build and maintain your own vim installation without having to bother or bother with your system administrator. > I went looking for release notes for vim, but the announcements I found > didn't go into detail about what bugs were fixed in which version. Can > someone point me in the right direction? Go to the vim home page, vim.sf.net, click on the link to Documentation, then "help files online", then "main help file", and finally, "version7.txt". Or you can just go that page directly, http://vimdoc.sourceforge.net/htmldoc/version7.html This describes all the changes from version 6 to version 7, including bug fixes. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: weird defaults in Feisty
fREW wrote:
> On 5/22/07, fREW <[EMAIL PROTECTED]> wrote:
>> On 5/22/07, Gene Kwiecinski <[EMAIL PROTECTED]> wrote:
>> > >I just updated to feisty on a samba server machine and a lot of the
>> > >vim defaults went crazy. For example: Pressing the Up or Down keys
>> > >in insert mode add new lines with just A or B on them, respectively.
>> >
>> > Sounds like it stopped recognising arrow keys' ANSI sequences
>> ("[A"
>> > and "[B"). Wouldda thought the would break out of insert
>> > mode, but...
>> >
>> >
>> > >That I can live with, but check this out, if I have the following
>> > >sentence:
>> > >fREW is a silly guy
>> > >and my cursor is on the s, and I press cw, it changes to
>> > >fREW is a sill$ guy
>> > >and it works just like I had pressed cw and it replaces up the the $
>> > >or if I press escape it only has the new text I put in, but it's just
>> > >so weird! Does anyone know where these new changes in Feisty come
>> >
>> > Uhh, sounds like what it's supposta do, no? ??
>> >
>> > Is there a problem with actually changing the text, or just what's
>> > displayed? Dunno the setting offhand, but a slow-redraw will mark to
>> > the end of the text to be replaced, eg, if you were to change to the
>> end
>> > of the line, you'd still see the whole line, but with a '$' where the
>> > last character would be, vs erasing all the text and just leaving the
>> > insert-cursor in its place. I find the latter disquieting, and would
>> > rather *see* what I'm replacing, but never really paid too much
>> > attention to which settings do what. I'm complacent that way... :D
>> >
>>
>> I prefer that cw doesn't do this weird $ thing. It bothers me. I
>> might be ok with it if the word I was typing over were a different
>> color, but that is not the case.
>>
>> Also: set nocompatible worked just fine, but I wanted to make this a
>> system wide setting. I think that the problem has to do with vim not
>> sourcing the /etc/vim/vimrc. It appears that that is why things
>> aren't working correctly. Anyone know why it wouldn't source that
>> file?
>>
>> -fREW
>>
>
> I figured it out and if anyone else has this problem I am sending out
> the solution. Basically when I run vi it is running vim.tiny.
> vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also,
> vim.tiny is pretty crippled, in that it doesn't even have syntax
> highlighting, so consider whether that's even what you want.
This is by design. Note that vimrc.tiny is /only/ sourced when vim.tiny
is invoked as vi. This is a Debian/Ubuntu extension; unmodified vim has
no notion of vimrc.tiny.
As at least one person has noted, there are many users who expect a
vi-compatible program when they type "vi" at the command-line. When this
isn't what you want, you really should consider changing your habit to
use vim, as that way you are sure to get a featureful vim, if one is
installed ("vi" could get you any one of a number of programs, depending
on the system you're on).
To switch your "vi" to pull a real vim, you might consider installing a
vim such as vim-gnome or vim-full (these are Debian names), and using
update-alternatives to set vi to be one of those instead of vim-tiny.
Actually, current default is for vi to point at /usr/bin/vim, so if your
update-alternatives has vim set to /usr/bin/vim.gnome or
/usr/bin/vim.full, your vi will probably start sourcing vimrc instead of
vimrc.tiny. This may change in the future (vi may default to
/usr/bin/vim.tiny instead of /usr/bin/vim).
Further discussion of this should possibly be moved to the Ubuntu or
Debian forums (I'm not certain how much of this may be specific to
Ubuntu as opposed to Debian; the source code changes included macro
names with "DEBIAN", in them, so I'm assuming that most of the
decision-making for this was made by Debian developers).
--
HTH,
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
signature.asc
Description: OpenPGP digital signature
Re: A performance question
Hmm, interesting. I've noticed before that the CPU is pegged when I'm deleting, but I don't think my machine's behavior is due to CPU load; the machine has two CPUs, I'm typically the only (serious) user, as "top" has confirmed is the case now, and I get the same behavior whether I'm running another large job or not. My other large job takes about 1 Gb leaving almost 2 Gb of memory free, so I don't think I'm running out of physical memory, either. Given the difference between your results and mine, I finally checked my software versions, which are old: Red Hat 3.4.6, vim 6.3.82. Unfortunately I don't have permission to update this system, and the administrator hasn't been willing to do so in the past. I went looking for release notes for vim, but the announcements I found didn't go into detail about what bugs were fixed in which version. Can someone point me in the right direction? Thanks. --Max On Tue, 22 May 2007, Gary Johnson wrote: Now, does having the undo facility available _necessarily_ mean deleting a large chunk of a file takes so long, or can that be added to the list of desired performance enhancements? Not in my experience. In both experiments I reported earlier I hadn't done anything special with 'undolevels' and checking them now shows "undolevels=1000". I repeated the experiment on the Linux system staring vim as vim -u NONE two_million_lines ":.,$d" took 13 seconds. I did notice that the CPU was railed at 100% during that time, so loading of your CPU by other tasks may have an effect, as might the actual physical memory available to vim. ":set undolevels=-1" did reduce the time to 10 seconds. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: A performance question
On 2007-05-22, Robert Maxwell Robinson <[EMAIL PROTECTED]> wrote: > ":set undolevels=-1" caused my test to run in less than 15 sec, with no > other options fiddled with. Thanks Tim, now I have a work-around! > > Now, does having the undo facility available _necessarily_ mean deleting a > large chunk of a file takes so long, or can that be added to the list of > desired performance enhancements? Not in my experience. In both experiments I reported earlier I hadn't done anything special with 'undolevels' and checking them now shows "undolevels=1000". I repeated the experiment on the Linux system staring vim as vim -u NONE two_million_lines ":.,$d" took 13 seconds. I did notice that the CPU was railed at 100% during that time, so loading of your CPU by other tasks may have an effect, as might the actual physical memory available to vim. ":set undolevels=-1" did reduce the time to 10 seconds. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Right click = toggle fold
Hi I just wanted to share this little mapping I've come up with: :map za It makes right-clicking on a fold toggle it opened/closed. Using the mouse wheel all the time to scroll around in GVim, I find this very useful for navigating big files, especially with automatic syntax- or indent-folding. Scroll, click (expand), read, click (collapse), scroll some more... Tobia
Re: A performance question
Thanks, Andy; the black hole register is a new idea to me. Unfortunately,
":.,$d _" to the black hole register appears to take the same amount of
time as ":.,$d" itself. "set undolevels=-1" speeds it up, but "set
undolevels=0" does not; this suggests to me that the problem isn't related
to how many undo buffers are around, just that the undo facility is
available at all.
Honestly, the 3 minutes it takes has to involve a significant amount of
waste, such as timing out for some system resource; reading the 2 million
line file into memory doesn't take that long in the first place, and the
delete is the first change I make to the file, so there isn't a stack of
buffers filled with undo information to start with.
Max
On Tue, 22 May 2007, Andy Wokula wrote:
A.J.Mechelynck schrieb:
Robert M Robinson wrote:
First, thanks very much for creating VIM! I have been using it on Linux
systems for years, and now use it via cygwin at home as well. I vastly
prefer VIM to EMACS, especially at home. I learned vi on a VAX/VMS
system long ago (a friend of mine had ported it), when our computer
science department was loading so many people on the VAXen that EDT was
rendered unusably slow. I still like VIM largely because I can do so
much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large
files (millions of lines), deleting a large number of lines (say,
hundreds of thousands to millions) takes an unbelieveably long time in
VIM--at least on my systems. This struck me as so odd, I looked you up
(for the first time in all my years of use) so I could ask why!
Seriously, going to line 1 million of a 2 million line file and typing
the command ":.,$d" takes _minutes_ on my system (Red Hat Linux on a
2GHz Athlon processor (i686), 512kb cache, 3 Gb memory), far longer than
searching the entire 2 million line file for a single word
(":g/MyQueryName/p"). Doing it this way fits way better into my usual
workflow than using "head -n 100", because of course I'm using a
regular expression search to determine that I
want to truncate my file at line 100 in the first place.
I looked in the archive, and couldn't see that this issue had been
raised before. Is there any chance it can get added to the list of
performance enhancement requests?
Thanks,
Max Robinson, PhD
I think this is just "part of how Vim behaves".
When you edit a file, Vim holds the whole file in memory (IIUC). When you
delete a million lines, Vim frees (i.e., releases to the OS) the memory
those lines were using. That takes some time.
Best regards,
Tony.
What about the numbered registers?
:h "1
After freeing the lines, they are copied to "1 .
And the content of "1 is shifted to "2 (before, of course)
And so on, until register "9.
To avoid the copies, the blackhole register can be used:
:.,$d _
If there are copies, registeres can be cleared by hand:
:let @1 = ""
:let @2 = ""
...
:let @9 = ""
This also takes time, but frees the memory.
--
Regards,
Andy
Re: A performance question
A.J.Mechelynck schrieb:
Robert M Robinson wrote:
First, thanks very much for creating VIM! I have been using it on
Linux systems for years, and now use it via cygwin at home as well. I
vastly prefer VIM to EMACS, especially at home. I learned vi on a
VAX/VMS system long ago (a friend of mine had ported it), when our
computer science department was loading so many people on the VAXen
that EDT was rendered unusably slow. I still like VIM largely because
I can do so much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large
files (millions of lines), deleting a large number of lines (say,
hundreds of thousands to millions) takes an unbelieveably long time in
VIM--at least on my systems. This struck me as so odd, I looked you
up (for the first time in all my years of use) so I could ask why!
Seriously, going to line 1 million of a 2 million line file and typing
the command ":.,$d" takes _minutes_ on my system (Red Hat Linux on a
2GHz Athlon processor (i686), 512kb cache, 3 Gb memory), far longer
than searching the entire 2 million line file for a single word
(":g/MyQueryName/p"). Doing it this way fits way better into my usual
workflow than using "head -n 100", because of course I'm using a
regular expression search to determine that I
want to truncate my file at line 100 in the first place.
I looked in the archive, and couldn't see that this issue had been
raised before. Is there any chance it can get added to the list of
performance enhancement requests?
Thanks,
Max Robinson, PhD
I think this is just "part of how Vim behaves".
When you edit a file, Vim holds the whole file in memory (IIUC). When
you delete a million lines, Vim frees (i.e., releases to the OS) the
memory those lines were using. That takes some time.
Best regards,
Tony.
What about the numbered registers?
:h "1
After freeing the lines, they are copied to "1 .
And the content of "1 is shifted to "2 (before, of course)
And so on, until register "9.
To avoid the copies, the blackhole register can be used:
:.,$d _
If there are copies, registeres can be cleared by hand:
:let @1 = ""
:let @2 = ""
...
:let @9 = ""
This also takes time, but frees the memory.
--
Regards,
Andy
Re: A performance question
":set undolevels=-1" caused my test to run in less than 15 sec, with no other options fiddled with. Thanks Tim, now I have a work-around! Now, does having the undo facility available _necessarily_ mean deleting a large chunk of a file takes so long, or can that be added to the list of desired performance enhancements? Max On Tue, 22 May 2007, Tim Chase wrote: The issue of editing large files comes up occasionally. A few settings can be tweaked to vastly improve performance. Notably, the 'undolevels' setting can be reduced to -1 or 0 for improved performance. If your lines are long, it can also help to disable syntax highlighting as well. You can drop in on one such thread here:
Re: A performance question
":set syntax?" replies "syntax=". I don't think it's syntax highlighting. I've used that with C and Prolog code before; I gave it up because it was too slow. I'm editing text output from one of my programs; truncating the output of a day-long run to match a run in progress for testing purposes, hunting down rare bugs. Max On Tue, 22 May 2007, Tim Chase wrote: Do you have syntax highlighting enabled? That can really slow vim down. Well, I don't mean to. ":set" says this: It can be toggled via :syntax on and :syntax off To see what flavor of syntax highlighting you currently have, you can query the 'syntax' setting: :set syntax? -tim
Re: A performance question
I just tried deleting 1133093 lines of a 1133093+1133409 line file, after typing ":syntax off". It took about 3 minutes. Max On Tue, 22 May 2007, Tim Chase wrote: Do you have syntax highlighting enabled? That can really slow vim down. Well, I don't mean to. ":set" says this: It can be toggled via :syntax on and :syntax off To see what flavor of syntax highlighting you currently have, you can query the 'syntax' setting: :set syntax? -tim
Re: A performance question
Do you have syntax highlighting enabled? That can really slow vim down. Well, I don't mean to. ":set" says this: It can be toggled via :syntax on and :syntax off To see what flavor of syntax highlighting you currently have, you can query the 'syntax' setting: :set syntax? -tim
Re: A performance question
Well, I don't mean to. ":set" says this: -- autoindent helplang=en scroll=11 t_Sb=Esc[4%dm backspace=2 history=50 ttyfast t_Sf=Esc[3%dm cscopetag hlsearchttymouse=xterm cscopeverbose ruler viminfo='20,"50 cscopeprg=/usr/bin/cscope fileencoding=utf-8 fileendcodings=utf-8,latin1 formatoptions=tcql -- So, do I have syntax highlighting enabled? The t_Sb and t_Sf look suspiciously like formatting commands, but I confess I'm not conversant on vim options. Thanks, Max On Tue, 22 May 2007, Gary Johnson wrote: Do you have syntax highlighting enabled? That can really slow vim down. I created and opened a file as follows: while true do echo '123456789012345678901234567890123456789012345678901234567890' done | head -200 > two_million_lines vim two_million_lines Then within vim executed: 50% :.,$d Using vim 7.1 under Cygwin and Windows XP on a 3.6 GHz Pentium with 2 GB of RAM: 9 seconds. Using vim 7.1 under Red Hat Enterprise Linux WS release 4 on a 2.8 GHz Pentium with 500 MB RAM: 16 seconds. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: A performance question
Thanks, Tim. I'll look at the options you recommended--and those you didn't, so I may not need to ask next time. :) Cheers, Max On Tue, 22 May 2007, Tim Chase wrote: The issue of editing large files comes up occasionally. A few settings can be tweaked to vastly improve performance. Notably, the 'undolevels' setting can be reduced to -1 or 0 for improved performance. If your lines are long, it can also help to disable syntax highlighting as well. You can drop in on one such thread here: http://www.nabble.com/Re%3A-editing-large-file-p3665161.html or the associated vim-tip at http://www.vim.org/tips/tip.php?tip_id=611 Another option might be to use a stream-oriented tool such as sed to edit your file: sed '10q' < infile.txt > outfile.txt Fortunately, Vim has oodles of knobs to twiddle, so you can monkey with 'undolevels', 'swapfile', and the 'bufhidden' setting, as well as turning off sytnax highlighting, all of which can improve the performance of vim under uncommon load. This struck me as so odd, I looked you up (for the first time in all my years of use) so I could ask why! Welcome aboard...the list is friendly, informative, on-topic, and an all-round example of what a mailing-list should be. :) -tim
Re: A performance question
On 2007-05-22, Robert M Robinson <[EMAIL PROTECTED]> wrote:
> That brings me to my question. I have noticed that when editing large files
> (millions of lines), deleting a large number of lines (say, hundreds of
> thousands to millions) takes an unbelieveably long time in VIM--at least on
> my systems. This struck me as so odd, I looked you up (for the first time
> in all my years of use) so I could ask why!
>
> Seriously, going to line 1 million of a 2 million line file and typing the
> command ":.,$d" takes _minutes_ on my system (Red Hat Linux on a 2GHz Athlon
> processor (i686), 512kb cache, 3 Gb memory), far longer than searching the
> entire 2 million line file for a single word (":g/MyQueryName/p"). Doing it
> this way fits way better into my usual workflow than using "head -n
> 100", because of course I'm using a regular expression search to
> determine that I
> want to truncate my file at line 100 in the first place.
>
> I looked in the archive, and couldn't see that this issue had been raised
> before. Is there any chance it can get added to the list of performance
> enhancement requests?
Do you have syntax highlighting enabled? That can really slow vim
down.
I created and opened a file as follows:
while true
do
echo '123456789012345678901234567890123456789012345678901234567890'
done | head -200 > two_million_lines
vim two_million_lines
Then within vim executed:
50%
:.,$d
Using vim 7.1 under Cygwin and Windows XP on a 3.6 GHz Pentium with
2 GB of RAM: 9 seconds.
Using vim 7.1 under Red Hat Enterprise Linux WS release 4 on a 2.8
GHz Pentium with 500 MB RAM: 16 seconds.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
Re: A performance question
That brings me to my question. I have noticed that when editing large files (millions of lines), deleting a large number of lines (say, hundreds of thousands to millions) takes an unbelieveably long time in VIM--at least on my systems. The issue of editing large files comes up occasionally. A few settings can be tweaked to vastly improve performance. Notably, the 'undolevels' setting can be reduced to -1 or 0 for improved performance. If your lines are long, it can also help to disable syntax highlighting as well. You can drop in on one such thread here: http://www.nabble.com/Re%3A-editing-large-file-p3665161.html or the associated vim-tip at http://www.vim.org/tips/tip.php?tip_id=611 Another option might be to use a stream-oriented tool such as sed to edit your file: sed '10q' < infile.txt > outfile.txt Fortunately, Vim has oodles of knobs to twiddle, so you can monkey with 'undolevels', 'swapfile', and the 'bufhidden' setting, as well as turning off sytnax highlighting, all of which can improve the performance of vim under uncommon load. This struck me as so odd, I looked you up (for the first time in all my years of use) so I could ask why! Welcome aboard...the list is friendly, informative, on-topic, and an all-round example of what a mailing-list should be. :) -tim
Re: A performance question
Robert M Robinson wrote:
First, thanks very much for creating VIM! I have been using it on Linux
systems for years, and now use it via cygwin at home as well. I vastly
prefer VIM to EMACS, especially at home. I learned vi on a VAX/VMS
system long ago (a friend of mine had ported it), when our computer
science department was loading so many people on the VAXen that EDT was
rendered unusably slow. I still like VIM largely because I can do so
much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large
files (millions of lines), deleting a large number of lines (say,
hundreds of thousands to millions) takes an unbelieveably long time in
VIM--at least on my systems. This struck me as so odd, I looked you up
(for the first time in all my years of use) so I could ask why!
Seriously, going to line 1 million of a 2 million line file and typing
the command ":.,$d" takes _minutes_ on my system (Red Hat Linux on a
2GHz Athlon processor (i686), 512kb cache, 3 Gb memory), far longer than
searching the entire 2 million line file for a single word
(":g/MyQueryName/p"). Doing it this way fits way better into my usual
workflow than using "head -n 100", because of course I'm using a
regular expression search to determine that I
want to truncate my file at line 100 in the first place.
I looked in the archive, and couldn't see that this issue had been
raised before. Is there any chance it can get added to the list of
performance enhancement requests?
Thanks,
Max Robinson, PhD
I think this is just "part of how Vim behaves".
When you edit a file, Vim holds the whole file in memory (IIUC). When you
delete a million lines, Vim frees (i.e., releases to the OS) the memory those
lines were using. That takes some time.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
250. You've given up the search for the "perfect woman" and instead,
sit in front of the PC until you're just too tired to care.
A performance question
First, thanks very much for creating VIM! I have been using it on Linux
systems for years, and now use it via cygwin at home as well. I vastly prefer
VIM to EMACS, especially at home. I learned vi on a VAX/VMS system long ago (a
friend of mine had ported it), when our computer science department was loading
so many people on the VAXen that EDT was rendered unusably slow. I still like
VIM largely because I can do so much with so little effort in so little time.
That brings me to my question. I have noticed that when editing large files
(millions of lines), deleting a large number of lines (say, hundreds of
thousands to millions) takes an unbelieveably long time in VIM--at least on my
systems. This struck me as so odd, I looked you up (for the first time in all
my years of use) so I could ask why!
Seriously, going to line 1 million of a 2 million line file and typing the command ":.,$d" takes
_minutes_ on my system (Red Hat Linux on a 2GHz Athlon processor (i686), 512kb cache, 3 Gb memory), far
longer than searching the entire 2 million line file for a single word (":g/MyQueryName/p"). Doing
it this way fits way better into my usual workflow than using "head -n 100", because of course
I'm using a regular expression search to determine that I
want to truncate my file at line 100 in the first place.
I looked in the archive, and couldn't see that this issue had been raised
before. Is there any chance it can get added to the list of performance
enhancement requests?
Thanks,
Max Robinson, PhD
Re: Getting vimscripts
Quoting Robert Hicks <[EMAIL PROTECTED]>: > Is there a way to use "wget" or "curl" to get scripts off the Vim site? Sure -- getscript.vim (:GLVS, :GetLatestVimScripts) uses wget if its available, curl otherwise. Getscript comes with vim 7.1, too. If you set up a file called GetLatestVimScripts.dat: ScriptID SourceID Filename -- 294 1 Align.vim 120 2 Decho.vim etc then :GLVS will check if the scripts have been updated and download them automically (via wget or curl) if they have been. Scripts which have lines such as: " GetLatestVimScripts: [srcid] 1 :AutoInstall: Scriptname.vim will be searched for and automatically made a part of your GetLatestVimScripts.dat file. The optional ":AutoInstall:" line means that the script author believes that its safe for getscripts.vim to go ahead and automatically install the script if an update is available. Try reading the help for this if you're interested... :help getscript Regards, Chip Campbell
Re: Vim to Vi (Was: weird defaults in Feisty)
On May 22, 2007, at 3:11 PM, Tobia wrote: The point is: I don't consider my learning path in any way peculiar, and if Vim had suddenly reverted to Vi while I was in phases 1 to 3, I would have looked at my computer with a blank, baffled expression on my face. Tobia If you find that your path is non-linear, I've actually learned vi after vim, which is even more backwards haha. Some servers I need to admin have nano and vi... I'd much rather use vi than nano, even though nano is "easier" to most people, because to me vi is "like" vim. Of course vim is the clone, not vi, but since I learned vim first that's what I've grown to expect. --Mike H
Vim to Vi (Was: weird defaults in Feisty)
David Nečas (Yeti) wrote:
> it's a bit strange when a vim user describes vi as `crazy' and `so
> weird'...
It may sound strange to us Vim veterans, but it's what I would expect.
My path to learning Vi/Vim (which took place at the same time as my
learning of GNU/Linux, by the way) was as follows:
1. Use it as a Notepad with weird save/quit commands (:w ...)
Always in insert mode, only using the arrows, Del, BS, Home, End, and
hitting Esc and 'u' like crazy whenever something weird happened.
2. Learn "copy & paste", first line-wise (dd yy p P), then selection-wise
(v V ^V y d, still only using the arrow keys.
At this point (a few months?) I was already as productive as with my
former Windows editor of choice! (something like TextEdit™ or TextPad™)
3. Learn that command mode is actually useful for moving around in the
file (gg, G, {, }) and opening two files at a time (:e, C-^)
4. Other stuff (complex movements, buffers/windows/tabs, registers,
macros, mappings, autocommands, folding, custom syntax files...)
This timeline might look non-linear, in fact I believe that learning Vim
is an exponential task to the engaged user, and that's a very good thing!
The point is: I don't consider my learning path in any way peculiar, and
if Vim had suddenly reverted to Vi while I was in phases 1 to 3, I would
have looked at my computer with a blank, baffled expression on my face.
Tobia
Re: How to alter the cscope search results in the vim so that they refer to the right files.
On 2007-05-22, Natesh Kedlaya <[EMAIL PROTECTED]> wrote:
> Hi Gary,
> I apologize for my earlier email. I should have given the full details.
> I would like to provide it now.
>
> I have tried your suggestion of setting the cscopeprg to a script that
> contained
> /usr/local/bin/cscope "$@" | sed s@/dir1/@/dir2/@
> But the cscope results still contained the directory /dir1 reference.
>
> While doing this test, I have observed a strange behavior. If the cscopeprg
> is set to anything other than /usr/bin/cscope and /usr/local/bin/cscope,
> somewhow
> the vim resets them back to /usr/bin/cscope.
> So, I tried replacing the /usr/bin/cscope itself with the script mentioned
> above and
> got the following errors while opening any source files.
>
> Error detected while processing /etc/vimrc:
> line 35:
> cs_read_prompt EOF: Interrupted system call
> Interrupted
> Error detected while processing /home/myname/.vimrc:
> line1:
> Interrupted
> Interrupt: Hit ENTER or type command to continue
That is indeed strange behavior. Let's take one behavior at a time.
If setting 'cscopeprg' to the name of your script left the /dir1
references unchanged, then either that setting is being overwritten
or the sed command is failing. You can check the former by
executing
:verbose set cscopeprg?
which will return the current value of 'cscopeprg' and where it was
set last. You can check the sed script by changing it to
cat "$@" | sed s@/dir1/@/dir2/@
and executing it from a shell prompt with the name of your cscope
database (cscope.out?) as the only argument. This will ensure that
the sed command is being executed in the same environment as when it
filters the output of cscope, helps catch quoting issues and avoids
copy-and-paste issues.
>From what you said about the errors and the renaming of 'cscopeprg',
though, it looks more like something changing 'cscopeprg' than a
problem with the sed command.
I don't have an explanation for the errors from /etc/vimrc or
/home/myname/.vimrc yet. I don't know how the contents of
/usr/bin/cscope would affect the behavior of vim so early in vim's
startup. Unless, of course, either of those files executed a
:cscope command, which would also be unusual. You might take a look
at the lines where those errors are reported for a clue to what's
happening.
> Out of the three solutions that you have suggested, would you please
> elaborate on the third one, ie. "execute cscope as a quickfix command
> (instead of using the :cs
> commands) and filter its output before being read by vim." This looks
> very promising to me.
When the cscope feature was first added to vim, its results could
not be sent to the quickfix error list as they can now. I really
wanted to use the quickfix interface with cscope, so I wrote a
function to behave just like ":cs find" but to send the cscope
output to the quickfix list by setting 'grepprg' to "cscope" plus
some arguments. I've attached the function (actually a pair of
functions) to this message. You can invoke it from the command line
as, e.g.,
:Csfind g somevar
or bind it to a mapping, e.g.,
map ,g :Csfind g zv
to search for the definition of the symbol under the cursor.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
| Spokane, Washington, USA
if v:version < 602
" Csfind
"
" Usage:
"
" :Csfind {querytype} {name}
"
" Example:
"
" :Csfind s myvar
"
" finds all occurrences of the C symbol "myvar".
command! -nargs=+ Csfind call Csfind()
function! Csfind(querytype, name)
" Check the validity of the querytype argument.
"
if strlen(a:querytype) != 1 || stridx("01234678sgdctefi", a:querytype)
== -1
echohl ErrorMsg
echo "Usage: :Csfind {querytype} {name}"
echo "See \":help cs\""
echohl None
return
endif
" Save previous 'grep' options.
"
let gf = &grepformat
let gp = &grepprg
" Set new 'grep' options for running cscope.
"
set grepformat=%f\ %[%^\ ]%#\ %l\ %m
let &grepprg = &csprg . " -L -f " . s:cscope_database
" Find the numerical form of the querytype.
"
if a:querytype =~ '\d'
let num = a:querytype
else
let num = stridx("sgdct?efi", a:querytype)
endif
" Do it.
"
execute "grep -" . num . a:name
" Restore previous 'grep' options.
"
let &grepprg = gp
let &grepformat = gf
endfunction
else
" Csfind()
"
" This function uses :try and related commands which were first introduced
" at vim-6.2, so any application should check for v:version >= 602 before
" calling it.
"
" When errors occur within a function, vim p
Re: How to alter the cscope search results in the vim so that they refer to the right files.
--- Natesh Kedlaya <[EMAIL PROTECTED]> wrote: > Hi, > I am using Vim6.3 > My cscope db was built on a source directory structure 'src1' which was > mounted on /dir1. If I use this cscope db in my vim, my cscope query would > yeild following results. > > > Cscope tag: myFunc ># line filename / context / line >1342 /dir1/src1/util/myprog.h > <> > void myFunc(); >2 1563 /dir1/src1/util/mycallprog.c > <> > op_status = myFunc(); >3 1584 /dir1/src1/util/myprog.c > <> > void myFunc() > Enter nr of choice ( to abort): > -- > > Everything works good till I mount the source directory structure > on /dir2 instead of /dir1. The cscope db still has referrers to the /dir1 > based on which > it was built. > > I don't want to rebuild the cscope db with the new mount point. > How do I make use of the existing cscope db by somehow modifying the > cscope search results to point to /dir2 instead of /dir1? I would like to > see > the following output when I do cscope search. > > > > Cscope tag: myFunc > ># line filename / context / line > >1342 /dir2/src1/util/myprog.h > > <> > > void myFunc(); > >2 1563 /dir2/src1/util/mycallprog.c > > <> > > op_status = myFunc(); > >3 1584 /dir2/src1/util/myprog.c > > <> > > void myFunc() > > Enter nr of choice ( to abort): > > -- > > > Any pointers appreciated. Hello Natesh, I have a similar setup. There's a "work" directory that shows up as /mnt1/work or /mnt2/work etc. on different hosts. I built the cscope db once, in work directory with $ cd /mnt1/work $ cscope -bRq Then from the other machine: $ cd /mnt2/work $ gvim ":cs add cscope.out" (Note that I did not specify full path) ":cs show" shows "cscope.out" (not full path) as the database name. Whenever I do a cscope search I see relative pathnames, never the full path. Can you try this and see if it works? Regards, Navdeep > > Thanks, > Natesh > > > > > > > > Never miss an email again! > Yahoo! Toolbar alerts you the instant new Mail arrives. > http://tools.search.yahoo.com/toolbar/features/mail/ > Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/
Re: How to alter the cscope search results in the vim so that they refer to the right files.
Hi Gary, I apologize for my earlier email. I should have given the full details. I would like to provide it now. I have tried your suggestion of setting the cscopeprg to a script that contained /usr/local/bin/cscope "$@" | sed s@/dir1/@/dir2/@ But the cscope results still contained the directory /dir1 reference. While doing this test, I have observed a strange behavior. If the cscopeprg is set to anything other than /usr/bin/cscope and /usr/local/bin/cscope, somewhow the vim resets them back to /usr/bin/cscope. So, I tried replacing the /usr/bin/cscope itself with the script mentioned above and got the following errors while opening any source files. Error detected while processing /etc/vimrc: line 35: cs_read_prompt EOF: Interrupted system call Interrupted Error detected while processing /home/myname/.vimrc: line1: Interrupted Interrupt: Hit ENTER or type command to continue Out of the three solutions that you have suggested, would you please elaborate on the third one, ie. "execute cscope as a quickfix command (instead of using the :cs commands) and filter its output before being read by vim." This looks very promising to me. Thanks, Natesh - Original Message From: Gary Johnson <[EMAIL PROTECTED]> To: Natesh Kedlaya <[EMAIL PROTECTED]> Cc: vim@vim.org Sent: Tuesday, May 22, 2007 9:05:30 AM Subject: Re: How to alter the cscope search results in the vim so that they refer to the right files. On 2007-05-22, Natesh Kedlaya <[EMAIL PROTECTED]> wrote: > From: Gary Johnson <[EMAIL PROTECTED]> > Sent: Monday, May 21, 2007 5:30:52 PM > > On 2007-05-21, Natesh Kedlaya <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I am using Vim6.3 > > > My cscope db was built on a source directory structure 'src1' which was > > > mounted on /dir1. If I use this cscope db in my vim, my cscope query > > > would > > > yeild following results. > > [...] > > > Any pointers appreciated. > > > > You asked this question before on May 3 and May 7 and I replied with > > a suggestion. Did you try that? > Hi Gray, >Yes, I have tried it. But, no luck. No luck in that cscope commands still tried opening the /dir1 files? No luck in that cscope commands didn't work at all? Vim has no way that I know of of altering the names it gets from cscope, so I think the only alternatives are: 1. correct the cscope database (e.g., apply a sed command to change /dir1 to /dir2 when copying the database), 2. insert a filter between cscope and vim (e.g., with a wrapper script around cscope), 3. execute cscope as a quickfix command (instead of using the :cs commands) and filter its output before being read by vim. If you would like help in getting any of those to work, we're going to have to know exactly what you tried and exactly what happened when it didn't work. It will also help to keep the conversation on the list (I cc'd vim@vim.org) so that others can follow the discussion and contribute. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/
Re: weird defaults in Feisty
On Tue, May 22, 2007 at 10:41:18AM -0600, fREW wrote: > > Well, nocompatible is recommended, and since this is a vim list, not > just a vi list, I wouldn't think that it would be strange at all for > people to expect vim (not vi) when they want vim. That's why you have two commands: vi and vim. Vim automatically switches to nocompatible if you have ~/.vimrc. Vi does not even have to know what vimrc is. Particularly, vi can be aliased to some other vi clone, for example elvis. If you run vi, you get something that can be used as vi. If you run vim, you get vim. Yeti -- http://gwyddion.net/
Re: weird defaults in Feisty
On 5/22/07, David Nečas (Yeti) <[EMAIL PROTECTED]> wrote: On Tue, May 22, 2007 at 09:39:29AM -0600, fREW wrote: > I just updated to feisty on a samba server machine and a lot of the > vim defaults went crazy. For example: Pressing the Up or Down keys > in insert mode add new lines with just A or B on them, respectively. This is what vi does. Movement is performed by hjkl, remember? > That I can live with, but check this out, if I have the following > sentence: > > fREW is a silly guy > > and my cursor is on the s, and I press cw, it changes to > > fREW is a sill$ guy > > and it works just like I had pressed cw and it replaces up the the $ > or if I press escape it only has the new text I put in, but it's just > so weird! This is exactly what vi does. Command cw changes the word (and does only that), $ marks where it ends. > Does anyone know where these new changes in Feisty come > from? This has been hopefully explained already (vi runs a binary that really behaves like vi, whereas vim runs something more featureful -- this common in Linux distros). Anyway, it's a bit strange when a vim user describes vi as `crazy' and `so weird'... Yeti -- http://gwyddion.net/ Well, nocompatible is recommended, and since this is a vim list, not just a vi list, I wouldn't think that it would be strange at all for people to expect vim (not vi) when they want vim. Just my two-cents. -fREW
Re: weird defaults in Feisty
On May 22, 2007, at 12:34 PM, David Nečas (Yeti) wrote: This has been hopefully explained already (vi runs a binary that really behaves like vi, whereas vim runs something more featureful -- this common in Linux distros). Anyway, it's a bit strange when a vim user describes vi as `crazy' and `so weird'... Yeti -- http://gwyddion.net/ I think it just goes to show us that in 2007 there are people who have been raised on vim, i.e. they didn't convert from vi... vim is all some people are used to. I don't think there's anything wrong with that really. A bit strange... yes I agree there, but I imagine it's only going to be more common as time passes and vi becomes more and more a "vintage" program :) --Mike H
Re: weird defaults in Feisty
On 5/22/07, Peter Palm <[EMAIL PROTECTED]> wrote: Op dinsdag 22 mei 2007, schreef fREW: > I figured it out and if anyone else has this problem I am sending out > the solution. Basically when I run vi it is running vim.tiny. > vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, > vim.tiny is pretty crippled, in that it doesn't even have syntax > highlighting, so consider whether that's even what you want. Actually, if I run vi (not vim), I definitely don't want a 'full-featured' vim (modeline exploits etc), and expect vim to run in 'compatible mode' (or whatever vi implementation is the default on my system). (my shell config aliases vi to vim, if it's available, but only as a normal user) Setting the defaults in /etc/vim/vimrc is, in my opinion, not 'the right way', it's what ~/.vimrc is for. And, just out of curiosity, does vim.tiny parse ~/.vimrc, or does it (only?) look at ~/.vimrc.tiny as well? Regards, Peter Palm No, as far as I know it still reads the regular .vimrc. I changed the system wide defaults because it wasn't just me who was surprised by the changes. Otherwise I would directly copy over my personal .vimrc. -fREW
Re: weird defaults in Feisty
On Tue, May 22, 2007 at 09:39:29AM -0600, fREW wrote: > I just updated to feisty on a samba server machine and a lot of the > vim defaults went crazy. For example: Pressing the Up or Down keys > in insert mode add new lines with just A or B on them, respectively. This is what vi does. Movement is performed by hjkl, remember? > That I can live with, but check this out, if I have the following > sentence: > > fREW is a silly guy > > and my cursor is on the s, and I press cw, it changes to > > fREW is a sill$ guy > > and it works just like I had pressed cw and it replaces up the the $ > or if I press escape it only has the new text I put in, but it's just > so weird! This is exactly what vi does. Command cw changes the word (and does only that), $ marks where it ends. > Does anyone know where these new changes in Feisty come > from? This has been hopefully explained already (vi runs a binary that really behaves like vi, whereas vim runs something more featureful -- this common in Linux distros). Anyway, it's a bit strange when a vim user describes vi as `crazy' and `so weird'... Yeti -- http://gwyddion.net/
Re: weird defaults in Feisty
On May 22, 2007, at 11:59 AM, fREW wrote: I figured it out and if anyone else has this problem I am sending out the solution. Basically when I run vi it is running vim.tiny. vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, vim.tiny is pretty crippled, in that it doesn't even have syntax highlighting, so consider whether that's even what you want. -fREW Yes the "tiny bugs", as I call them, have hit me in another way - I tried using syntax highlighting and got a "sorry this command is not implemented" error. That's what lead me to install a more complete version (namely vim-ruby, which has some minor annoyances of it's own btw). I attribute these default annoyances to the fact that ubuntu is a desktop distro, not really intended for development "out-of-the- box". Luckily installing and configuring the vim that you want is a trivial matter so you can go about vimming proper in no time :) --Mike H
Re: weird defaults in Feisty
Op dinsdag 22 mei 2007, schreef fREW: > I figured it out and if anyone else has this problem I am sending out > the solution. Basically when I run vi it is running vim.tiny. > vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also, > vim.tiny is pretty crippled, in that it doesn't even have syntax > highlighting, so consider whether that's even what you want. Actually, if I run vi (not vim), I definitely don't want a 'full-featured' vim (modeline exploits etc), and expect vim to run in 'compatible mode' (or whatever vi implementation is the default on my system). (my shell config aliases vi to vim, if it's available, but only as a normal user) Setting the defaults in /etc/vim/vimrc is, in my opinion, not 'the right way', it's what ~/.vimrc is for. And, just out of curiosity, does vim.tiny parse ~/.vimrc, or does it (only?) look at ~/.vimrc.tiny as well? Regards, Peter Palm
Re: How to alter the cscope search results in the vim so that they refer to the right files.
On 2007-05-22, Natesh Kedlaya <[EMAIL PROTECTED]> wrote: > From: Gary Johnson <[EMAIL PROTECTED]> > Sent: Monday, May 21, 2007 5:30:52 PM > > On 2007-05-21, Natesh Kedlaya <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I am using Vim6.3 > > > My cscope db was built on a source directory structure 'src1' which was > > > mounted on /dir1. If I use this cscope db in my vim, my cscope query > > > would > > > yeild following results. > > [...] > > > Any pointers appreciated. > > > > You asked this question before on May 3 and May 7 and I replied with > > a suggestion. Did you try that? > Hi Gray, >Yes, I have tried it. But, no luck. No luck in that cscope commands still tried opening the /dir1 files? No luck in that cscope commands didn't work at all? Vim has no way that I know of of altering the names it gets from cscope, so I think the only alternatives are: 1. correct the cscope database (e.g., apply a sed command to change /dir1 to /dir2 when copying the database), 2. insert a filter between cscope and vim (e.g., with a wrapper script around cscope), 3. execute cscope as a quickfix command (instead of using the :cs commands) and filter its output before being read by vim. If you would like help in getting any of those to work, we're going to have to know exactly what you tried and exactly what happened when it didn't work. It will also help to keep the conversation on the list (I cc'd vim@vim.org) so that others can follow the discussion and contribute. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division | Spokane, Washington, USA
Re: weird defaults in Feisty
On 5/22/07, fREW <[EMAIL PROTECTED]> wrote:
On 5/22/07, Gene Kwiecinski <[EMAIL PROTECTED]> wrote:
> >I just updated to feisty on a samba server machine and a lot of the
> >vim defaults went crazy. For example: Pressing the Up or Down keys
> >in insert mode add new lines with just A or B on them, respectively.
>
> Sounds like it stopped recognising arrow keys' ANSI sequences ("[A"
> and "[B"). Wouldda thought the would break out of insert
> mode, but...
>
>
> >That I can live with, but check this out, if I have the following
> >sentence:
> >fREW is a silly guy
> >and my cursor is on the s, and I press cw, it changes to
> >fREW is a sill$ guy
> >and it works just like I had pressed cw and it replaces up the the $
> >or if I press escape it only has the new text I put in, but it's just
> >so weird! Does anyone know where these new changes in Feisty come
>
> Uhh, sounds like what it's supposta do, no? ??
>
> Is there a problem with actually changing the text, or just what's
> displayed? Dunno the setting offhand, but a slow-redraw will mark to
> the end of the text to be replaced, eg, if you were to change to the end
> of the line, you'd still see the whole line, but with a '$' where the
> last character would be, vs erasing all the text and just leaving the
> insert-cursor in its place. I find the latter disquieting, and would
> rather *see* what I'm replacing, but never really paid too much
> attention to which settings do what. I'm complacent that way... :D
>
I prefer that cw doesn't do this weird $ thing. It bothers me. I
might be ok with it if the word I was typing over were a different
color, but that is not the case.
Also: set nocompatible worked just fine, but I wanted to make this a
system wide setting. I think that the problem has to do with vim not
sourcing the /etc/vim/vimrc. It appears that that is why things
aren't working correctly. Anyone know why it wouldn't source that
file?
-fREW
I figured it out and if anyone else has this problem I am sending out
the solution. Basically when I run vi it is running vim.tiny.
vim.tiny sources /etc/vim/vimrc.tiny, not /etc/vim/vimrc, also,
vim.tiny is pretty crippled, in that it doesn't even have syntax
highlighting, so consider whether that's even what you want.
-fREW
Re: weird defaults in Feisty
On 5/22/07, Gene Kwiecinski <[EMAIL PROTECTED]> wrote:
>I just updated to feisty on a samba server machine and a lot of the
>vim defaults went crazy. For example: Pressing the Up or Down keys
>in insert mode add new lines with just A or B on them, respectively.
Sounds like it stopped recognising arrow keys' ANSI sequences ("[A"
and "[B"). Wouldda thought the would break out of insert
mode, but...
>That I can live with, but check this out, if I have the following
>sentence:
>fREW is a silly guy
>and my cursor is on the s, and I press cw, it changes to
>fREW is a sill$ guy
>and it works just like I had pressed cw and it replaces up the the $
>or if I press escape it only has the new text I put in, but it's just
>so weird! Does anyone know where these new changes in Feisty come
Uhh, sounds like what it's supposta do, no? ??
Is there a problem with actually changing the text, or just what's
displayed? Dunno the setting offhand, but a slow-redraw will mark to
the end of the text to be replaced, eg, if you were to change to the end
of the line, you'd still see the whole line, but with a '$' where the
last character would be, vs erasing all the text and just leaving the
insert-cursor in its place. I find the latter disquieting, and would
rather *see* what I'm replacing, but never really paid too much
attention to which settings do what. I'm complacent that way... :D
I prefer that cw doesn't do this weird $ thing. It bothers me. I
might be ok with it if the word I was typing over were a different
color, but that is not the case.
Also: set nocompatible worked just fine, but I wanted to make this a
system wide setting. I think that the problem has to do with vim not
sourcing the /etc/vim/vimrc. It appears that that is why things
aren't working correctly. Anyone know why it wouldn't source that
file?
-fREW
RE: weird defaults in Feisty
>I just updated to feisty on a samba server machine and a lot of the
>vim defaults went crazy. For example: Pressing the Up or Down keys
>in insert mode add new lines with just A or B on them, respectively.
Sounds like it stopped recognising arrow keys' ANSI sequences ("[A"
and "[B"). Wouldda thought the would break out of insert
mode, but...
>That I can live with, but check this out, if I have the following
>sentence:
>fREW is a silly guy
>and my cursor is on the s, and I press cw, it changes to
>fREW is a sill$ guy
>and it works just like I had pressed cw and it replaces up the the $
>or if I press escape it only has the new text I put in, but it's just
>so weird! Does anyone know where these new changes in Feisty come
Uhh, sounds like what it's supposta do, no? ??
Is there a problem with actually changing the text, or just what's
displayed? Dunno the setting offhand, but a slow-redraw will mark to
the end of the text to be replaced, eg, if you were to change to the end
of the line, you'd still see the whole line, but with a '$' where the
last character would be, vs erasing all the text and just leaving the
insert-cursor in its place. I find the latter disquieting, and would
rather *see* what I'm replacing, but never really paid too much
attention to which settings do what. I'm complacent that way... :D
Re: weird defaults in Feisty
On 5/22/07, Michael Hernandez <[EMAIL PROTECTED]> wrote: On May 22, 2007, at 11:39 AM, fREW wrote: > Hey all, > I just updated to feisty on a samba server machine and a lot of the > vim defaults went crazy. For example: Pressing the Up or Down keys > in insert mode add new lines with just A or B on them, respectively. > That I can live with, but check this out, if I have the following > sentence: > > fREW is a silly guy > > and my cursor is on the s, and I press cw, it changes to > > fREW is a sill$ guy > > and it works just like I had pressed cw and it replaces up the the $ > or if I press escape it only has the new text I put in, but it's just > so weird! Does anyone know where these new changes in Feisty come > from? I wanted to just replace /etc/vim/vimrc, but it was exactly the > same. > > Ideas? > > Thanks, > -fREW The letters coming from the arrow keys is probably because you don't have set nocompatible in your rc file. Not sure what the other stuff is... I am using vim on feisty right now and have never seen that stuff before :) --Mike H That's the bizarre thing. The computer I am using right now has feisty with no issue, but I also have a heavily customized .vimrc, so that could change that. Anyway, I opened /etc/vim/vimrc and changed a lot of stuff in there to make it more nice to use (incsearch and the like) and for some reason vim appears to be not sourcing the file. Does anyone know why that would be the case? -fREW
Re: weird defaults in Feisty
On May 22, 2007, at 11:39 AM, fREW wrote: Hey all, I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come from? I wanted to just replace /etc/vim/vimrc, but it was exactly the same. Ideas? Thanks, -fREW Sorry to reply twice but I think the $ showing up at the end of the word you are changing is also part of the vi compatible mode. I hadn't read your example well enough - I thought it was printing fREW is when you entered the cw command ;) Just add set nocompatible in your .vimrc and you should be fine? --Mike H
Re: weird defaults in Feisty
On May 22, 2007, at 11:39 AM, fREW wrote: Hey all, I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come from? I wanted to just replace /etc/vim/vimrc, but it was exactly the same. Ideas? Thanks, -fREW The letters coming from the arrow keys is probably because you don't have set nocompatible in your rc file. Not sure what the other stuff is... I am using vim on feisty right now and have never seen that stuff before :) --Mike H
weird defaults in Feisty
Hey all, I just updated to feisty on a samba server machine and a lot of the vim defaults went crazy. For example: Pressing the Up or Down keys in insert mode add new lines with just A or B on them, respectively. That I can live with, but check this out, if I have the following sentence: fREW is a silly guy and my cursor is on the s, and I press cw, it changes to fREW is a sill$ guy and it works just like I had pressed cw and it replaces up the the $ or if I press escape it only has the new text I put in, but it's just so weird! Does anyone know where these new changes in Feisty come from? I wanted to just replace /etc/vim/vimrc, but it was exactly the same. Ideas? Thanks, -fREW
Re: Vim Wiki - Tip Page Formatting Deadline
On Mon, May 21, 2007 10:16 am, Sebastian Menge wrote: > A problem are tips that contain URLs to external sites (e.g. other tips) > This is regarded as spam by mediawiki (captcha). Though the URLs are > clean (since someone edited them before) we have to either import these > tips by hand or convert all in the script. I am able to add links to external web sites to a page without going through a captcha on the wikia site. If we do end up using the wikia site, I can run the conversion script and avoid a lot of the obstacles that are affecting the rest of you. Thanks, Tom Purl
can i map the number pad enter or somesuch?
hello all, Is the enter key on the numeric keypad different than the enter key of the keyboard? i was thinking that it would be super handy to map it to gg. I have a lot of long files to mess around with. thanks for any tips. shawn
Re: Getting vimscripts
Swaroop C H wrote: Is there a way to use "wget" or "curl" to get scripts off the Vim site? Use `wget http://www.vim.org/scripts/download_script.php?src_id=$id -O foo` ? Best, Swaroop Must have been a corrupt file. I removed everything and reinstalled the scripts and all is well. Robert
Re: Is it possible to do spelling check for comments only?
On 5/22/07, Edward L. Fox <[EMAIL PROTECTED]> wrote: On 5/21/07, Swaroop C H <[EMAIL PROTECTED]> wrote: > > When programming, I have to turn the spelling check off. Or it will > > show a lot of spelling "mistakes" in the code. I'd like to apply > > spelling check for sentences within the comment blocks only. Is it > > possible to configure VIM to do this? > > > See :help spell-syntax Hmmm, so that means that I could only define which regions to be spelling checked in the syntax highlight plugins. It's expected that syntax file would enable/allow spelling in comments. But it's added by synatx file maintainers, no ? Is it a problem of a specific language you are using ? Which language specifically are you talking about ? I think most-used languages do have spelling enabled in the comments. The less used languages might not yet have this added by their respective maintainer. not all, because this is relatively new feature and I do not think all syntax maintainers added this. But maybe I am wrong and I'm missing something. Which language are you talking about ? Yakov
Re: Vim Wiki - Tip Page Formatting Deadline
Sebastian Menge wrote: [...very helpful summary for Vim Wiki...] Thanks for keeping this moving. I'm happy with what you said, but here are some comments. Please disregard all this and just do it, if you can't stand my detail at the moment! everything should fit on one page, no scrolling That would be an aim, but clearly it can't be enforced by the initial import (although it does mean that any information box should be at the end of the tip). 2.) Drop the id for new tips, use old ids just to redirect. Good, but let's have a specific example. How about: ---Current example--- URL:http://scratchpad.wikia.com/wiki/VimTip1_v2 Title: Tip: #1 - the super star ---What we want--- URL:http://vim.wikia.com/wiki/the_super_star Title: The super star The import script should change the tip title as above. -Or- Do we want to keep the (obsolete!) tip number? ---Also have a redirect page--- URL:http://scratchpad.wikia.com/wiki/vimtip1 Page content (I'm not sure if syntax is correct): #REDIRECT [[the_super_star]] ---Example of new tip--- URL:http://vim.wikia.com/wiki/my_great_new_tip Title: My great new tip (there would be no tip number and no redirect page) 3.) Use some scripting to keep ids, e.g. via a cron job that tidies up each night or a javascript that uses a timestamp. I think you are saying that this is not a good plan. I agree that we cannot realistically have an automated process run on someone's computer to edit wiki pages. We'll have to plan so there is no need to automate adjustments. Tony mentioned the possibility of a wiki robot, but I guess that we would not be able to use such a feature, unless we knew a friendly administrator (hi Martin!). Layout issues of the template can be discussed in the respective discussion page. Let's not do that yet. I suggest we keep all discussion here until the wiki is imported. After the first import, let's discuss it here and agree "yes". Once that is done, those who are willing can discuss details on the wiki discussion pages. Conversion of HTML in Tip-Text. This should be converted to wiki markup in the long run. Please - let's do it in the import script! Anything else would be a heap of unrewarding and unending work. The script could convert simple cases, and maybe flag awkward cases for manual attention. We have had three fantastic scripts (I think it's three) that were produced very quickly. Someone needs to pick one and ask the author if they are willing to make adjustments. A problem are tips that contain URLs to external sites (e.g. other tips) Fix this in the import script as well: - Links to tips should be adjusted to wiki format. - Links to external sites should be converted to plain text for later review. I like Martin Krischik's suggestion that we use the vi wikibooks where he is an administrator. However, we would get really ugly URLs - I think something like (one line!): http://en.wikibooks.org/wiki/Learning_the_vi_editor/Vim/Tips_and_Tricks/the_super_star Maybe Martin has a suggestion to improve that. I also saw a comment that wikia would provide additional benefits over wikibooks (I don't quite understand this): a complete wiki, not just a bunch of pages To do: - Discuss here for, say, three more days. - Import ten tips. - Discuss for another three days. - Import all tips. John
