Re: a question related to substitution using regular expression
Why not just s/ .*// ? (For either vim or sed.) Marshall On Jul 25, 2006, at 1:09 PM, Tim Chase wrote: My file is like the following: data_1.dat pre= -1908.77 post= -48977.33 diff= -448.947 data_2.dat pre= -444.333 post= -333.545 diff= -777.333 . . I hope to find out a regular expression subtitution commad to delete everything after dat to get a file like: data_1.dat data_2.dat . . I know visual mode will do the work too. But I still hope to find out the substitution command using regular expression so I can use sed to make it automatic. Well, you're in luck...the Vim regexp can be the same regexp as for sed: s/\.dat[[:blank:]].*/.dat/ or possibly the slightly shorter s/[[:blank:]]*pre=.*// Some sed's may allow for vim's \s or \ notation, in which case you can trim it even further: s/\.dat\.*/.dat/ or even s/\s*pre=.*// However, in your case, you might even be able to use the cut program: cut -d -f1 text which just asks for the first field, when delimited by spaces (if your original file uses tabs, you can ignore the -d , as cut defaults to using tabs) Just a few ideas... -tim
Re: colors
As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall On Jul 17, 2006, at 7:01 PM, A.J.Mechelynck wrote: Bill Hollingsworth wrote: Hi, I recently upgraded to VIM 7.0 and now the color settings for my PERL programs are different. I liked the way the colors were before. Could someone tell me how to return to the old settings, or how to set the colors myself? For instance, now comments and variable names are the same color. Thanks and best wishes, Bill Hollingsworth University of Cambridge Computer Laboratory I guess the easiest way is to write your own colorscheme. For instance I use the attached colorscheme which I wrote, named $HOME/.vim/colors/almost-default.vim and invoked by :colorscheme almost-default. It is a simple example which might help you create your own. You will have to find out the names of the highlight groups for which you need a non-default color. (Try Comment and Identifier; I guess changing them will also change perlComment and PerlIdentifier, or however they are named). You can set different colors for console Vim and gvim by using, in the same :highlight command, arguments cterm= ctermfg= ctermbg= on the one hand, and gui= guibg= guifg= onthe other hand. There are also a number of colorschemes available in your distribution (in $VIMRUNTIME/colors) and at vim-online (which can be installed by dropping them in one of the following: - system-wide: $VIM/vimfiles/colors - user-private on Unix: ~/.vim/colors - user-private on Windows: ~/vimfiles/colors ). Don't change anything in $VIMRUNTIME or its subdirs, because any upgrade can silently overwrite any changes you made there. See :help :highlight :help :colorscheme :view $VIMRUNTIME/colors/README.txt HTH, Tony. Vim color file Maintainer: Tony Mechelynck [EMAIL PROTECTED] Last Change: 2006 Jun 21 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 Errorguibg=red guifg=black hi clear ErrorMsg hi link ErrorMsg Error hi StatusLine gui=NONE,bold guibg=red guifg=white hi StatusLineNC gui=reverse,bold hi TabLine gui=NONEguibg=#DD guifg=black hi TabLineFill gui=NONEguibg=#AA guifg=red hi User1ctermfg=magenta guibg=white guifg=magenta hi User2ctermfg=darkmagenta guibg=#DD guifg=magenta remember the current colorscheme name let colors_name = almost-default vim: sw=2
Key mappings (was: Re: colors)
On Jul 18, 2006, at 2:33 PM, A.J.Mechelynck wrote: Marshall Abrams wrote: As a devotee of vim, I want to put in a vote for trying to make new releases violate fewer rather than more of existing users' assumptions (although I know that there are always tradeoffs). Why should the default color scheme suddenly change when one upgrades? (Hmm maybe fire suits should go on now.) Every time I install a new version of vim I have to go and fix some little thing so that it will work the way I want it to work. The problems I've experienced recently are due to the fact that I've been mapping g to 1G for years. In recent releases, matchit.vim (which I love) and the new fancy file browser have created mappings for g plus something else, so that vim has to pause when I type g to make sure that I'm not about to type another character (this is not the behavior you want for the go to the top of the file mapping). I have fixed these problems, but: How about adding functions without assigning them to keys? If a key hasn't been mapped before, then someone has their own private mapping for it, and by adding a new mapping, you're going to break something, perhaps for the sake of a function that most people won't use. (Shouldn't a *network* file browser be optional? I already have more than one with my operating system. ) Just pet peeves. If I didn't love it so much I wouldn't complain. Marshall My answer to that (and it is a personal opinion, not a dogma) is that most of the alphabetic keys (with or without Shift or Ctrl) are already assigned in standard Vim I have noticed that, but I'm not a fan of it. Fortunately, I rarely need the functions assigned to g+something. I occasionally undo my q mapping in order to record a macro. (including gg for go to top if you don't like the hand movement and Shift chord required by 1G), and more of them if possible are likely to get mapped in the future, so it's risky business at best to try mapping one's own functions I was mapping g long before vim started mapping things to it. So from my point of view, it was the developers who engaged in risky behavior. (Let me emphasize that I remain extremely grateful.) to them. An infamous example of the latter is the mswin.vim plugin, which overrides several of the Ctrl-letter keys with its own Windows-like mappings, thus obliterating many useful Vim keystrokes. OTOH, the F keys (other than F1 and sometimes F10) are available by default; so my advice is to map user-defined mappings to F keys with or without Shift/Ctrl/Alt, and mappings defined in unofficial plugins to multikey sequences starting with Leader LocalLeader etc. Uggh. F-keys. That's why I kept using Emacs for a long time. Why I switched to vi for even greater ease. So my fingers wouldn't have to leave the letter keys. (Esc is an exception, but easy to slap.) Same reason I don't like editors that make essential use of the mouse. Let nothing intervene between thought and text. Best regards, Tony. Oh well. Thanks Tony. Marshall
Re: auto upper/lower in replace pattern based on search pattern?
Thanks--keepcase.vim is great. So now with :%s/firstname/\=KeepCase(submatch(0), 'LastName')/ig I can replace all instances of firstname with lastname firstName with lastName FirstName with LastName But \=KeepCase(submatch(0), '') is a mouthful. Not a problem; that exact expression does what I'll want 99% of the time, so I've already mapped it to a control-key. And there are other ways to abbreviate. Still, this seems *such* a useful function in a programmer's editor, it seems worthwhile to build it into the :substitute command as some kind of optional behavior. How about one of these: :s/firstname/LastName/k ['k' for keepcase] :set MaGiC or some kind of delimiter that can be stuck into a pattern to say use KeepCase() on this part. OK, I know there aren't many delimiters that are available at this point. Does this make any sense as a possible future feature? Marshall On Jul 7, 2006, at 4:26 AM, Yakov Lerner wrote: On 7/7/06, Marshall Abrams [EMAIL PROTECTED] wrote: Hate to ask this because I'm sure the answer is already out there somewhere, but I've searched help and vim.org until I was blue in the fingers I could swear that I remember from a few years back that there's a way to do this. Can't remember whether it required something special in the patterns or some special :set variable or loading a plugin. I want to the replace pattern in a substitution to be able to figure out whether I want an upper or lower character in the replacement, depending on whether the search pattern matched an upper or lower character. Very useful for substitutions on studlyCaps. For example, suppose I want to replace all instances of 'first' with 'last' and of 'First' with 'Last'. Can I do that with a slinge :s/// line? Try this script: http://www.vim.org/scripts/script.php?script_id=6 keepcase.vim : Functions for doing case-persistant substitutions Yakov Marshall Abrams Programmer [EMAIL PROTECTED] 5points.net, LLC Voice: 518-392-5505 www.5points.net Fax: 518-392-8410 CONFIDENTIALITY NOTICE: This communication and any accompanying document(s) are confidential and privileged. They are intended for the sole use of the addressee. If you receive this transmission in error, you are advised that any disclosure, copying, distribution, or the taking of any action in reliance upon the communication is strictly prohibited. If you have received this communication in error, please contact us by email at [EMAIL PROTECTED], or by telephone at (518) 392-5505. Thank you.
auto upper/lower in replace pattern based on search pattern?
Hate to ask this because I'm sure the answer is already out there somewhere, but I've searched help and vim.org until I was blue in the fingers I could swear that I remember from a few years back that there's a way to do this. Can't remember whether it required something special in the patterns or some special :set variable or loading a plugin. I want to the replace pattern in a substitution to be able to figure out whether I want an upper or lower character in the replacement, depending on whether the search pattern matched an upper or lower character. Very useful for substitutions on studlyCaps. For example, suppose I want to replace all instances of 'first' with 'last' and of 'First' with 'Last'. Can I do that with a slinge :s/// line? Thanks- Marshall
