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.
On Mon, May 27, 2013 at 12:44 AM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote: > Alexey Radul <axch@xxxxxxx> 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."