Re: Highlighting keywords from C libraries
On Thu, Feb 22, 2007 at 03:19:24AM +0900, Kazunobu Kuriyama wrote: snip I attach a modified c.vim syntax file (minor changes to accommodate the modular structure above), and glibc.vim, xlib.vim (which should be put inside syntax/clibs/) to highlight functions and constants from glibc and xlib respectively. I'm afraid this is not a good idea; c.vim should not depend on any set of the symbols which come from the particular implementation of an arbitrarily chosen C library. To be more specific, I can't see any good reason why I have to give up highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, unless I use glibc.vim together with c.vim. I strongly believe that all symbols defined in the *standard* C library must remain in c.vim. Also, I hardly imagine a situation where all C library symbols are needed at a time to highlight a file in a buffer. For example, it is annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn are highlighted even if math.h is irrelevant that file. Well, I think that all symbols defined in the *standard* C library should be included in say libc.vim. I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. Lastly, I'm afraid that, since C library functions are so common, highlighting them would rather kill the purposes and effects of highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. GI -- 'Common' Proof Techniques: 14. Proof by eminent authority -- I saw Karp in the elevator and he said it was probably NP-complete.
Re: Highlighting keywords from C libraries
On Wed, Feb 21, 2007 at 10:07:22AM -0600, Bill McCarthy wrote: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. This is a nice addition that I would like to see included. I noticed that you patched c.vim against an older version. The current version is dated Feb 13, 2007. Sorry. I did this sometime last year, and completely forgot about it. After seeing Bram at Google, and the video of his talk yesterday I got reminded and sent it off to the list. If it looks like it's going to be included with Vim, I'll of course update to the latest version and write appropriate documentation. GI -- An Apple a day, keeps Windows away.
Re: Highlighting keywords from C libraries
On 2/21/07, Gautam Iyer [EMAIL PROTECTED] wrote: Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. Reasonable. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. Yes, this is appreciated, because I personally think that having too much highlighting goes against the purpose of highlighting - hey, the default highlighting is to highlight everything in the same color (black) and it works a lot better than having everything highlighted as green, red, blue, orange, yellow, black, magenta, I'm not the right person to say anything here, because my syntax definitions tend to highlight basically everything, but I've gone more and more to defining syntaxes where people can highlight anything they want, but keep the default set of highlights sparse. nikolai
Re: Cannot run background process in gvim 7
Manu Hack wrote: gvim --version gives [...] So? What exactly are you trying to do? How does it fail? Best regards, Tony. -- 'Twas midnight, and the UNIX hacks Did gyre and gimble in their cave All mimsy was the CS-VAX And Cory raths outgrabe. Beware the software rot, my son! The faults that bite, the jobs that thrash! Beware the broken pipe, and shun The frumious system crash!
Re: Highlighting keywords from C libraries
Gautam Iyer wrote: On Thu, Feb 22, 2007 at 03:19:24AM +0900, Kazunobu Kuriyama wrote: snip I attach a modified c.vim syntax file (minor changes to accommodate the modular structure above), and glibc.vim, xlib.vim (which should be put inside syntax/clibs/) to highlight functions and constants from glibc and xlib respectively. I'm afraid this is not a good idea; c.vim should not depend on any set of the symbols which come from the particular implementation of an arbitrarily chosen C library. To be more specific, I can't see any good reason why I have to give up highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, unless I use glibc.vim together with c.vim. I strongly believe that all symbols defined in the *standard* C library must remain in c.vim. Also, I hardly imagine a situation where all C library symbols are needed at a time to highlight a file in a buffer. For example, it is annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn are highlighted even if math.h is irrelevant that file. Well, I think that all symbols defined in the *standard* C library should be included in say libc.vim. I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. I guess you could easily find someone around you who has a standard C library reference. Can't you borrow one from a public library or somewhere else, if not online... Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. It would be better to take into consideration those who source the current c.vim in their vim scripts. Are you sure that your proposed modularization scheme give little or no harm to such user scripts? It's not obvious to me. What's your prospect? Lastly, I'm afraid that, since C library functions are so common, highlighting them would rather kill the purposes and effects of highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. But once your syntax files are included in run time, poor users have to either follow your taste all along or reject it completely. Why not give them a middle ground? The proposed structure will surely give such flexibility as you claim, but I don't feel the syntax files you have proposed are written in such a way that they actually comply with your claim. I still don't understand why familiar C library function calls ought to catch our eyes; it could be sometimes sort of distraction for some people. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. I don't think this is the right purpose of highlighting. It would be sometimes extremely harmful as much. If there are two or more similar names, you can't tell one from others only by highlighting. If it should pass compilation, you would surely get extremely frustrated to spot a bug, because you would wrongly keep believing you had chosen the right name. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. I rather want to highlight something I need to pay attention to. It doesn't matter and has nothing to do with my concern whether a symbol is made up of upper case letters or lower ones or beginning with a underscore. I don't understand how the choices mentioned above make coding efficient, though I admit it makes hightlighting fancier. Thanks, - KK
Re: Highlighting keywords from C libraries
* Gautam Iyer gautam@ [070221 12:17]: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. Check out the std_c syntax, http://www.eandem.co.uk/mrw/vim/syntax/ -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: Highlighting keywords from C libraries
On Thu, Feb 22, 2007 at 07:39:50AM +0900, Kazunobu Kuriyama wrote: snip I attach a modified c.vim syntax file (minor changes to accommodate the modular structure above), and glibc.vim, xlib.vim (which should be put inside syntax/clibs/) to highlight functions and constants from glibc and xlib respectively. I'm afraid this is not a good idea; c.vim should not depend on any set of the symbols which come from the particular implementation of an arbitrarily chosen C library. To be more specific, I can't see any good reason why I have to give up highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, unless I use glibc.vim together with c.vim. I strongly believe that all symbols defined in the *standard* C library must remain in c.vim. Also, I hardly imagine a situation where all C library symbols are needed at a time to highlight a file in a buffer. For example, it is annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn are highlighted even if math.h is irrelevant that file. Well, I think that all symbols defined in the *standard* C library should be included in say libc.vim. I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. I guess you could easily find someone around you who has a standard C library reference. Can't you borrow one from a public library or somewhere else, if not online... Theres no way I'm going to type in by hand all standard C keywords. If I can generate it easily from an online reference, I'll do that. I couldn't, so I did glibc from the info page instead. Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to clibs/default.vim, and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. It would be better to take into consideration those who source the current c.vim in their vim scripts. Are you sure that your proposed modularization scheme give little or no harm to such user scripts? It's not obvious to me. What's your prospect? Yes. Read the modification. All it does is define one new cluster, and include all files in the syntax/clibs directory PROVIDED some Vim variables are defined. If those variables are not defined, the syntax/clibs files are ignored, and c.vim should behave as it did earlier. (The commented out symbols you pointed out in your previous message will be added to a stdc.vim soon). Lastly, I'm afraid that, since C library functions are so common, highlighting them would rather kill the purposes and effects of highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. But once your syntax files are included in run time, poor users have to either follow your taste all along or reject it completely. Why not give them a middle ground? The proposed structure will surely give such flexibility as you claim, but I don't feel the syntax files you have proposed are written in such a way that they actually comply with your claim. Have you read the attached syntax files? They do exactly what I claimed. (Read glibc.vim with fdm=marker, and you will see). I still don't understand why familiar C library function calls ought to catch our eyes; it could be sometimes sort of distraction for some people. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. I don't think this is the right purpose of highlighting. It would be sometimes extremely harmful as much. If there are two or more similar names, you can't tell one from others only by highlighting. If it should pass compilation, you would surely get extremely frustrated to spot a bug, because you would wrongly keep believing you had chosen the right name. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. I rather want to highlight something I need to pay
Re: Highlighting keywords from C libraries
Since projects won't have as many keywords as glibc, the only slow down will be with the syntax file (re)generation. ctags is reasonably fast Sorry. I haven't read your message thoroughly enough. I was talking about what you've written in your comment. /me hides ;) Marc
Re: Highlighting keywords from C libraries
Gautam Iyer wrote: snip I guess you could easily find someone around you who has a standard C library reference. Can't you borrow one from a public library or somewhere else, if not online... Theres no way I'm going to type in by hand all standard C keywords. If I can generate it easily from an online reference, I'll do that. I couldn't, so I did glibc from the info page instead. As you know, glibc borrows a great number of symbols from a bunch of the existing C library specifications such as POSIX, SVID, BSD, XOpen, and so on. Also, there're a number of symbols peculiar to GNU. Do you think people want to come across SIGCLD and SIGCHLD which are equally highlighted due to your reluctance in manual labor? What answer do you have for those who want to highlight only symbols complying with their libc? I think a decent stragey calls for some division, e.g., stdc.vim - collection of symbols commonly defined in any kind of the libc specifications. (I respectfully borrows the name from what you wrote below.) svid.vim - collection of symbols peculiar to SVID. bsd.vim - collection of symbols peculiar to BSD. ... xxx.vim - collection of symbols peculiar to the specification XXX. And then you offer some flags in order to let the user choose which specifications she/he wants to use. It is highly likely that gnu.vim is a short script invoking stdc.vim svid.vim, bsd.vim and other (UNIX variants.).vim. snip It would be better to take into consideration those who source the current c.vim in their vim scripts. Are you sure that your proposed modularization scheme give little or no harm to such user scripts? It's not obvious to me. What's your prospect? Yes. Read the modification. All it does is define one new cluster, and include all files in the syntax/clibs directory PROVIDED some Vim variables are defined. If those variables are not defined, the syntax/clibs files are ignored, and c.vim should behave as it did earlier. (The commented out symbols you pointed out in your previous message will be added to a stdc.vim soon). I did read it. This is a baseless accusation. As you pointed out, my point is in the parentheses above. How come you could say as if I were lazy? It was my careful examination of your scripts that enabled me to point out the problem. If you don't want it, tell me, I'll quit. snip Have you read the attached syntax files? They do exactly what I claimed. (Read glibc.vim with fdm=marker, and you will see). Well, I would like to read this comment after you have done with what you call stdc.vim. Till then, we will never see it. snip I find the above useful, and think it makes my coding more efficient. You don't. A matter of opinion like this usually has no right answer, and different people have different tastes. There's an option by which users who find it useful can use it, and those who don't find it useful need not use it. Freedom of choice is best, That's it. But what you actually did was to arbitrarily modify and break the original c.vim in favor of your preference. You deprived me of that freedom, didn't you? How dare you speak to me that way? You should have come up with a set of rewritten scripts and showed me how your scripts were as nice as you claimed before challenging my voluntary efferts for you. So long as c.vim works as it is, I don't care about what you are doing. GI
Re: Insert mode and arrow keys philosophy
On Tue, 20 Feb 2007 17:28:37 -0500, Gene Kwiecinski [EMAIL PROTECTED] wrote: Pretty much so. Early dumbterminals (think ADM-3a and similar critters) didn't have arrow keys, but they *did* go so far as to have little arrow marks on the keycaps themselves, underneath the letters, on -- you guessed it -- h/j/k/l. I remember using that sort of terminal. At one point I also had to use one where the escape key was so far from the rest of the keys that I almost had to get up and walk across the room to reach it, so for a long time I was accustomed to using Ctrl-[ in place of escape. As for getting into the correct habits, I don't think it matters. Use whatever works. If you're frequently moving between keyboards with different layouts then it helps to stick with the main key block as much as possible, but otherwise use what is the most comfortable. When editing a file I usually use hjkl for movement, but if all I'm doing is viewing a file then I rest my right hand next to the cursor keys and use them instead, as I find it to be a more relaxed position. If there is a vi philosophy it's a matter of being familiar with all the ways of moving around and being able to use them. For example, if you're on the word moving in the previous sentence and want to add something before the full stop then a vi master will type f.i or t.a to get there, while someone less advanced might hit w until they're in the right place, then i. The wrong way to do it is to hit the right arrow key over and over again or to reach for the mouse: that's the notepad way of working, and it tarnishes the soul. -- Matthew Winn
Problem with opening files from UNC
I'm using vim7 from my Total Commander under Windows XP with the following command line: vim70\gvim.exe --remote-tab-silent filename Whenever I try to open a file from a UNC path (e.g. \\Cd-server\HKR_304B\install.inf ), I get the attached message, roughly translated as Directory \CD-server\HKR_304B could not be found in 'cdpath' I'm not sure if this is a problem of vim. Trying the same on a random command line (cmd.exe) using absolute path to vim and UNC for the file, I get the file opened with no contents and vim claims, it's a new file. vim also hickups away one \ and claims the final path is \Cd-server\HKR_304B\install.inf. It would save the file now to localharddisc:\Cd-server\HKR_304B\install.inf, which is hardly what I tried to do :) Thanks. Thomas -- GPG-Key: tengelke.de/thomas_michael_engelke.asc
Re: Insert mode and arrow keys philosophy
Hi all, In my first reply to this topic, I had in mind the 'small' keyboards without arrows keys (I first started to code BASIC on an Apple 2 and the T arrows weren't on the keyboard). This is why I said although the use of h/j/k/l might have originated for other reasons back in the old 'vi' days. Thanks to Gene to confirm this and here is a picture of an ADM-3a keyboard: http://neil.franklin.ch/Computers/ADM-3A/IMG_0344.JPG. About the wrist movement that's just as bad when you hit ESC as when you use the arrow keys: just do the movement in slow motion for yourself: Hitting ESC is merely a little stretch with your hand (I use my middle finger to hit ESC) while you have to move your arm, elbow, forearm and hand to use the arrows keys. Don't forget either that in 'motion' mode you have tons of other shortcuts that will speed up your typing and avoid you to 'move' your hand to HOME, END, PG-UP and PG-DOWN etc. And as Raimon pointed out, ESC can be remapped to anything you want that could be easier for you to use. If it is true that at first some of the shortcuts are a bit 'unnatural' and could feel like you type twice more to reach the same results as with using the keyboard-provided keys, in the long term, once you've mastered motion in Vim, you'll realise that it's tuely priceless and it does speed up your typing. Good luck with it! All the best; Laurent
Re: Insert mode and arrow keys philosophy
Hi Laurent :) * vim [EMAIL PROTECTED] dixit: About the wrist movement that's just as bad when you hit ESC as when you use the arrow keys: just do the movement in slow motion for yourself: Yes, I've done it: the distance (in my keyboard at least) from touch typing position to ESC and arrows is more or less the same (measured from little finger to key). I have to move the same set of parts and muscles, only in different directions (northwest for ESC, southeast for arrows). Having the ESC key remapped DOES make a difference. I've tested a bit and I move a bit faster (not counting errors due to insist that 'j' is left instead of 'h') mapping ESC to 'jj' and using hjkl. Unfortunately, I still have problems using 'h' :( If it is true that at first some of the shortcuts are a bit 'unnatural' and could feel like you type twice more to reach the same results as with using the keyboard-provided keys, in the long term, once you've mastered motion in Vim, you'll realise that it's tuely priceless and it does speed up your typing. You must take into account another thing: in any other program you end up moving using the arrows and movement keys. So, doing movement without thinking in vim is difficult to me, because a whole lot other programs I use force me to use the arrows (no problem, because I don't type as much text there, so I can keep my hand on the arrows). Learning two sets of movements are not that difficult, but anyway *is* difficult. And of course, I'm not discussing that having the hand at touch typing position really improves performance at the keyboard: that's true. And blind typing does, too. The point I try to make is that ESC is a very bad key to switch modes, but a simple mapping solves that, really. Good luck with it! Thanks ;)) I'm still learning motion commands appart from hjkl, and probably I will make a plan: learn to move by chars (done), after that do it by words and later go to more sophisticated commands like 'f'. 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: tips project
Tom Purl wrote: I just checked the Google Code site (http://code.google.com/hosting/), and couldn't find a Vim or VimTips project. I'd try creating it, but I feel like someone more official to the project should do so. I think someone should do it before someone else takes the name (like some malicious Emacs user :), even if the tips conversion script isn't done yet. Otherwise, I'd be happy to do it and brag to my dorky friends about how integral my efforts are to the Vim project ;) Tom: Were you thinking of creating the conversion script? And copying the web site tips into the wiki? Does anyone know of some docs that might assist in this process? Does a wiki have a bulk import, or is it a matter of emulating what a person would type? John
Re: tips project
Tom Purl wrote: I just checked the Google Code site (http://code.google.com/hosting/), and couldn't find a Vim or VimTips project. I'd try creating it, but I feel like someone more official to the project should do so. I think someone should do it before someone else takes the name (like some malicious Emacs user :), even if the tips conversion script isn't done yet. Otherwise, I'd be happy to do it and brag to my dorky friends about how integral my efforts are to the Vim project ;) Tom: Were you thinking of creating the conversion script? And copying the web site tips into the wiki? Does anyone know of some docs that might assist in this process? Does a wiki have a bulk import, or is it a matter of emulating what a person would type? John
Re: Insert mode and arrow keys philosophy
On 2/21/07, DervishD [EMAIL PROTECTED] wrote: Hi Laurent :) Unfortunately, I still have problems using 'h' :( That's my biggest problem at the moment as well, as a blind typer i can't get used to it...oh, i think i just should stop whining and exercise more ;) -- Best regards, Pavel
Re: Insert mode and arrow keys philosophy
On 2/20/07, DervishD [EMAIL PROTECTED] wrote: Hi Laurent :) * vim [EMAIL PROTECTED] dixit: The idea behind using h/j/k/l is to avoid moving your hand/wrist too often while going back and forth between your keyboard and the arrow set (although the use of h/j/k/l might have originated for other reasons back in the old 'vi' days). Hitting ESC doesn't make your wrist move? I may have a very small hand, but I have to move my left hand for hitting ESC. I suspect that the main reason behind the hjkl (which is very unnatural for me, the arrows have a much better design with the inverted T at least IMHO) was that the first keyboards used to develop/use vi probably hadn't arrow keys, or they were very far at the right of the keyboard. The keyboard on which the original author of vi (Bill Joy) worked indeed did not have the arrow keys. See http://en.wikipedia.org/wiki/Vi for the layout and the name of the keyboard. Yakov
How to: display only the lines that have a matching pattern and fold /hide others.
Is there a way to display only the lines that match a search pattern and hide/fold others. Any help appreciated. Thanks .. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367
Re: How to: display only the lines that have a matching pattern and fold /hide others.
If you pattern happens to be word, then you can place cursor over the word and then press [I or [i. See also :h [I On 2/21/07, Muddassirali Mirzani [EMAIL PROTECTED] wrote: Is there a way to display only the lines that match a search pattern and hide/fold others. Any help appreciated. Thanks .. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367
Re: Insert mode and arrow k eys philosophyç
Hi Yakov :) * Yakov Lerner [EMAIL PROTECTED] dixit: On 2/20/07, DervishD [EMAIL PROTECTED] wrote: I suspect that the main reason behind the hjkl (which is very unnatural for me, the arrows have a much better design with the inverted T at least IMHO) was that the first keyboards used to develop/use vi probably hadn't arrow keys, or they were very far at the right of the keyboard. The keyboard on which the original author of vi (Bill Joy) worked indeed did not have the arrow keys. See http://en.wikipedia.org/wiki/Vi for the layout and the name of the keyboard. Oh, my loved Wikipedia ;) I forgot to take a look to see if the Vi entry had this kind of trivia data. Thanks for the link! 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: Insert mode and arrow keys philosophy
Hi Pavel :) * Pavel Shevaev [EMAIL PROTECTED] dixit: On 2/21/07, DervishD [EMAIL PROTECTED] wrote: Unfortunately, I still have problems using 'h' :( That's my biggest problem at the moment as well, as a blind typer i can't get used to it...oh, i think i just should stop whining and exercise more ;) Me too! ;)) My problem is not really blind typing or touch typing, I can do it. My problem is that my brain doesn't associate movement one key at the left. I have my fingers over jklñ (a spanish keyboard), so moving around with those four keys is OK to me, but hjkl is a bit more difficult. I suppose I can map them, but if I learn moving around using hjkl I want to learn it to be able to use it in any vim or vi I use. As you very intelligently said: I should stop whining and exercise more! ;))) 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: How to: display only the lines that have a matching pattern and fold /hide others.
On 2/21/07, Jeenu V [EMAIL PROTECTED] wrote: If you pattern happens to be word, then you can place cursor over the word and then press [I or [i. See also :h [I On 2/21/07, Muddassirali Mirzani [EMAIL PROTECTED] wrote: Is there a way to display only the lines that match a search pattern and hide/fold others. Any help appreciated. Thanks .. Hello, This is what I use: fu! ToggleFoldByCurrentSearchPattern() if !foldenable set foldenable set foldmethod=expr set foldexpr=getline(v:lnum)!~@/ :normal zM set foldmethod=manual echo zR to open all folds; zo top open 1 fold; zc to close 1 fold else set nofoldenable endif endfu :nmap F5 :call ToggleFoldByCurrentSearchPattern()cr Yakov
Re: How to: display only the lines that have a matching pattern and fold /hide others.
Is there a way to display only the lines that match a search pattern and hide/fold others. Any help appreciated. There are a number of ways to get the effect you are looking for. One might be: :set foldmethod=expr :set foldexpr=getline(v:lnum)!~'pattern' which will actually use folding to fold away any adjacent lines that don't match 'pattern'. However, if there aren't adjacent lines, the folding doesn't always show up (you see it in the fold-column if you have that showing, but it's not usually visible otherwise). You can tweak the 'foldminlines' setting and bump this back to 0 to get some visual indicator that a single line is folded: :set foldminlines=0 You could also do something like :match Comment /pattern/ which will make every line matching /pattern/ appear as if it's commented out. You can even take this a step further and make a highlighting target like hi Invisible termbg=black termfg=black and then use Invisible rather than Comment. This doesn't actually fold away the lines, but it just makes your non-hidden lines pop out visually. Another idea would be just to exploit the powerful undo abilities of Vim and simply :g/pattern/d to delete the lines you don't want to see, and then just use u to undo it. (or save beforehand, delete the lines, and then re-edit the file with :e!) Just a few ideas depending on the sort of behavior you want. HTH, -tim
Re: Problem with opening files from UNC
On 2/21/07, Thomas Michael Engelke [EMAIL PROTECTED] wrote: I'm using vim7 from my Total Commander under Windows XP with the following command line: vim70\gvim.exe --remote-tab-silent filename Whenever I try to open a file from a UNC path (e.g. \\Cd-server\HKR_304B\install.inf ), I get the attached message, roughly translated as Directory \CD-server\HKR_304B could not be found in 'cdpath' I'm not sure if this is a problem of vim. Trying the same on a random command line (cmd.exe) using absolute path to vim and UNC for the file, I get the file opened with no contents and vim claims, it's a new file. vim also hickups away one \ and claims the final path is \Cd-server\HKR_304B\install.inf. It would save the file now to localharddisc:\Cd-server\HKR_304B\install.inf, which is hardly what I tried to do :) 1. What happens if you double every backspace ? Like \\Cd-server\\HKR_304B\\install.inf ? 2. What happens if you change backslashes to slashes ? //Cd-server/HKR_304B/install.inf ? Yakov
Re: How to: display only the lines that have a matching pattern and fold /hide others.
* Muddassirali Mirzani [2007.02.21 07:30]: Is there a way to display only the lines that match a search pattern and hide/fold others. The foldutil plugin makes that very easy. I use it quite a bit. http://www.vim.org/scripts/script.php?script_id=158 -- JR
question about auto indenting tab width
lo there all. i found where i can set my tab stop in .vimrc to 4, but i can't seem to find where to set it to 4 when i have an auto indent. for example, in python, if i do a for x in range(20): it auto indents 8 spaces and i need it to auto indent 4 any tips are appreciated. thanks
Re: question about auto indenting tab width
Hi Shawn, I think set shiftwidth=4 is what you're looking for. HTH, Swaroop On 2/21/07, shawn bright [EMAIL PROTECTED] wrote: lo there all. i found where i can set my tab stop in .vimrc to 4, but i can't seem to find where to set it to 4 when i have an auto indent. for example, in python, if i do a for x in range(20): it auto indents 8 spaces and i need it to auto indent 4 any tips are appreciated. thanks -- If I had eight hours to chop down a tree, I'd spend six hours sharpening my axe -- Abraham Lincoln
Re: question about auto indenting tab width
shawn bright wrote: lo there all. i found where i can set my tab stop in .vimrc to 4, but i can't seem to find where to set it to 4 when i have an auto indent. for example, in python, if i do a for x in range(20): it auto indents 8 spaces and i need it to auto indent 4 any tips are appreciated. thanks No you don't. The Python language specification includes the requirements that indents are significant and that a one-hard-tab indent is equivalent to 8 spaces. If you ever find yourself facing a Python source with mixed space- and tab-indents, you'll ask yourself why it doesn't compile. Best regards, Tony. -- What this world needs is a good five-dollar plasma weapon.
Re: question about auto indenting tab width
ok, thanks, gents shawn On 2/21/07, A.J.Mechelynck [EMAIL PROTECTED] wrote: shawn bright wrote: lo there all. i found where i can set my tab stop in .vimrc to 4, but i can't seem to find where to set it to 4 when i have an auto indent. for example, in python, if i do a for x in range(20): it auto indents 8 spaces and i need it to auto indent 4 any tips are appreciated. thanks No you don't. The Python language specification includes the requirements that indents are significant and that a one-hard-tab indent is equivalent to 8 spaces. If you ever find yourself facing a Python source with mixed space- and tab-indents, you'll ask yourself why it doesn't compile. Best regards, Tony. -- What this world needs is a good five-dollar plasma weapon.
Re: tips project
Tom Purl wrote: I just checked the Google Code site (http://code.google.com/hosting/), and couldn't find a Vim or VimTips project. I'd try creating it, but I feel like someone more official to the project should do so. I think someone should do it before someone else takes the name (like some malicious Emacs user :), even if the tips conversion script isn't done yet. Otherwise, I'd be happy to do it and brag to my dorky friends about how integral my efforts are to the Vim project ;) Tom: Were you thinking of creating the conversion script? And copying the web site tips into the wiki? I haven't started something like that, but I would be happy to help with such an effort. I've written a few wiki conversion scripts before coincidentally. Does anyone know of some docs that might assist in this process? Does a wiki have a bulk import, or is it a matter of emulating what a person would type? Here's the basic process as I see it: 1. Scrape the tips from vim.org. We can either scrape the HTML itself, or pipe it through a tool like elinks to get formatted content (if that ends up being easier to parse). * I know that we can download a plain-text version of the tips as some sort of tarball, but I don't think that version includes comments. 2. Convert said content into a the wiki markup language that Google likes to use. We can do this a variety of ways. I'm partial to python, perl, and shell tools like sed and awk. * We probably will want to create one text file for each tip. 3. Post a sample of some converted tips on the wiki and get community sign-off (more or less). 4. Upload marked-up content to the Google wiki * Google usually provides some sort of RPC api for this sort of thing, but lacking that, a simple Perl script could do the job. Honestly, the only hard part here is step 2, and we can host our script(s) on Google code if we would like. If it's ok with you guys, I would be happy to set up a Vim Tips project on the Google code site and create a section for the conversion scripts. I know that Bram said that he didn't want to set up the VimTips project until we were ready convert content, but I think that it would be nice to set it up very soon for the following reasons: * We can host the scripts necessary to convert the tips there * We can post examples of how the tips might look so we can gain feedback * We can take the name before some nefarious person decides to Google-squat :) So yeah, what do you guys think? Thanks! Tom Purl
Re: tips project
On 2/21/07, Tom Purl [EMAIL PROTECTED] wrote: * We can host the scripts necessary to convert the tips there * We can post examples of how the tips might look so we can gain feedback * We can take the name before some nefarious person decides to Google-squat :) So yeah, what do you guys think? Tom, please do get started! I can pitch in some help. -- Swaroop
RE: tips project
2. Convert said content into a the wiki markup language that Google likes to use. We can do this a variety of ways. I'm partial to python, perl, and shell tools like sed and awk. I know nothing about the tips format as they exist now, nor Goggle's wiki markup language, but gimme a few docs pre- and post-converted manually, and I can 'lex' myself silly to give youse *exactly* what you need. I've converted a raw .xls file (*not* exported xml or anything) and converted that to html pages, that's how powerful 'lex' is. Let me know...
Solaris 10, VIM, and Tab completion
Hello all, I tried to get the automatic command completion to work under solaris 10, but for some simple reasons it does not seem to work. Whatever build option I try (athena/GTK/Motif), and even if I try to download the version compiled by SUN, I cannot do something as simple as :e /usr/inc[TAB]: it just replaces every tab with a dreaded ^I, instead of providing :e /usr/include like expected. This is not what I get from vim/gvim version 5 and 6. Is there something glaringly obvious I'm missing ? -- /Bruno
Re: Solaris 10, VIM, and Tab completion
Bruno Hivert wrote: Hello all, I tried to get the automatic command completion to work under solaris 10, but for some simple reasons it does not seem to work. Whatever build option I try (athena/GTK/Motif), and even if I try to download the version compiled by SUN, I cannot do something as simple as :e /usr/inc[TAB]: it just replaces every tab with a dreaded ^I, instead of providing :e /usr/include like expected. This is not what I get from vim/gvim version 5 and 6. Is there something glaringly obvious I'm missing ? Assuming /usr/include exists on your system, are you sure you're starting Vim in 'nocompatible' mode? IIRC, when 'compatible' the completion key is different (Ctrl-E maybe?) Try invoking Vim as vim -N -u NONE and see if you still have the same problem. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 52. You ask a plumber how much it would cost to replace the chair in front of your computer with a toilet.
Help needed to : Start on the line where I left when I opened the file last time
Hi, I just need some help on vim configuration. Let say the file is good.text. I open the file and goto 66 line and come out by typing :wq in escape mode. Now, when I open it again, my cursor is placed in line 0. I want it to be placed in line 66. I am facing this problem in my Solaris 10 x86 machine. The same thing is working fine in Linux. Can you please help me what configuration do I need to change to enable this feature. [I have tried Google search and could not get useful links]. Thank you Durga Prasad Looking for earth-friendly autos? Browse Top Cars by Green Rating at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
Re: Help needed to : Start on the line where I left when I opened the file last time
Let say the file is good.text. I open the file and goto 66 line and come out by typing :wq in escape mode. Now, when I open it again, my cursor is placed in line 0. I want it to be placed in line 66. Can you please help me what configuration do I need to change to enable this feature. [I have tried Google search and could not get useful links]. Maybe http://tech.groups.yahoo.com/group/vim/message/77644 can help you. HTH, Swaroop
Re: Help needed to : Start on the line where I left when I opened the file last time
Hi Swaroop, Thank you for the reply. I have tried the option suggested by you. But unfortunately it is not working. After reading some documentation, I came to know that we can do that by typing ` [backquote doublequote ]. But I want to do this automatically at the time when I open the file. Can you please help regarding this? - Durga Prasad Jammula webpage : http://durgaprasad.wordpress.com - Original Message From: Swaroop C H [EMAIL PROTECTED] To: durgaprasad jammula [EMAIL PROTECTED] Cc: vim@vim.org Sent: Wednesday, February 21, 2007 11:07:25 PM Subject: Re: Help needed to : Start on the line where I left when I opened the file last time Let say the file is good.text. I open the file and goto 66 line and come out by typing :wq in escape mode. Now, when I open it again, my cursor is placed in line 0. I want it to be placed in line 66. Can you please help me what configuration do I need to change to enable this feature. [I have tried Google search and could not get useful links]. Maybe http://tech.groups.yahoo.com/group/vim/message/77644 can help you. HTH, Swaroop It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
Re: Help needed to : Start on the line where I left when I opened the file last time
durgaprasad jammula wrote: Hi, I just need some help on vim configuration. Let say the file is good.text. I open the file and goto 66 line and come out by typing :wq in escape mode. Now, when I open it again, my cursor is placed in line 0. I want it to be placed in line 66. I am facing this problem in my Solaris 10 x86 machine. The same thing is working fine in Linux. Can you please help me what configuration do I need to change to enable this feature. [I have tried Google search and could not get useful links]. Thank you Durga Prasad There is an autocommand near the end of the vimrc_example which does just that; so adding runtime vimrc_example.vim near the top of your vimrc should be enough. Best regards, Tony. -- Puns are little plays on words that a certain breed of person loves to spring on you and then look at you in a certain self-satisfied way to indicate that he thinks that you must think that he is by far the cleverest person on Earth now that Benjamin Franklin is dead, when in fact what you are thinking is that if this person ever ends up in a lifeboat, the other passengers will hurl him overboard by the end of the first day even if they have plenty of food and water. -- Dave Barry, Why Humor is Funny
Re: Help needed to : Start on the line where I left when I opened the file last time
durgaprasad jammula wrote: I just need some help on vim configuration. Let say the file is good.text. I open the file and goto 66 line and come out by typing :wq in escape mode. Now, when I open it again, my cursor is placed in line 0. I want it to be placed in line 66. I am facing this problem in my Solaris 10 x86 machine. The same thing is working fine in Linux. Can you please help me what configuration do I need to change to enable this feature. [I have tried Google search and could not get useful links]. Read http://vim.sourceforge.net/tips/tip.php?tip_id=80 , Restore cursor to file position in previous editing session. HTH, Chip Campbell
Re: Help needed to : Start on the line where I left when I opened the file last time
Hi,
I have solved this problem myself.
I have taken the following from my suse linux /etc/vimrc and added the same in
my Solaris .vimrc file. Now, it is working fine.
if has(autocmd)
autocmd BufReadPost *
\ if line('\) 0 line('\) = line($) |
\ exe normal g`\ |
\ endif
endif
Thank you for your help.
-
Durga Prasad Jammula
webpage : http://durgaprasad.wordpress.com
- Original Message
From: durgaprasad jammula [EMAIL PROTECTED]
To: Swaroop C H [EMAIL PROTECTED]
Cc: vim@vim.org
Sent: Wednesday, February 21, 2007 11:25:27 PM
Subject: Re: Help needed to : Start on the line where I left when I opened the
file last time
Hi Swaroop,
Thank you for the reply.
I have tried the option suggested by you. But unfortunately it is not
working. After reading some documentation, I came to know that we can do that
by typing ` [backquote doublequote ]. But I want to do this automatically
at the time when I open the file.
Can you please help regarding this?
-
Durga Prasad Jammula
webpage : http://durgaprasad.wordpress.com
- Original Message
From: Swaroop C H [EMAIL PROTECTED]
To: durgaprasad jammula [EMAIL PROTECTED]
Cc: vim@vim.org
Sent: Wednesday, February 21, 2007 11:07:25 PM
Subject: Re: Help needed to : Start on the line where I left when I opened the
file last time
Let say the file is good.text. I open the file and goto 66 line and come
out by typing :wq in escape mode.
Now, when I open it again, my cursor is placed in line 0. I want it to be
placed in line 66.
Can you please help me what configuration do I need to change to enable
this feature. [I have tried Google search and could not get useful links].
Maybe http://tech.groups.yahoo.com/group/vim/message/77644 can help you.
HTH,
Swaroop
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail
RE: tips project
Ok everyone, the project's created: * http://code.google.com/p/vimtips/ Hooray! The next step is to see some conversion script ideas. If you're the type of person who can write a script like this in 15 minutes, then by all means do so and send it to me. Otherwise, we can discuss it on the mailing list unless people think its too OT. So if you're interested in helping, start scraping vim.org/tips and let us know what works for you. Thanks! Tom Purl
RE: Help needed to : Start on the line where I left when I opened the file last time
Read http://vim.sourceforge.net/tips/tip.php?tip_id=80 , Restore cursor to file position in previous editing session. This tip does most of what I want thanks to the additional notes section. I have realized, this only returns us to the row we were on. Does anyone know if it is also possible to return the the row and column position? I am not sure if the column position is also stored within the viminfo file. TIA, Dave
RE: :wq vs ZZ
I wonder why some people use :wq instead of ZZ. Maybe they just don't know about ZZ? Obviously that's not the case with Bram. I added the following to my vimrc: Exit VIM, but prompt if any changes to save nnoremap ZX :conf qaCR I routinely have many files open at the sametime (hidden is set). So when I close Vim, I press ZX. Vim will prompt me for each and every buffer that was modified if I want to save. I like the prompt since I can decide quickly whether I want the file saved or not and not have to issue any further commands to find the next modified buffer. HTH, Dave
Mapping to search Google Code
Hello, I seem to be oblivious to what I am doing wrong. I have the following mapping I would like to execute from vim: nmap F2 :!/usr/bin/firefox 'http://www.google.com/codesearch?hl=enq=+'cword I can execute the following from ex, but I am missing something from the mapping, does anyone have an ideas? Thanks in advance, Sean
Re: Help needed to : Start on the line where I left when I opened the file last time
David Fishburn wrote:
Read http://vim.sourceforge.net/tips/tip.php?tip_id=80 ,
Restore cursor to file position in previous editing session.
This tip does most of what I want thanks to the additional notes section.
I have realized, this only returns us to the row we were on. Does anyone
know if it is also possible to return the the row and column position?
I am not sure if the column position is also stored within the viminfo file.
TIA,
Dave
The row and column are both stored as part of the mark. Just make sure you
execute g` where the first character after the g is a backtick. The
vimrc_example.vim does it as follows:
When editing a file, always jump to the last known cursor position.
Don't do it when the position is invalid or when inside an event handler
(happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line('\) 0 line('\) = line($) |
\ exe normal! g`\ |
\ endif
Best regards,
Tony.
--
Honesty pays, but it doesn't seem to pay enough to suit some people.
-- F. M. Hubbard
Re: Mapping to search Google Code
On 2007-02-21, Sean Hubbell [EMAIL PROTECTED] wrote: Hello, I seem to be oblivious to what I am doing wrong. I have the following mapping I would like to execute from vim: nmap F2 :!/usr/bin/firefox 'http://www.google.com/codesearch?hl=enq=+'cword I can execute the following from ex, but I am missing something from the mapping, does anyone have an ideas? 1. Get rid of the double-quotes (). They make the argument appear to the shell to be part of the command name. 2. Add CR to the end. nmap F2 :!/usr/bin/firefox 'http://www.google.com/codesearch?hl=enq=+'cwordCR HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division | Spokane, Washington, USA
Re: Insert mode and arrow keys philosophy
Pavel Shevaev wrote: On 2/21/07, DervishD [EMAIL PROTECTED] wrote: Hi Laurent :) Unfortunately, I still have problems using 'h' :( That's my biggest problem at the moment as well, as a blind typer i can't get used to it...oh, i think i just should stop whining and exercise more ;) I think I understand the issue; one sort of expects to use a different finger for each motion. I've sort of gotten used to shifting my right hand one key to the left when I intend to move the cursor, thus I get right index finger == h right middle finger == j right ring finger == k right little finger == l Of course, that means whenever I use OtherEditors, such as with certain mail clients, I end up with jjkkllhhh#)*()* sequences :O . Regards, Chip Campbell
Re: tips project
On 2/21/07, Tom Purl [EMAIL PROTECTED] wrote: The next step is to see some conversion script ideas. If you're the type of person who can write a script like this in 15 minutes, then by all means do so and send it to me. Otherwise, we can discuss it on the mailing list unless people think its too OT. So if you're interested in helping, start scraping vim.org/tips and let us know what works for you. I've thrown a quick script together, it's not perfect but it gets all the basic details such as the tip number, author, version and content : http://pastebin.com/886040 We could enhance it to fetch additional notes as well and then just loop it from 1 to 1504 I guess :) -- Swaroop
hello again
hello again from the newbie. i was wondering if there is an option to use spaces instead of tabs in my indenting and tabbing, especially when in python. This wouldn't be an issue, but i have written most of my stuff in JEdit using soft tabs and now when i mess with one of the files in vim, i get problems about indentation not being right. just wondering. and thanks shawn
Re: Solaris 10, VIM, and Tab completion
OK, thanks, it did the trick: I did wipe .vimrc since I wanted to start fresh, hence my problem. But at least, now I know for what to search in the documentation ;-) /B 2007/2/21, A.J.Mechelynck [EMAIL PROTECTED]: Bruno Hivert wrote: Hello all, I tried to get the automatic command completion to work under solaris 10, but for some simple reasons it does not seem to work. Whatever build option I try (athena/GTK/Motif), and even if I try to download the version compiled by SUN, I cannot do something as simple as :e /usr/inc[TAB]: it just replaces every tab with a dreaded ^I, instead of providing :e /usr/include like expected. This is not what I get from vim/gvim version 5 and 6. Is there something glaringly obvious I'm missing ? Assuming /usr/include exists on your system, are you sure you're starting Vim in 'nocompatible' mode? IIRC, when 'compatible' the completion key is different (Ctrl-E maybe?) Try invoking Vim as vim -N -u NONE and see if you still have the same problem. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 52. You ask a plumber how much it would cost to replace the chair in front of your computer with a toilet. -- /Bruno Hivert I have gone to look for myself, if I should return, before I get back, keep me here.
RE: hello again
Hello. Look up :help on 'ts' (with the single quotes), 'sts', 'sw' and 'et'. Basically, you want to :set 'tabstop' to 8, 'shiftwidth' to whatever you like to indent and 'expandtab' to on. This will take care of new code that you write. To convert existing tab-based indents, set 'tabstop' to the actual indent (4, for example), type :retab! to retab the whole thing and then set tabstop back to 8. At least, that's how I play this game :) Hope this help, Salman. -Original Message- From: shawn bright [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 2:44 PM To: vimlist Subject: hello again hello again from the newbie. i was wondering if there is an option to use spaces instead of tabs in my indenting and tabbing, especially when in python. This wouldn't be an issue, but i have written most of my stuff in JEdit using soft tabs and now when i mess with one of the files in vim, i get problems about indentation not being right. just wondering. and thanks shawn
Re: hello again
i was wondering if there is an option to use spaces instead of tabs in my indenting and tabbing, especially when in python. You can set the 'expandtab' option to behave as you like. You may also want to tweak your 'ts' and 'sw' options to act in accord. Thus, you may want to do :set et ts=4 sw=4 If you want to convert from one format to the other, you can also use the :retab command. You can read more at :help 'et' :he 'ts' :he 'sw' :he :retab HTH, -tim
Spaces vs. tabs (Was: hello again)
shawn bright wrote: hello again from the newbie. Please use a more descriptive Subject line: I almost threw your mail away as spam. i was wondering if there is an option to use spaces instead of tabs in my indenting and tabbing, especially when in python. Sure. See: :help 'expandtab' :help :retab This wouldn't be an issue, but i have written most of my stuff in JEdit using soft tabs and now when i mess with one of the files in vim, i get problems about indentation not being right. just wondering. and thanks shawn Best regards, Tony. -- Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!!
Re: tips project
On 2/21/07, Tom Purl [EMAIL PROTECTED] wrote: The next step is to see some conversion script ideas. If you're the type of person who can write a script like this in 15 minutes, then by all means do so and send it to me. Otherwise, we can discuss it on the mailing list unless people think its too OT. So if you're interested in helping, start scraping vim.org/tips and let us know what works for you. I've thrown a quick script together, it's not perfect but it gets all the basic details such as the tip number, author, version and content : http://pastebin.com/886040 We could enhance it to fetch additional notes as well and then just loop it from 1 to 1504 I guess :) Fantastic. I can't look at this script until tonight, but I'll be sure to do so. Swaroop, could you please convert a few tips using your script and them post them on the wiki? I would love to see the final output. Also, I just wanted to say that it looks like we won't have to write any sort of upload script. The Google wiki is built on top of an svn repository, so we'll just have to check in our converted files to publish them. I think that this feature will be especially nice if we find ourselves doing the conversion multiple times. Thanks again Swaroop! Tom Purl
Re: surround.vim in AsNeeded
Bill McCarthy wrote: BTW, as an enhancement request, could AN be enhanced to look for leadermap when it fails to find charmap? That is, if I want to load the align maps: AN \abox doesn't work. I would need to type: AN leaderabox If you happen to have (as an example) let mapleader= ; in your .vimrc, did you know that :AN ;abox would load AlignMaps.vim? So you don't actually need to type leader, just the leader you're actually currently using. Regards, Chip Campbell
hlsearch on dark back ground
consider $ cat file.c /* kamaraju * kamaraju * kamaraju */ kamaraju I use konsole with black background and white foreground on Debian Etch, vim 7.0.122 $ cat .vimrc set hls syn enable With this configuration, if I do set background=dark and search for the word kamaraju, then text highlighted inside the comments is very difficult to read. More over it is very difficult to see the cursor (when it is inside the comments and on the word kamaraju) position. Is there any way to use background=dark and hls together and edit a C file (which includes comments) efficiently? thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/
Re: surround.vim in AsNeeded
On Wed 21-Feb-07 1:56pm -0600, Charles E Campbell Jr wrote: Bill McCarthy wrote: BTW, as an enhancement request, could AN be enhanced to look for leadermap when it fails to find charmap? That is, if I want to load the align maps: AN \abox doesn't work. I would need to type: AN leaderabox If you happen to have (as an example) let mapleader= ; in your .vimrc, did you know that :AN ;abox would load AlignMaps.vim? So you don't actually need to type leader, just the leader you're actually currently using. Yes, I understand that if the user has explicitly defined g:mapleader in their vimrc, then that works. However, if the user lets Vim default to '\' then it doesn't work the way your code is written. One can certainly add to their vimrc: let g:mapleader = '\' and now: :AN \abox works - which it doesn't now as I mentioned above. But that won't work when running with -u NORC. Your fix notes specify: v3 May 19, 2004 : * bugfix: now works correctly when mapleader wasn't set by user explicitly so perhaps you fixed this in the past and something is preventing your fix from working today. You could easily make default behavior work by adding, right after your check for previous load, code such as: if !exists(g:mapleader) let g:mapleader = '\' endif Which would allow users who use Vim's default behavior, without explicitly setting mapleader, to do: :AN \abox -- Best regards, Bill
Re: hlsearch on dark back ground
Kamaraju S Kusumanchi wrote: consider $ cat file.c /* kamaraju * kamaraju * kamaraju */ kamaraju I use konsole with black background and white foreground on Debian Etch, vim 7.0.122 $ cat .vimrc set hls syn enable With this configuration, if I do set background=dark and search for the word kamaraju, then text highlighted inside the comments is very difficult to read. More over it is very difficult to see the cursor (when it is inside the comments and on the word kamaraju) position. Is there any way to use background=dark and hls together and edit a C file (which includes comments) efficiently? thanks raju If you don't set 'background' at all, what is the default? I would expect it to be set to dark in your kind of console terminal. If it isn't try changing your vimrc to set hls bg=dark sy on or even to set nocompatible if ! has(gui_running) set bg=dark endif runtime vimrc_example.vim set hls so that (in both cases) the 'background' option is set correctly before turning syntax highlighting on. When I use Vim on /dev/tty (pure-text console, default colors lightgrey on black), 'background' is set to dark by default, and I get lightgrey on brown as 'hlsearch' colours. In konsole, 'bg' is set to light by default, even in a lightgrey-on-black scheme. If I set it to dark I still get Search highlight in lightgrey on brown. If that doesn't suit you, you can look into the colorschemes that come with Vim (in $VIMRUNTIME/colors), those available at vim-online, or you can write your own. It isn't hard: I'm appending a simple example. See :help :colorscheme :view $VIMRUNTIME/colors/README.txt Best regards, Tony. -- The New Testament offers the basis for modern computer coding theory, in the form of an affirmation of the binary number system. But let your communication be Yea, yea; nay, nay: for whatsoever is more than these cometh of evil. -- Matthew 5:37 Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Sep 06 This is almost the default color scheme. It doesn't define the Normal highlighting, it uses whatever the colors used to be. Only the few highlight groups named below are defined; the rest (most of them) are left at their compiled-in default settings. Set 'background' back to the default. The value can't always be estimated and is then guessed. hi clear Normal set bg Remove all existing highlighting and set the defaults. hi clear Load the syntax highlighting defaults, if it's enabled. if exists(syntax_on) syntax reset endif Set our own highlighting settings hi SpecialKey guibg=NONE hi PyjamaEven ctermbg=greygui=NONEguibg=#FFD8FF white on red is not always distinct in the GUI: use black on red then hi Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error show cursor line/column (if enabled) in very light grey in the GUI, underlined in the console if has(gui_running) hi clear CursorLine hi CursorLine guibg=#F4F4F4 endif hi clear CursorColumn hi link CursorColumn CursorLine do not make help bars and stars invisible hi clear helpBar hi link helpBarhelpHyperTextJump hi clear helpStar hi link helpStar helpHyperTextEntry the following were forgotten in the syntax/vim.vim (and ended up cleared) hi clear vimVar hi link vimVar Identifier hi clear vimGroupName hi link vimGroupName vimGroup hi clear vimHiClear hi link vimHiClear vimHighlight display the status line of the active window in a distinctive color: bold black on bright red in the GUI, white on green in the console (where the bg is never bright, and dark red is sometimes an ugly sort of reddish brown). hi StatusLine gui=NONE,bold guibg=red guifg=black \ cterm=NONE,bold ctermbg=green ctermfg=white make the status line bold-reverse (but BW) for inactive windows hi StatusLineNC gui=reverse,bold \ cterm=reverse,bold define colors for the tab line: file name of unselected tab hi TabLine gui=NONEguibg=#EE guifg=black \ cterm=NONE,bold ctermbg=lightgrey ctermfg=white file name of selected tab (GUI default is bold black on white) hi TabLineSel cterm=NONE,bold ctermbg=green ctermfg=white fillup and tab-delete X at right hi TabLineFill gui=NONE,bold guibg=#CC guifg=#99 \ cterm=NONE ctermbg=lightgrey ctermfg=red tab and file number 1:2/3 (meaning tab 1: window 2 of 3) for selected tab hi
Re: hlsearch on dark back ground
A.J.Mechelynck wrote: Kamaraju S Kusumanchi wrote: consider $ cat file.c /* kamaraju * kamaraju * kamaraju */ kamaraju I use konsole with black background and white foreground on Debian Etch, vim 7.0.122 $ cat .vimrc set hls syn enable With this configuration, if I do set background=dark and search for the word kamaraju, then text highlighted inside the comments is very difficult to read. More over it is very difficult to see the cursor (when it is inside the comments and on the word kamaraju) position. Is there any way to use background=dark and hls together and edit a C file (which includes comments) efficiently? thanks raju If you don't set 'background' at all, what is the default? I would expect it to be set to dark in your kind of console terminal. If it isn't try changing your vimrc to set hls bg=dark sy on Ok. I set my .vimrc as above. Now if I open a file in konsole, or in xterm the :set bg? shows that the background is set to dark. However, in konsole the highlighted string is shown in brown background. where as in xterm -bg black -fg white, the highlighted string is shown in yellow background. Why are they different when all the config files are same? Can I get xterm's colors/behavior in konsole? thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/
Re: hlsearch on dark back ground
Kamaraju S Kusumanchi wrote: A.J.Mechelynck wrote: Kamaraju S Kusumanchi wrote: consider $ cat file.c /* kamaraju * kamaraju * kamaraju */ kamaraju I use konsole with black background and white foreground on Debian Etch, vim 7.0.122 $ cat .vimrc set hls syn enable With this configuration, if I do set background=dark and search for the word kamaraju, then text highlighted inside the comments is very difficult to read. More over it is very difficult to see the cursor (when it is inside the comments and on the word kamaraju) position. Is there any way to use background=dark and hls together and edit a C file (which includes comments) efficiently? thanks raju If you don't set 'background' at all, what is the default? I would expect it to be set to dark in your kind of console terminal. If it isn't try changing your vimrc to set hls bg=dark sy on Ok. I set my .vimrc as above. Now if I open a file in konsole, or in xterm the :set bg? shows that the background is set to dark. However, in konsole the highlighted string is shown in brown background. where as in xterm -bg black -fg white, the highlighted string is shown in yellow background. Why are they different when all the config files are same? Can I get xterm's colors/behavior in konsole? thanks raju Most console terminals have only 8 background colours, 16 foreground colours. Some have 16 of both. Non-bright yellow (including every background yellow) is usually shown as brown. Whether you can or cannot change the terminal's colour palette is outside the realm of Vim. Best regards, Tony. -- hundred-and-one symptoms of being an internet addict: 54. You start tilting your head sideways to smile.
Re: hlsearch on dark back ground
A.J.Mechelynck wrote: Most console terminals have only 8 background colours, 16 foreground colours. Some have 16 of both. Non-bright yellow (including every background yellow) is usually shown as brown. Whether you can or cannot change the terminal's colour palette is outside the realm of Vim. Best regards, Tony. How can I find out how many colors the konsole is using, how many colors the xterm is using? Any idea? I am using Debian Etch. raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/
Re: hlsearch on dark back ground
Kamaraju S Kusumanchi wrote: A.J.Mechelynck wrote: Most console terminals have only 8 background colours, 16 foreground colours. Some have 16 of both. Non-bright yellow (including every background yellow) is usually shown as brown. Whether you can or cannot change the terminal's colour palette is outside the realm of Vim. Best regards, Tony. How can I find out how many colors the konsole is using, how many colors the xterm is using? Any idea? I am using Debian Etch. raju :set t_Co? will tell you how many colours Vim thinks the terminal has. I'm not sure how it distinguishes terminals with 8 background and 16 foreground colours. There might also be an X.org utility and/or a kde utility, but I don't know about them. See also :help termcap-colors :help termcap-options Best regards, Tony. -- The faster we go, the rounder we get. -- The Grateful Dead
Re: repetition of a map
On 2/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can someone assist with the following: How do I get a map to repeat a certain number of times? e.g., given a simple map like: :map = 0Ea ;^[j I'd like to be able to do something along the lines of 95. to get the map to repeat 95 times. What I find is that the 'j' key in the map is not being implemented. I have experimented a bit with using parentheses inside the map to group commands but that hasn't panned out. I'm sure a simple vimscript would do this, but I haven't yet ventured into that domain and would like to find out what I'm missing here re: mapping. You can achieve iwhat you want with somle simpe s/// command + range. Does the following simple s/// command do what you want ?: .,.+94s/\/ ;/ Yakov
Re: repetition of a map
Hello, On 2/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can someone assist with the following: How do I get a map to repeat a certain number of times? e.g., given a simple map like: :map = 0Ea ;^[j I'd like to be able to do something along the lines of 95. to get the map to repeat 95 times. What I find is that the 'j' key in the map is not being implemented. I have experimented a bit with using parentheses inside the map to group commands but that hasn't panned out. I'm sure a simple vimscript would do this, but I haven't yet ventured into that domain and would like to find out what I'm missing here re: mapping. You can refer to the Vim keymap tutorial about specifying a count to a map: http://www.geocities.com/yegappan/vim_keymap.html The section that describes specifying a count to a map is below: --- When a count is entered before invoking a map, the map will not be repeated the specified number of 'count' times. Instead the count will be prepended to the key sequence executed for the map. For example, assume you have mapped F7 to move the cursor by 5 characters to the right: :nnoremap F7 5l If you invoke the above map with a count of 2 using 2F7, the cursor will not be moved 10 characters to the right. Instead, the cursor will be moved 25 characters to the right. This is because the count 2 is prepended to the 5 in the map. You have to use the @= expression register to repeat the map by the specified number of times. For example, change the above map command to: :nnoremap F7 @='5l'CR Now, if you use 2F7, the cursor will be moved 10 characters to the right. If you are invoking a function from a normal mode map, then the count will be supplied to the function. If the function doesn't accept a range, then this will result in an error. Example: function! Myfunc() Function that doesn't accept a range endfunction :nnoremap _w :call Myfunc()CR If you specify a count to _w, then this will result in an error message. To remedy this problem you can use the C-U command to erase the text on the command-line before invoking the function as shown below: :nnoremap _w :C-Ucall Myfunc()CR If you want your map to accept a range, then you have to modify the function to accept a range as shown below: function! Myfunc() range echo 'range = ' . a:firstline . ',' . a:lastline endfunction :nnoremap _w :call Myfunc()CR Now you can pass a count to the _w map. The a:firstline and a:lastline variables in the function refer to the starting line number and ending line number of the range supplied to the function. The default is the current line number. You can also use the internal v:count and v:count1 variables to get the count specified to the last normal mode command or map. Example: :nnoremap C-W :C-Ucall Myfunc()CR function! Myfunc() let c = v:count Do something count number of times endfunction The v:count1 variable returns 1 if a count is not specified to the normal mode command/map. --- - Yegappan
Re: entering copied text into command mode?
Hi Gene - sorry for the delay in replying - On Feb 16, 2007, at 8:11 AM, Gene Kwiecinski wrote: I often find myself copy/pasting via my GUI text that I might have on the screen, and then pasting it into the command to be performed - is there any way to cut/paste text into the command area when I have it highlighted with just the keyboard? I'm not quite sure what you mean, but if it's what I think it is, sure. If I want to, eg, globally delete paths from links to images and such in html source, eg, to turn img src=big_honking_pile_of_hooey_files/image.jpg into just img src=image.jpg , then I'd want to execute :[EMAIL PROTECTED]/@@g as a command, so I'd just 'v' the pathname to highlight it, control-insert it to yank it into the clipboard(?), then do :s@sh-ins@@g ie, use shift-insert to paste the path directly into the command. is that any help, or were you referring to something different? Unless I'm mistaken, these are OS-specific copy/paste commands, correct? I don't have an 'insert' key on my keyboard, but I was hoping for something built into vim, where it has it's own copy/paste buffer that it can use in the command mode. thanks! -lev
Re: entering copied text into command mode?
Lev Lvovsky wrote: Hi Gene - sorry for the delay in replying - On Feb 16, 2007, at 8:11 AM, Gene Kwiecinski wrote: I often find myself copy/pasting via my GUI text that I might have on the screen, and then pasting it into the command to be performed - is there any way to cut/paste text into the command area when I have it highlighted with just the keyboard? I'm not quite sure what you mean, but if it's what I think it is, sure. If I want to, eg, globally delete paths from links to images and such in html source, eg, to turn img src=big_honking_pile_of_hooey_files/image.jpg into just img src=image.jpg , then I'd want to execute :[EMAIL PROTECTED]/@@g as a command, so I'd just 'v' the pathname to highlight it, control-insert it to yank it into the clipboard(?), then do :s@sh-ins@@g ie, use shift-insert to paste the path directly into the command. is that any help, or were you referring to something different? Unless I'm mistaken, these are OS-specific copy/paste commands, correct? I don't have an 'insert' key on my keyboard, but I was hoping for something built into vim, where it has it's own copy/paste buffer that it can use in the command mode. thanks! -lev The clipboard is known in Vim as the + register. Start characterwise visual with v then extend it by moving the cursor Yank with y Yank to the clipboard with +y Paste (put) before the cursor with P -- after the cursor with p Prefix it with + to use the system clipboard. In Vim you don't need to use the clipboard unless you want to paste to/from another program. See the other replies in this thread for details. See also :help change.txt Best regards, Tony. -- Stay away from hurricanes for a while.
[Fwd: Re: hlsearch on dark back ground]
I got this privately by mistake. Konstantin: next time, please use Reply to All (or Reply to List if your mailer has it), unless you're straying off-topic. Best regards, Tony. Original Message Subject: Re: hlsearch on dark back ground Date: Thu, 22 Feb 2007 01:19:08 +0100 From: Konstantin Baierer [EMAIL PROTECTED] To: A.J.Mechelynck [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Hey Kamaraju, To test your terminal's colouring abilities, try this little perl script by Todd Larason (http://www.cs.rice.edu/~scrosby/software/tf256color/src/256colors2.pl). I don't know which terminal emulator you use, but if it's xterm or konsole, it supports 256 colours. In Konsole, you have to set your terminal type to xterm-256color and add set t_Co=256 in your .vimrc. I did that just yesterday and it worked for me. Also, you could simply change the highlight background colour in either the apropriate colour file or your .vimrc. good luck. konsti Am Mittwoch, 21. Februar 2007 23:51 schrieben Sie: Kamaraju S Kusumanchi wrote: A.J.Mechelynck wrote: Most console terminals have only 8 background colours, 16 foreground colours. Some have 16 of both. Non-bright yellow (including every background yellow) is usually shown as brown. Whether you can or cannot change the terminal's colour palette is outside the realm of Vim. Best regards, Tony. How can I find out how many colors the konsole is using, how many colors the xterm is using? Any idea? I am using Debian Etch. raju :set t_Co? will tell you how many colours Vim thinks the terminal has. I'm not sure how it distinguishes terminals with 8 background and 16 foreground colours. There might also be an X.org utility and/or a kde utility, but I don't know about them. See also :help termcap-colors :help termcap-options Best regards, Tony.
Re: entering copied text into command mode?
On Feb 21, 2007, at 4:15 PM, A.J.Mechelynck wrote: [snip very useful advice] See the other replies in this thread for details. blargh! I only saw the one reply from Gene (sent to me directly), and completely missed the long thread actually going on in my vim folder - reading up on that now. thanks for the help, this is exactly what I was looking for! -lev
Re: Help needed on pt_BR spell checking
Not much news, but I'd like you to know I didn't give up on the pt dictionary. There are two pt_PT dictionaries, and I'm negotiating with them which will be included. Is anyone from Portugal reading this? I still don't get how are the sug files created. If I run the mkspell command myself I end up with only a spl file... Leonardo Fontenelle 2007/2/17, Leonardo Fontenelle [EMAIL PROTECTED]: You are right. It seems that gentoo is distributing the source code without the runtime/spell dir. It took me your e-mail to prompt me to grab the tarball from the ftp site, because usually the tarballs gentoo distribute are the same as the original. I'll play with it and write back when I get something. Thanks for your assistance! Leonardo Fontenelle 2007/2/16, Bram Moolenaar [EMAIL PROTECTED]: You can find the spell *.diff files in the Unix archive and the PC runtime archive.
Re: [Fwd: Re: hlsearch on dark back ground]
Hey Kamaraju, To test your terminal's colouring abilities, try this little perl script by Todd Larason (http://www.cs.rice.edu/~scrosby/software/tf256color/src/256colors2.pl). Thanks for the script. I don't know which terminal emulator you use, but if it's xterm or konsole, it supports 256 colours. In Konsole, you have to set your terminal type to xterm-256color and add set t_Co=256 in your .vimrc. I am using konsole. There I have $ echo $TERM xterm This is the default and I did not change it. With this setting, when I did :set t_Co=256 in .vimrc, I get yellow background for searched items. Cool! One problem solved. thanks raju -- Kamaraju S Kusumanchi http://www.people.cornell.edu/pages/kk288/ http://malayamaarutham.blogspot.com/
Re: hlsearch on dark back ground
On Wed, Feb 21, 2007 at 05:25:41PM EST, Kamaraju S Kusumanchi wrote: A.J.Mechelynck wrote: Most console terminals have only 8 background colours, 16 foreground colours. Some have 16 of both. Non-bright yellow (including every background yellow) is usually shown as brown. Whether you can or cannot change the terminal's colour palette is outside the realm of Vim. Best regards, Tony. How can I find out how many colors the konsole is using, how many colors the xterm is using? Any idea? I am using Debian Etch. $ strings $(which xterm) | grep ^color[0-9] Thanks, cga
Re: Help needed on pt_BR spell checking
Leonardo Fontenelle wrote: Not much news, but I'd like you to know I didn't give up on the pt dictionary. There are two pt_PT dictionaries, and I'm negotiating with them which will be included. Is anyone from Portugal reading this? I still don't get how are the sug files created. If I run the mkspell command myself I end up with only a spl file... :help spell-NOSUGFILE explains how you get one (and how to avoid that if you don't want it). You need to define soundfolding. Without that Vim doesn't need a .sug file. -- Hit any key to continue is very confusing when you have two keyboards. /// 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: Marking an undo-block before ^U in insert-mode
Hi,
On 2/20/07, A.J.Mechelynck [EMAIL PROTECTED] wrote:
Tim Chase wrote:
:help nop
but rather is being interpreted as less-than, en, oh, pee,
greater-than and the en portion of it is trying to look for the
last regexp.
Try (untested):
:inoremap c-u c-oltNopc-u
This is the behavior I _see_, but that I understood having nop
should send a no-op keycode. Thus, I had understood the mapping
:inoremap c-u c-onopc-u
would act like typing control+O [no-op character that clears the
control-O (insert) mode] control+U. This is the behavior I had expected.
What you propose would act like typing control+O less-than en oh pee
greater-than control+U. This is the behavior I see.
The i_CTRL-G_u did what I wanted. Thanks though,
-tim
A little experimenting shows that Nop is only interpreted as do-nothing when
it is the _whole_ {rhs} of the mapping, as in
:map F6 Nop
Yes. In the Vim source code, the following code snippet is used by
the do_map() function in the getchar.c file:
if (STRICMP(rhs, nop) == 0) /* Nop means nothing */
rhs = (char_u *);
else
rhs = replace_termcodes(rhs, arg_buf, FALSE, TRUE, special);
So Nop is treated as an empty key sequence only if it appears by itself
in the {rhs} of a mapping. I think, the help text for Nop should be
updated.
- Yegappan
; and in this case, :map F6 will print the Nop in blue (or in whatever
colour your clourscheme assigns to the SpecialKey group). If it is not alone,
as in
:map F6 NopNop
it is displayed in black (or in the Normal highlight colour) and means
less-than, N-for-November, o-for-Oscar, p-for-Papa, greater-than.
Re: tips project
Quick updates: 1. I posted all of the scripts that were sent to me today on the Google site in the svn repository under the scripts directory. 2. I've added everyone who has sent me his or her google id as project participants. Thanks again! Tom Purl On 2/22/07, Tom Purl [EMAIL PROTECTED] wrote: Swaroop, could you please convert a few tips using your script and them post them on the wiki? I would love to see the final output. Looks like I can't add anything to the wiki until the admin adds me as part of the project :) Here's the output of the script for tip 1504 : --- Tip 1504 Authored by Tim Keating Created on February 6, 2007 9:16 Complexity is basic Version of Vim required is '' codeIf you want to execute an external command on Windows, you need to know one trick. Let's say you're building a command to check out the file you're working on (using Perforce as an example): br / br /map lt;f6gt;:!p4 edit % br / br /However, that will just populate the command line. To force the command to execute without having to hit Enter, you need to embed a CR/LF. On Linux, you do this with CTRL+V CTRL+M. On Windows (as of version 7; not sure how far back this goes), CTRL+V is mapped to quot;Paste from Windows Clipboardquot;. You have to use CTRL+Q instead: br / br /map lt;f6gt;:!p4 edit %CTRL+Q CTRL+M br / br /Which will look like: br / br /map lt;f6gt;:!p4 edit %^M/code --- -- Swaroop
RE: tips project
Tom Purl wrote: Ok everyone, the project's created: * http://code.google.com/p/vimtips/ Hooray! The next step is to see some conversion script ideas. If you're the type of person who can write a script like this in 15 minutes, then by all means do so and send it to me. Otherwise, we can discuss it on the mailing list unless people think its too OT. So if you're interested in helping, start scraping vim.org/tips and let us know what works for you. Thanks to Tom for getting this started! All the others: please give constructive suggestions. -- An error has occurred. Hit any user to continue. /// 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///
