[ jEdit-devel ] History's Lessons: Regular Expressions vs. Selection Expressions
June 25, 2006
Hi,
With the recent encounter with regex difficulties surrounding the switch
to the Java standard library regex from the previously used Gnu Regex
and the suggestions regarding improvements, I thought I'd again bring
up a topic near and dear to my heart and which I mentioned here a few
years ago. At the time, it didn't get much traction, but maybe now it
might be seen differently.
The issue is the notion of a selection expression as introduced
(as far as I know) in the Macintosh Programmer's Workshop (MPW).
Selection expression build upon regular expressions and add
considerable practical recognizing ability to unadorned regular
expressions.
>From the comparison between MPW and Unix at
<http://www.geek-central.gen.nz/MPW/intro.html>:
"[MPW has] support not just for regular expressions, but for selection
expressions, which are an additional layer built on top of conventional
regular-expression search patterns. In MPW, selection expressions are
mainly used with the Find and Replace commands: Find selects something
in an editor window, while Replace selects something and replaces it
with something else. These commands can be used in various ways, for
example"Find /regexp/
"searches forward from the current position for a match for regexp,
while"Find \regexp\
"searches backward from the current position. So far, perhaps, not much
more than you can do with normal UNIX regular expressions. Until you
come to constructs like"Find selection1:selection2
"which selects everything from a match for selection1 to a match for
selection2, inclusive (either or both may involve forwards or backwards
searches). Another valid form is"Find markername
where markername is the name of one of the markers previously defined
for this file"
There are other features not mentioned in this brief remark. Selection
expressions can themselves be parenthesized and a SE or and RE that
recognizes a range of characters can be adorned to indicate the
selection should be transformed to an insertion point at one or the
other end of the expression / match so adorned. With nesting via
parenthesis and range selection using colon, matching can proceed from
there.
One easy practical illustration of the increased power of selection
expressions is their ability to match C / C++ / Java comments,
something that can only be done in RE matchers with minimal-bite
options (which wasn't common, if it existed at all, at the time of
MPW's heyday).
Here's the definitive specification of Selection Expressions:
<http://developer.apple.com/tools/mpw-tools/commandref/appc_expression.html>.
Don't be put off by the liberal use of the extended Macintosh character
set. A transliteration to a more universally available (at the
keyboard) notation would be required, of course.
The "Find" command's man page supplies some useful context:
<http://developer.apple.com/tools/mpw-tools/commandref/find.html>
Selection Expressions can be little hard to get your head around and
they're not the easiest things to work with, but in combination with
scripting or, more to the point, mode files, they're quite a boon in
things like program analysis, navigation and synthesis, not to mention
syntax highlighting.
Date: Today 04:01:29 pm
On Sunday 25 June 2006 15:34, Marcelo Vanzin wrote:
> Adding my two bits.
> Having a full-fledged grammar-based parser would not only make
> highlighting more accurate, but also would make all the
> <insertLanguageHere>SideKick implementations just a specialization of
> the syntax highlighting/parsing system.
Seems important to distinguish between the two ideas.
#1 incremental parser generator as a new component in the core. A great idea
I heartily support and would try to make time to contribute to.
#2 selection expressions: a new feature for users built on top of regex and
independent of #1. I like this idea too and it's not a fundamental change
like #1. This one is, I think, a fairly easy task and could be a implemented
— at least at first — as a plugin.
Re: [ jEdit-devel ] History's Lessons: Regular Expressions vs. Selection Expressions
Date: Today 05:09:32 pm
Andy,
I agree with this analysis. Clearly having the ability to incrementally
(and in an error-tolerant, recoverable manner) build proper syntax
trees for the code being edited would open up many opportunities.
Ultimately, we could have an editor as good as jEdit already is at
basic editing with the kind of language-specific programming support
associated with Eclipse or Idea. That would make it quite the
stand-out. ... As if it isn't already.
And in the meantime, selection expressions, in addition to their
inherent value, might be useful in improving syntax highlighting.
What would be even better for me personally (I'm not all that big on
syntax colorization, though I've become gradually accustomed to it)
would be better auto-indent. Right now, jEdit's got big problems in
that department. I use a lot of {@link ClassName} and such in my
JavaDoc comments, as well as a lot of deeply indented, columnar
formatting, and both of these make jEdit's auto-indent shortcomings
glaringly obvious (to me, anyway).
