Tim, thank you for pointing out the *help* ( :help s/\L ) for the case replacement and more specifically the how to end the case replacement using the \e or \E... it probably should have been intuitive on how to find the correct ending using the *help*, but your reply pointed me in the right direction.. thanks again
On Thursday, April 24, 2008 at 12:37:05 PM UTC-5 [email protected] wrote: > Is there an 'easy' (:-)) (I could write a program, but not exactly my > idea of an easy editing task)...still might end up being the fastest > way to do this...) way to change case of a 'bunch' of identifiers > delimited by curly brackets in a 'block' of text? > > I.e. I have a module that currently uses variables of the form: > > pkg{VARA}=pkg2{VAR_B}+$offsetp->{VC}; > > The part that I want to change is the 'upper' case tag in curly > brackets to lower case. So what I'd like is something like a > combination substitute and "tr" (character translate), so I can > do (spaces added for clarity, and using a perl-ish syntax, cuz if I > knew the vim syntax, I'd just use it :-) ): > > : '<,'> s / { ([A-Z_]\+) } / { (? { $1=~tr/[A-Z]/[a-z]/ } ) } /xg <- vimish > :<range>s / L (capture ) L / L (? { evaluate-able expr. } ) L <- legend > > where - the parens in the first part captures the sub expression; > - above the 'L' in the legend are literal curly braces, delimiting > the captured expression in the search-string, and added back as > literals to the replacement string. > - and everything in (?{replacement-expr}) with the evaluated contents > of a "tr" (translate) substitution operator that operates on > the left-variable of the "=~" expression -- so "tr/[A-Z]/[a-z]/" > would replace every char in the captured-sub-expression (represented > by "$1") that matches in the 1st range "[A-Z]" to it's corresponding > character in the target range "[a-z]" and return the result as the > contents of the replacement sub-expression "(?{$1=~tr/[A-Z]/[a-z]/})", > which would itself be between the two literal curly brackets in the > replacement string. > > ==== that's "it" ==== > > Equivalently, if I could run the same command in perl (I have the > perl5.8.dll, but it doesn't seem to be integrated in a way to > do this: > : '<,'> <-- starting with a vi "Visual" range, and appending a perl > command to operate on the range like: > : '<,'> perl 's/ {([A-Z_]+)} / { (?{$1=~tr/A-Z/[a-z]/}) } /xg' <- vimish > ' <-- perl expression between single quotes --> ' <- legend > > So what would be the equivalent line of vim-code to do what > I want above? I happen to know the perlish way to do it (or at > least I think I do -- haven't tried the above to be honest, but it > was more intended to communicate what I want than being a working > perl example :-), mostly because I know the POSIX (*nix) search and > command set (I believe 'tr' the utility is also part of the POSIX > system command set, and perl was originally designed as an amalgamation > of of several commands that have ended up being part of the POSIX > command set. > > Only problem with perl is it didn't include the 'vi[m]' editor :-). > I'm sure 'vim' would somehow be a great feature addition > in perl 5.12. (Perl6, being a fairly different language from its > predecessors, doesn't appear to fulfill the mission of being the > next version or evolution of perl5.8 or 5.10. Apparently the author > admits he only chose the name "perl6" for the perl-name recognition, > not because it was intended to be a compatible upgrade, operators and > variable syntax have even changed.) > > BTW, is there a way (or a reason why the ability was disabled) to > always use "very magic" for interactive regular expressions? Sure > would help me in remembering more of the expression syntax. I never > know if I need an extra "\" to make something have it be treated > as its 'normal' Regex character function (magic) vs. being treated > as a literal without trying to look it up in a chart -- and even > then it's confusing with things like square-brackets not being > symmetric in their backslash requirements. I understand the logic > of why it is the way it is, but that doesn't mean it's not a > different logic and mind-set from where 'symmetry' would take > precedence over necessity. > > > Thanks for any help & pointers... > -Linda > > > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/f7d9bf06-4850-475d-80e5-c917cdfdaae9n%40googlegroups.com.
