RE: Structural regular expressions

[Drew Adams]

> This structural regex thing is interesting. You can perform operations
> (e.g. replace text) on all strings in the file, or everywhere except
> in strings and comments, etc. Here's the description of the feature
> on the E editor blog if someone wants to implement something like
> this for emacs: http://e-texteditor.com/blog/2010/beyond-vi
 
FWIW -

Not to pretend that this is exactly the same thing, but you can use Icicles to
do that.  A similar approach could be adopted by vanilla Emacs.

Icicles can use a text property to identify the parts of the buffer to search.
Those parts then act as completion candidates that you can match using a regexp
or other pattern (which you can change on the fly, to dynamically filter the
search hits).

Font-locking already provides such labeling-using-a-property, for free. It was
designed with another purpose in mind, of course, so the buffer parts identified
by font-lock might not always be those most pertinent for the job at hand.
Depends on just what "structures" you need - those provided by font-lock are
pretty basic.

Anyway, as an example, using the identification provided by font-lock, you can
use `C-c "' (`icicle-search-text-property') to search (e.g. using regexps) among
only the strings or only the comments, etc. of a buffer (or of multiple buffers
or files) - based on their different font-lock faces. (You cannot, however,
search among the complementary parts - e.g. the non-comments, without defining a
new Icicles search command.)

Font-lock faces can be used this way to do what you describe, provided the
"structural" parts of the buffer you are interested in are font-locked using
different faces.

This feature does not depend on font-lock, however.  The text property that is
used to divide the buffer into searchable parts need not be `face' - any
property will do.  So if you have a function that parses buffer parts (code
structures) in a more meaningful way (in some sense) than font-locking does, it
can add a text property with different values to identify the parts, and Icicles
search can exploit that labeling immediately.

And the property could be an overlay property instead of a text property.  And
you can replace matches while you search, on-demand.  And you could easily
define a specialized search command that allows other actions besides
replacement (e.g. a popup menu of alternative actions).

http://www.emacswiki.org/emacs/Icicles_-_Other_Search_Commands#toc2

In addition, it looks like the "structure" described in the blog post you cited
is in fact defined just by a set of regexp matches (but I'm no expert on reading
vi-ese):

Y/^\n/ V%A.*Pike<enter> \ V|^%T

It looks as though a few simple patterns do the trick to select the target
lines, for the example given.  If true, then for that simple kind of structure
definition you can just use ordinary Icicles search - no need for any fancy
(non-regexp) parsing or the application of a text property.  Ordinary Icicles
search (like the text-property search) lets you combine the filtering of any
number of input patterns (e.g. regexps).

And if you have a hairy pattern or set of patterns that you want to reuse,
instead of typing it interactively each time (as would seem to be the case for
the bibtex/refer references, though the blob touts the "effortlessness" of
typing such incantations), then you can define a command that incorporates that
info for the initial Icicle-search parse.

`C-c =' (`icicle-imenu') does that, for instance: it just passes the hairy imenu
regexp to `icicle-search'.  Any additional, dynamic pattern you then type just
filters the imenu candidates (e.g. function definitions).