bug#50929: Add slurp-sexp and barf-sexp

bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Tags: patch


Hi,

I'd like to suggest adding the command slurp-sexp and barf-sexp to
lisp.el (perhaps after changing the names). These commands were
popularized by structural editing packages like Paredit, and allow the
user to quickly pull or push s-expressions into the current list.

In GNU Emacs 28.0.50 (build 5, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars)
 of 2021-09-30 built on icterid
Repository revision: a1789fd67b2dd67d891b6c7181aee885a9ab9447
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation --with-x-toolkit=athena
 'CFLAGS=-Os -march=native -pipe' LDFLAGS=-flto'


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-slurp-sexp-and-barf-sexp.patch --]
[-- Type: text/patch, Size: 1679 bytes --]

From 90ca9317f524359786f6427f6d5a109abee2211c Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 1 Oct 2021 09:25:43 +0200
Subject: [PATCH] Add slurp-sexp and barf-sexp

* lisp.el (slurp-sexp): Add function
(barf-sexp): Add function
---
 lisp/emacs-lisp/lisp.el | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/lisp/emacs-lisp/lisp.el b/lisp/emacs-lisp/lisp.el
index 9b38d86e2c..e49893303c 100644
--- a/lisp/emacs-lisp/lisp.el
+++ b/lisp/emacs-lisp/lisp.el
@@ -867,6 +867,33 @@ raise-sexp
     (delete-region (point) (save-excursion (forward-sexp 1) (point)))
     (save-excursion (insert s))))
 
