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 9:55 AM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote: > Alexey Radul <axch@xxxxxxx> wrote: >> Then I strongly recommend you try [Paredit]... > > Okay, I'll give Paredit a whirl. > >> ... May I suggest writing an Emacs mode for >> sweet-expressions as a fitting project for learning Paredit? > > I'm hoping someone else will pick up the "write an emacs mode" part; > I don't have unlimited time, and I expect serious emacs mode > creation to take time. But I can certainly sit down > and try fiddling with Paredit. That's all I ask :) > Hopefully [Paredit] mode won't launch me into a dystopian world where I have > to eat snot for breakfast :-). They say that ignorance is bliss... >> > 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, > > Agreed, but you then have to move the cursor to what you're looking at. > My eyes can move faster than my hands. Only when the thing you want is already on the screen. >> 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. > > In sweet-expressions the indentation should be clear to start with, since > it's actually *used*. Oh, I was referring to expressions indented perfectly according to style that are still complex enough not to pop out. It's nice to be able to inspect the real parse tree in a non-intrusive way. ~Alexey