Okay, here's a cut at the semantisc of a "limited" form of ParEdit for
indentation, which I shall dub IndEndit, just to screw with everyone's
tongues.

1.  Consider an indentation expression (t-expr) as being composed of
n-expressions.

1.1.  n-expressions are just s-expressions plus the added forms in
SRFI-105.  Basically, the only difference to ParEdit is that {} are
considered as another expression-delimiting pair aside from (), and
that a symbol that has a { or ( right after it without a space is
considered as part of the () or {} expression right after it.

; basically, SRFI-105 is a relatively small patch on top of ParEdit, I
think.  One view of SRFI-110 (which is obscured by the long BNF) is
that t-expressions are just made of up of n-expressions separated by
syntactically-significant whitespace; this meant also that falling
back to s-expressions is *trivial*.  In fact, earlier versions of the
code used this view, but this version was discarded and the SRFI
re-implemented since we desired the automatic BNF checking of ANTLR,
and desired to follow the ANTLR code more closely in the parser.

2.  If the cursor is at the start of a line (after indentation chars,
i.e. space tab and bang) then the extent of the expression is
considered as being up to the next non-comment line at or with lesser
indentation.

Sincerely,
AmkG

On 5/27/13, Alexey Radul <xxxxxx@mit.edu> wrote:
> On Mon, May 27, 2013 at 12:44 AM, David A. Wheeler
> <xxxxxx@dwheeler.com> wrote:
>> Alexey Radul <xxxxxx@mit.edu> wrote:
>>
>>> I don't know whether anyone else on this list uses Emacs' Paredit mode
>>> http://www.emacswiki.org/emacs/ParEdit to edit their S-expressions,
>>
>> I haven't used Paredit mode, sorry.
>
> Then I strongly recommend you try it.  I think anyone who takes syntax
> design seriously, as you clearly do, should be familiar with the
> best-in-class editing tools, lest their design should accidentally
> impede their adaptaion.  May I suggest writing an Emacs mode for
> sweet-expressions as a fitting project for learning Paredit?
>
>>> ... In any case,
>>> I submit that sweet-expressions would become a much more powerful and
>>> effective notation if they were to obey the Paredit Property -- or,
>>> more broadly, if someone were to implement Paredit mode for them.
>>
>> Advanced editing modes are definitely desirable!!
>> I think there's a reluctance to spend a lot of time creating editing
>> modes
>> when the notation itself is still in flux.
>
> My point was that this reluctance, while understandable, is dangerous.
> Choices made in the design of the notation have consequences for the
> ease of implementation of advanced editing modes.
>
>> ... I certainly hope to see cool modes
>> in the future.
>>
>> I *do* believe that sweet-expressions
>> can be well-supported by an editing mode.
>> Heck, people manage to support Python (which is indentation-sensitive)
>> and C++ (which is notoriously hard to parse) with fancy editing modes.
>> Compared to them, sweet-expressions should be a snap :-).
>
> Oh, certainly there are editing modes for Python and C++.  I have had
> the good fortune of not needing them, but I have tried the
> community-recommended editing modes for Ruby and Haskell, and Paredit
> is just a level above.  Heck, I find even Eclipse, with all its fancy
> refactorings, to still be slower and less pleasant, on balance, than
> Paredit (though maybe that's because I haven't written anything except
> Java in Eclipse).  You're editing the syntax tree, not the text file.
> I cannot tell you what editing with Paredit is; you have to experience
> it for yourself.
>
>>> P.P.S. I was motivated to write this note in part because of the
>>> recurrent complaint about 10 closing parens being hard to distinguish
>>> from 12.  In the presence of Paredit mode this is simply a
>>> non-problem.  Paredit maintains the invariant that one's s-expressions
>>> are always well-formed (e.g., typing '(' inserts "()"; typing ')'
>>> inserts nothing but moves the next ")" to the cursor and steps over
>>> it; etc).
>>
>> That *invariant* I completely buy in to.
>> I have a long-standing habit of always typing the closing paren if
>> I'm using an editor that won't do it for me.
>
> What I can't stand are tools that add the closing paren when I type an
> open paren, but then add another closing paren when I type a closing
> paren, producing unopened items.  I had neglected to mention another
> of Paredit's design goals: it doesn't force you to change how you
> type.  If you just type as if Paredit is off, Paredit will do the
> right thing.
>
>> An editor can help you when you're *typing*, but it's far less helpful
>> when *reading*
>> the code.
>
> I'm actually not sure I agree with that.  Navigating to the definition
> of an item one is looking at is extremely helpful when reading code,
> though this has precious little to do with the syntax.  However, I
> find that show-paren-mode solves the paren-matching problem quite
> nicely for reading -- just put your cursor on a paren you are curious
> about and the matching one lights up.  Which, in an s-expression
> syntax, means that I can always see the bounds of any node in the
> parse tree.  Together with the s-expression navigation commands (next
> sexp, previous sexp, enclosing sexp, etc), this produces a
> higher-level reading experience than paper, which is essentially
> linear.
>
> In practice, of course, I mainly use the indentation to group what I'm
> reading, and rely on show-paren-mode and s-expression navigation
> commands as reading aids only when the indentation is not sufficiently
> clear.  However, inventing a mechanism not to break these two things
> would also be advantageous.  Alas, I do not have a specific suggestion
> to offer -- except to advocate Paredit mode to you, as something
> valuable that s-expressions have, and that may be worth effort to
> keep.
>
> Best,
> ~Alexey
>
> P.S. I think this kind of read/write tool support may have something
> to do with what people mean when they say "the parens just fade away."
>
>