[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Thoughts on sweet-expression editor modes (including ParEdit operations)

Clearly editor modes are important for sweet-expressions.
I've looked into this a little, and I think editor modes for sweet-expressions
should be fairly easy to build.  Below are some thoughts, esp. relating to ParEdit,
in case anyone wants to discuss them.  My I hope is that
I can convince someone to implement one :-).

--- David A. Wheeler


Sweet-expression editor modes have to figure out where
lists begin and end; outside of (), this primarily involves
comparing indent levels.  So that shouldn't be bad.
Also, the Scheme reference implementation must deal with
the problem that Scheme has no portable multi-character peeking;
an editor has no such limit, making it significantly easier to do.

One editor mode in particular that was pointed out to me is ParEdit:

ParEdit helps "keep parentheses balanced" - something I normally
do with s-expressions also.  That isn't needed as much in
sweet-expressions, because indents and outdents have
the same effect as paren-balancing outside of (), [], and {}.

Perhaps a more interesting feaure of ParEdit is its AST-like
manipulation functions. It several keys infer certain operations,
and it even defines special list-processing
operations (e.g., slurp, barf, convolute).

For example, here's a forward-slurp-sexp operation,
where "|" is the current cursor position: 	
(foo (bar |baz) quux zot)
(foo (bar |baz quux) zot)

But it appears to me that an editor mode for sweet-expressions
can do the same thing.  It'd need to deal with parens vs.
multi-line cases, but it doesn't look hard.
The same example could look like this:

; single-line forward slurp:
foo bar(|baz) quux zot
foo bar(|baz quux) zot

; multi-line forward slurp:
! bar |baz
! quux
! zot
! bar |baz quux
! zot