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

[Drew Adams <drew.adams@oracle.com>]

> > 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.)