Re: parinfer-mode for Emacs might be neat for encouraging Lisp adoption

[Oleh Krehel <ohwoeowho@gmail.com>]

João Távora <joaotavora@gmail.com> writes:

> On Fri, Nov 13, 2015 at 3:34 PM, Oleh Krehel <ohwoeowho@gmail.com> wrote:
>> João Távora <joaotavora@gmail.com> writes:
>>
>>> Hi Oleh,
>>>
>>> What do you think of this prototype?
>
>> I think this is what `aggresive-indent-mode' does. Additionally "DEL" on
>> `let*' doesn't work for me for some reason.
>
> Ahaha. Right. That's what I get for not reading up on prior art :-)
>
>> I've disabled it long time ago, since I use lispy. But I tried just now
>> and the interactive variant of this doesn't work in `electric-pair-mode':
>>
>> (progn
>>   (kill-new "(foo")
>>   (yank))
>
> What do you mean, it doesn't work what did you expect to happen?

Well, suppose it was Parinfer-like. Then it would either modify "(foo"
to either "foo" or "(foo)". That's what I meant: automatic re-balancing
after each buffer change.

> electric-pair-mode only kicks in when inserting parenthesis interactively.

I understand. I'm saying that neither Parinfer, nor lispy, nor
electic-pair-mode solves the problem of pasting "(foo".

>> The thing with lispy is that you get /extra/ free shortcuts only for
>> LISP. These free shortcuts are possible to get only for LISP because of
>
> To be fair to lispy, probably also for JSON and some other languages.

You can enable lispy for JSON. I just checked, "C" (`lispy-convolute')
still works. Even "w" (`lispy-move-up') sort-of works :)

>> the
>> The first `forward-list' will work fine, but the second one will
>> throw. Why not just call `up-list' in that case?
>> "]" (`lispy-forward') is `forward-list' with exactly that modification.
>
> I like that it forbids me to go past the end of the list. I even use that
> for programming without looking at the computer. Just forward list a
> million times until you hear the bell.

Also a feature in lispy: "99j" or "999]" or "99>" will not exit the
parent list.

> I understand lispy's convenience philosophy, but it's undeniable that
> it expands the instruction set. I'm after the low hanging fruit: keep
> the same reduced instruction set and have Emacs resonably guess
> what I'm trying to do.

It's a reasonable choice, although I made a different one.
What I try to do is to use an extended instruction set until I sieve out
a super-efficient subset of that instruction set.

For example, "j" is usually a better command than "C-M-n". In plain
Emacs terms, from the left paren, "j" translates to "C-M-n C-M-n C-M-p",
i.e. it selects the next sexp while staying on the same side (left or
right).