[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: replace a textblock in multiple files
From: |
B. T. Raven |
Subject: |
Re: AW: replace a textblock in multiple files |
Date: |
Thu, 28 Sep 2006 19:51:13 -0500 |
"Mathias Dahl" <brakjoller@gmail.com> wrote in message
u8xk6iqel.fsf@gmail.com">news:u8xk6iqel.fsf@gmail.com...
> <C.Strobl@dlr.de> writes:
>
> > 1) i want to work on several subdirectories, not only in one directory
> > 2) i want to replace blocks consisting of more than one line.
>
> In dired, navigate one folder "higher" than where you want to start
> your replacement. Then insert the directory you want to work with
> using C-u i and add an R to the arguments at the prompt. This will add
> all files recursively into the dired buffer and you can work with the
> files from there.
>
> The Q command should accept multi line blocks as long as you can find
> a regexp to do it. If not, maybe you want to write a small helper
> elisp function.
Beautiful! Emacs can do it out of the box without loading any further
resources. Here is what I did combining this problem with the one in the
other thread about replacing text in the html <column_right> block:
C-u [actual numeric argument not needed] C-x d [here modify the ls
switches to make them read -IR as per Mathias] [specify parent of all
sub-directories of interest; files in this parent directory containing
matches to regexp will be processed too.] %g someregexp* Q sameregexp [a
buffer is opened for each file in parent and in all subdirectories
containing match(es) to regexp and the process works exactly as in C-M-%.
* In the block search-replace example you could use: (not tested but I
think the middle pair of escaped parentheses will be interpreted as
grouping rather than as matched substring for later reference by \1 \2)
\(<starttextpattern>\)\(.\|^J\)*?\(<endtextpattern>\) RET
\1<replacementtext>\2 RET ;; search-replace arbitary text bracketed by
start- and endpattern. ^J is input with C-qC-j
[Thanks to Florian Kaufman for this. Now I understand non-greedy operators
better.]
Ed