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

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

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.

The one trick is, in
! bar
does forward-<anything>-sexp scope over just foo, or all of foo and
bar?  With actual s-expressions, there would be an explicit open paren
there, so whether the cursor was in front of or behind it would
determine the answer.  The immortality of having implemented an
excellent editor mode awaits anyone who can solve this problem (in a
coherent and useful way).


On Thu, Aug 8, 2013 at 10:44 PM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote:
> 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:
>   http://www.emacswiki.org/emacs/ParEdit
> Demo:
>   http://emacsrocks.com/e14.html
> 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:
> foo
> ! bar |baz
> ! quux
> ! zot
> ==>
> foo
> ! bar |baz quux
> ! zot