Re: [ jEdit-users ] Find previous/next

[Slava P. <sl...@je...>]

I don't understand how this is different than searching for, say, 
"/\*(.|\n)?\*/", except you can specify what part of the match gets selected 
or not. However the latter should be possible with look-aheads and 
look-behinds.

On March 4, 2003 01:54 pm, Randall R Schulz wrote:
> At 10:05 2003-03-04, Slava Pestov wrote:
> >On March 4, 2003 11:03 am, Randall R Schulz wrote:
> >...
> >
> > > Does anybody here know about MPW's "selection expressions?" Now that
> > > would be cool. I don't know of any other editor that implemented them.
> >
> >Can you describe this feature?
> >--
> >Slava Pestov
>
> Slava,
>
> I'll try to do it from memory, since all my printed MPW manuals are
> buried. (MPW is now obsolete and only runs under Mac OS 9, may it RIP.)
>
>
> Selection expressions were an extension of regular expressions. MPW had
> fairly typical regular expression capabilities, though the lexical
> conventions were pretty unusual--they used the Macintosh extended
> character set liberally for both the regular expression base and the
> selection expression extensions.
>
> MPW REs indicated backward search by using \backslashes\ instead of of
> /forward slashes/. (This made sense since the single-character escape
> was another special Mac character--the one that looked like the partial
> derivative operator. Get it? Partial? Another character follows to
> complete the escape sequence. That's the way the MPW designers thought,
> apparently.)
>
> Selection expressions allowed one to establish a selection (in the
> usual sense of selecting some text) by combining regular expressions.
> For example, you could use selection expressions to find balanced
> constructs like comments (though not nested ones). For example, to find
> a C / C++ / Java balanced comment, you'd use a selection expression like
> this:
>
>      ^/\/\*/:/\*\//^
>
> (MPW used the delta symbol instead of the ^ I'm using here. Vertical
> bar would proably be a good choice, too.)
>
> The regular expressions /\/\*/ and /\*\// are the usual thing (this
> example is practical but unfortunate because it requires so much
> escaping). The up-arrows _outside_ the REs indicate a selection at the
> corresponding "edge" of the text matched by the RE--in other words, an
> insertion point. So the first ^/RE/ creates an insertion point left of
> the RE match. The colon separates SEs and extends the selection from
> the SE on its left to that on its right. The right-most ^ indicates an
> insertion point to the right of the RE it follows.
>
> So that should show you how the SE I gave will find the next /* commend
> */ going forward from wherever the selection was when that SE was invoked.
>
> If you wanted a SE that selected the comment content but not the /* and
> */ that surround it, you'd write this:
>
>      /\/\*/^:^/\*\//
>
> SEs have notations for the current selection (they used the Mac
> double-S ligature usually used as a "section reference" for this). I'll
> write that as & here. So you could create an insertion point just left
> of the current selection with ^&. Likewise, an insertion point to the
> right of the current selection would result from the SE &^. This was
> useful, e.g., when you wanted to write an SE that would start the next
> search / selection action outside the current selection. Selecting
> forward you'd use &^ and selecting backward you'd use ^& as a "priming"
> SE element.
>
> There were SE notations for top and bottom of file, too (the
> top-of-file character was the bullet and the bottom-of-file was the
> infinity symbol). Simple numeric strings are SEs, too--they select
> whole lines based on line numbers. So the SE to select lines 5 through
> 10 would be 5:10.
>
> SEs could be parenthesized and nested arbitrarily. The order of
> application was similar to that of parenthesized expressions in a
> programming language--left-to-right and inner-most first. This wasn't
> the most intuitive thing, but it was very powerful. There was a
> well-defined operator precedence for SEs, of course:
>
> High
>      ( SE )
>      /RE/ \RE\ line-number TOF BOF &
>      ^
>
> Low
>
> Combined with MPW's (also rather funky) scripting language, SEs could
> do a lot of very fancy and powerful search tasks that REs alone cannot
> do. They'd clearly extend jEdit's search capabilities just as much.
>
> I think that pretty much covers it. If anybody else is familiar with
> MPW SEs, please correct any mistakes and fill in any gaps in my
> description.
>
> There'd be two challenges to implementing these for jEdit: Defining a
> suitable set of operator characters without recourse to all the funky
> Mac characters and, of course, writing the code to implement such
> selections.
>
> If anybody thinks this is interesting, I'll try to find more
> comprehensive, detailed and precise references.
>
>
> Randall Schulz

-- 
Slava Pestov