+(defun slurp-sexp (&optional arg)
+  "Pull the next ARG sexps into the current list."
+  (interactive "p")
+  (save-excursion
+    (up-list 1)
+    (let ((start (point)))
+      (forward-sexp arg)
+      (let ((copy (delete-and-extract-region start (point))))
+        (down-list -1)
+        (insert copy)))
+    (let ((bounds (bounds-of-thing-at-point 'sexp)))
+      (indent-region (car bounds) (cdr bounds)))))
+
+(defun barf-sexp (&optional arg)
+  "Push the last ARG sexps out of the current list."
+  (interactive "p")
+  (save-excursion
+    (up-list 1)
+    (down-list -1)
+    (let ((start (point)))
+      (backward-sexp arg)
+      (let ((copy (delete-and-extract-region (point) start)))
+        (move-past-close-and-reindent)
+        (insert copy)))
+    (let ((bounds (bounds-of-thing-at-point 'sexp)))
+      (indent-region (car bounds) (cdr bounds)))))
+
 (defun move-past-close-and-reindent ()
   "Move past next `)', delete indentation before it, then indent after it."
   (interactive)
-- 
2.30.2


[-- Attachment #3: Type: text/plain, Size: 16 bytes --]


-- 
	Philip K.

bug#50929: Add slurp-sexp and barf-sexp

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

> I'd like to suggest adding the command slurp-sexp and barf-sexp to
> lisp.el (perhaps after changing the names). These commands were
> popularized by structural editing packages like Paredit, and allow the
> user to quickly pull or push s-expressions into the current list.

There's already paredit-forward-slurp-sexp (etc) -- do we need them in
lisp.el, too?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I'd like to suggest adding the command slurp-sexp and barf-sexp to
>> lisp.el (perhaps after changing the names). These commands were
>> popularized by structural editing packages like Paredit, and allow the
>> user to quickly pull or push s-expressions into the current list.
>
> There's already paredit-forward-slurp-sexp (etc) -- do we need them in
> lisp.el, too?

Need is a difficult concept: Paredit also has a raise-sexp analogue, so
lisp.el doesn't need that either (hence why I added slurp-sexp and
barf-sexp right under raise-sexp), beyond the fact that it has already
been added to the file.

-- 
	Philip Kaludercic

bug#50929: Add slurp-sexp and barf-sexp

[Lars Ingebrigtsen]

Philip Kaludercic <philipk@posteo.net> writes:

>>> I'd like to suggest adding the command slurp-sexp and barf-sexp to
>>> lisp.el (perhaps after changing the names). These commands were
>>> popularized by structural editing packages like Paredit, and allow the
>>> user to quickly pull or push s-expressions into the current list.
>>
>> There's already paredit-forward-slurp-sexp (etc) -- do we need them in
>> lisp.el, too?
>
> Need is a difficult concept: Paredit also has a raise-sexp analogue, so
> lisp.el doesn't need that either (hence why I added slurp-sexp and
> barf-sexp right under raise-sexp), beyond the fact that it has already
> been added to the file.

I rather think that raise-sexp is an indication that these commands do
not belong in Emacs core -- it seems like raise-sexp was added in 2004,
but nobody seems to have clamoured for getting a key binding for it,
which would be unusual if it was a popular command.  (And nobody has
documented it either, apparently.)

My feeling is that these commands are vital for people who do structural
editing a lot -- but those people use paredit or similar.  People who
don't really don't think in those terms, so they don't miss the commands.

So my conclusion is that we don't want to add these commands, so I'm
closing this bug report (but if everybody else feels strongly that Emacs
should grow a more substantial support for structural Lisp editing, I
won't protest, but it should be just that -- more substantial, with a
fuller set of commands (with better names) and an Emacs manual section
explaining how it all ties together).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#50929: Add slurp-sexp and barf-sexp

[Juri Linkov]

>>>> I'd like to suggest adding the command slurp-sexp and barf-sexp to
>>>> lisp.el (perhaps after changing the names). These commands were
>>>> popularized by structural editing packages like Paredit, and allow the
>>>> user to quickly pull or push s-expressions into the current list.
>>>
>>> There's already paredit-forward-slurp-sexp (etc) -- do we need them in
>>> lisp.el, too?
>>
>> Need is a difficult concept: Paredit also has a raise-sexp analogue, so
>> lisp.el doesn't need that either (hence why I added slurp-sexp and
>> barf-sexp right under raise-sexp), beyond the fact that it has already
>> been added to the file.
>
> I rather think that raise-sexp is an indication that these commands do
> not belong in Emacs core -- it seems like raise-sexp was added in 2004,
> but nobody seems to have clamoured for getting a key binding for it,
> which would be unusual if it was a popular command.  (And nobody has
> documented it either, apparently.)

I use raise-sexp all the time bound to 'C-x C-M-u'
with mnemonics of "delete everything except sexp raised by C-M-u".
(I don't know if this will make sense for ‘lisp.el’.)

> My feeling is that these commands are vital for people who do structural
> editing a lot -- but those people use paredit or similar.  People who
> don't really don't think in those terms, so they don't miss the commands.
>
> So my conclusion is that we don't want to add these commands, so I'm
> closing this bug report (but if everybody else feels strongly that Emacs
> should grow a more substantial support for structural Lisp editing, I
> won't protest, but it should be just that -- more substantial, with a
> fuller set of commands (with better names) and an Emacs manual section
> explaining how it all ties together).

Sorry, I don't have an opinion about the proposed new commands:
it seems easier to use mark-sexp/copy/paste for complex structural editing
than to remember all possible list transformation commands with their keybindings.
But more commands could be added if more people will ask for them.

bug#50929: Add slurp-sexp and barf-sexp

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What does slurp-sexp do?
What does barf-sexp do?

If we want to have those operations, let's find less gross names for
them.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> What does slurp-sexp do?
> What does barf-sexp do?

Given two expressions like

(save-excursion
  |(foo))
(bar)

where "|" is the position of the point, slurp-sexp would transform this
into

(save-excursion
  |(foo)
  (bar))

and barf-sexp would reverse this change. 

> If we want to have those operations, let's find less gross names for
> them.

I reused the names that other structural editing packages use, but they
could be renamed into somthing like pull-sexp/ and push-sexp just as
well.

-- 
	Philip Kaludercic

bug#50929: Add slurp-sexp and barf-sexp

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Thanks for explaining.  I think these commands will be useful if they
have short enough key sequences -- can we find short enough ones to
give them?

I think `swallow-sexp' and `disgorge-sexp' are better names.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Thanks for explaining.  I think these commands will be useful if they
> have short enough key sequences -- can we find short enough ones to
> give them?

I use C-<left> and C-<right>, but alternatives I can think of are
M-<left> and M-<right>, C-< and C-> or M-[ and M-].  The former two
combinations are both bound to left- and right-word, and the latter two
combination is unbound in emacs-lisp-mode.

> I think `swallow-sexp' and `disgorge-sexp' are better names.

I like these too.

-- 
	Philip Kaludercic

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Drew Adams]

> I use C-<left> and C-<right>, but alternatives I can think of are
> M-<left> and M-<right>, C-< and C-> or M-[ and M-].  The former two
> combinations are both bound to left- and right-word, and the latter two
> combination is unbound in emacs-lisp-mode.

FWIW -

I'd prefer that no default key bindings be sacrificed
for this.  This kind of editing is mostly appropriate
for use with "structured editing" modes that
automatically and always pair delimiters.  I think it
makes most sense for only such modes to bind keys for
such commands.

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

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

>> I use C-<left> and C-<right>, but alternatives I can think of are
>> M-<left> and M-<right>, C-< and C-> or M-[ and M-].  The former two
>> combinations are both bound to left- and right-word, and the latter two
>> combination is unbound in emacs-lisp-mode.
>
> FWIW -
>
> I'd prefer that no default key bindings be sacrificed
> for this.

I think you and I already discussed this a few months ago, but binding
anything to these keys wouldn't sacrifice anything besides an unbound
slot, that the user can still override.

> This kind of editing is mostly appropriate for use with "structured
> editing" modes that automatically and always pair delimiters.  I think
> it makes most sense for only such modes to bind keys for such
> commands.

The reason I suggested adding the commands in the first place is because
I think some kind of structural editing can be done without the need for
any special modes or the need to bundle commands together.

-- 
	Philip Kaludercic

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Drew Adams]

> > FWIW -
> >
> > I'd prefer that no default key bindings be sacrificed
> > for this.
> 
> I think you and I already discussed this a few months ago, but binding
> anything to these keys wouldn't sacrifice anything besides an unbound
> slot, that the user can still override.

Users can always override _any_ key bindings.
That's not a reason to proliferate default
key bindings.

> > This kind of editing is mostly appropriate for use with "structured
> > editing" modes that automatically and always pair delimiters.  I think
> > it makes most sense for only such modes to bind keys for such
> > commands.
> 
> The reason I suggested adding the commands in the first place is because
> I think some kind of structural editing can be done without the need for
> any special modes or the need to bundle commands together.

Most use will be with such modes, I think.

These commands make sense when paired delimiters
are present.  Of course it's true that paired
delimiters are often present even without such
modes.

It's fine that someone might find it useful to
slurp or barf content, regardless of whether
they're using such a mode - granted.

That's not a reason to sacrifice _default_ key
bindings for these particular commands.

Users are free to bind these commands to keys.
If lots of users do so, and ask for default
bindings for them, then default bindings can
be considered.

Just because a command might be useful, that's
not a reason to give it a default binding.
How useful, for how many users?  Evidence?

Gauge/guess/measure the demand a bit first -
don't just sacrifice a default key willy
nilly because someone finds a command useful.

Finally, those proposed keys are repeatable
(= just hold down to repeat).  Sure, such a
command _can_ be repeated.  But repeating it
often, many times in a row, isn't common.
Better to reserve such (now rare) keys for
commands that really deserve (take advantage)
of such repetition.

So: (1) not needed by default, (2) certainly
not such special keys.

Let user practice guide the creation of
default key bindings (aka loss of unbound
keys).

(Just one opinion.)

bug#50929: Add slurp-sexp and barf-sexp

[Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Philip Kaludercic <philipk@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> […] can we find short enough ones to give them?
>
> I use C-<left> and C-<right>, but alternatives I can think of are
> M-<left> and M-<right>, C-< and C-> or M-[ and M-].  The former two
> combinations are both bound to left- and right-word, and the latter two
> combination is unbound in emacs-lisp-mode.

How about us, people without the arrow keys? :) BTW, I find C-() and C-{} used by Paredit fairly usable.

>> I think `swallow-sexp' and `disgorge-sexp' are better names.
>
> I like these too.

Another option: "pull in" and "push out" sexp.

Rudy
-- 
"Programming reliably --- must be an activity of an undeniably mathematical nature […] You see, mathematics is about thinking, and doing mathematics is always trying to think as well as possible." -- Edsger W. Dijkstra (1981)

Rudolf Adamkovič <salutis@me.com>
Studenohorská 25
84103 Bratislava
Slovakia

[he/him]

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Drew Adams]

BTW, I'd point out, at least for Richard's benefit,
that slurp and barf have been around for years (and
with those names).  They were even around in the
mid 80s, for some "structured editors" (I don't
recall the command names used for them).  Some Emacs
packages have had them for a decade or so.

And if you search for those operation names you'll
likely see hits for auto-pairing packages, such as
smartparens and paredit.  Not an accident.

[Though I don't really care, and I'm no special fan
of the names "slurp" and "barf", I'd suggest that
using those same names might aid discoverability -
users from other editors (or even from GNU Emacs
packages) may look for those names.  Not a strong
reason to go with those names, but maybe something
to keep in mind.]

bug#50929: Add slurp-sexp and barf-sexp

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I use C-<left> and C-<right>, but alternatives I can think of are
  > > M-<left> and M-<right>, C-< and C-> or M-[ and M-].

You can bind these keys yourself if they work ok on your terminal, but
they can't be the standard bindings.  C-< and C-> are not ASCII.
M-<left> moves by words; M-[ not possible on ttys.  C-<left> seems to be the
same as <left> on this tty.

                                                           The former two
  > > combinations are both bound to left- and right-word, and the latter two
  > > combination is unbound in emacs-lisp-mode.

  > How about us, people without the arrow keys? :) BTW, I find C-()
  > and C-{} used by Paredit fairly usable.

If `C-()' means C-( and C-), they are not in ASCII.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > [Though I don't really care, and I'm no special fan
  > of the names "slurp" and "barf", I'd suggest that
  > using those same names might aid discoverability -

We could define them as aliases for the sake of those who know
those names.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Philip Kaludercic]

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

>> > FWIW -
>> >
>> > I'd prefer that no default key bindings be sacrificed
>> > for this.
>> 
>> I think you and I already discussed this a few months ago, but binding
>> anything to these keys wouldn't sacrifice anything besides an unbound
>> slot, that the user can still override.
>
> Users can always override _any_ key bindings.
> That's not a reason to proliferate default
> key bindings.

Why?

-- 
	Philip Kaludercic

bug#50929: [External] : bug#50929: Add slurp-sexp and barf-sexp

[Drew Adams]

> >> > FWIW -
> >> >
> >> > I'd prefer that no default key bindings be sacrificed
> >> > for this.
> >>
> >> I think you and I already discussed this a few months ago, but binding
> >> anything to these keys wouldn't sacrifice anything besides an unbound
> >> slot, that the user can still override.
> >
> > Users can always override _any_ key bindings.
> > That's not a reason to proliferate default
> > key bindings.
> 
> Why?

It's up to someone arguing for a change to Emacs
to make an argument in support of that proposal.

Please make an argument for Emacs to sacrifice
those specific keys to default bindings.

Users have always been able to bind any keys.
That in itself is obviously not an argument for
binding any particular key by default.  And if
you were to suppose it were, then it would be an
argument for binding _any_ and _all_ keys by
default.

You need to present arguments in favor of binding
these keys by default to those specific commands.
The burden of argument/proof/convincing is on
whoever is proposing a change.  Just "Why not?"
doesn't cut the mustard.