Most Valuable Tricks

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Most Valuable Tricks

Frederico Franzosi
Hi, I've been a reader of the list for about 2 months and I've been
collecting lots of knowledge about vim. I think I'm still a begginer
facing people in the list. Anyway, my editing abilities grown up so
much with Vim that I decided to give a (introductory) course of it in
a Free Software event ( http://www.inf.ufes.br/eri2005/?q=node/4 ) in
my town. So, I've been collecting lots of material at Vim.org
Tips/Scrips, vim online-help (wich I think it's the best help system
ever created), other sites in the internet and here. Even though, I've
decided to ask you for some motivational tricks you can do with Vim,
like when the editor really saved life (or at least hours of work).

 Hope I get some good answer here.
 Thanks anyway
 Frederico Franzosi
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Dominic Evans
Well, the things that I personally would focus on as being important
(based on a quick think after reading this email) are:

* macros: quickly recording a sequence of commands based on position in file
e.g. numbering a list by making a macro that copies a number, pates it
below and increments it - give demonstrations of lots of different
uses

* block edit: CTRL-V is powerful

* marks & jumping: important things people miss are ` and ' for jump
to column in line or jump to begining of line, using the . mark to
jump to last edited place, `` or '' to jump to last place before jump
- and of course using CTRL-O CTRL-I to traverse the stack of jumps

* vimdiff: invaluable

* multiple windows showing different positions in the same file/buffer

I could probably think of more but im busy @ work at the mo :)

Dom

On 29/09/05, Frederico Franzosi <[hidden email]> wrote:

> Hi, I've been a reader of the list for about 2 months and I've been
> collecting lots of knowledge about vim. I think I'm still a begginer
> facing people in the list. Anyway, my editing abilities grown up so
> much with Vim that I decided to give a (introductory) course of it in
> a Free Software event ( http://www.inf.ufes.br/eri2005/?q=node/4 ) in
> my town. So, I've been collecting lots of material at Vim.org
> Tips/Scrips, vim online-help (wich I think it's the best help system
> ever created), other sites in the internet and here. Even though, I've
> decided to ask you for some motivational tricks you can do with Vim,
> like when the editor really saved life (or at least hours of work).
>
>  Hope I get some good answer here.
>  Thanks anyway
>  Frederico Franzosi
>
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Wes Potts
I use filters many times daily.  (Well, mainly just one filter: perl).
 This saves me hours writing code for my team's ETL tool (the code
tends to be verbose and repetitive).  I can write one statement (or
group of statements) then generate the same statement(s) for many
fields, or variables.

For example, in vim:
==============================================================
for $field ( <DATA> ) {
chomp $field;
printf "out.%s :: if ( is_defined( in.%s ) ) string_lrtrim( in.%s )
else NULL;\n", $field;
}

__DATA__
field1
field2
field3
==============================================================

Then run:

:%!perl

As a software developer (who frequently must generate MANY lines of
similar code) this is invaluable.  Hope you find this useful.

Wes


On 9/29/05, Dominic Evans <[hidden email]> wrote:

> Well, the things that I personally would focus on as being important
> (based on a quick think after reading this email) are:
>
> * macros: quickly recording a sequence of commands based on position in file
> e.g. numbering a list by making a macro that copies a number, pates it
> below and increments it - give demonstrations of lots of different
> uses
>
> * block edit: CTRL-V is powerful
>
> * marks & jumping: important things people miss are ` and ' for jump
> to column in line or jump to begining of line, using the . mark to
> jump to last edited place, `` or '' to jump to last place before jump
> - and of course using CTRL-O CTRL-I to traverse the stack of jumps
>
> * vimdiff: invaluable
>
> * multiple windows showing different positions in the same file/buffer
>
> I could probably think of more but im busy @ work at the mo :)
>
> Dom
>
> On 29/09/05, Frederico Franzosi <[hidden email]> wrote:
> > Hi, I've been a reader of the list for about 2 months and I've been
> > collecting lots of knowledge about vim. I think I'm still a begginer
> > facing people in the list. Anyway, my editing abilities grown up so
> > much with Vim that I decided to give a (introductory) course of it in
> > a Free Software event ( http://www.inf.ufes.br/eri2005/?q=node/4 ) in
> > my town. So, I've been collecting lots of material at Vim.org
> > Tips/Scrips, vim online-help (wich I think it's the best help system
> > ever created), other sites in the internet and here. Even though, I've
> > decided to ask you for some motivational tricks you can do with Vim,
> > like when the editor really saved life (or at least hours of work).
> >
> >  Hope I get some good answer here.
> >  Thanks anyway
> >  Frederico Franzosi
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Tim Chase-2
> For example, in vim:
> ==============================================================
> for $field ( <DATA> ) {
> chomp $field;
> printf "out.%s :: if ( is_defined( in.%s ) ) string_lrtrim( in.%s )
> else NULL;\n", $field;
> }
>
> __DATA__
> field1
> field2
> field3
> ==============================================================

For those in the crowd (such as myself) that don't particularly
care for Perl, if you've got the above __DATA__ in a file, such
as above, you can just run a regular :s command across it:

:%s/\w\+/out.& :: if (is_defined(in.&)) string_lrtrim(in.&)

(adjust the "\w\+" accordingly depending on your input data)

-tim





Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Antony Scriven
On Sep 29, Tim Chase wrote:

 > >For example, in vim:
 > >==============================================================
 > >for $field ( <DATA> ) {
 > >chomp $field;
 > >printf "out.%s :: if ( is_defined( in.%s ) ) string_lrtrim( in.%s )
 > >else NULL;\n", $field;
 > >}

Missing some $fields?

 > >
 > >__DATA__
 > >field1
 > >field2
 > >field3
 > >==============================================================
 >
 > For those in the crowd (such as myself) that don't particularly
 > care for Perl, if you've got the above __DATA__ in a file, such
 > as above, you can just run a regular :s command across it:
 >
 > :%s/\w\+/out.& :: if (is_defined(in.&)) string_lrtrim(in.&)
 >
 > (adjust the "\w\+" accordingly depending on your input data)

Or you could use the shell:

   while read f
   do
      echo "out.$f :: if ( is_defined( in.$f ) ) string_lrtrim( in.$f )"
   done
   field1
   field2
   field3
   :%!sh

Antony
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Neil Watson
In reply to this post by Tim Chase-2
On Thu, Sep 29, 2005 at 09:36:28AM -0500, Tim Chase wrote:
>For those in the crowd (such as myself) that don't particularly
>care for Perl,

Blasphemer!

I have some macros I use to generate html markup:
"===================================
"HTML SECTION
"===================================

set matchpairs+=<:>
:syntax match xComment /<!.*/

"html comment current line
map ,hc I<!--<ESC>A--><ESC>

"html header
map ,hh i<html><CR><head><CR><meta name="keywords" content=""><CR><meta name="Author" content="Neil H Watson"><CR><title></title><CR></head><CR><body><CR><ESC>:3>3<CR>

"html footer
map ,hf :i</body><CR></html><C-C>

"create html header lines (h1 to h6)
nmap ,h1 <HOME>v$"zdi<h1><ESC>"zp$a</h1><ESC>
nmap ,h2 <HOME>v$"zdi<h2><ESC>"zp$a</h2><ESC>
nmap ,h3 <HOME>v$"zdi<h3><ESC>"zp$a</h3><ESC>
nmap ,h4 <HOME>v$"zdi<h4><ESC>"zp$a</h4><ESC>
nmap ,h5 <HOME>v$"zdi<h5><ESC>"zp$a</h5><ESC>
nmap ,h6 <HOME>v$"zdi<h6><ESC>"zp$a</h6><ESC>

"add html bold tags
vmap ,hb "zdi<b><ESC>"zpgviw<ESC>a</b><ESC>

"add html code tags
vmap ,hc "zdi<code><ESC>"zp<ESC>a</code><ESC>

"add html name tags
vmap ,hn "zdi<name="<ESC>"zp<ESC>a"></a><ESC>

"add html paragraph tags
nmap ,hp <HOME>v$"zdi<p><ESC>"zp$a</p><ESC>

"create html table from ;; delimited table
nmap ,ht vip :s/^/<tr>/<CR> gv :s/$/<\/tr>/<CR> gv :s/<tr>/<tr>\r\t<td>/<CR> gvip :s/<\/tr>/<\/td>\r<\/tr>/<CR> gvip :s/;;/<\/td>\r\t<td>/g<CR>:noh<C-C>

"create html list items
nmap ,hl vip :s/^\(.*\)$/\t<li>\1<\/li>/g<CR>:noh<C-C>

iab ht http://<C-R>=Eatchar('\s')<CR>
iab ah <a href="<C-R>=Eatchar('\s')<CR>
iab mailto <a href="mailto:"></a>

"===================================
"SUBROUTINES
"===================================

"remove last character (space) after abbreviation
fun! Eatchar(pat)
    let c = nr2char(getchar())
    return (c =~ a:pat) ? '' : c
endfun

--
Neil Watson               | Gentoo Linux
Network Administrator     | Uptime 28 days
http://watson-wilson.ca   | 2.6.11.4 AMD Athlon(tm) MP 2000+ x 2
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Wes Potts
In reply to this post by Antony Scriven
Ah yes... Thanks for the correction (printf missing some args).  Also,
I like the shell tip.  I don't think I've used shell loops like that
from vim.

I probably should have mentioned another reason I like using the
filter functionality.  Like many (most) programmers, I'm pressed for
time and I need to generate much "nastier" code than the example below
so, I make several mistakes before getting it right.  Therefore, my
work cycle goes something like:

1. edit my code (to generate code)
2. :%!perl -or- :n,m!perl
3. undo
4. repeat 1-3 until I'm happy

This cycle often gets repeated several times when I must generate
several seperate blocks of code based upon the same input.

One of my favorites was something like:

for $s ( statements ) {
  for $v ( variable_bases ) {
    for $i ( 1 2 3 ) {
      print the statement
    }
  }
}

which generated about 3 pages of code (as I had about 4 statements and
10 or 15 variable base names).

But, back to the original topic, I hope these comments will help at
your software event.

Wes

On 9/29/05, Antony Scriven <[hidden email]> wrote:

> On Sep 29, Tim Chase wrote:
>
>  > >For example, in vim:
>  > >==============================================================
>  > >for $field ( <DATA> ) {
>  > >chomp $field;
>  > >printf "out.%s :: if ( is_defined( in.%s ) ) string_lrtrim( in.%s )
>  > >else NULL;\n", $field;
>  > >}
>
> Missing some $fields?
>
>  > >
>  > >__DATA__
>  > >field1
>  > >field2
>  > >field3
>  > >==============================================================
>  >
>  > For those in the crowd (such as myself) that don't particularly
>  > care for Perl, if you've got the above __DATA__ in a file, such
>  > as above, you can just run a regular :s command across it:
>  >
>  > :%s/\w\+/out.& :: if (is_defined(in.&)) string_lrtrim(in.&)
>  >
>  > (adjust the "\w\+" accordingly depending on your input data)
>
> Or you could use the shell:
>
>    while read f
>    do
>       echo "out.$f :: if ( is_defined( in.$f ) ) string_lrtrim( in.$f )"
>    done
>    field1
>    field2
>    field3
>    :%!sh
>
> Antony
>
Reply | Threaded
Open this post in threaded view
|

RE: Most Valuable Tricks

Suresh Govindachar`
   
   Wes Potts Sent September 29, 2005 9:23 AM
 
  [snip]
  > Therefore, my work cycle goes something like:
  >
  > 1. edit my code (to generate code)
  > 2. :%!perl -or- :n,m!perl
  > 3. undo
  > 4. repeat 1-3 until I'm happy
  >
  > This cycle often gets repeated several times ...
  [snip]
 
  Something that might help:
 
  1) Put the following toward the top of you perl file
         BEGIN {(*STDERR = *STDOUT) || die;}
  2) End the perl file with the line
         __END__
  3) In $vim/ftplugin/perl.vim, use a mapping such as:
         nmap <buffer> <F5>  :w<esc>mwG:r!perl %:p<CR>`.
 
  The just hit <F5> and you will see the results of the perl
  processing.  You can go back to where you were using `w.
 
  --Suresh
 

Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Gary Johnson
In reply to this post by Frederico Franzosi
On 2005-09-29, Frederico Franzosi <[hidden email]> wrote:

> Hi, I've been a reader of the list for about 2 months and I've been
> collecting lots of knowledge about vim. I think I'm still a begginer
> facing people in the list. Anyway, my editing abilities grown up so
> much with Vim that I decided to give a (introductory) course of it in
> a Free Software event ( http://www.inf.ufes.br/eri2005/?q=node/4 ) in
> my town. So, I've been collecting lots of material at Vim.org
> Tips/Scrips, vim online-help (wich I think it's the best help system
> ever created), other sites in the internet and here. Even though, I've
> decided to ask you for some motivational tricks you can do with Vim,
> like when the editor really saved life (or at least hours of work).

I've used vim for so long that I'm sure I take a lot of its neater
features for granted, but the ones that come to mind that have saved
me the most time while coding C are:

-  * - search for the word under the cursor
-  diff
-  quickfix
   -  for linting code before compiling
   -  for finding all occurrences of some symbol or string in the
      code set
-  cscope and/or tags
-  CTRL-X name completion
   -  to avoid typing long file names
   -  to avoid misspelling variable names

Most of the other programmers around here use xemacs, and I see them
constantly searching for file icons on their desktops, using other
tools to find symbols, and copying-and-pasting or retyping files and
line numbers from other windows and applications to find things.  I
usually use one large vim window (sometimes a second vim window in
the other monitor) and use the integrated quickfix tools to jump
from place to place in the code set without having to think too much
about which file I'm in or where it's located.

HTH,
Gary

--
Gary Johnson                 | Agilent Technologies
[hidden email]     | Wireless Division
                             | Spokane, Washington, USA
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Matthew Winn
In reply to this post by Frederico Franzosi
On Thu, Sep 29, 2005 at 09:18:39AM -0300, Frederico Franzosi wrote:

> Hi, I've been a reader of the list for about 2 months and I've been
> collecting lots of knowledge about vim. I think I'm still a begginer
> facing people in the list. Anyway, my editing abilities grown up so
> much with Vim that I decided to give a (introductory) course of it in
> a Free Software event ( http://www.inf.ufes.br/eri2005/?q=node/4 ) in
> my town. So, I've been collecting lots of material at Vim.org
> Tips/Scrips, vim online-help (wich I think it's the best help system
> ever created), other sites in the internet and here. Even though, I've
> decided to ask you for some motivational tricks you can do with Vim,
> like when the editor really saved life (or at least hours of work).

If I had to pick one single feature that's saved me hours of work it
would have to be the one that most people overlook or reject because
they see it as too complicated and wonder if it's worth the effort
required to learn it: regular expressions.

It's astonishing how many apparently impossible tasks become trivial
with regular expression matching or replacing.  I couldn't begin to
count the number of times a regular expression has allowed me to perform
what would otherwise be hours of editing with a single Vim command.
Similarly, in Perl one regular expression can replace a hundred lines
of procedural code.  An hour spent learning regular expressions will
pay for itself within a day.

--
Matthew Winn ([hidden email])
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Paul-433
Amen to this, and it gets easier the more you learn.

On Fri, 30 Sep 2005, Matthew Winn wrote:

> It's astonishing how many apparently impossible tasks become trivial
> with regular expression matching or replacing.  I couldn't begin to
> count the number of times a regular expression has allowed me to perform
> what would otherwise be hours of editing with a single Vim command.
> Similarly, in Perl one regular expression can replace a hundred lines
> of procedural code.  An hour spent learning regular expressions will
> pay for itself within a day.

--

.
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

John (Eljay) Love-Jensen
In reply to this post by Matthew Winn
Hi everyone,

> It's astonishing how many apparently impossible tasks become trivial with
regular expression matching or replacing.

Agreed!

Here's a book I highly recommend:

Mastering Regular Expressions
by Jeffery E. F. Friedl
http://www.amazon.com/exec/obidos/tg/detail/-/0596002890

It really is *THE* definitive book on mastering regular expressions.

Sincerely,
--Eljay

PS:  I'm in no way connected to the book, other than I bought it and read it
and was very impressed.

Reply | Threaded
Open this post in threaded view
|

RE: Most Valuable Tricks

Zdenek Sekera
In reply to this post by Frederico Franzosi
> -----Original Message-----
> From: John Love-Jensen [mailto:[hidden email]]
> Sent: 30 September 2005 13:33
> To: MSX to Vim
> Subject: Re: Most Valuable Tricks
>
> Hi everyone,
>
> > It's astonishing how many apparently impossible tasks
> become trivial with
> regular expression matching or replacing.
>
> Agreed!
>
> Here's a book I highly recommend:
>
> Mastering Regular Expressions
> by Jeffery E. F. Friedl
> http://www.amazon.com/exec/obidos/tg/detail/-/0596002890
>
> It really is *THE* definitive book on mastering regular expressions.

I totally agree with Mathew Winn original posting, it's regular
expressions for me, too, that really make a difference.
I have the book you mentioned, use it every time I realize
I again forgot something, but you'll agree that vim has even
more of RE possibilities.

Wouldn't it be time that someone real guru would sacrifice
himself and write some guide/cookbook/or "how to master
vim Regexp's" ? I am sometimes really amazed when reading
posts on this forum what some people are capable of doing
with RE's. Takes me some time to decipher that.

---Zdenek
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Tim Chase-2
> Mastering Regular Expressions by Jeffery E. F. Friedl
> http://www.amazon.com/exec/obidos/tg/detail/-/0596002890
>
> It really is *THE* definitive book on mastering regular
> expressions.

Having not read this text in particular, does it have (or do you
know of) a nifty chart comparing regexp operators in various
utilities?

It drives me nuts switching between Vim, Sed, Ed, Grep (and with
Sed/Grep, which quotes I use in bash trigger differing needs for
escaping), Posix regexps, Perl/pcre, Java's regexps, Python's
regexps, PHP's regexps, etc.  It would be handy to have some big
table where I could look up the Vim way (with which I'm most
versed) and then see how to translate that into the other ones.
Things like

-Are groupings done with "\(...\)" or just unescaped parens?

-Do \< and \> work, or does the program want \b

-Does non-greedy ("\{-}") matching work in this program?

-Does the N-M matching need to be escaped? ("\{2,3}" vs. "{2,3}"
vs "\{2,3\}")

These are just some of those little gotchas that I can pull off
the top of my head.  However, it would be handy to be able to
look it up somewhere to convince myself that I'm *not* crazy (or
at least any more than usual ;) and that a given regexp *should*
work, just in another application.

-tim





Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Stephen R Laniel
On Fri, Sep 30, 2005 at 08:09:22AM -0500, Tim Chase wrote:
> Having not read this text in particular, does it have (or do you
> know of) a nifty chart comparing regexp operators in various
> utilities?

Yes, Friedl's book has this. And I agree that it's really
irritating trying to keep track of which regex uses what.
Me, I think Perl's is the smartest: all metacharacters are
unescaped. That's a nice straightahead rule, rather than
remembering that (for instance) the '.' metacharacter is
unescaped and '{' is escaped. Silliness. PCREs for all.

--
Stephen R. Laniel
[hidden email]
+(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Most Valuable Tricks

Matthew Winn
On Fri, Sep 30, 2005 at 09:08:23AM -0400, Stephen R Laniel wrote:
> On Fri, Sep 30, 2005 at 08:09:22AM -0500, Tim Chase wrote:
> > Having not read this text in particular, does it have (or do you
> > know of) a nifty chart comparing regexp operators in various
> > utilities?
>
> Yes, Friedl's book has this. And I agree that it's really
> irritating trying to keep track of which regex uses what.

And just to _really_ throw a spanner in the works, Perl 6 has a new
regular expression syntax.  Regular expression syntaxes multiply
like coathangers in a cupboard.

> Me, I think Perl's is the smartest: all metacharacters are
> unescaped. That's a nice straightahead rule, rather than
> remembering that (for instance) the '.' metacharacter is
> unescaped and '{' is escaped. Silliness. PCREs for all.

I can see why there's a difference, though.  In Perl you're creating an
expression that will be written once but used many times, so the simple
policy of
                  |  backslashed   no backslash
    --------------|----------------------------
    letter        |    special        literal
    punctuation   |    literal        special

makes for an easy syntax to remember.  In Vi, on the other hand, most
expressions are typed once and used once so it's more important to make
the most common uses quick to type.  Leaning toothpick syndrome isn't a
problem if you write your expression once and then leave it lurking in a
program forever, but you wouldn't want it in an interactive environment.

The main difficulty I have with regular expressions is all the different
styles of grep out there.  I don't just mean the fact that I have to
choose between egrep, fgrep and grep, but also that different versions
of Unix have different greps, each with a different set of characters
requiring backslashes.

--
Matthew Winn ([hidden email])
Reply | Threaded
Open this post in threaded view
|

OT: Perl regexes (was Re: Most Valuable Tricks)

Stephen R Laniel
On Fri, Sep 30, 2005 at 02:55:43PM +0100, Matthew Winn wrote:
> makes for an easy syntax to remember.  In Vi, on the other hand, most
> expressions are typed once and used once so it's more important to make
> the most common uses quick to type.

Isn't the most common use of '{' the metacharacter use,
though? Likewise for '.', and '[', and I'm pretty sure all
of the others. So if the metacharacter use is the most
common, shouldn't metacharacters all be unescaped? I think
that's the reasoning behind Perl's escaping policies. (To
the extent that Perl can be said to have policies [1].)

I also think Perl's ability to choose your own quote- and
substitution-delimiter makes it easier to type. E.g., if you
could only use 's/pattern/sub/options', and you wanted to do
some HTML substitution in Perl, you'd have

s/<oldTag>(.*?)<\/oldTag>/<newTag>$1<\/newTag>/g

which is messy, whereas Perl's

s{<oldTag>(.*?)</oldTag}{<newTag>$1</newTag>}g

is clean.

[1] - http://www.wall.org/~larry/pm.html

--
Stephen R. Laniel
[hidden email]
+(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OT: Perl regexes (was Re: Most Valuable Tricks)

Chris Allen
On 30/09/05, Stephen R Laniel <[hidden email]> wrote:
> Isn't the most common use of '{' the metacharacter use,
> though? Likewise for '.', and '[', and I'm pretty sure all
> of the others. So if the metacharacter use is the most
> common, shouldn't metacharacters all be unescaped? I think
> that's the reasoning behind Perl's escaping policies. (To
> the extent that Perl can be said to have policies [1].)

I think the consensus has been that what you've said is true for Perl
but not for Vim.  When I code I certainly do a lot of grepping for
literal characters like () (functional calls everywhere), {} (Perl
hashes) and [] (arrays everywhere).  I generally do *much* less
complicated greppage in Vim than in Perl and it could be argued that
matching what I am searching for by default is the correct behaviour.
Of course, as a Perl programmer I know regexps and think magic
properties should be identical everywhere.  Others may not agree, so
perhaps this is a feature for them.

Thanks,
Chris Allen
Reply | Threaded
Open this post in threaded view
|

Re: OT: Perl regexes (was Re: Most Valuable Tricks)

Gareth Oakes-2
> I think the consensus has been that what you've said is true for Perl
> but not for Vim.  When I code I certainly do a lot of grepping for
> literal characters like () (functional calls everywhere), {} (Perl
> hashes) and [] (arrays everywhere).  I generally do *much* less
> complicated greppage in Vim than in Perl and it could be argued that
> matching what I am searching for by default is the correct behaviour.
> Of course, as a Perl programmer I know regexps and think magic
> properties should be identical everywhere.  Others may not agree, so
> perhaps this is a feature for them.

My view on the whole situation is that it would be much quicker for
everyone to have one scheme or the other exclusively.  It takes more
time to figure out which characters need escaping or not than to
actually just type the backslashes.

-G
Reply | Threaded
Open this post in threaded view
|

Re: OT: Perl regexes (was Re: Most Valuable Tricks)

Mikołaj Machowski
In reply to this post by Stephen R Laniel
Dnia pi?tek, 30 wrze?nia 2005 16:02, Stephen R Laniel napisa?:

> I also think Perl's ability to choose your own quote- and
> substitution-delimiter makes it easier to type. E.g., if you
> could only use 's/pattern/sub/options', and you wanted to do
> some HTML substitution in Perl, you'd have
>
> s/<oldTag>(.*?)<\/oldTag>/<newTag>$1<\/newTag>/g
>
> which is messy, whereas Perl's
>
> s{<oldTag>(.*?)</oldTag}{<newTag>$1</newTag>}g

Vim also has this possibility, just choice is limited to non-pair
elements like +.

m.

12