on adding a function call to a s-exp

on adding a function call to a s-exp

[Robert Girault]

In Lisp mode, when I select a region, in whatever way of selecting it,
and press (, it surrounds the region with parentheses, (...|), but it
puts the point where ``|'' is.  I'd like the point to be at (|...) so
I can add a function call to that region without having to move the
point back to the beginning of the region.

I'm surprised this isn't the default behavior.  Is there a minor mode
or something that makes that the default?  I'd like use it if so
because it means the mode and myself think alike, so there may other
good things in there for me.

Thank you!

Re: on adding a function call to a s-exp

[Noam Postavsky]

On 9 June 2018 at 18:05, Robert Girault <rfrancoisgirault@gmail.com> wrote:
> In Lisp mode, when I select a region, in whatever way of selecting it,
> and press (, it surrounds the region with parentheses, (...|), but it

Hmm, that must be some package you have installed, by default ( just
inserts a ( at point without wrapping anything.

> puts the point where ``|'' is.  I'd like the point to be at (|...) so
> I can add a function call to that region without having to move the
> point back to the beginning of the region.
>
> I'm surprised this isn't the default behavior.

In emacs -Q M-( does what you want.

  M-( runs the command insert-parentheses (found in global-map), which
  is an interactive compiled Lisp function in ‘lisp.el’.

  It is bound to M-(.

  (insert-parentheses &optional ARG)

  Enclose following ARG sexps in parentheses.
  Leave point after open-paren.
  [...]
  If region is active, insert enclosing characters at region boundaries.

Re: on adding a function call to a s-exp

[João Távora]

On Sun, Jun 10, 2018 at 3:38 AM, Noam Postavsky <npostavs@gmail.com> wrote:

> On 9 June 2018 at 18:05, Robert Girault <rfrancoisgirault@gmail.com>
> wrote:
> > In Lisp mode, when I select a region, in whatever way of selecting it,
> > and press (, it surrounds the region with parentheses, (...|), but it
>
> Hmm, that must be some package you have installed, by default ( just
> inserts a ( at point without wrapping anything.
>
> > puts the point where ``|'' is.  I'd like the point to be at (|...) so
> > I can add a function call to that region without having to move the
> > point back to the beginning of the region.
> >
> > I'm surprised this isn't the default behavior.
>
> In emacs -Q M-( does what you want.
>
>   M-( runs the command insert-parentheses (found in global-map), which
>   is an interactive compiled Lisp function in ‘lisp.el’.
>
>   It is bound to M-(.
>
>   (insert-parentheses &optional ARG)
>
>   Enclose following ARG sexps in parentheses.
>   Leave point after open-paren.
>   [...]
>   If region is active, insert enclosing characters at region boundaries.
>
> Additionally, if the "autopairing/autowrapping" package you are using is
Emacs's built-in M-x electric-pair-mode, it should work exactly as you
explain: "(" leaves the point after the opener and ")" leaves point after
the closer (and both wrap the region, obviously).

João




-- 
João Távora

Re: on adding a function call to a s-exp

[Robert Girault]

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

> On Sun, Jun 10, 2018 at 3:38 AM, Noam Postavsky <npostavs@gmail.com> wrote:
>
>> On 9 June 2018 at 18:05, Robert Girault <rfrancoisgirault@gmail.com>
>> wrote:
>> > In Lisp mode, when I select a region, in whatever way of selecting it,
>> > and press (, it surrounds the region with parentheses, (...|), but it
>>
>> Hmm, that must be some package you have installed, by default ( just
>> inserts a ( at point without wrapping anything.
>>
>> > puts the point where ``|'' is.  I'd like the point to be at (|...) so
>> > I can add a function call to that region without having to move the
>> > point back to the beginning of the region.
>> >
>> > I'm surprised this isn't the default behavior.
>>
>> In emacs -Q M-( does what you want.
>>
>>   M-( runs the command insert-parentheses (found in global-map), which
>>   is an interactive compiled Lisp function in ‘lisp.el’.
>>
>>   It is bound to M-(.
>>
>>   (insert-parentheses &optional ARG)
>>
>>   Enclose following ARG sexps in parentheses.
>>   Leave point after open-paren.
>>   [...]
>>   If region is active, insert enclosing characters at region boundaries.
>>
>> Additionally, if the "autopairing/autowrapping" package you are using is
> Emacs's built-in M-x electric-pair-mode, it should work exactly as you
> explain: "(" leaves the point after the opener and ")" leaves point after
> the closer (and both wrap the region, obviously).

I do not confirm this.  Try this: emacs -Q

  + 1 2 3 C-a C-space C-e M-(

it will leave the point at where the | character is in ``(+ 1 2 3|)''.
It could a version difference.  I'm running 

  GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN

Thanks!

Re: on adding a function call to a s-exp

[Noam Postavsky]

On 10 June 2018 at 21:04, Robert Girault <rfrancoisgirault@gmail.com> wrote:

>>> In emacs -Q M-( does what you want.

>> Additionally, if the "autopairing/autowrapping" package you are using is
>> Emacs's built-in M-x electric-pair-mode, it should work exactly as you
>> explain: "(" leaves the point after the opener and ")" leaves point after
>> the closer (and both wrap the region, obviously).
>
> I do not confirm this.  Try this: emacs -Q
>
>   + 1 2 3 C-a C-space C-e M-(
>
> it will leave the point at where the | character is in ``(+ 1 2 3|)''.
> It could a version difference.  I'm running
>
>   GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN

Yes, I see that too up to version 24.5. In Emacs 25.3 and up (I can't
build 25.1 successfully here) M-( behaves like you want.

Re: on adding a function call to a s-exp

[João Távora]

On Mon, Jun 11, 2018 at 2:30 AM, Noam Postavsky <npostavs@gmail.com> wrote:

> On 10 June 2018 at 21:04, Robert Girault <rfrancoisgirault@gmail.com>
> wrote:
>
> >>> In emacs -Q M-( does what you want.
>
> >> Additionally, if the "autopairing/autowrapping" package you are using is
> >> Emacs's built-in M-x electric-pair-mode, it should work exactly as you
> >> explain: "(" leaves the point after the opener and ")" leaves point
> after
> >> the closer (and both wrap the region, obviously).
> >
> > I do not confirm this.  Try this: emacs -Q
> >
> >   + 1 2 3 C-a C-space C-e M-(
> >
> > it will leave the point at where the | character is in ``(+ 1 2 3|)''.
> > It could a version difference.  I'm running
> >
> >   GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN
>
> Yes, I see that too up to version 24.5. In Emacs 25.3 and up (I can't
> build 25.1 successfully here) M-( behaves like you want.
>
> Noam, are you taking about `(' or `M-('? I was referring to the former,
when combined with a "M-x electric-pair-mode".
I would be surprised it doesn't work like that in 24.4 (can't check now
though, my build segfauls for some reason).

-- 
João Távora

Re: on adding a function call to a s-exp

[Noam Postavsky]

On 12 June 2018 at 10:40, João Távora <joaotavora@gmail.com> wrote:

>> Yes, I see that too up to version 24.5. In Emacs 25.3 and up (I can't
>> build 25.1 successfully here) M-( behaves like you want.
>>
> Noam, are you taking about `(' or `M-('? I was referring to the former,
> when combined with a "M-x electric-pair-mode".

I was talking about `M-(' before. I can confirm `(' with "M-x
electric-pair-mode" does the right thing in 24.4.

> I would be surprised it doesn't work like that in 24.4 (can't check now
> though, my build segfauls for some reason).

I needed to backport "Emacs shouldn't segfault when gcc expects
-nopie" (99892eee) to make it work.

Re: on adding a function call to a s-exp

[Robert Girault]

Noam Postavsky <npostavs@gmail.com> writes:

> On 10 June 2018 at 21:04, Robert Girault <rfrancoisgirault@gmail.com> wrote:
>
>>>> In emacs -Q M-( does what you want.
>
>>> Additionally, if the "autopairing/autowrapping" package you are using is
>>> Emacs's built-in M-x electric-pair-mode, it should work exactly as you
>>> explain: "(" leaves the point after the opener and ")" leaves point after
>>> the closer (and both wrap the region, obviously).
>>
>> I do not confirm this.  Try this: emacs -Q
>>
>>   + 1 2 3 C-a C-space C-e M-(
>>
>> it will leave the point at where the | character is in ``(+ 1 2 3|)''.
>> It could a version difference.  I'm running
>>
>>   GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN
>
> Yes, I see that too up to version 24.5. In Emacs 25.3 and up (I can't
> build 25.1 successfully here) M-( behaves like you want.

Good to know things are evolving in a way I'd approve! :-)

Re: on adding a function call to a s-exp

[João Távora]

On Mon, Jun 11, 2018 at 2:04 AM, Robert Girault <rfrancoisgirault@gmail.com>
wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > On Sun, Jun 10, 2018 at 3:38 AM, Noam Postavsky <npostavs@gmail.com>
> wrote:
> >
> >> On 9 June 2018 at 18:05, Robert Girault <rfrancoisgirault@gmail.com>
> >> wrote:
> >> > In Lisp mode, when I select a region, in whatever way of selecting it,
> >> > and press (, it surrounds the region with parentheses, (...|), but it
> >>
> >> Hmm, that must be some package you have installed, by default ( just
> >> inserts a ( at point without wrapping anything.
> >>
> >> > puts the point where ``|'' is.  I'd like the point to be at (|...) so
> >> > I can add a function call to that region without having to move the
> >> > point back to the beginning of the region.
> >> >
> >> > I'm surprised this isn't the default behavior.
> >>
> >> In emacs -Q M-( does what you want.
> >>
> >>   M-( runs the command insert-parentheses (found in global-map), which
> >>   is an interactive compiled Lisp function in ‘lisp.el’.
> >>
> >>   It is bound to M-(.
> >>
> >>   (insert-parentheses &optional ARG)
> >>
> >>   Enclose following ARG sexps in parentheses.
> >>   Leave point after open-paren.
> >>   [...]
> >>   If region is active, insert enclosing characters at region boundaries.
> >>
> >> Additionally, if the "autopairing/autowrapping" package you are using is
> > Emacs's built-in M-x electric-pair-mode, it should work exactly as you
> > explain: "(" leaves the point after the opener and ")" leaves point after
> > the closer (and both wrap the region, obviously).
>
> I do not confirm this.  Try this: emacs -Q
>
>   + 1 2 3 C-a C-space C-e M-(
>
> it will leave the point at where the | character is in ``(+ 1 2 3|)''.
> It could a version difference.  I'm running
>
>   GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN
>
> Oh then I take it back, the improved electric-pair-mode only made it in
24.4.

BTW why are you running a 5year+ old emacs version?

João

Re: on adding a function call to a s-exp

[Robert Girault]

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

[...]

>> > Emacs's built-in M-x electric-pair-mode, it should work exactly as you
>> > explain: "(" leaves the point after the opener and ")" leaves point after
>> > the closer (and both wrap the region, obviously).
>>
>> I do not confirm this.  Try this: emacs -Q
>>
>>   + 1 2 3 C-a C-space C-e M-(
>>
>> it will leave the point at where the | character is in ``(+ 1 2 3|)''.
>> It could a version difference.  I'm running
>>
>>   GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN
>>
>> Oh then I take it back, the improved electric-pair-mode only made it in
> 24.4.
>
> BTW why are you running a 5year+ old emacs version?

I put it together in 2015, actually.  It should be 3 years old.  I must
taken taken it from the GNU people.  My habit is to always get software
directly from the authors.  I hate to upgrade to find out old things I
liked are gone or find new broken things.  But eventually I guess I'll
upgrade.

Re: on adding a function call to a s-exp

[Xavier Maillard]

> From: Robert Girault <rfrancoisgirault@gmail.com>
> Date: Sat, 09 Jun 2018 19:05:16 -0300
> 
> In Lisp mode, when I select a region, in whatever way of selecting it,
> and press (, it surrounds the region with parentheses, (...|), but it
> puts the point where ``|'' is.  I'd like the point to be at (|...) so
> I can add a function call to that region without having to move the
> point back to the beginning of the region.

I just do M-( and it lets the point after the open parenthesis.


-- 
Xavier Maillard                      
e/j:xavier@maillard.im               w:www.maillard.im
m: 06 52 18 63 43
GPG: 9983 DCA1 1FAC 8DA7 653A  F9AA BA49 09B7 8F04 DE1B

Re: on adding a function call to a s-exp

[Robert Girault]

Noam Postavsky <npostavs@gmail.com> writes:

> On 9 June 2018 at 18:05, Robert Girault <rfrancoisgirault@gmail.com> wrote:
>> In Lisp mode, when I select a region, in whatever way of selecting it,
>> and press (, it surrounds the region with parentheses, (...|), but it
>
> Hmm, that must be some package you have installed, by default ( just
> inserts a ( at point without wrapping anything.

You're correct.  I had actually:

(show-paren-mode)
(electric-pair-mode)
(autoload 'enable-paredit-mode "paredit"
    "Turn on pseudo-structural editing of Lisp code."
     t)
(add-hook 'M-mode-hook 'enable-paredit-mode)

>> puts the point where ``|'' is.  I'd like the point to be at (|...) so
>> I can add a function call to that region without having to move the
>> point back to the beginning of the region.
>>
>> I'm surprised this isn't the default behavior.
>
> In emacs -Q M-( does what you want.
>
>   M-( runs the command insert-parentheses (found in global-map), which
>   is an interactive compiled Lisp function in ‘lisp.el’.
>
>   It is bound to M-(.
>
>   (insert-parentheses &optional ARG)
>
>   Enclose following ARG sexps in parentheses.
>   Leave point after open-paren.
>   [...]
>   If region is active, insert enclosing characters at region boundaries.

Where the point ends up depends on how one selects the region.  If the
region is selected from end to beginning, the point ends up on the
opening (.  If from beginning to end, after the closing ).

My desire is to always leave it after the opening ( because I think
whenever I surround a region with parentheses, it's usually because I'll
apply a function to that region.  This is the default behavior in
DrRacket.

Is there any minor mode that does or should I hack something up?  Thanks!

Re: on adding a function call to a s-exp

[Michael Heerdegen]

Robert Girault <rfrancoisgirault@gmail.com> writes:

> (show-paren-mode)
> (electric-pair-mode)
> (autoload 'enable-paredit-mode "paredit"
>     "Turn on pseudo-structural editing of Lisp code."
>      t)
> (add-hook 'M-mode-hook 'enable-paredit-mode)

I don't know what M-mode is, but in elisp-lisp-mode and with paredit,
it's like you want.  If you use paredit for Emacs Lisp, you probably
also don't need electric-pair-mode.

Without paredit-mode, AFAICT what you get when you hit M-( is
`insert-pair' via `insert-parentheses', and that has hardcoded what you
see.  You would have to change `insert-pair' to get what you want - with
an advice probably.  Alternatively, as said, paredit should behave as
you want without configuration.


Michael.

Re: on adding a function call to a s-exp

[Michael Heerdegen]

I <michael_heerdegen@web.de> wrote:

> If you use paredit for Emacs Lisp, you probably also don't need
> electric-pair-mode.

I mean, they shouldn't interfere, however, `electric-pair-mode' is a
global mode.  I always forget that people don't use Emacs only for
hacking Elisp...


Michael.

Re: on adding a function call to a s-exp

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Without paredit-mode, AFAICT what you get when you hit M-( is
> `insert-pair' via `insert-parentheses', and that has hardcoded what
> you see.

That was also an unripe answer.  As Noam has mentioned, what is
hardcoded in later Emacsen is actually the behavior you want.


Michael.

Re: on adding a function call to a s-exp

[Robert Girault]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Robert Girault <rfrancoisgirault@gmail.com> writes:
>
>> (show-paren-mode)
>> (electric-pair-mode)
>> (autoload 'enable-paredit-mode "paredit"
>>     "Turn on pseudo-structural editing of Lisp code."
>>      t)
>> (add-hook 'M-mode-hook 'enable-paredit-mode)
>
> I don't know what M-mode is, but in elisp-lisp-mode and with paredit,
> it's like you want.  If you use paredit for Emacs Lisp, you probably
> also don't need electric-pair-mode.

I confirm this.  (Thanks!)

> Without paredit-mode, AFAICT what you get when you hit M-( is
> `insert-pair' via `insert-parentheses', and that has hardcoded what you
> see.  You would have to change `insert-pair' to get what you want - with
> an advice probably.  Alternatively, as said, paredit should behave as
> you want without configuration.

I'll choose to use paredit and learn how to use it properly.  (There'll
likely be other good things there that I don't currently know or use.)

Re: on adding a function call to a s-exp

[João Távora]

On Mon, Jun 11, 2018 at 3:35 PM, Robert Girault <rfrancoisgirault@gmail.com>
wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > Robert Girault <rfrancoisgirault@gmail.com> writes:
> >
> >> (show-paren-mode)
> >> (electric-pair-mode)
> >> (autoload 'enable-paredit-mode "paredit"
> >>     "Turn on pseudo-structural editing of Lisp code."
> >>      t)
> >> (add-hook 'M-mode-hook 'enable-paredit-mode)
> >
> > I don't know what M-mode is, but in elisp-lisp-mode and with paredit,
> > it's like you want.  If you use paredit for Emacs Lisp, you probably
> > also don't need electric-pair-mode.
>
> I confirm this.  (Thanks!)
>
> > Without paredit-mode, AFAICT what you get when you hit M-( is
> > `insert-pair' via `insert-parentheses', and that has hardcoded what you
> > see.  You would have to change `insert-pair' to get what you want - with
> > an advice probably.  Alternatively, as said, paredit should behave as
> > you want without configuration.
>
> I'll choose to use paredit and learn how to use it properly.  (There'll
> likely be other good things there that I don't currently know or use.)
>

I suggest you also give (the newer, 24.4+) eletric-pair-mode a try.  It
should work consistently in all emacs major modes, not just lisp
modes, and is maintained together with Emacs. By default, in
emacs-lisp-mode you won't notice a difference to paredit for the most
common operations (you *will* notice that it lets you unbalance the
buffer temporarily though, but I consider that a feature).

disclaimer, if you hadn't figured it out: I wrote it :-)

João

Re: on adding a function call to a s-exp

[Óscar Fuentes]

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

>> I'll choose to use paredit and learn how to use it properly.  (There'll
>> likely be other good things there that I don't currently know or use.)
>>
>
> I suggest you also give (the newer, 24.4+) eletric-pair-mode a try.  It
> should work consistently in all emacs major modes, not just lisp
> modes, and is maintained together with Emacs. By default, in
> emacs-lisp-mode you won't notice a difference to paredit for the most
> common operations (you *will* notice that it lets you unbalance the
> buffer temporarily though, but I consider that a feature).

electric-pair-mode offers a tiny fraction of the features of paredit.
The later takes some time to learn, but in my experience the effort pays
off if you work with lispy languages.

RE: on adding a function call to a s-exp

[Drew Adams]

> electric-pair-mode offers a tiny fraction of the features of paredit.
> The later takes some time to learn, but in my experience the effort
> pays off if you work with lispy languages.

FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
don't use any "structured-editing" feature (crutch / ball-&-chain)
such as `paredit' or `electric-pair-mode'.  I'm non-electric all
the way.

I use only (1) the usual keys to indent, move over & around sexps,
transpose sexps, etc.; (2) `show-paren-mode', `blink-matching-paren';
and (3) (yes!) sometimes a mouse (double-click sexp select,
copy-kill-yank).

I've never had any problem with unbalanced parentheses, brackets,
braces, angle-brackets, double-quotes, etc.  Really _not_ a big
deal, IMHO.

To me, having an editor automatically insert a closing delimiter
each time I type an opening delimiter is a bother, not an aid.

Back in the 1980s (!) I briefly tried such slurp-barfing
"structured-editing" gimmicks.  Abandoned them quickly.  I
suppose one could become accustomed/habituated to using them,
and then see them as essential, but no one I knew ever did.

These features originated outside Emacs, BTW, in experimental
editors that were extremely rigid, based on the brilliant idea
that editing operations should always leave text "valid" in some
sense.  These were not editors designed & developed by users!

It was thought that users should be prevented/protected from
writing code that is not syntactically well formed.  That was
supposed to improve software reliability and programming
productivity.

No.  Users should instead have aids to (1) tell whether code is
well formed and (2) make it well formed (in different ways).

(Just one experience and one opinion.)

Re: on adding a function call to a s-exp

[João Távora]

On Tue, Jun 12, 2018 at 5:17 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > electric-pair-mode offers a tiny fraction of the features of paredit.
> > The later takes some time to learn, but in my experience the effort
> > pays off if you work with lispy languages.
>
> FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
> don't use any "structured-editing" feature (crutch / ball-&-chain)
> such as `paredit' or `electric-pair-mode'.  I'm non-electric all
> the way.
>

That's very reasonable too. Emacs already has great sexp-manipulating
commands (electric-pair-mode uses them). So, if you're disciplined to
use them, you don't need either package (though I still think e-p-m is
good when you momentarily lose your sexp-fu).

João Távora

Re: on adding a function call to a s-exp

[Andreas Röhler]

On 12.06.2018 18:17, Drew Adams wrote:
>> electric-pair-mode offers a tiny fraction of the features of paredit.
>> The later takes some time to learn, but in my experience the effort
>> pays off if you work with lispy languages.
> FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
> don't use any "structured-editing" feature (crutch / ball-&-chain)
> such as `paredit' or `electric-pair-mode'.  I'm non-electric all
> the way.
> 
> I use only (1) the usual keys to indent, move over & around sexps,
> transpose sexps, etc.; (2) `show-paren-mode', `blink-matching-paren';
> and (3) (yes!) sometimes a mouse (double-click sexp select,
> copy-kill-yank).
> 
> I've never had any problem with unbalanced parentheses, brackets,
> braces, angle-brackets, double-quotes, etc.  Really_not_  a big
> deal, IMHO.
> 
> To me, having an editor automatically insert a closing delimiter
> each time I type an opening delimiter is a bother, not an aid.

+1

Wrote a deliberately non-electric simple-paren WRT cases, where the 
closing delimiter should be inserted too:

https://github.com/andreas-roehler/simple-paren

Re: on adding a function call to a s-exp

[João Távora]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
> don't use any "structured-editing" feature (crutch / ball-&-chain)
> such as `paredit' or `electric-pair-mode'.  I'm non-electric all
> the way.
>
> To me, having an editor automatically insert a closing delimiter
> each time I type an opening delimiter is a bother, not an aid.

For the sake of improving electric-pair-mode, can you explain exactly
when/under what conditions it is a bother?

I'm asking because that's precisely what electric-pair-mode attempts: It
*doesn't* insert a closing delimiter "each time", only when it guesses
that it will not bother you.  If it is mis-guessing some situation I
would very much like to know about it.

João

RE: on adding a function call to a s-exp

[Drew Adams]

> > FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
> > don't use any "structured-editing" feature (crutch / ball-&-chain)
> > such as `paredit' or `electric-pair-mode'.  I'm non-electric all
> > the way.
> >
> > To me, having an editor automatically insert a closing delimiter
> > each time I type an opening delimiter is a bother, not an aid.
> 
> For the sake of improving electric-pair-mode, can you explain exactly
> when/under what conditions it is a bother?

A bother _to me_.  People are different.  People use Emacs
differently.

To me, it's a bother to care about the inserted closing
delimiters and where they might currently be - they just
get in my way.

I think that if you go the route of using such
delimiter-balancing "aids" you need to do it whole-hog.
The ability to have things automatically closed for you
_necessitates_ slurping, barfing, etc.

What you see as convenience, I see as workaround hacks,
needed only because you've turned on automatically closing
delimiters.

If things are pre-closed then, yes, of course you need
commands to pull stuff inside the closings and push stuff
outside the closings.  You want to add a list element?
OK, now you have to insert it before the proper closing
paren.

I don't want Emacs to assume where/when I want to close
a list, vector, string, etc.  I'll close it where/when
I want.

With Emacs it's _trivial_ to see which closing delimiter
corresponds to which opening delimiter.  If this were
not easy to see then, sure, maybe there would be a stronger
case for automatically inserting closing delimiters.

In Emacs it's almost impossible to accidentally leave
something unclosed or to close something in the wrong
place.  Automatic closing?  YAGNI.

> I'm asking because that's precisely what electric-pair-mode attempts: It
> *doesn't* insert a closing delimiter "each time", only when it guesses
> that it will not bother you.  If it is mis-guessing some situation I
> would very much like to know about it.

FWIW: DWIM too often really means _not_ "Do what I mean"
but "Do what some programmer thought would be cool to
guess I might mean."

I don't want Mr. Electric trying to second-guess where/when
I want to close something.  I don't need that kind of "help".

It's easier for me to know whether a paren is escaped or
inside a string or whatever than it is for some "smart"
code.  I know my intentions.  DWIM code can only guess
my intentions.  And when it guesses wrong I need to go
behind it an sweep up the droppings.

But as I say, everyone's different.  It's _good_, not bad,
that such electric-delimiter modes exist.  I don't argue
against them.  With Emacs, anyone can get what s?he wants.

Re: on adding a function call to a s-exp

[João Távora]

Sorry Drew, this was a very long-winded way to not an answer a
simple question.

I understand you just don't like Emacs guessing your intentions.
That's just fine.  I asked you for the sake of improving e-p-m *for
other users* if you could provide an example where it didn't correctly
guess your intentions.  Something like "Oh I wanted to put a x-and-y
here and your naughty package put it there instead". That was all I
asked.

What's more, the reason I ask this is because I completely agree
with you on your DWIM/sweep-up-the-droppings stance.

João

On Wed, Jun 13, 2018 at 3:39 PM, Drew Adams <drew.adams@oracle.com> wrote:

> > > FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
> > > don't use any "structured-editing" feature (crutch / ball-&-chain)
> > > such as `paredit' or `electric-pair-mode'.  I'm non-electric all
> > > the way.
> > >
> > > To me, having an editor automatically insert a closing delimiter
> > > each time I type an opening delimiter is a bother, not an aid.
> >
> > For the sake of improving electric-pair-mode, can you explain exactly
> > when/under what conditions it is a bother?
>
> A bother _to me_.  People are different.  People use Emacs
> differently.
>
> To me, it's a bother to care about the inserted closing
> delimiters and where they might currently be - they just
> get in my way.
>
> I think that if you go the route of using such
> delimiter-balancing "aids" you need to do it whole-hog.
> The ability to have things automatically closed for you
> _necessitates_ slurping, barfing, etc.
>
> What you see as convenience, I see as workaround hacks,
> needed only because you've turned on automatically closing
> delimiters.
>
> If things are pre-closed then, yes, of course you need
> commands to pull stuff inside the closings and push stuff
> outside the closings.  You want to add a list element?
> OK, now you have to insert it before the proper closing
> paren.
>
> I don't want Emacs to assume where/when I want to close
> a list, vector, string, etc.  I'll close it where/when
> I want.
>
> With Emacs it's _trivial_ to see which closing delimiter
> corresponds to which opening delimiter.  If this were
> not easy to see then, sure, maybe there would be a stronger
> case for automatically inserting closing delimiters.
>
> In Emacs it's almost impossible to accidentally leave
> something unclosed or to close something in the wrong
> place.  Automatic closing?  YAGNI.
>
> > I'm asking because that's precisely what electric-pair-mode attempts: It
> > *doesn't* insert a closing delimiter "each time", only when it guesses
> > that it will not bother you.  If it is mis-guessing some situation I
> > would very much like to know about it.
>
> FWIW: DWIM too often really means _not_ "Do what I mean"
> but "Do what some programmer thought would be cool to
> guess I might mean."
>
> I don't want Mr. Electric trying to second-guess where/when
> I want to close something.  I don't need that kind of "help".
>
> It's easier for me to know whether a paren is escaped or
> inside a string or whatever than it is for some "smart"
> code.  I know my intentions.  DWIM code can only guess
> my intentions.  And when it guesses wrong I need to go
> behind it an sweep up the droppings.
>
> But as I say, everyone's different.  It's _good_, not bad,
> that such electric-delimiter modes exist.  I don't argue
> against them.  With Emacs, anyone can get what s?he wants.
>



-- 
João Távora

RE: on adding a function call to a s-exp

[Drew Adams]

> I understand you just don't like Emacs guessing your intentions. That's just fine.  I asked you for the sake of improving e-p-m *for other users* if you could provide an example where it didn't correctly guess your intentions.  Something like "Oh I wanted to put a x-and-y here and your naughty package put it there instead". That was all I asked.  

Sorry, but I don't have an example.  As I said, I tried this
kind of thing _many_ moon ago.  You're better off getting
feedback from real users of the e-p-m code.  They will help
by pointing out any difficulties they run into.

To be clear, I'm not trying to convince anyone not to use
modes that automatically insert delimiters.  If that helps
someone, so much the better.  I chimed in only to say that
I'm one dinosaur who doesn't use such modes.  Nothing more.

Re: on adding a function call to a s-exp

[Andreas Röhler]

On 13.06.2018 12:44, João Távora wrote:
> Drew Adams <drew.adams@oracle.com> writes:
> 
>> FWIW (he ducks), I work with a Lispy language, Elisp ;-).  And I
>> don't use any "structured-editing" feature (crutch / ball-&-chain)
>> such as `paredit' or `electric-pair-mode'.  I'm non-electric all
>> the way.
>>
>> To me, having an editor automatically insert a closing delimiter
>> each time I type an opening delimiter is a bother, not an aid.
> 
> For the sake of improving electric-pair-mode, can you explain exactly
> when/under what conditions it is a bother?
> 
> I'm asking because that's precisely what electric-pair-mode attempts: It
> *doesn't* insert a closing delimiter "each time", only when it guesses
> that it will not bother you.  If it is mis-guessing some situation I
> would very much like to know about it.
> 
> João
> 

Hi João,

after being interested resp. impressed by electric behavior at earlier 
times, finally switched off all electric in all modes.

Coding circumstances are a way too complex to foresee all reliably. In 
the result electric might work mostly but never completely. If it fails, 
you might have for switch it off. Which needs to identify which electric 
caused it. This will be a pain for the beginner, it breaks the workflow 
in any case.

Cheers,

Andreas

Re: on adding a function call to a s-exp

[João Távora]

Hi Andreas,

I accept that, and it's fine.

But instead of providing a speculative argument that "it will be a
pain eventually" you could provide a concrete case where it was
a pain in actuality.

With such examples I can, as the developer of the package, know if
the package is flawed in its DWIM guessing or if you were just editing
text in a very bizarre way (which, granted, isalways a subjective
judgement)

> Coding circumstances are a way too complex to foresee all reliably.

Indeed, let's say you're an eccentric programmer who likes to write
programs backwards, starting from the closing delimiter.  To write

  (+ 1 2)

you type

  ) <left> 2 <left> SPC <left> 1 <left> + <left> (

Then electric-pair-mode might be a nuisance (though I've just tried
this particular technique and it didn't misbehave).

João

Re: on adding a function call to a s-exp

[Emanuel Berg]

Távora wrote:

> DWIM guessing

One point regarding language: DWIM is far from
the computer "guessing" what the user wants!
Because the different actions are very
predictable based on the current state (which
is known, all clear and visible, and often part
of the workflow just one second ago), the Emacs
user is very aware of what is going on, and the
computer response is equally predictable!

Seeing the state is whatever it is, or setting
it up a certain way prior to invoking the DWIM
command, is thus part of executing the command
in the way that fits the situation!

So DWIM is a way to set up a natural, intuitive
workflow with less keys to memorize - it is not
the user being moronic, hitting the same key
for tons of purposes, and then have the
computer sweat in panic, trying to put together
something sensible of it!

There seems to be at least two definitions
of DWIM.

One is to do different things depending on if
some situation is or is not there. And it can
be based on something as simple as the position
of the cursor.

For example, in dired, if there is a file at
point, kill its path; if there isn't, kill the
path of the directory. As in:

    (defun dired-kill-path-dwim ()
      (interactive)
      (kill-new
       (or (dired-get-filename nil t)    ; kill file including path; or
           (dired-current-directory) ))) ; kill directory path if file u/a

The other, which is more undisputably DWIM, is
when you either use the region, or don't use
the region because there isn't one, and instead
fall back to a default behavior.

For example, to count the chars, if there is
a region, count the chars in the region, if
there isn't one, count the chars in the whole
buffer. As in:

    (defun count-chars (&optional start end)
      (interactive
       (if (use-region-p)
           (list (region-beginning) (region-end))
         (list (point-min) (point-max)) ))
      (message "%d" (- end start)) )

As you see, this is all-deterministic, no
guessing, and setting the state up is part of
executing the command. And that sounds
complicated and cool but actually it is
completely natural.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: on adding a function call to a s-exp

[João Távora]

Berg writes:

> As you see, this is all-deterministic, no guessing

It's simpler.  Most programs are deterministic (certainly mine try to
be).  When a program doesn't force you to fully consider the conditions
that determine its behaviour, and still does what you wanted, if can be
said to be guessing.  But it's really not, because it's a machine ;)

João

RE: on adding a function call to a s-exp

[Drew Adams]

> > DWIM guessing
> 
> DWIM is far from the computer "guessing" what the user wants!

Yes, that should be obvious.  It's a loose use of the
term "guess".  (It's more that users can have to guess
what's going on.)

> Because the different actions are very
> predictable based on the current state (which
> is known, all clear and visible, and often part
> of the workflow just one second ago), the Emacs
> user is very aware of what is going on, and the
> computer response is equally predictable!

Predictable in the code does not imply visible to
users and understood by them.

It doesn't follow that just because (1) the code of a
command is deterministic and can be well understood,
(2) a user understands it or knows what to expect.

The real problem comes when Emacs (e.g. by default)
substitutes a complex DWIM command for a clear command
with a simple behavior, e.g., by changing the default
key binding or by just redefining the command.

But just think about the name "DWIM".  It supposes
(claims) that the predictable behavior of the code
is just what you, a user, really want to happen in
your current context.  Really?  In that case, all
DWIM commands can be equally applied in any context,
and they all do what you want. ;-)

What it really comes down to, I think, is that some
programmer wrote a command that s?he thinks is handy
in some context, and s?he wants to get the point
across to users that it does different things, depending,
and that users will be happy with what it does, without
knowing just what or why.

The code assumes that if this, this, and that condition
hold then what the user wants is this behavior.  Yes, in
effect it's guessing what the user wants in that context.
The programmer guessed.  The user might be guessing too
(What's going on?).  But the code is deterministic.  

----

To be clear, I do define and use some commands that
one might call "DWIM".

But the possible alternative behaviors typically depend
on an explicit user choice, e.g., by using different
kinds of prefix arg.  Multiple behaviors are still
available on a single key, but they're picked by
explicit user action, not by context.

A _command_ picking a behavior based only on context
requires a user to understand what the context is, as
defined by that command.  Sometimes that's fine.
Sometimes it's not clear at all.

A _user_ picking a behavior pretty much guarantees that
s?he agrees with that choice (modulo misunderstanding).

Sure, in both cases a user might need to consult the
doc string of the command.  But in the case of explicit
user action the user at least (usually) knows what s?he
did and can figure out what the resulting behavior is
all about.

As an example of a quite complex command that I defined
and use, consider `secondary-yank|select|move|swap'.

Yes, someone else might have called it `secondary-dwim'
(and that's what I called it at first).  I prefer the name
I use now.  Anyway, you use it via a key (I use `C-M-y').

What does it do?  `C-h f' tells you:

__________________

 secondary-yank|select|move|swap is an interactive compiled Lisp
 function in ‘second-sel.el’.

 It is bound to C-M-y, menu-bar edit secondary-yank|select|move|swap.

 (secondary-yank|select|move|swap ARG)

 Yank the secondary selection.  With a prefix arg, interact with region.
 Prefix arg:

  None: Yank secondary.
  Zero: Select secondary as region.
  > 0:  Move secondary to region.
  < 0:  Swap region and secondary.

 Details:

 No prefix arg: Yank the secondary selection at point.  Move point to
 the end of the inserted text.  Leave mark where it was.

 Zero arg: Select the secondary selection and pop to its buffer.

 Non-zero arg: Move the secondary selection to this buffer’s region.

 Negative arg: Also go to where the secondary selection was and select
 it as the region.  That is, swap the region and the secondary
 selection.
__________________

So the default behavior is just to yank the secondary
selection.  In any context.  Doesn't matter whether the
moon is full or the coast is clear.  Same with each of
the alternative behaviors (which are used much less).

And each of those possible actions is also realized by a
separate command, so you are not _obliged_ to bind and
use only the complex command.

And the doc tells you what it does, and its name suggests
the combination that it is.

The name `secondary-dwim' tells you nothing, except that
there's some mystery to check out.

And not all DWIM commands have doc that accurately and
clearly describes context-dependent behavior.  Too often
they count on the behavior being "what someone would want",
and related to that assumption is the assumption that no
one needs to be told what they do.  Just try it - it'll do
what you want/expect.  No, not always; not so much.

Re: on adding a function call to a s-exp

[Emanuel Berg]

Drew Adams wrote:

> Predictable in the code does not imply
> visible to users and understood by them.
>
> It doesn't follow that just because (1) the
> code of a command is deterministic and can be
> well understood, (2) a user understands it or
> knows what to expect.

It is not an implication in the logical sense
but in practice it is what happens. If it
doesn't, either the DWIM implementation is
lacking, or the whole situation was unfit for
DWIM to begin with.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: on adding a function call to a s-exp

[João Távora]

On Tue, Jun 12, 2018 at 4:14 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> >> I'll choose to use paredit and learn how to use it properly.  (There'll
> >> likely be other good things there that I don't currently know or use.)
> >>
> >
> > I suggest you also give (the newer, 24.4+) eletric-pair-mode a try.  It
> > should work consistently in all emacs major modes, not just lisp
> > modes, and is maintained together with Emacs. By default, in
> > emacs-lisp-mode you won't notice a difference to paredit for the most
> > common operations (you *will* notice that it lets you unbalance the
> > buffer temporarily though, but I consider that a feature).
>
> electric-pair-mode offers a tiny fraction of the features of paredit.
> The later takes some time to learn, but in my experience the effort pays
> off if you work with lispy languages.
>

OK let's bikeshed a bit here :-)

What you say is of course true for some definition of tiny, and for
some definition of the disadvantages of being tiny, which, when
compared to being bloated, are very few.

Indeed, as you say, learning-curve-wise there are exactly 0 new
commands to learn in electric-pair-mode, versus 72 in paredit, a net
gain of infinity :-).

I would add that e-p-m also doesn't surprise newcomers regardless if
you're coming from another major mode, or from Window notepad.

My main gripe with paredit is not that it forces structural integrity,
it's that it doesn't force it completely: there are many situations
where it becomes confused.  Here's an example:

   "
   some string
   "  "
   another string
   "

In paredit, I must admit to liking that C-k in the first line blows
away the whole string: it's nice because doing so would unbalance the
buffer.  But annoingly, I can't C-k the middle line to join the two
strings, which would equally result in a balanced buffer.  And neither
does it kill both strings, which would be slightly more annoying but
still reasonable in paredit-land.  Instead it does nothing.  So I
select the line and kill the region.  Emacs now complies,
unconsistently and surpsingly.  And yep, as you've guessed it, I can
delete one of the quotes in middle line.  And now comes the worse
part, because trying to rebalance is impossible (bar C-q antics and
M-x paredit-mode to turn it off):

(1) typing a quote in the middle line gives you two quotes,
    leaving the buffer unbalanced.

(2) typing a quote in the last line gives you a "scan error" about
    unbalanced parentheses.

(3) As does trying to delete the last quote, that also signals an
    error.  And deleting the first line now errors, too. grrr :-)

In (1) and (2), electric-pair-mode would notice the temporary and only
insert one quote, after which it would of course resume autopairing
and autoskipping.

The example is only short for illustrative purposes: it can happen
when applying diff hunks or editing some merge-conflicted lisp file.
Or just if you happen to use the region.

João

PS: writing this in message-mode where smileys have special syntax so
electric-pair-mode keeps working :-)

Re: on adding a function call to a s-exp

[Eric Abrahamsen]

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

> My main gripe with paredit is not that it forces structural integrity,
> it's that it doesn't force it completely: there are many situations
> where it becomes confused. Here's an example:
>
> "
> some string
> " "
> another string
> "

M-J (paredit-join-sexp) :)

Not that I actually disagree with you: my least favorite paredit
behavior is that if you kill sentence in a docstring, it will eat up a
closing double quote, and then you're unbalanced.

I can't imagine how much work it would be to catch all the possible
cases where the buffer could be left unbalanced, though...

Re: on adding a function call to a s-exp

[Óscar Fuentes]

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

[...]

It is true that paredit is irritating sometimes, but very convenient
otherwise.

For the benefit of those who don't know it, let's put a simple example.
Suppose that you have:

(foo)
(bar)

but now you wish to wrap those function calls inside a conditional. So
you write:

(when something
(foo)
(bar))

Which requires moving the cursor through several lines just to add a
parenthesis.

With paredit, you write

(when something_)
(foo)
(bar)

(the underscore represents the position of the cursor). Now you can
incorporte the function calls inside the `when' with
paredit-forward-slurp-sexp.

Things like this, combined with aggressive-indent-mode, makes editing
Lispy languages quite pleasant, IMHO. In the past I worked like Drew
describes, which is fine, but now I need to worry less about putting the
parens on the right place. Paredit does that for me.

Re: on adding a function call to a s-exp

[Eric Abrahamsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> João Távora <joaotavora@gmail.com> writes:
>
> [...]
>
> It is true that paredit is irritating sometimes, but very convenient
> otherwise.
>
> For the benefit of those who don't know it, let's put a simple example.
> Suppose that you have:
>
> (foo)
> (bar)
>
> but now you wish to wrap those function calls inside a conditional. So
> you write:
>
> (when something
> (foo)
> (bar))
>
> Which requires moving the cursor through several lines just to add a
> parenthesis.
>
> With paredit, you write
>
> (when something_)
> (foo)
> (bar)

I typically write "M-2 (when...", which wraps automatically. Unless I'm
wrapping some huge chunk where it isn't obvious how many sexps should be
wrapped.

Eric

Re: on adding a function call to a s-exp

[João Távora]

On Tue, Jun 12, 2018 at 6:07 PM, Eric Abrahamsen <eric@ericabrahamsen.net>
wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
> > João Távora <joaotavora@gmail.com> writes:
> >
> > [...]
> >
> > It is true that paredit is irritating sometimes, but very convenient
> > otherwise.
> >
> > For the benefit of those who don't know it, let's put a simple example.
> > Suppose that you have:
> >
> > (foo)
> > (bar)
> >
> > but now you wish to wrap those function calls inside a conditional. So
> > you write:
> >
> > (when something
> > (foo)
> > (bar))
> >
> > Which requires moving the cursor through several lines just to add a
> > parenthesis.
> >
> > With paredit, you write
> >
> > (when something_)
> > (foo)
> > (bar)
>
> I typically write "M-2 (when...", which wraps automatically. Unless I'm
> wrapping some huge chunk where it isn't obvious how many sexps should be
> wrapped.
>

Nice tip, but you mean M-2 M-( w h e n , right? (of course you get to hold
the M).

When I don't know how many there are, I just C-M-SPC until I hit an
error :-) I'm sure there's a better way, but this one works for me.

João

Re: on adding a function call to a s-exp

[Eric Abrahamsen]

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

> On Tue, Jun 12, 2018 at 6:07 PM, Eric Abrahamsen <eric@ericabrahamsen.net>
> wrote:
>
>> Óscar Fuentes <ofv@wanadoo.es> writes:
>>
>> > João Távora <joaotavora@gmail.com> writes:
>> >
>> > [...]
>> >
>> > It is true that paredit is irritating sometimes, but very convenient
>> > otherwise.
>> >
>> > For the benefit of those who don't know it, let's put a simple example.
>> > Suppose that you have:
>> >
>> > (foo)
>> > (bar)
>> >
>> > but now you wish to wrap those function calls inside a conditional. So
>> > you write:
>> >
>> > (when something
>> > (foo)
>> > (bar))
>> >
>> > Which requires moving the cursor through several lines just to add a
>> > parenthesis.
>> >
>> > With paredit, you write
>> >
>> > (when something_)
>> > (foo)
>> > (bar)
>>
>> I typically write "M-2 (when...", which wraps automatically. Unless I'm
>> wrapping some huge chunk where it isn't obvious how many sexps should be
>> wrapped.
>>
>
> Nice tip, but you mean M-2 M-( w h e n , right? (of course you get to hold
> the M).

No, seems to work fine for me with just the plain parenthesis (to be
clear, I'm still talking about paredit-mode, where left parenthesis is
`paredit-open-round'.

Re: on adding a function call to a s-exp

[João Távora]

On Tue, Jun 12, 2018 at 6:04 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> [...]
>
> It is true that paredit is irritating sometimes, but very convenient
> otherwise.
>
> For the benefit of those who don't know it, let's put a simple example.
> Suppose that you have:
>
> (foo)
> (bar)
>
> but now you wish to wrap those function calls inside a conditional. So
> you write:
>
> (when something
> (foo)
> (bar))
>
> Which requires moving the cursor through several lines just to add a
> parenthesis.
>
> With paredit, you write
>
> (when something_)
> (foo)
> (bar)
>
> (the underscore represents the position of the cursor). Now you can
> incorporte the function calls inside the `when' with
> paredit-forward-slurp-sexp.
>

In electric-pair-mode, you C-M-SPC C-M-SPC ( w h e n SPC s o m e ...

this gets you the same thing, with the advantage that if you hold
C-M you type SPC twice, and with the advantage that you've typed
only ancient primitive Emacs commands.


> Things like this, combined with aggressive-indent-mode, makes editing
> Lispy languages quite pleasant, IMHO. In the past I worked like Drew
> describes, which is fine, but now I need to worry less about putting the
> parens on the right place. Paredit does that for me.


I'm just saying that electric-pair-mode will do that for you without
the annoyances or the extra brain space required to learn "slurps".

But even now, you can enjoy your paredit-.*-slurp commands
with electric-pair-mode: just don't turn on paredit-mode. Then
you have the best of both worlds.

I use aggressive-indent-mode too, btw. It's very nice... but very
aggressive too.

-- 
João Távora

Re: on adding a function call to a s-exp

[Robert Girault]

Drew Adams <drew.adams@oracle.com> writes:

[...]

> No.  Users should instead have aids to (1) tell whether code is
> well formed and (2) make it well formed (in different ways).
>
> (Just one experience and one opinion.)

I think you have a point.  Also, I prefer to work than to be always on
training with yet another new tool.

Re: on adding a function call to a s-exp

[Robert Girault]

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

[...]

>> I'll choose to use paredit and learn how to use it properly.  (There'll
>> likely be other good things there that I don't currently know or use.)
>
> I suggest you also give (the newer, 24.4+) eletric-pair-mode a try.

Where is it?  Is it autopair?  I found your repositories, but I only see
autopair there.  I'd have to upgrade my GNU EMACS, which is not good
news.  What is it about 24.3 that made you not support it?

> It should work consistently in all emacs major modes, not just lisp
> modes, and is maintained together with Emacs. By default, in
> emacs-lisp-mode you won't notice a difference to paredit for the most
> common operations (you *will* notice that it lets you unbalance the
> buffer temporarily though, but I consider that a feature).

I consider that a feature as well.

> disclaimer, if you hadn't figured it out: I wrote it :-)

I had no idea. :-) Thanks for writing it.  I really like it.

Re: on adding a function call to a s-exp

[João Távora]

On Wed, Jun 13, 2018 at 10:02 PM, Robert Girault <rfrancoisgirault@gmail.com
> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> [...]
>
> >> I'll choose to use paredit and learn how to use it properly.  (There'll
> >> likely be other good things there that I don't currently know or use.)
> >
> > I suggest you also give (the newer, 24.4+) eletric-pair-mode a try.
>
> Where is it?  Is it autopair?  I found your repositories, but I only see
> autopair there.  I'd have to upgrade my GNU EMACS, which is not good
> news.  What is it about 24.3 that made you not support it?
>

It's based on autopair, but better, and written it for Emacs 24.4. But yes
basically its autopair.

João

Re: on adding a function call to a s-exp

[Robert Girault]

Xavier Maillard <xavier@maillard.im> writes:

>> From: Robert Girault <rfrancoisgirault@gmail.com>
>> Date: Sat, 09 Jun 2018 19:05:16 -0300
>> 
>> In Lisp mode, when I select a region, in whatever way of selecting it,
>> and press (, it surrounds the region with parentheses, (...|), but it
>> puts the point where ``|'' is.  I'd like the point to be at (|...) so
>> I can add a function call to that region without having to move the
>> point back to the beginning of the region.
>
> I just do M-( and it lets the point after the open parenthesis.

What version of GNU EMACS are you running?  (How could I tell which
version of electric-pair-mode am I running?)  Thanks!