Re: Vim 7 performance notes
Hi Bram Moolenaar, you wrote: Speed should be OK this way, but it does keep up to 32 Kbyte allocated. That may not seem much, but if we do this in many places it quickly adds up. Any keep limit greater than initial size (e.g. 16384 bytes) will give the same effect in many cases. By many cases here I mean cases when the stack just doesn't grow more than 512 bytes (very usual for syntax highlighting). Is 16384 still too big? Regexp matching and syntax highlighting is one of the most important things in VIM so maybe it's tolerable? Also, as far as I understand, previosly (version 6) VIM used program stack as regstack, right? Compared with program stack solution current solution with the change proposed is much better because program stack never shrinks - once it grows to 1M, for example, the memory won't be ever given back. At least, this is so on Windows, Linux and I guess most Unixes. Can you show the benchmarks you used to see the performance and the stack space that is being used? Otherwise we keep guessing the best numbers. OK. Platform used for investigations: x86, Windows XP SP 2. Pentium 4 Northwood, 2.4 GHz, 512M RAM. I did 2 things: understanding stack usage and performance measurement. To understand the stack usage I added some simple logging to regexp.c: printing ga_maxlen before regstack and backpos clearing and forced the arrays to have the grow size 1 (so that ga_maxlen will be high watermark in bytes). Of course, for performance investigations I used version with normal grow size and without logging. The version with logging was used to perform the following: 1. With syntax highlighting on, the following files were viewed from gg to G (with PgDn) and the following high watermark of stack size was observed: spell.c (444 bytes), $VIMRUNTIME/filetype.vim (820 bytes), big text file with a lot of syntax errors (252 bytes) 2. Command gvim -c vimgrep /a\(.\)*z/ *.c | q was executed in VIM 7 source directory. Stack watermark - 31008 bytes. This is example of non-optimal regexp which tends to take a lot of stack space. Similar other test cases were tried leading to the following conclusions: 1) there is a lot of vim_regexec_both calls during syntax highlighting which work in very shallow stacks (1K); 2) when user searches for something with regexp there are cases when regular expression can require big amount of memory (10K). The performance measurements were done against original version (7.0.188) and modified regexp.c (initial: 8192, keep limit: 16384). Each measurement was performed 3 times, minimal time was picked up. First, I test the syntax highlighting speed: Command: gvim.exe -f $VIMRUNTIME/filetype.vim -c for i in range(199) | redraw! | endfor | q Original version: 10.6 seconds Modified version: 8.5 seconds The difference is about 25%. Second, I did some grepping through Vim sources again: Command: gvim.exe -c vimgrep /a.*z/ *.c | q Original version: 6.6 seconds Modified version: 5.6 seconds The difference is about 15%. Coding detail: please don't use if (!number), use if (number == 0), that is so much easier to read. Checking if ga_data is NULL would be simpler. Got it - no problem. -- Alexei Alexandrov
Re: Vim 7 performance notes
Alexei Alexandrov wrote: OK. Platform used for investigations: x86, Windows XP SP 2. Pentium 4 Northwood, 2.4 GHz, 512M RAM. I did 2 things: understanding stack usage and performance measurement. To understand the stack usage I added some simple logging to regexp.c: printing ga_maxlen before regstack and backpos clearing and forced the arrays to have the grow size 1 (so that ga_maxlen will be high watermark in bytes). Of course, for performance investigations I used version with normal grow size and without logging. The version with logging was used to perform the following: 1. With syntax highlighting on, the following files were viewed from gg to G (with PgDn) and the following high watermark of stack size was observed: spell.c (444 bytes), $VIMRUNTIME/filetype.vim (820 bytes), big text file with a lot of syntax errors (252 bytes) It sounds like keeping only 1024 bytes would already work for most situations. That would be an acceptable amount to keep allocated at all times. So why don't we use this as the initial size, and when it grows larger we free it when finished. The growth size can be doubled each time perhaps. 2. Command gvim -c vimgrep /a\(.\)*z/ *.c | q was executed in VIM 7 source directory. Stack watermark - 31008 bytes. This is example of non-optimal regexp which tends to take a lot of stack space. Right, this may happen and stack size wil greatly depend on the line length. Similar other test cases were tried leading to the following conclusions: 1) there is a lot of vim_regexec_both calls during syntax highlighting which work in very shallow stacks (1K); 2) when user searches for something with regexp there are cases when regular expression can require big amount of memory (10K). The performance measurements were done against original version (7.0.188) and modified regexp.c (initial: 8192, keep limit: 16384). Each measurement was performed 3 times, minimal time was picked up. First, I test the syntax highlighting speed: Command: gvim.exe -f $VIMRUNTIME/filetype.vim -c for i in range(199) | redraw! | endfor | q Original version: 10.6 seconds Modified version: 8.5 seconds The difference is about 25%. Second, I did some grepping through Vim sources again: Command: gvim.exe -c vimgrep /a.*z/ *.c | q Original version: 6.6 seconds Modified version: 5.6 seconds The difference is about 15%. That's very useful, thanks for diving into this. -- From know your smileys: 8}} Glasses, big nose, beard /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: color loading sequence in GVIM
Eric Leenman wrote: Hi, I'm doing a reinstall of gvim and placing my color and font setting in a seperate file in the plugin. This file is located in: C:\Program Files\Vim\vimfiles\plugin And it contains the following: [START OF FILE] :hi Commentctermfg=darkgreen gui=None guifg=darkgreen :hi Statement ctermfg=blue gui=None guifg=blue :hi Identifier ctermfg=darkredgui=None guifg=darkred :hi PreProcctermfg=blue gui=None guifg=darkblue :hi Type ctermfg=darkgray gui=None guifg=darkgray :hi Constant ctermfg=redgui=None guifg=red GUI font instellingen set guifont=courier:h7:w7 [END OF FILE] What now happens is that the font is taken over but the colors aren't For example: When I type :hi Comment vim returns: Comment xxx term=bold ctermfg=1 guifg=Blue What do I do wrong? Regards, Eric _ Check out all that glitters with the MSN Entertainment Guide to the Academy Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2 Colour files should go into the vimfiles/colors directory, and needs to be named according to the filetype you want it to be used for. For instance, sql.vim will be loaded for .sql files. You can further specify what filetype to use for a file by creating a filetypes.vim file in the vimfiles/ftdetect directory. For more info about this, see :help ftdetect Also, :help syntax Hope that helps -- Albie Janse van Rensburg (neonpill) Registered Linux User 438873 | http://counter.li.org
Re: [SPAM?]Re: Vim 7 performance notes
George V. Reilly wrote: Yakov Lerner wrote: On 2/4/07, Yakov Lerner [EMAIL PROTECTED] wrote: On 2/4/07, Alexei Alexandrov [EMAIL PROTECTED] wrote: Gnu malloc (glibc) is exceptionally fast, iirc. It is possible to benchmark the malloc speed during the ./configure time. And auto-select the initital size depending on the results. The procmail this similar technique in configure: It automatically benchmarks it's own builtin strstr() vs system's strstr() and selects the one which is faster. In this particular case the speed of malloc is not the only factor. Big fraction of time is spent in memset() while initializing the array with zeros. That's why I thought that it's reasonable to benchmark malloc() relative to the time it takes to memset() that same area. (When benchmarking, you need to know what to compare it to). If you compare time it takes to malloc N bytes to the time it takes to memset() same N bytes, you can tell the speed of malloc *relative* to the time of memset()ting same size. So you will automatically know which one is realtively more expensive, the memset() or the malloc(). And then maybe the optimal initial size will be size where memset() time is equal to the malloc() time ? The break-even, so to say, in which neither of two time dominates the other ? memset() is an O(N) operation. Its running time has to be proportional to N because it has to touch every single byte. If the pagefile gets involved, it's still O(N), but with a much larger constant. malloc()'s running time is much harder to say anything about. Not only can it vary widely between different implementations, it also depends upon the state of the system. Is the heap fragmented? Is it suffering from lock contention? (Not a problem with single-threaded apps like Vim.) Is the memory already in the process's working set, or does malloc have to ask the OS for more pages? Is the system under intense memory pressure and will the malloc() operation cause paging to disk? Finally, malloc(N) is probably independent of N. It has to find a free entry of size N in its data structures, which is very dependent on both the implementation and the preceding factors. Benchmarking malloc() in ./configure is not likely to tell you very much about its performance in a workload you care about. Sorry to butt in here, but I had a question about all this discussion on malloc. If you are talking about the C function malloc which I think you are as you referred to glibc, then as far as I am aware, malloc does not zero the memory that is allocated, it merely allocates it, so I do not see where memset would be used. calloc on the other hand, also zeros the memory that it allocates. Sorry if I am completely misguided but just interested to know other people's thoughts on it. Cheers, Rob.
A question about syntax file and vim regexps
Hi Vimers, I wonder if I can highlight more things in Python, I would like to highlight functions call , i.e in a Python source, in the following line: os.popen(...) be able to highlight the word popen. is it possible ? Thanks for your advices Kib.
Re: [OT]Bram fortune file. Know your smileys.
Kazuo Teramoto wrote: Hi, I love the Bram fortune file (I read it all, is fun) but now looks it be updated (with From know your smileys and jokes about proofs...) but it is not updated in Bram site, anyone know from are Bram take the 'know your smileys'? Bye. PS. I love the vim list, really, I read it for fun, I don't post so much but I think we have one of the best ml or better one of the best user community. Here's a variation on Bram's fortunes.vim script for use when not using Vim to write mail: I wrote this into my vimrc and checked that it works: if has(autocmd) augroup vimrclocal move first fortune (with initial sig delimiter) to the bottom and the clipboard au BufRead fortunes.txt \ map buffer F5 \ :1;/^-- $/-1d + \ Bar$put + \ Barw \ CR augroup END endif This is not perfect: you may want to create a more complex mapping to insert your fixed sig after the -- line after moving the fortune. The above requires: 1. modification of the fortunes.txt file (as follows) to use proper sig delimiters as separators: :1,$s/^--$/-- / This adds 529 (decimal) bytes to the file, which I think is acceptable. 2. a Vim version with access to the clipboard (i.e., any version of gvim, or a console Vim compiled with clipboard support and running in a terminal with access to the clipboard). This should also be a Vim version 6.1 or later, and preferably 6.1.092 or later, because of the :map buffer command. ;-) To use it, open fortunes.txt in Vim, hit F5, then go to your mailer, place the cursor on an empty line after last line, and paste. You may then add the fixed part of your sig below the delimiter. (Of course, replace F5 by another key to map it to something else.) Note: I just found that on Linux systems such as mine, the fortune shell command will deliver random aphorisms. Use fortune -f to list fortune files, fortune for a random non-offensive fortune, man fortune for details. However I don't know how to add a database (a pair of files, something in text format and something.dat in binary format) to the list. I think I'll write a function to get fortunes from both Bram's and the Linux lists. ... Done (I think I put the necessary safeguards into it to make it portable). Two status variables are remembered across Vim runs if the viminfo is enabled. Two more varaiables are initialized at first call. With the settings below, Bram's fortunes will happen 20% of the time (on Unix when both ~/fortunes.txt and the fortune program are present). Change g:FortuneCycle to alter that. Each call to the function Fortune() returns a new fortune both as the return value and in the clipboard, except when neither source of aphorisms is installed, in which case it returns the empty string. -- Replace :echo by :call in the mapping to avoid displaying the fortune in Vim. if has(viminfo) (viminfo != ) append at left end because the viminfo name (if present) must be last set viminfo-=! set viminfo^=! endif function Fortune() In order to remember them in the viminfo, the first two variables defined below must have names starting with an uppercase letter and containing no lowercase letters. if !exists(g:FORTUNE) let g:FORTUNE = 0 endif if !exists(g:FORTUNECYCLE) let g:FORTUNECYCLE = 5 endif if !exists(s:sysFortunes) let s:sysFortunes = \ (system(which fortune) != ) (!v:shell_error) endif if !exists(s:bramFortunes) let s:bramFortunes = \ filereadeable(expand(~/fortunes.txt)) endif if s:sysFortunes (g:FORTUNE || (!s:bramFortunes)) let @+ = -- \n . system(fortune -a) elseif s:bramFortunes new ~/fortunes.txt silent 1;/^-- $/-1d + $put + wq else let @+ = endif let g:FORTUNE = g:FORTUNE + 1 if g:FORTUNE = g:FORTUNECYCLE let g:FORTUNE = 0 endif return @+ endfunction map F5 :echo Fortune()CR -- Best regards, Tony. Too clever is dumb. -- Ogden Nash
Re: color loading sequence in GVIM
Albie Janse van Rensburg wrote: Eric Leenman wrote: Hi, I'm doing a reinstall of gvim and placing my color and font setting in a seperate file in the plugin. This file is located in: C:\Program Files\Vim\vimfiles\plugin And it contains the following: [START OF FILE] :hi Commentctermfg=darkgreen gui=None guifg=darkgreen :hi Statement ctermfg=blue gui=None guifg=blue :hi Identifier ctermfg=darkredgui=None guifg=darkred :hi PreProcctermfg=blue gui=None guifg=darkblue :hi Type ctermfg=darkgray gui=None guifg=darkgray :hi Constant ctermfg=redgui=None guifg=red GUI font instellingen set guifont=courier:h7:w7 [END OF FILE] What now happens is that the font is taken over but the colors aren't For example: When I type :hi Comment vim returns: Comment xxx term=bold ctermfg=1 guifg=Blue What do I do wrong? Regards, Eric _ Check out all that glitters with the MSN Entertainment Guide to the Academy Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2 Colour files should go into the vimfiles/colors directory, Yes. and needs to be named according to the filetype you want it to be used for. For instance, sql.vim will be loaded for .sql files. No (see below). You can further specify what filetype to use for a file by creating a filetypes.vim file in the vimfiles/ftdetect directory. ... a filetype.vim file in a directory in 'runtimepath', *and/or* one or more Vim script(s) of _any_ name in the ftdetect subdirectory of a directory in 'runtimepath'. For more info about this, see :help ftdetect Also, :help syntax and also (more important) :help :colorscheme Hope that helps The files in the colors directory are what is called color schemes in Vim parlance, and correspond to what would be called themes or skins in other programs. Their names bear *no relation* to the files to be edited with them. Vim never loads them automatically but only as a result of the :colorscheme name command, which is roughly equivalent to :runtime colors/name.vim where name.vim is the name of an arbitrary colorscheme script. The highlight groups to use for files of a given syntax are in the syntax subdirectory of directories in 'runtimepath', and they may define default colors for highlight groups not predefined in Vim, by using :highlight default commands (see :help :highlight-default). -- Best regards, Tony. The average income of the modern teenager is about 2 a.m.
Re: color loading sequence in GVIM
A.J.Mechelynck wrote: [...] The highlight groups to use for files of a given syntax are in the oops. The highlight groups to use for files of a given syntax are defined by the script syntaxname.vim (where syntaxname is the relevant setting of the 'syntax' option), living in the syntax subdirectory of directories in 'runtimepath', and they may define default colors for highlight groups not predefined in Vim, by using :highlight default commands (see :help :highlight-default). Best regards, Tony. -- Canada Bill Jone's Motto: It's morally wrong to allow suckers to keep their money. Supplement: A .44 magnum beats four aces.
GVim colours
I've been using Vim with colorscheme evening, run in gnome-terminal set to disallow bold text and to use the Rxvt colour palette, and it's been working great for me. So great, in fact, that now, when I want to give GVim a chance, I can't stand its default interpretation of the evening colorscheme, but I have no idea how to make it drop the bold text and use the Rxvt colour palette. Is it at all doable? If so, how? Or, to rephrase my question, how to make GVim (below) look the same as Vim (above) in the following screenshot? http://shot.pl/gvim-colours.png -- Shot -- It is not yet possible to change operating system by writing to /proc/sys/kernel/ostype. -- man 2 sysctl
Re: GVim colours
Shot (Piotr Szotkowski) wrote: I've been using Vim with colorscheme evening, run in gnome-terminal set to disallow bold text and to use the Rxvt colour palette, and it's been working great for me. So great, in fact, that now, when I want to give GVim a chance, I can't stand its default interpretation of the evening colorscheme, but I have no idea how to make it drop the bold text and use the Rxvt colour palette. Is it at all doable? If so, how? Or, to rephrase my question, how to make GVim (below) look the same as Vim (above) in the following screenshot? http://shot.pl/gvim-colours.png -- Shot 1. copy the colorscheme to ~/.vim/colors/, possibly under a different name. 2. :%s/\bold\/NONE/g 3. replace the arguments of guibg= and guifg= by their #RRGGBB hex equivalents from the rxvt color palette. What these equivalents are, I don't know; but you can set any 32-bit color that way. If you want it to be usable (without dithering) on a 256-color terminal, you should use red, green and blue components, each of which is a multiple of 0x33 (i.e., 00 33 66 99 CC or FF). 4. If in (1) above you changed the name, alter the :colorscheme statement in your vimrc accordingly. Under (2) and (3) above you may have to add :highlight commands for any groups which the evening colorscheme would leave at their default, especially if the default is bold. Best regards, Tony. -- The capacity of human beings to bore one another seems to be vastly greater than that of any other animals. Some of their most esteemed inventions have no other apparent purpose, for example, the dinner party of more than two, the epic poem, and the science of metaphysics. -- H. L. Mencken
Re: GVim colours
I've written a script to remove all the gui=bold properties, please be ware that it isn't easy, since you cannot just set all the highlighting to gui=NONE. For those who had a default value of gui=reverse, you should NOT set it to gui=NONE, for those who had gui=reverse,bold, you should first set gui=NONE and then set gui=reverse again. Well, I really HATE the way to do that since it seems to be a dirty and hacked way, but unfortuanately it is the only way for gvim now, I strongly hope the next Vim version will have a much clean way to disable all the bold font. An alternative solution, is to use a bold font for the default font of gVim. And then all text will be highlight as the same thickness. Again, this is not a very satisfying approach but it might work for some people. -- Sincerely, Pan, Shi Zhu. ext: 2606 news [EMAIL PROTECTED] wrote on 2007-02-04 20:00:18: I've been using Vim with colorscheme evening, run in gnome-terminal set to disallow bold text and to use the Rxvt colour palette, and it's been working great for me. So great, in fact, that now, when I want to give GVim a chance, I can't stand its default interpretation of the evening colorscheme, but I have no idea how to make it drop the bold text and use the Rxvt colour palette. Is it at all doable? If so, how? Or, to rephrase my question, how to make GVim (below) look the same as Vim (above) in the following screenshot? http://shot.pl/gvim-colours.png -- Shot -- It is not yet possible to change operating system by writing to /proc/sys/kernel/ostype. -- man 2 sysctl
Re: A question about syntax file and vim regexps
Hi Kib :) * kib2 [EMAIL PROTECTED] dixit: I wonder if I can highlight more things in Python, I would like to highlight functions call , i.e in a Python source, in the following line: os.popen(...) be able to highlight the word popen. is it possible ? Yes, it is. First, check the Python syntax file: if it already has a syntax group for such constructs, you just need to do: hi def TheSyntaxGroup ... See :help highlight for that. If the syntax file doesn't have such construct, you will need to do something like this (UNTESTED!): syntax match PythonFunCall \I\i\+.\zs\I\i\+\ze( hi def PythonFunCall ... The regex means: \I Identifier character except numbers \i Identifier character including numbers \+ One or more of the last atom .A literal dot \zs Here starts the match (so, the coloring) \I Id \i Id \+ Id \ze Here ends the match (so, the coloring) (A literal open parentheses Please note that I'm not sure about \zs and \ze being legal in a syntax match command. If they aren't, use [EMAIL PROTECTED] and family instead (see :help zero-width for that). Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | http://www.dervishd.net It's my PC and I'll cry if I want to... RAmen!
Re: color loading sequence in GVIM
Albie Janse van Rensburg wrote: A.J.Mechelynck wrote: Albie Janse van Rensburg wrote: Eric Leenman wrote: Hi, I'm doing a reinstall of gvim and placing my color and font setting in a seperate file in the plugin. This file is located in: C:\Program Files\Vim\vimfiles\plugin And it contains the following: [START OF FILE] :hi Commentctermfg=darkgreen gui=None guifg=darkgreen :hi Statement ctermfg=blue gui=None guifg=blue :hi Identifier ctermfg=darkredgui=None guifg=darkred :hi PreProcctermfg=blue gui=None guifg=darkblue :hi Type ctermfg=darkgray gui=None guifg=darkgray :hi Constant ctermfg=redgui=None guifg=red GUI font instellingen set guifont=courier:h7:w7 [END OF FILE] What now happens is that the font is taken over but the colors aren't For example: When I type :hi Comment vim returns: Comment xxx term=bold ctermfg=1 guifg=Blue What do I do wrong? Regards, Eric _ Check out all that glitters with the MSN Entertainment Guide to the Academy Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2 Colour files should go into the vimfiles/colors directory, Yes. and needs to be named according to the filetype you want it to be used for. For instance, sql.vim will be loaded for .sql files. No (see below). You can further specify what filetype to use for a file by creating a filetypes.vim file in the vimfiles/ftdetect directory. ... a filetype.vim file in a directory in 'runtimepath', *and/or* one or more Vim script(s) of _any_ name in the ftdetect subdirectory of a directory in 'runtimepath'. For more info about this, see :help ftdetect Also, :help syntax and also (more important) :help :colorscheme Hope that helps The files in the colors directory are what is called color schemes in Vim parlance, and correspond to what would be called themes or skins in other programs. Their names bear *no relation* to the files to be edited with them. Vim never loads them automatically but only as a result of the :colorscheme name command, which is roughly equivalent to :runtime colors/name.vim where name.vim is the name of an arbitrary colorscheme script. The highlight groups to use for files of a given syntax are in the syntax subdirectory of directories in 'runtimepath', and they may define default colors for highlight groups not predefined in Vim, by using :highlight default commands (see :help :highlight-default). Absolutely. I had my syntax file and colorschemes info mixed up. I hope the OP reads your corrections. _Syntax_ files need to be named according to their application (language), whereas colorscheme files are used to change the colours of text _according_to_the_syntax_ file definition. The colorscheme effectively is applied over the syntax definition. Indeed. This also means that :syntax on reloads the current colorscheme (if any, or sets the default colours if none), which may explain why Eric didn't see his colour highlights. Note that since many syntax scripts define their color highlight groups by linking them to the default groups, setting highlights for said default groups will usually go a long way towards colouring everything. (For instance, by default the colours of the Comment group are reused for cComment, htmlComment, vimComment, etc., so unless you want to use different colours for each of these -- which IMHO would be rather pointless -- you can content yourself with defining Comment highlights and the various somethingComment groups will all be set to that.) :help :colorscheme indeed. The OP is talking about a colorscheme file though (the first part, defining highlight groups), which should be placed in vimfiles/colors. As for the guifont setting, I personally do it in my vimrc file, but afaik it should work in a colorscheme file as well. From what I can see, the highlight settings are loaded into a colorscheme (which will have the name of the .vim file containing them), so by running :colorscheme filename your highlight groups will get set, Eric. First move your file into the vimfiles/colors directory to avoid unpredictable results. Best regards, Tony. -- The USA is so enormous, and so numerous are its schools, colleges and religious seminaries, many devoted to special religious beliefs ranging from the unorthodox to the dotty, that we can hardly wonder at its yielding a more bounteous harvest of gobbledygook than the rest of the world put together. -- Sir Peter Medawar
RE: Mapping with Shift, Ctrl and Alt/Meta
Using Ctrl-V, I can see that Gvim doesn't see Alt-Ctrl or Alt-Ctrl-Shift for normal keys, just for function keys, insert/delete, home/end, page-up/down an the arrow keys. This is NOT a Windows issue. My email program (The Bat!), for example, lets me make use of all of those combinations. I believe it is a bug in the Gvim keyboard handling. The tab key is a bit of an oddity. Of the eight possibilities, Ctrl-Tab and Alt-Ctrl-Tab don't work, although Ctrl-Shift-Tab and Alt-Ctrl-Shift-Tab do work. [Windows always takes over Alt-Tab and Alt-Shift-Tab.] Actually, it *might* be a Windows issue. If you do a typical Control-Panel thing where you get a bunch of pages with the little tabs on top, regular tab will run through all the fields/buttons/etc. on that page, but ctl-tab will pop over to the next tab. Eg, just picking one at random, Control Panel -- Folder Options, cycling through the options in General is done with the tab key, but getting to the View, File Types, etc., is done via ctl-tab. (Just tried it now, I speak the trvth. :) ) I try to never ever ever use the moose unless I'm practically forced at gunpoint, well, at least if the program/app is sucky enough to not have a keyboard way to do something, so this is kind of familiar to me. Sooo, point was that it might very well he a grabbed key-combo, even if nothing's immediately done with it.
Re: open multiple files with wildcard from inside vim
Cameron Simpson wrote: On 05Feb2007 01:44, ben lieb [EMAIL PROTECTED] wrote: | Have you tried: |:n path/file* [...] | That's better than where I was, thanks. Ideally the files would all be | visible, either split on the screen, or in separate tabs. Is there a | way to do this? You're now into vim areas of which I know little. I only migrated to vim from nvi recently, and that basicly for the syntax highlighting and file completion for :n commands; nvi has file completion - better than vim's in some ways, and worse in others. I find split displays annoying and confusing, and generally just keep multiple editor windows around where you would probably use tabs. A split display leaves me feeling I'm sacrificing text display space to a file I'm not editing:-( However, if you have a large number of files: how well will they display in split mode or tabs? My first thought is not awfully well. My usual editing mode has only one file displayed at once per window. Combined with autowrite and # mapped to :n #^M it's quite effective for me. It seems that everyone has such specialized needs sometimes. I'm a web develper and have at least 10 programs going at one time. More windows is not an option. Multiple tabs would be ideal, but once you get used to working with a split screen (horiz, or vert), you find that it has its uses. Usually when you have a long file or want to make a quick edit. Anyone else?
Re: open multiple files with wildcard from inside vim
ben lieb wrote, Cameron Simpson wrote: On 05Feb2007 01:44, ben lieb [EMAIL PROTECTED] wrote: | Have you tried: |:n path/file* [...] | That's better than where I was, thanks. Ideally the files would all be | visible, either split on the screen, or in separate tabs. Is there a | way to do this? You're now into vim areas of which I know little. I only migrated to vim from nvi recently, and that basicly for the syntax highlighting and file completion for :n commands; nvi has file completion - better than vim's in some ways, and worse in others. I find split displays annoying and confusing, and generally just keep multiple editor windows around where you would probably use tabs. A split display leaves me feeling I'm sacrificing text display space to a file I'm not editing:-( However, if you have a large number of files: how well will they display in split mode or tabs? My first thought is not awfully well. My usual editing mode has only one file displayed at once per window. Combined with autowrite and # mapped to :n #^M it's quite effective for me. It seems that everyone has such specialized needs sometimes. I'm a web develper and have at least 10 programs going at one time. More windows is not an option. Multiple tabs would be ideal, but once you get used to working with a split screen (horiz, or vert), you find that it has its uses. Usually when you have a long file or want to make a quick edit. Anyone else? I am getting used to working with tabs, but yes, once you get going with split screens, it's hard to break the habit...
RE: Verilog Indentation
I'm not sure what you mean by properly indented files because I've seen a lot of different styles in the verilog code I've reviewed even though it is coming from a group if individuals at our company who supposedly are designing to a company standard. I have the following in my .vimrc: set ai always set autoindenting on set smartindent C-intelligent indenting set sw=4 shiftwidth (indent) set tabstop=8Tab width is 8 Also, I have CCverilog.vim in my ftplugin folder. -Clint -Original Message- From: Naim Far [mailto:[EMAIL PROTECTED] Sent: Sunday, February 04, 2007 5:05 AM To: Vim users Subject: Verilog Indentation Hi Vimers, Can anyone please help me with making the vim indent verilog files properly?! Thanx in advance!
Clearing undo history after a file write
After writing out a file, I would (sometimes, not always) like to prevent 'u' from undoing past the :w into old changes, e.g., - change #1 - change #2 - :w - change #3 - change #4 - 'u' undoes #4 and then #3, but then stops This seems like such a simple thing, but to my surprise it's less trivial than I thought it would be. The only thing in :help undo and its related tags which seems to be relevant is the undolevels variable. So maybe something like - copy undolevels into some temp variable // I don't remember the let syntax offhand - set undolevels=-1 - set undolevels=temp_holding_variable would work? A value of -1 disables undo altogether, so would this sequence kill the history and start it from scratch? -phil
RE: Clearing undo history after a file write
The easiest thing to do would probably just to do :e after your :w. :e will re-read the file, wiping the undo buffer. Max -Original Message- From: Phil Edwards [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 9:26 AM To: vim@vim.org Subject: Clearing undo history after a file write After writing out a file, I would (sometimes, not always) like to prevent 'u' from undoing past the :w into old changes, e.g., - change #1 - change #2 - :w - change #3 - change #4 - 'u' undoes #4 and then #3, but then stops This seems like such a simple thing, but to my surprise it's less trivial than I thought it would be. The only thing in :help undo and its related tags which seems to be relevant is the undolevels variable. So maybe something like - copy undolevels into some temp variable // I don't remember the let syntax offhand - set undolevels=-1 - set undolevels=temp_holding_variable would work? A value of -1 disables undo altogether, so would this sequence kill the history and start it from scratch? -phil
Re: Clearing undo history after a file write
On 2/5/07, Max Dyckhoff [EMAIL PROTECTED] wrote: The easiest thing to do would probably just to do :e after your :w. :e will re-read the file, wiping the undo buffer. Ah, didn't know about that side effect. I knew there had to be an easier solution. :-) Thanks! phil
Re: Clearing undo history after a file write
The easiest thing to do would probably just to do :e after your :w. :e will re-read the file, wiping the undo buffer. Ah, didn't know about that side effect. I knew there had to be an easier solution. :-) Thanks! Max is correct (and it is quite easy), though just be aware that there are some other side effects that go with that method...particularly marks and your jumplist for the given file will also go up in smoke in the same way as your undo history. You may or may not want that effect. But every alternative way of clearing the undo history that I've thought of has also cleared these items as well so it's just tough luck. :) -tim
Re: color loading sequence in GVIM
Hi,
Following your comments, I've converted my file to a scheme and placed it in
C:\Program Files\Vim\vimfiles\colors
For testing I also placed a bw.vim and a print_bw.vim in it.
The problem now is that it doesn't get loaded.
When I type :colorscheme eric it says E185: Can not find colorscheme eric
When I type echo g:colors_name it says undefined variable
When I type :colorscheme print_bw it switches to this scheme
When I type echo g:colors_name it says print_bw
Copying the print_bw file to print_bw2.vim and changing only the line
let g:colors_name = blabla
gives also the same errors with my ëricscheme
Why
Rgds,
Eric
Header information {{{
Remove all existing highlighting. {{{
==
set background=light
hi clear
if exists(syntax_on)
syntax reset
endif
===
}}}
Name the scheme eric {{{
let g:colors_name = eric
===
}}}
Define colorscheme as visual C++ {{{
==
hi Commentcterm=NONE ctermfg=darkgreen ctermbg=white gui=NONE
guifg=darkgreen guibg=white
hi Statement cterm=NONE ctermfg=blue ctermbg=white gui=NONE
guifg=blue
guibg=white
hi Identifier cterm=NONE ctermfg=darkredctermbg=white gui=NONE
guifg=darkred
guibg=white
hi PreProccterm=NONE ctermfg=blue ctermbg=white gui=NONE
guifg=darkblue guibg=white
hi Type cterm=NONE ctermfg=darkgray ctermbg=white gui=NONE
guifg=darkgray guibg=white
hi Constant cterm=NONE ctermfg=red ctermbg=white gui=NONE guifg=red
guibg=white
===
}}}
vim60: set foldmethod=marker: {{{
}}}
From: A.J.Mechelynck [EMAIL PROTECTED]
To: Albie Janse van Rensburg [EMAIL PROTECTED]
CC: Eric Leenman [EMAIL PROTECTED], vim@vim.org
Subject: Re: color loading sequence in GVIM
Date: Mon, 05 Feb 2007 17:01:57 +0100
Albie Janse van Rensburg wrote:
A.J.Mechelynck wrote:
Albie Janse van Rensburg wrote:
Eric Leenman wrote:
Hi,
I'm doing a reinstall of gvim and placing my color and font setting in
a seperate file in the plugin.
This file is located in: C:\Program Files\Vim\vimfiles\plugin
And it contains the following:
[START OF FILE]
:hi Commentctermfg=darkgreen gui=None guifg=darkgreen
:hi Statement ctermfg=blue gui=None guifg=blue
:hi Identifier ctermfg=darkredgui=None guifg=darkred
:hi PreProcctermfg=blue gui=None guifg=darkblue
:hi Type ctermfg=darkgray gui=None guifg=darkgray
:hi Constant ctermfg=redgui=None guifg=red
GUI font instellingen
set guifont=courier:h7:w7
[END OF FILE]
What now happens is that the font is taken over but the colors aren't
For example:
When I type :hi Comment
vim returns:
Comment xxx term=bold ctermfg=1 guifg=Blue
What do I do wrong?
Regards,
Eric
_
Check out all that glitters with the MSN Entertainment Guide to the
Academy Awards®
http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline2
Colour files should go into the vimfiles/colors directory,
Yes.
and needs to be named according to the filetype you want it to be used
for. For instance, sql.vim will be loaded for .sql files.
No (see below).
You can further specify what filetype to use for a file by creating a
filetypes.vim file in the vimfiles/ftdetect directory.
... a filetype.vim file in a directory in 'runtimepath', *and/or* one or
more Vim script(s) of _any_ name in the ftdetect subdirectory of a
directory in 'runtimepath'.
For more info about this, see
:help ftdetect
Also,
:help syntax
and also (more important)
:help :colorscheme
Hope that helps
The files in the colors directory are what is called color schemes in Vim
parlance, and correspond to what would be called themes or skins in
other programs. Their names bear *no relation* to the files to be edited
with them. Vim never loads them automatically but only as a result of the
:colorscheme name command, which is roughly equivalent to :runtime
colors/name.vim where name.vim is the name of an arbitrary
colorscheme script.
The highlight groups to use for files of a given syntax are in the syntax
subdirectory of directories in 'runtimepath', and they may define default
colors for highlight groups not predefined in Vim, by using :highlight
default commands (see :help :highlight-default).
Absolutely. I had my syntax file and colorschemes info mixed up. I hope
the OP reads your corrections. _Syntax_ files need to be named according
to their application (language), whereas colorscheme files are used to
change the colours of text _according_to_the_syntax_ file definition. The
colorscheme effectively is applied over the syntax definition.
Indeed. This also means that
Re: Tips which are spam
Currently there is much spam in recent comments: http://vim.sourceforge.net/tips/recent_notes.php Andy -- EOF ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Tips which are spam
Andy Wokula wrote: Currently there is much spam in recent comments: http://vim.sourceforge.net/tips/recent_notes.php Last time this was discussed I got the impression that there is a feeling that if no one reads the spam, then it is not a problem. But I think the situation is worse than that. The spammers don't care if anyone reads the tips. They want the optimisation to their search ranking in Google et al from having links to their site. Helping these leaches is no longer acceptable IMHO. Lots of places on the Internet have had to implement a simple logon or at least a captcha - anonymous posting can't be allowed. John
Re: Clearing undo history after a file write
That's strange, my marks are maintained when I do an reload the buffer with :e, and the jumplist seems to be preserved, too. I never use either mechanism, but a little experiment shows they are still there. Perhaps there are other things that are erased too though, a side-effect I hadn't thought of. Ah...I do see some persistance of these things depending on where the marks were in the file. I tested the following in a 100 line file (with vi -u NONE): :1,30d :3 :ka :e! :'a It doesn't return to the line I marked previously (originally line 33), but to line 3 of the previous file. Semi-understandable...just a somewhat peculiar behavior when :1,30d :3 :ka :u :'a does return to the proper spot. It seems to sorta keep the marks. Similar oddities seem to happen with jumps. Perhaps it is something to do with my vimrc; I am pretty keen on keeping things around for as long as possible (:set hidden, :set history=1000, etc) I'm somewhere in between...I like long histories, but only set 'hidden' as needed as a reminder to myself. I also don't let .viminfo handle much, as I like to have a fairly fresh copy of vim each time I start it.
Re: Tips which are spam
John Beckett schrieb: Andy Wokula wrote: Currently there is much spam in recent comments: http://vim.sourceforge.net/tips/recent_notes.php Last time this was discussed I got the impression that there is a feeling that if no one reads the spam, then it is not a problem. But I think the situation is worse than that. The spammers don't care if anyone reads the tips. They want the optimisation to their search ranking in Google et al from having links to their site. Helping these leaches is no longer acceptable IMHO. Lots of places on the Internet have had to implement a simple logon or at least a captcha - anonymous posting can't be allowed. John E.g. posters must either login or solve simple math (or answer simple Vim questions, even better ;) next to the Add Note button. Should be fairly easy to add? Andy -- EOF ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
RE: Tips which are spam
Might be easier on the user to use the 'negative captcha' idea floating about online: Put a hidden form field called email, phone, login or some such that a bot is likely to fill and use CSS to hide it. A human won't see it, but a bot will (ignoring CSS). If the field ends up containing a value, it must have been filled by a bot; ignore the tip/note submission. Not foolproof, but it'll probably work here. Salman. -Original Message- From: Andy Wokula [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 3:35 PM To: John Beckett Cc: vim Subject: Re: Tips which are spam John Beckett schrieb: Andy Wokula wrote: Currently there is much spam in recent comments: http://vim.sourceforge.net/tips/recent_notes.php Last time this was discussed I got the impression that there is a feeling that if no one reads the spam, then it is not a problem. But I think the situation is worse than that. The spammers don't care if anyone reads the tips. They want the optimisation to their search ranking in Google et al from having links to their site. Helping these leaches is no longer acceptable IMHO. Lots of places on the Internet have had to implement a simple logon or at least a captcha - anonymous posting can't be allowed. John E.g. posters must either login or solve simple math (or answer simple Vim questions, even better ;) next to the Add Note button. Should be fairly easy to add? Andy -- EOF ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
RE: Tips which are spam
My suggestion: implement a reverse captcha. There is no additional overhead for users, and friends of mine who have implemented it have found that it foils the spammers, at least for now, with very little work. http://damienkatz.net/2007/01/negative_captch.html Max -Original Message- From: John Beckett [mailto:[EMAIL PROTECTED] Sent: Monday, February 05, 2007 12:15 PM To: vim Subject: Re: Tips which are spam Andy Wokula wrote: Currently there is much spam in recent comments: http://vim.sourceforge.net/tips/recent_notes.php Last time this was discussed I got the impression that there is a feeling that if no one reads the spam, then it is not a problem. But I think the situation is worse than that. The spammers don't care if anyone reads the tips. They want the optimisation to their search ranking in Google et al from having links to their site. Helping these leaches is no longer acceptable IMHO. Lots of places on the Internet have had to implement a simple logon or at least a captcha - anonymous posting can't be allowed. John
test and question
Works? Anyway my question: Is it possible to set a global textwidth option in some way? It is annoying me that it is set to 78 after pretty much every file I load. Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
Re: test and question
Works? Yup. Is it possible to set a global textwidth option in some way? It is annoying me that it is set to 78 after pretty much every file I load. Edit your $HOME/.vimrc (or _vimrc on win32) and add the line set tw=78 Presto! -tim
Re: test and question
No no, the options is local to a buffer. The only way I can think of is to create a hook of some sort (events) and do 'set tw=0' after a file loads, but gurus might know better. Need Mail bonding? Go to the Yahoo! Mail QA for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=listsid=396546091
Re: test and question
Try putting the following in your ~/.vimrc. set textwidth=0 A zero for textwidth, sounds bizarre. - Original Message From: John Doe [EMAIL PROTECTED] To: vim@vim.org Sent: Monday, February 5, 2007 4:10:14 PM Subject: test and question Works? Anyway my question: Is it possible to set a global textwidth option in some way? It is annoying me that it is set to 78 after pretty much every file I load. Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html
timer revisited
Well, I am so happy I can post here again (I've been shut out for about 1/2 year for no apparent reason). So I need to catch up with the question backlog. I used to be able to conjure regenerating timer events in vim 6.4 like this: here's a nice workaround for a regenerative CursorHold event, suggested by Antony Scriven au CursorHold * exe norm! r\ESC | call SIDTimerEvent() the norm r \ESC kludge used to simulate a keypress to vim 6.4 (both on linux and win32) so that the event was regenerated after the usual 5 seconds or so. Not so anymore! I cannot get regenerating timer events in vim anymore and the only way I can think of getting around this is: 1. vote for special Timer events addon and pay for it 2. get a new kludge from you folks I don't know if option 1 is viable BTW. Please, a new kludge, you'll get recognition in my script. Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: test and question
No no, the options is local to a buffer. The only way I can think of is to create a hook of some sort (events) and do 'set tw=0' after a file loads, but gurus might know better. Ah, I see the problem. Yes, vim has hooks (autocommands, verbosely detailed at :help autocmd.txt where you can read more than any sane person should want to :) to do just the sort of thing you describe. You put a line something like the following in your vimrc: autocmd BufNewFile,BufRead * set tw=0 You can adjust the * to be whatever filespecs you might want. If you just want .html or .txt files, it's easy enough to isolate them: augroup TextFiles au! autocmd BufNewFile,BufRead *.htm set tw=0 autocmd BufNewFile,BufRead *.html set tw=0 autocmd BufNewFile,BufRead *.txt set tw=0 augroup END However, vim *should default to having 'tw' set to zero. If you start vim with vim -u NONE, and :set tw? it comes back as 0. This leads me to believe that some plugin/script that you load is monkeying with your setting. You can use :verbose set tw? to learn where it was last set. You might also find :scriptnames helfpul for nailing down the troublesome script. Once you find the troublemaker, you can either edit it or remove it. Just a few ideas. -tim
Re: test and question
On 2007-02-05, John Doe [EMAIL PROTECTED] wrote: No no, the options is local to a buffer. The only way I can think of is to create a hook of some sort (events) and do 'set tw=0' after a file loads, but gurus might know better. There are several ways to do this. If this is a problem for only a few file types, then the standard solution is to create your own plugin file for each file type for which this is a problem and put them in ~/.vim/after/ftplugin/ on Unix or $VIM\vimfiles\after\ftplugin on Windows. Each file would contain just this line: setlocal tw=0 If you want to do this for all file types, you might be better off putting this in your ~/.vimrc: au FileType * setlocal tw=0 It's important to put this towards the end of your ~/.vimrc, after any :filetype command(s), so that this autocommand is executed _after_ any filetype plugins are loaded. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: open multiple files with wildcard from inside vim
Hi, On 2/5/07, ben lieb [EMAIL PROTECTED] wrote: Cameron Simpson wrote: On 05Feb2007 01:44, ben lieb [EMAIL PROTECTED] wrote: | Have you tried: |:n path/file* [...] | That's better than where I was, thanks. Ideally the files would all be | visible, either split on the screen, or in separate tabs. Is there a | way to do this? You can use the :sall or :all command to open all the files in the argument list in a separate window. :n *.txt :sall You can use the :argadd command instead of the :next command to add files to the argument list. :argadd *.txt :all To open the files in separate tabs, use the :tab command modifier. :tab all Similarly you can use the :sball command to open all the files in the Vim buffer list. - Yegappan
Re: open multiple files with wildcard from inside vim
Yegappan Lakshmanan wrote: Hi, On 2/5/07, ben lieb [EMAIL PROTECTED] wrote: Cameron Simpson wrote: On 05Feb2007 01:44, ben lieb [EMAIL PROTECTED] wrote: | Have you tried: |:n path/file* [...] | That's better than where I was, thanks. Ideally the files would all be | visible, either split on the screen, or in separate tabs. Is there a | way to do this? You can use the :sall or :all command to open all the files in the argument list in a separate window. :n *.txt :sall You can use the :argadd command instead of the :next command to add files to the argument list. :argadd *.txt :all To open the files in separate tabs, use the :tab command modifier. :tab all Similarly you can use the :sball command to open all the files in the Vim buffer list. - Yegappan ... yes, and, to lift any ambiguity, in Vim terminology windows are what other programs would call panes or split screens; not what Windows or X11 would call (program) windows. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 13. You refer to going to the bathroom as downloading.
Re: Clearing undo history after a file write
Max Dyckhoff wrote: That's strange, my marks are maintained when I do an reload the buffer with :e, and the jumplist seems to be preserved, too. I never use either mechanism, but a little experiment shows they are still there. Perhaps there are other things that are erased too though, a side-effect I hadn't thought of. Perhaps it is something to do with my vimrc; I am pretty keen on keeping things around for as long as possible (:set hidden, :set history=1000, etc) Max Marks are remembered in the viminfo: local marks according to 'nn (nn = number of files) which must be included whenever 'viminfo' is nonempty, and global marks according to f (default=all, fn [n != 0] =all, f0 = none). Best regards, Tony. -- The assertion that all men are created equal was of no practical use in effecting our separation from Great Britain and it was placed in the Declaration not for that, but for future use. -- Abraham Lincoln
Vim presentation in Mountain View
Dear Vim users,
I will be doing a presentation on Vim, here is the announcement:
Open Source Developers @ Google Speaker Series: Bram Moolenaar
Tuesday, February 13, 19.00h
Title: Seven habits for effective text editing, 2.0.
Bram's presentation will give an overview of several ways to effectively
use Vim to edit programs, structured text and documentation.
Please join us for Bram's presentation if you're in the area. Doors will
open at 6:30 PM and Bram will begin speaking at 7:00 PM. Refreshments
will be served; please plan to sign in at Building 41 reception when you
arrive.
More information:
http://google-code-updates.blogspot.com/2007/02/open-source-developers-google-speaker.html
For instructions how to get there click on Mountain View headquarters.
But pay attention to the building number 41, there are many Google
buildings :-).
Hope to meet you there!
--
From know your smileys:
:-{Worf (Never smiles anyways, so he's a bad smiley)
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: How to maximize my vim window when I start it?
On 2/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, The :set lines=9 columns=9 does not really maxmize the Vim window. Since there's still borders for the window, a maximized window have no borders (AFAIK this is true for WinXP and KDE). Since you are highly unlikely to use a Windows version other than English and Chinese. The following method works: if has(gui_win32)NT Windows autocmd GUIEnter * :simalt ~x endif Tony think the method is non-portable, that is true, if there's a portable way to do the job, I will prefer the portable way. However, the :set lines=9 columns=9 cannot do the same job as the :simalt can do, so their must be a compromize. I would recommend the :simalt way until there is a nature way for vim to cope with that. There's a third (although not exactly desirable) way. If you use vim sessions, you can add 'resize' to the set of sessionoptions, and set columns and lines to values that are useful for a significant length of time. This way, they will persist across sessions. I use this method under the ratpoison window manager in Linux and it works quite well.
:copen annoying trouble
Hi! When I work with many buffers inside vim and suddenly need to :copen :make project, vim opens buffer in which warning or error is detected. This is very annoying, since I have to switch from pouped-up buffer where error or warning is detected to last working one. Is it possible to switch off autoswitching to buffer where warning or error is detected? -- God bless you! Ilia 2.6.18-gentoo-r6 AMD Athlon(tm) XP 2600+ mailto: [EMAIL PROTECTED] icq: 198233378 VegaTrek Developer: http://wcuniverse.sourceforge.net/vegatrek/ VegaTrek Forum Moderator: http://vegastrike.sourceforge.net/forums/viewforum.php?f=13 You know you're using the computer too much when: beautiful women start looking as good a penguins do... -- jcmorris $gpg --keyserver cryptonomicon.mit.edu --search-keys tillias
Re: How to maximize my vim window when I start it?
I don't know if I am in error, but ':set lines=999 columns=999' from .vimrc does not work for me under KDE 3.5. It works in ex mode, after everything is loaded, but not from the .vimrc file (and yes I am using gvim). There are also some notable strange effects: au GUIEnter * set lines=999 columns=999 seems to really make gvim think there are so many columns and lines: word-wrap is turned off and command line disappears, but it resizes the gvim's window ok. the only thing that works for me is: au CursorHold * exe ':set lines=999 columns=999 | au! CursorHold', which does the resizing after a delay, but sometimes even this produces the aforementioned strange effect. In short, under KDE, :set lines=999 columns=999 works for me after everything settles down, but not before. I am using gvim 7.0.17.
