Another Emacs incompatibilty

Another Emacs incompatibilty

[Torbjörn Granlund]

Rms once said something along the lines of

  Imagine if every car manufacturer would need to rearrange the controls
  of their car in order to avoid look-and-feel copyrights.

The picture was clear, the steering wheel, the brake pedal, the gear
shift would all need to be changed around for each manufacturer.

What does this have to do with emacs?  Well, each emacs release changes
things to make much of what we long term users have gotten accustomed to
invalid.  A few releases back, the way the area between the mark and the
insert point worked was fundamentally changed.  (Replace the steering
wheel with a lever!)

Indent region?  Change that to a different key!  (Replace the braking
pedal with a handle bar!)

Encrypted email broke with incompatible changes in emacs 25 or 26.  I
spent many hours trying to get it to work again, but had to give up.  In
the end I essentually stopped encrypting email.

Now, with emacs 27 gremlins are inserted each time a window's focus
changes.  I need to either suspend emacs before changing focus, or undo
these gremlin insertions when returning to emacs.ÄOÄIÄOÄI

Oops, some gremlins snuck in there.ÄOÄI
And there.  Oops agaun.

There have been dozens of other major incompatible changes in the last
10 or so years.  To me, emacs is in a state of deterioration.  By all
means, add features.  Don't mess with the existing interface.  Don't
break things.


I am sure I could maintain an ever increasing .emacs to work around most
of the incompatibilities and keep the controls work as they did.  If
only I had some more hours each week.


Torbjörn

GMP maintainer (previously worked on gcc, foundations of glibc, and
several GNU command line utilities)

Re: Another Emacs incompatibilty

[Stefan Monnier]

Torbjörn Granlund [2020-08-16 22:57:03] wrote:
> Now, with emacs 27 gremlins are inserted each time a window's focus
> changes.

It's one of the main new features, yes.


        Stefan

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Torbjörn Granlund wrote:

> Rms once said something along the lines of
>
>   Imagine if every car manufacturer would need to
>   rearrange the controls of their car in order to
>   avoid look-and-feel copyrights.
>
> The picture was clear, the steering wheel, the
> brake pedal, the gear shift would all need to be
> changed around for each manufacturer.
>
> What does this have to do with emacs? Well, each
> emacs release changes things to make much of what
> we long term users have gotten accustomed to
> invalid. A few releases back, the way the area
> between the mark and the insert point worked was
> fundamentally changed. (Replace the steering wheel
> with a lever!) [...]

I agree that doesn't make sense but... is it really
that way? I used Emacs for 10~15 years and never
experience any problems with updates.

Also, I wrote a lot of Elisp, 100+ files [1] and the
way I did it was based on my own engineering instinct
so to say, I never read any README or ChangeLogs or
any of that, so that would make me even more
vulnerable to changes, right?

But what happens is when I get the new version the
byte-compiler tells me maybe one or at most two
things in the Elisp, I fix them and that's it.

So I wonder how and why we can have such different
experience with this...


[1] https://dataswamp.org/~incal/conf/emacs-init/

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

On the rate of change [was: Another Emacs incompatibilty]

[tomas]

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

On Sun, Aug 16, 2020 at 10:57:03PM +0200, Torbjörn Granlund wrote:

[...]

> What does this have to do with emacs?  Well, each emacs release changes
> things to make much of what we long term users have gotten accustomed to
> invalid [...]

It's a very difficult balance to hit for a bigger "software project" (and
by this seemingly innocuous phrase I encompass the whole thing around it:
design, uses, developers and their dreams, users and their needs, culture,
haters, detractors, the whole kaboodle).

It doesn't move, and then it's dead (heck even /bin/ls had to take ACLs
into account at some point and SELinux at another). It does move too
much, and then people flee in all directions (remember Jamie Zawinski's
CADT [1]?).

The really, really hard part in it is that there's no "just right" rate
of change. Emacs (the project, the whole kaboodle) just happens to hit
my sweet spot squarely. It doesn't seem to be the case for you. It moves
too fast. Have a look at the mailing list and you'll see as many people
desperate because it doesn't move fast enough (just a month ago we had
a monster thread on this ML, I think).

I have seen so much grief caused (basically) by this kind of tension.

Any ideas on how to tackle that?

Cheers

[1] https://www.jwz.org/doc/cadt.html

-- t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: On the rate of change [was: Another Emacs incompatibilty]

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> It doesn't move, and then it's dead (heck even
> /bin/ls had to take ACLs into account at some point
> and SELinux at another). It does move too much, and
> then people flee in all directions (remember Jamie
> Zawinski's CADT?).

Well, no one is contemplating re-writing
Emacs, right?

I don't know if the rate of change is really the/a
problem. Can't you expand without breaking what is
there already? Isn't that what's been happening, 99%
of the time?

As for breaking what's there already, if it doesn't
make sense, just break it. If that breaks code that
relies on it as well, sure, that has to be changed as
well. But that's only a good thing!

If it _does_ make sense, leave it as it is, no doubt.

Who decides what makes sense and what doesn't?
People with skill and experience.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Torbjörn Granlund]

[Unfortunately, since I am not subscribed to this mailing list, this
follow-up mail will not have the right thread backlinks.]

To define this as a matter of balance between development progress and
compatibility is a false dichotomy.

No, emacs development is not "too fast" for me, as somebody suggested.
Any rate of fundamentally incompatible changes is too fast.

For example, changing the way something as fundamental as regions work
in a very mature editor is just a bad idea.  A really really bad idea.
By all means, define some other type of region and let that have other
semantics, or, let users opt in to incompatible regions by having them
set a variable in their .emacs.

And please do explain why inserting gremlins in my buffers upon window
focus changes is progress.

If the current emacs developers feel an urge to break emacs
compatibility, I think they should fork it and break the fork all they
want.  We GNU hackers need an editor which we can rely upon.  Some of
you might think hacking elisp is the best way of spending your time.
The rest of us prefer not getting interrupted in order to further GNU.

Please respect your users.  I do, and therefore I will not change the
options of cp, mv, or rm.  I will not push a change for swapping
operands or memcpy, strcpy, etc.  I will not suggest changing gcc's
command line options, or "improving" the C syntax it accepts.  And I
will still let GMP's mpz_add add its operands, and not do a subtract.

-- 
Torbjörn
Please encrypt, key id 0xC8601622

Re: On the rate of change [was: Another Emacs incompatibilty]

[tomas]

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

On Mon, Aug 17, 2020 at 04:21:41PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> tomas wrote:
> 
> > It doesn't move, and then it's dead (heck even
> > /bin/ls had to take ACLs into account at some point
> > and SELinux at another). It does move too much, and
> > then people flee in all directions (remember Jamie
> > Zawinski's CADT?).
> 
> Well, no one is contemplating re-writing
> Emacs, right?

I hope not :)

But then, if someone takes up this huge task, kudos, anyway.

> I don't know if the rate of change is really the/a
> problem. Can't you expand without breaking what is
> there already? Isn't that what's been happening, 99%
> of the time?

I'm totally happy about Emacs's rate of change, mind you. If
my mumblings implied otherwise, that's more a limitation on
my communications skills.

[...]

Agreed with you on the rest.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Another Emacs incompatibilty

[Robert Pluim]

>>>>> On Mon, 17 Aug 2020 17:14:54 +0200, tg@gmplib.org (Torbjörn Granlund) said:

    Torbjörn> [Unfortunately, since I am not subscribed to this mailing list, this
    Torbjörn> follow-up mail will not have the right thread backlinks.]

    Torbjörn> To define this as a matter of balance between development progress and
    Torbjörn> compatibility is a false dichotomy.

    Torbjörn> No, emacs development is not "too fast" for me, as somebody suggested.
    Torbjörn> Any rate of fundamentally incompatible changes is too fast.

    Torbjörn> For example, changing the way something as fundamental as regions work
    Torbjörn> in a very mature editor is just a bad idea.  A really really bad idea.
    Torbjörn> By all means, define some other type of region and let that have other
    Torbjörn> semantics, or, let users opt in to incompatible regions by having them
    Torbjörn> set a variable in their .emacs.

    Torbjörn> And please do explain why inserting gremlins in my buffers upon window
    Torbjörn> focus changes is progress.

Thatʼs not progress, thatʼs a bug. Did you report it?

Robert

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> From: tg@gmplib.org (Torbjörn Granlund)
> Date: Mon, 17 Aug 2020 17:14:54 +0200
> 
> For example, changing the way something as fundamental as regions work
> in a very mature editor is just a bad idea.

It would help if you'd tell what changes in how region works you are
alluding to.  I use Emacs for the last 30 years, and the way region
works for me didn't change at all, AFAICT.  So I'm really puzzled by
what you say here.

> Please respect your users.  I do, and therefore I will not change the
> options of cp, mv, or rm.  I will not push a change for swapping
> operands or memcpy, strcpy, etc.  I will not suggest changing gcc's
> command line options, or "improving" the C syntax it accepts.  And I
> will still let GMP's mpz_add add its operands, and not do a subtract.

Emacs doesn't change such basic traits of its usage, either.  We
haven't changed the command-line options, didn't change the documented
APIs of Emacs primitives in incompatible ways, and '+' still adds,
doesn't subtract.  However, Emacs has several orders of magnitude more
features as aspects than the likes of cp and mv, and as time passes
and the Emacs audience changes, the popular demand for some of them
also changes.

In any case, whenever a backward-incompatible change happens, there's
usually a way, called out in NEWS, to get back old behavior.

Re: Another Emacs incompatibilty

[Gregory Heytings via Users list for the GNU Emacs text editor]

Torbjörn Granlund:
>
> For example, changing the way something as fundamental as regions work 
> in a very mature editor is just a bad idea.  A really really bad idea. 
> By all means, define some other type of region and let that have other 
> semantics, or, let users opt in to incompatible regions by having them 
> set a variable in their .emacs.
>

Like Eli, I really wonder what this means.  I've been using Emacs for 
about 25 years, and I've not seen any change in the way regions work.

>
> And please do explain why inserting gremlins in my buffers upon window 
> focus changes is progress.
>

Again, what does this mean?  I thought it was a joke the first time you 
wrote it, but now you write it again, so it seems you're serious.

Gregory

Re: Another Emacs incompatibilty

[Perry Smith]

> On Aug 17, 2020, at 11:31 AM, Gregory Heytings via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> 
> Torbjörn Granlund:
>> 
>> For example, changing the way something as fundamental as regions work in a very mature editor is just a bad idea.  A really really bad idea. By all means, define some other type of region and let that have other semantics, or, let users opt in to incompatible regions by having them set a variable in their .emacs.
>> 
> 
> Like Eli, I really wonder what this means.  I've been using Emacs for about 25 years, and I've not seen any change in the way regions work.

Perhaps he is talking about transient-mark-mode?

Re: Another Emacs incompatibilty

[Gregory Heytings via Users list for the GNU Emacs text editor]

>>> For example, changing the way something as fundamental as regions work 
>>> in a very mature editor is just a bad idea.  A really really bad idea. 
>>> By all means, define some other type of region and let that have other 
>>> semantics, or, let users opt in to incompatible regions by having them 
>>> set a variable in their .emacs.
>>>
>>
>> Like Eli, I really wonder what this means.  I've been using Emacs for 
>> about 25 years, and I've not seen any change in the way regions work.
>
> Perhaps he is talking about transient-mark-mode?
>

I don't think so.  It was introduced in Emacs 19 (almost thirty years 
ago!), and it only requires (transient-mark-mode -1) in .emacs to be 
disabled.

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> From: Perry Smith <pedz@easesoftware.com>
> Date: Mon, 17 Aug 2020 11:49:35 -0500
> 
> > Like Eli, I really wonder what this means.  I've been using Emacs for about 25 years, and I've not seen any change in the way regions work.
> 
> Perhaps he is talking about transient-mark-mode?

Maybe so, but then just disabling it (which is what I do) does away
with any problems.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Torbjörn Granlund wrote:

> We GNU hackers need an editor which we can rely
> upon. Some of you might think hacking elisp is the
> best way of spending your time. The rest of us
> prefer not getting interrupted in order to
> further GNU.

... :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> Date: Mon, 17 Aug 2020 16:54:53 +0000
> From: Gregory Heytings via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > Perhaps he is talking about transient-mark-mode?
> >
> 
> I don't think so.  It was introduced in Emacs 19 (almost thirty years 
> ago!)

Yes, but originally it wasn't on by default.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings via Users list for the GNU Emacs text editor wrote:

> I don't think so.  It was introduced in Emacs 19
> (almost thirty years ago!)

Indeed:

  $ time-from 1993-05-22 # GNU Emacs 19.7
  27y 2m 26d

https://www.gnu.org/software/emacs/history.html
https://dataswamp.org/~incal/conf/.zsh/time

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: On the rate of change [was: Another Emacs incompatibilty]

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

> I'm totally happy about Emacs's rate of change,
> mind you. If my mumblings implied otherwise, that's
> more a limitation on my communications skills.

No, I didn't think you had a problem with the rate,
rather I thought _you thought_ the OP had a problem
with it, but I think the OP has a problem with some
particular new things breaking his old things, not
with new things in general...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Torbjörn Granlund]

Eli Zaretskii <eliz@gnu.org> writes:

  It would help if you'd tell what changes in how region works you are
  alluding to.  I use Emacs for the last 30 years, and the way region
  works for me didn't change at all, AFAICT.  So I'm really puzzled by
  what you say here.

Mark a region, immediately press e.g. "A".  The region is zapped and
replaced by an A.

That used to insert an A at the insert point since TECO emacs until a
few releases back.

(There is also an implicit mode in the new behavioutr: Only regions just
created exhibit the incompatible zap behavioutr.)

  In any case, whenever a backward-incompatible change happens, there's
  usually a way, called out in NEWS, to get back old behavior.

How about keeping the accepted interface and document in NEWS how to
make it work in a new, incompatible way?

-- 
Torbjörn
Please encrypt, key id 0xC8601622

Re: Another Emacs incompatibilty

[Stefan Monnier]

> Mark a region, immediately press e.g. "A".  The region is zapped and
> replaced by an A.
>
> That used to insert an A at the insert point since TECO emacs until a
> few releases back.

Still does for me in a vanilla Emacs.  Maybe it's something in your config?

>   In any case, whenever a backward-incompatible change happens, there's
>   usually a way, called out in NEWS, to get back old behavior.
> How about keeping the accepted interface and document in NEWS how to
> make it work in a new, incompatible way?

That's what we do for most new features.  But sometimes the annoyance
for N users of having to disable a "feature" is eclipsed by the expected
benefit for M users getting this new "feature" without having to figure
that they want it nor how to get it.

For any change to Emacs (new feature, change to defaults, bug fix, you
name it), one can easily come up with some scenario where the change
results in an undesired result [ the credibility/likelihood of the
scenario may vary widely, of course ].  So the only really safe way to
avoid introducing new problems is to leave the code 100% unchanged.


        Stefan

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

> So the only really safe way to avoid introducing
> new problems is to leave the code 100% unchanged.

Fixing one bug can introduce another bug. But to be
fair, I think everyone understands that, and no one
suggests the code should never change one ... bit.

I'm an "under the hood maximalist" myself. As long as
I can configure the interface [see dump 1] to be
minimalist and clutter free I don't mind having all
kinds of huge software libraries below, invisible.
They might come handy one day and until then they
don't bother anyone.


[1] https://dataswamp.org/~incal/pimgs/comp/mail.png

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Gregory Heytings via Users list for the GNU Emacs text editor]

>
>> Mark a region, immediately press e.g. "A".  The region is zapped and 
>> replaced by an A.
>>
>> That used to insert an A at the insert point since TECO emacs until a 
>> few releases back.
>
> Still does for me in a vanilla Emacs.  Maybe it's something in your 
> config?
>

Same for me.  It's a rather strange behavior, and I understand that it is 
annoying.  Can you perhaps post your .emacs somewhere, so that we can see 
what's going on?

Gregory

Re: Another Emacs incompatibilty

[Eric Abrahamsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Mark a region, immediately press e.g. "A".  The region is zapped and
>> replaced by an A.
>>
>> That used to insert an A at the insert point since TECO emacs until a
>> few releases back.
>
> Still does for me in a vanilla Emacs.  Maybe it's something in your config?

Sounds like cua-mode...

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eric Abrahamsen wrote:

>>> Mark a region, immediately press e.g. "A".
>>> The region is zapped and replaced by an A.
>>>
>>> That used to insert an A at the insert point
>>> since TECO emacs until a few releases back.
>>
>> Still does for me in a vanilla Emacs. Maybe it's
>> something in your config?
>
> Sounds like cua-mode...

Yes, I just tried this and can confirm the "zap"
behavior is there only after `cua-mode' with -Q in

  GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu) of
  2019-09-23, modified by Debian

One thing I wonder tho is... why do you mark a region
and press "A" to begin with? What's the purpose of
doing that? If the "zap" isn't what you want,
that is?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Eric Abrahamsen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Eric Abrahamsen wrote:
>
>>>> Mark a region, immediately press e.g. "A".
>>>> The region is zapped and replaced by an A.
>>>>
>>>> That used to insert an A at the insert point
>>>> since TECO emacs until a few releases back.
>>>
>>> Still does for me in a vanilla Emacs. Maybe it's
>>> something in your config?
>>
>> Sounds like cua-mode...
>
> Yes, I just tried this and can confirm the "zap"
> behavior is there only after `cua-mode' with -Q in
>
>   GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu) of
>   2019-09-23, modified by Debian
>
> One thing I wonder tho is... why do you mark a region
> and press "A" to begin with? What's the purpose of
> doing that? If the "zap" isn't what you want,
> that is?

Almost by coincidence, I just discovered `delete-selection-mode', which
does the same thing. I also don't understand the utility of this, but
apparently it's useful enough to have been implemented twice! Neither
should be active by default, though.

Re: Another Emacs incompatibilty

[Stefan Monnier]

> Almost by coincidence, I just discovered `delete-selection-mode', which
> does the same thing. I also don't understand the utility of this, but
> apparently it's useful enough to have been implemented twice! Neither
> should be active by default, though.

cua-mode is a superset.  It was indeed implemented twice, but IIRC
nowadays cua-mode uses delete-selection-mode internally.


        Stefan

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Mon, 17 Aug 2020 17:25:21 -0700
> 
> Almost by coincidence, I just discovered `delete-selection-mode', which
> does the same thing. I also don't understand the utility of this

Many "other" editing applications work like that.

> apparently it's useful enough to have been implemented twice!

CUA Mode comes with a lot of other baggage, whereas
delete-selection-mode only does this one job.  Not everyone want the
full CUA.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>> apparently it's useful enough to have been
>> implemented twice!
>
> CUA Mode comes with a lot of other baggage, whereas
> delete-selection-mode only does this one job.
> Not everyone want the full CUA.

Hold on, I think I'm onto something. What if both
cua-mode _and_ delete-selection-mode were removed
from Emacs? Wouldn't that solve the OP's problem?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> Date: Tue, 18 Aug 2020 07:27:56 +0200
> From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > CUA Mode comes with a lot of other baggage, whereas
> > delete-selection-mode only does this one job.
> > Not everyone want the full CUA.
> 
> Hold on, I think I'm onto something. What if both
> cua-mode _and_ delete-selection-mode were removed
> from Emacs? Wouldn't that solve the OP's problem?

They are both optional, so how can removing them solve anything?

Besides, we don't yet understand the cause for those problems, as the
description which was posted seems to indicate some local non-default
configuration.

RE: Another Emacs incompatibilty

[Drew Adams]

> Almost by coincidence, I just discovered `delete-selection-mode', which
> does the same thing. I also don't understand the utility of this, but
> apparently it's useful enough to have been implemented twice! Neither
> should be active by default, though.

Some of us think that `delete-selection-mode'
should be enabled by default - and that this
is long overdue.

FYI, a similar debate took place for
`transient-mark-mode'.  It took _decades_ to
finally get that turned on by default.

Maybe you can't imagine t-m-mode being off by
default.  Try it.  ;-)  There are some good
arguments for that behavior, as there are
against it.

I argued then to turn on t-m-mode by default.
And I argued (and still do) to also turn on
`delete-selection-mode' by default.

`delete-selection-mode' is a common behavior
outside Emacs: just-select-and-type-to-replace.
The default Emacs behavior makes you use `C-w'
first.

But d-s-mode also lets users and libraries easily
_control_ just which commands (actions) delete
selected text, which ones kill it, which ones do
neither, which ones are yanks (to not then yank
the text to be deleted), whether to also perform
the command's normal action, or whether to do
something else altogether.

Here's the relevant part of the `delsel.el'
Commentary:

;; Commands which will delete the selection need a `delete-selection'
                                                  ^
                                              [non-nil]
;; property on their symbols; commands which insert text but don't
;; have this property won't delete the selection.  It can be one of
;; the values:
;;
;;  `yank'
;;      For commands which do a yank; ensures the region about to be
;;      deleted isn't immediately yanked back, which would make the
;;      command a no-op.
;;  `supersede'
;;      Delete the active region and ignore the current command,
;;      i.e. the command will just delete the region.  This is for
;;      commands that normally delete small amounts of text, like
;;      a single character -- they will instead delete the whole
;;      active region.
;;  `kill'
;;      `kill-region' is used on the selection, rather than
;;      `delete-region'.  (Text selected with the mouse will typically
;;      be yankable anyhow.)
;;  t
;;      The normal case: delete the active region prior to executing
;;      the command which will insert replacement text.
;;  FUNCTION
;;      For commands which need to dynamically determine this behavior.
;;      FUNCTION should take no argument and return one of the above
;;      values, or nil.  In the latter case, FUNCTION should itself
;;      do with the active region whatever is appropriate."

That's the Emacs way: a general, default behavior,
but also user/code control over it.  You can get
whatever behavior you want for a given command.
The command gets to decide what it does with the
active region.  (That means you get to decide.)

 (put 'my-command 'delete-selection nil) ; Ignore d-s-mode.

Re: Another Emacs incompatibilty

[Eric Abrahamsen]

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

>> Almost by coincidence, I just discovered `delete-selection-mode', which
>> does the same thing. I also don't understand the utility of this, but
>> apparently it's useful enough to have been implemented twice! Neither
>> should be active by default, though.
>
> Some of us think that `delete-selection-mode'
> should be enabled by default - and that this
> is long overdue.
>
> FYI, a similar debate took place for
> `transient-mark-mode'.  It took _decades_ to
> finally get that turned on by default.
>
> Maybe you can't imagine t-m-mode being off by
> default.  Try it.  ;-)  There are some good
> arguments for that behavior, as there are
> against it.

I was mostly posting to point out possible clues to OP's problem, not to
disparage `d-s-m', et al! I can see why people might want it, especially
if they're also using a lot of other software. Personally I feel that it
obscures an "Emacs approach" to editing that, when fully embraced, is
much more powerful (I also disable `transient-mark-mode'), but I would
have no interest in making that decision for other people, one way or
the other.

RE: Another Emacs incompatibilty

[Drew Adams]

> > Some of us think that `delete-selection-mode'
> > should be enabled by default - and that this
> > is long overdue.
> >
> > FYI, a similar debate took place for
> > `transient-mark-mode'.  It took _decades_ to
> > finally get that turned on by default.
> >
> > Maybe you can't imagine t-m-mode being off by
> > default.  Try it.  ;-)  There are some good
> > arguments for that behavior, as there are
> > against it.
> 
> I was mostly posting to point out possible clues to OP's problem, not to
> disparage `d-s-m', et al! I can see why people might want it, especially
> if they're also using a lot of other software. Personally I feel that it
> obscures an "Emacs approach" to editing that, when fully embraced, is
> much more powerful (I also disable `transient-mark-mode'), but I would
> have no interest in making that decision for other people, one way or
> the other.

I understand your point of view better now,
since you've said that you also turn off
`transient-mark-mode'.

The two are related, IMO.  They're not
coupled, but there is some user-level relation
between them.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> `delete-selection-mode' is a common behavior
> outside Emacs: just-select-and-type-to-replace.
> The default Emacs behavior makes you use
> `C-w' first.

Yes, I mean, I never did that (select and type) but
_if_ I did I would expect that to happen.

Because what else should happen and for what reason
do you select and type, if not to replace? If you
want to type at the beginning of the selection why
don't you just move point there and type, without
selecting anything to begin with?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Eric Abrahamsen]

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

>> > Some of us think that `delete-selection-mode'
>> > should be enabled by default - and that this
>> > is long overdue.
>> >
>> > FYI, a similar debate took place for
>> > `transient-mark-mode'.  It took _decades_ to
>> > finally get that turned on by default.
>> >
>> > Maybe you can't imagine t-m-mode being off by
>> > default.  Try it.  ;-)  There are some good
>> > arguments for that behavior, as there are
>> > against it.
>> 
>> I was mostly posting to point out possible clues to OP's problem, not to
>> disparage `d-s-m', et al! I can see why people might want it, especially
>> if they're also using a lot of other software. Personally I feel that it
>> obscures an "Emacs approach" to editing that, when fully embraced, is
>> much more powerful (I also disable `transient-mark-mode'), but I would
>> have no interest in making that decision for other people, one way or
>> the other.
>
> I understand your point of view better now,
> since you've said that you also turn off
> `transient-mark-mode'.
>
> The two are related, IMO.  They're not
> coupled, but there is some user-level relation
> between them.

Yeah I see that -- I turned `d-s-m' on to try it, without disabling
`t-m-m', and had one of those "halp I broke my Emacs" moments.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Francis Belliveau:

> Easy answer

...

> Insert-Mark, word-right, Add-text-to-region,
> copy-region. This is a very frequent sequence for
> me what I am writing code along with
> it documentation.

OK, if you give me these in real functions instead
I'll be happy to try it right now...

> Sorry that I am late getting into
> this conversation.

Np, everything always in time. Please cite tho as
I don't remember every single piece of wisdom I so
generously distribute on this list...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Alan Davis]

A mere  two minutes before reading this thread, while writing an email in
Gmail, I had maneuvered to select and replace a short piece of text by a
manipulation parallel with delete-selected-text (if I understand
correctly), though I had no idea about this existing in Emacs.  At this
time, like at other times when dealing with crippled input systems on
popular software, my thoughts turned to Emacs.   It occurred to me that
this was not a perfect solution, unless the deleted piece is stashed
somewhere for reuse.

A good example of an Emacs sequence that is more nimble than other software
I have encountered is swapping two adjacent characters, or words, a
procedure I use  often.  I confess I have not bothered to master transcient
mark mode, as opposed to not using it; but it seems to be so logical,
however, that that alternative seems completely illogical.

 Emacs gives better control over my typing.   The developers of the dreaded
GUI editors seem not to care about this.  The lack of delete-selection-mode
(d-s-m) has not been on my radar.  But I think in some cases it does
happen.  I have not decided whether to take advantage of this new feature.

 Perhaps more sophisticated manipulations can be implemented through a
macro.

Is it currently  possible, if d-s-m is active, to easily retrieve the
deleted/replaced item?

Alan Davis

On Sun, Aug 23, 2020 at 1:10 PM Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Francis Belliveau:
>
> > Easy answer
>
> ...
>
> > Insert-Mark, word-right, Add-text-to-region,
> > copy-region. This is a very frequent sequence for
> > me what I am writing code along with
> > it documentation.
>
> OK, if you give me these in real functions instead
> I'll be happy to try it right now...
>
> > Sorry that I am late getting into
> > this conversation.
>
> Np, everything always in time. Please cite tho as
> I don't remember every single piece of wisdom I so
> generously distribute on this list...
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
>
>
>

-- 
The foundation of morality is to have done, once and for all, with lying.
                     ---Thomas Huxley,

Re: Another Emacs incompatibilty

[Eli Zaretskii]

> From: Alan Davis <alan3davis@gmail.com>
> Date: Sun, 23 Aug 2020 23:43:08 -0700
> 
> Is it currently  possible, if d-s-m is active, to easily retrieve the
> deleted/replaced item?

I think you need to put the 'delete-selection' property whose value is
'kill' (instead of the default 't') on the commends after which you
want to be able to retrieve the replaced text.

RE: Another Emacs incompatibilty

[Drew Adams]

> It occurred to me that this was not a perfect solution,
> unless the deleted piece is stashed somewhere for reuse.

Eli has mentioned in his reply that you can control this
on a command-by-command basis (or otherwise).

The reason both `kill' (so you can later yank/paste the
removed text) and `delete' (in which case you can't) are
offered is this:

There are many cases - typically the vast majority, where
the text that's removed (often replaced by other text) is
not something you want to "pollute" the kill ring (ring
of past deletions).  That is, you probably won't want to
later paste such text, and having it mixed in, on the
kill ring, with other text that you might want to paste,
makes it a bit more difficult to get to some text to paste.

> I have not decided whether to take advantage of this new feature.

Delete Selection mode is not a new feature for Emacs.
It's been there for decades.  It's not turned on by
default, that's all.

> Is it currently  possible, if d-s-m is active, to easily retrieve the
> deleted/replaced item?

Yes, on a per-command basis.

Re: Another Emacs incompatibilty

[Stefan Monnier]

> Is it currently  possible, if d-s-m is active, to easily retrieve the
> deleted/replaced item?

I believe this should depend on the value of `delete-active-region`, tho
AFAICT this is not currently implemented (the var is only obeyed when
you use things like DEL but not when you type a self-inserting
character).
Maybe you should `M-x report-emacs-bug` to request this behavior.


        Stefan

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Alan Davis wrote:

> A mere two minutes before reading this thread,
> while writing an email in Gmail, I had maneuvered
> to select and replace a short piece of text by
> a manipulation parallel with delete-selected-text
> (if I understand correctly), though I had no idea
> about this existing in Emacs. At this time, like at
> other times when dealing with crippled input
> systems on popular software, my thoughts turned to
> Emacs. It occurred to me that this was not
> a perfect solution, unless the deleted piece is
> stashed somewhere for reuse.
>
> A good example of an Emacs sequence that is more
> nimble than other software I have encountered is
> swapping two adjacent characters, or words,
> a procedure I use often. I confess I have not
> bothered to master transcient mark mode, as opposed
> to not using it; but it seems to be so logical,
> however, that that alternative seems
> completely illogical.
>
> Emacs gives better control over my typing.
> The developers of the dreaded GUI editors seem not
> to care about this. The lack of
> delete-selection-mode (d-s-m) has not been on my
> radar. But I think in some cases it does happen.
> I have not decided whether to take advantage of
> this new feature.
>
> Perhaps more sophisticated manipulations can be
> implemented through a macro.

??????

> Is it currently possible, if d-s-m is active, to
> easily retrieve the deleted/replaced item?

Yes, it should be possible with the help of
`delete-selection-helper':

  Delete selection according to TYPE
  [...]
  ‘kill’
     ‘kill-region’ is used on the selection, rather
     than ‘delete-region’. (Text selected with the
     mouse will typically be yankable anyhow).

but how that works I don't know, putting it like this


  (add-hook 'delete-selection-pre-hook
            '(delete-selection-helper "kill") )

doesn't seem to do anything to that end.

One would think an easier way to provide
a configuration interface would just be to have
a variable. (The implemented way is more
powerful/versatile tho, if one can only figure out
how to use it...)

Also, I _still_ don't understand the use case?
You are used to this behavior from other editors?
Or you can delete and insert with a single stroke, so
it is faster? That's it? Or is there something else?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

> I think you need to put the 'delete-selection'
> property whose value is 'kill' (instead of the
> default 't') on the commends after which you want
> to be able to retrieve the replaced text.

OK!

*scratches the head*

How do you put a commend property, again?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>> Is it currently possible, if d-s-m is active, to
>> easily retrieve the deleted/replaced item?
>
> Yes, on a per-command basis.

OK, I have an idea for a rule guys, whenever someone
asks if something is possible, please do not just
answer "yes" whenever it is, also show how one is
suppose to actually do it :)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Alan Davis]

I am beginning to see.  delete-selection-helper is a function defined in
delsel.el.  Customization of either delete-selection or
delete-selection-mode is more complicated than I have seen previously.

Lesson learned: never underestimate emacs's developers.

This could be useful.  I will attempt to enable it.

Thank you for answers that, if cryptic to me, went way beyond what I
usually expect.

Alan

On Mon, Aug 24, 2020 at 4:25 PM Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> Drew Adams wrote:
>
> >> Is it currently possible, if d-s-m is active, to
> >> easily retrieve the deleted/replaced item?
> >
> > Yes, on a per-command basis.
>
> OK, I have an idea for a rule guys, whenever someone
> asks if something is possible, please do not just
> answer "yes" whenever it is, also show how one is
> suppose to actually do it :)
>
> --
> underground experts united
> http://user.it.uu.se/~embe8573
> https://dataswamp.org/~incal
>
>
>

-- 
The foundation of morality is to have done, once and for all, with lying.
                     ---Thomas Huxley,

RE: Another Emacs incompatibilty

[Drew Adams]

[Sending again, explicitly ccing help-gnu-emacs@gnu.org
this time.  I need to remember that "Reply All" to you
doesn't work, at least not with my mail client (Outlook).]


> >> Is it currently possible, if d-s-m is active, to
> >> easily retrieve the deleted/replaced item?
> >
> > Yes, on a per-command basis.
> 
> OK, I have an idea for a rule guys, whenever someone
> asks if something is possible, please do not just
> answer "yes" whenever it is, also show how one is
> suppose to actually do it :)

FWIW, I didn't only offer that one-liner in that msg.
And another message of mine in this thread cited how
it's done, quoting what `delsel.el' says about it.

 ;; Commands which will delete the selection need
 ;; a `delete-selection' property on their symbols...

https://lists.gnu.org/archive/html/help-gnu-emacs/2020-08/msg00105.html

But OK.  Someone asked _how_ to put that property
on a command's symbol, or perhaps the question
was also what a command's _symbol_ is.

How is described in the Commentary of library
`delsel.el'.  (Old-school: doc in the file itself.)

Anyway, here's what you do:

To make command `insert-char' first delete the
selection (active region), before performing its
action (which is to insert one or more chars),
put property `delete-selection' on the symbol
`insert-char' - the symbol whose `symbol-function'
is the function name "insert-char".  Give the
property the value `t'.

 (put 'insert-char 'delete-selection t)

That's all.  Without that property, i.e., if
(get 'insert-char 'delete-selection) is nil,
`delete-selection-mode' has no effect on the
given command (`insert-char') - the command
just does its normal thing.

`insert-char is already set up that way for
`delete-selection-mode' (it deletes the
selection first), in `delsel.el'.

But if you want `insert-char' to do nothing
besides insert its arg chars, i.e., not kill
and not delete the selection first, do this,
to override its default behavior in
`delete-selection-mode':

  (put 'insert-char 'delete-selection nil)

Or if you instead want `insert-char' to kill
the selected text (so you can later yank it)
instead of just deleting it, add this to your
init file, to override the default behavior:

  (put 'insert-char 'delete-selection 'kill)

That gives you the same effect as using `C-w'
when the region's active, before using the
command in question (`insert-char', here).

(But unlike `C-w', it has no effect if the
region is not active - which is the case when
`transient-mark-mode' is off.)

And if you have your own command `foo', which
does <whatever>, and you want it to first
delete the active region, then do this:

  (put 'foo 'delete-selection t)

And if you want to override the normal behavior
of your command `tata' and ONLY delete the
active region, then do this:

  (put 'tata 'delete-selection 'supersede)

And if you want your command `titi' to delete
the selection sometimes, and kill it other
times, before it does whatever else it does
normally, then do this:

  (put 'titi 'delete-selection 'titi-kill/del)

where `titi-kill/del' is a function that DTRT
to the active region: kill, delete, or nothing
at all, according to the current context -
phase of the moon, your pulse rate, the number
of kilometers you've ridden your bike so far
today, roll of phantom dice...

Does this help?  If not, just try it - try
various `delete-selection' values for a few
commands.

The default `delete-selection' behavior (value
`t') is the "select-and-type-to-replace"
behavior that's fairly common outside Emacs.

RE: Another Emacs incompatibilty

[Drew Adams]

> put property `delete-selection' on the symbol
> `insert-char' - the symbol whose `symbol-function'
> is the function name "insert-char".  Give the
                   ^
                 named
> property the value `t'.

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>>> Is it currently possible, if d-s-m is active, to
>>>> easily retrieve the deleted/replaced item?
>>>
>>> Yes, on a per-command basis.
>> 
>> OK, I have an idea for a rule guys, whenever
>> someone asks if something is possible, please do
>> not just answer "yes" whenever it is, also show
>> how one is suppose to actually do it :)
>
> FWIW, I didn't only offer that one-liner in
> that msg.

One-liners are enough (preferable, even) if they show
how to do it.

> (put 'insert-char 'delete-selection t)

OK, so that's the syntax. This must be a very arcane
way of configuration. I did use `put' but only to
enable and disable, as in

  (put 'help-for-help 'disabled t)

But, what are properties and how do I know what
properties a function has?

And how do I write a function with properties? (I
don't think I want to, in general, but I always want
to do things I didn't do, at least once...)

> Or if you instead want `insert-char' to kill the
> selected text (so you can later yank it) instead of
> just deleting it, add this to your init file, to
> override the default behavior:
>
>   (put 'insert-char 'delete-selection 'kill)

`insert-char'? Sure, that's ONE way to insert, but
there are many other ways to insert things, and not
just a single char, and then (if you desire this
functionality to begin with, that is) then you
_always_ want the selection to be killed, I think is
the objective here?

Anyway, I don't get it to work:

  (delete-selection-mode) ; t
  (put 'insert-char 'delete-selection 'kill) ; kill
  I type this
  set-mark-command
  beginning-of-line
  set-mark-command
  s ("I type this" disappears, the letter s appears)
  yank
  "I type this" does NOT appear

?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

> One-liners are enough (preferable, even) if they show
> how to do it.

Here is a 19-liner how to do it:

(delete-selection-mode)

(defun delete-selection-pre-hook ()
  (when (and delete-selection-mode
             (use-region-p)
             (not buffer-read-only) )
    (if (member this-command '(self-insert-command insert-char insert) )
        (delete-selection-helper 'kill)
      (delete-selection-helper
       (and (symbolp this-command)
            (get this-command 'delete-selection) )))))

Now type:

  You better belive Manny is the best hacker around

mark it, type something, and yank it.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

RE: Another Emacs incompatibilty

[Drew Adams]

> > (put 'insert-char 'delete-selection t)
> 
> OK, so that's the syntax. This must be a very arcane
> way of configuration. I did use `put' but only to
> enable and disable, as in
> 
>   (put 'help-for-help 'disabled t)
> 
> But, what are properties and how do I know what
> properties a function has?

https://www.gnu.org/software/emacs/manual/html_node/elisp/Symbol-Properties.html

Ask Emacs: `C-h i m Elisp i symbol property'

A Lisp symbol is an object of sorts.  It has a name
and possibly other properties/attributes:

* a name           - `symbol-name'
* a function value - `symbol-function'
* a variable value - `symbol-value'
* a property list  - `symbol-plist'

And you can add any other properties you like.
Enjoy.

> And how do I write a function with properties? (I
> don't think I want to, in general, but I always want
> to do things I didn't do, at least once...)

As I think I said before, it's not really the function
that has properties.  It's the function symbol - the
symbol whose `symbol-function' is the function named
with the function's name (which is also the symbol's
name).

(defun foo ...)
(symbol-function 'foo) => foo ; symbol with name "foo"

(setq foo 42)
(symbol-value 'foo) => 42

See also `C-h f symbol-plist'.

> > Or if you instead want `insert-char' to kill the
> > selected text (so you can later yank it) instead of
> > just deleting it, add this to your init file, to
> > override the default behavior:
> >
> >   (put 'insert-char 'delete-selection 'kill)
> 
> `insert-char'? Sure, that's ONE way to insert, but
> there are many other ways to insert things, and not
> just a single char, 

It was an _example_.  A command whose `delete-selection'
property is defined to kill, not delete.  To show that
you can change the behavior to kill instead of only
delete.

> and then (if you desire this
> functionality to begin with, that is) then you
> _always_ want the selection to be killed, I think is
> the objective here?

It presumably is your objective, if you use `kill'.
Again, an _example_ of getting kill behavior.  Do I
think you'd likely really prefer to have `insert-char'
kill instead of delete?  No.  But you might.  Or some
library might.

> Anyway, I don't get it to work:
> 
>   (delete-selection-mode) ; t
>   (put 'insert-char 'delete-selection 'kill) ; kill
>   I type this
>   set-mark-command
>   beginning-of-line
>   set-mark-command
>   s ("I type this" disappears, the letter s appears)
>   yank
>   "I type this" does NOT appear

In your example, the kill behavior applies to
`insert-char', not to `self-insert-command', which
is what `s' is bound to.  So don't expect that when
you type `s' to replace the active region you can
then yank what was deleted.

If you instead select some text and use
`C-x 8 RET' `LATIN CAPITAL LETTER M', then the
selected text is replaced by `M', AND it's put in
the kill ring.

Maybe using `insert-char' to illustrate wasn't the
best choice.  I did so because it was the first one
in `delsel.el' after `self-insert-command' (which
is a special case).

> Here is a 19-liner how to do it:
> (delete-selection-mode)
> (defun delete-selection-pre-hook ()
>   (when (and delete-selection-mode
>              (use-region-p)
>              (not buffer-read-only) )
>     (if (member this-command '(self-insert-command insert-char insert) )
>         (delete-selection-helper 'kill)
>       (delete-selection-helper
>        (and (symbolp this-command)
>             (get this-command 'delete-selection) )))))

You don't need to redefine `delete-selection-pre-hook'.

You typically need only put a `delete-selection'
property on a command's symbol, to get the behavior
you want for it, which is just delete-the-selection
in most cases, i.e., value `t'.

And most people will never need to do even that.
They'll just use the out-of-the-box behavior.

People who add commands that insert or do some
other things might want to configure them to take
advantage of `delete-selection-mode'.  And even
then, they mostly just use `t': delete.

You didn't ask how to use `delete-selection-mode'.

I think you asked about its various behaviors and
configuring them by putting properties on command
symbols.  It can do more than your average "select
and type to replace".

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Anyway, I don't get it to work:
>
>   (delete-selection-mode) ; t
>   (put 'insert-char 'delete-selection 'kill) ; kill
>   I type this
>   set-mark-command
>   beginning-of-line
>   set-mark-command
>   s ("I type this" disappears, the letter s appears)
>   yank
>   "I type this" does NOT appear
>
> ?

To be fair, this should indeed work, the reason why
I didn't get it to work is hitting a key is
`self-insert-command', not `insert-char'...

To make a little list

  (put 'insert-char 'delete-selection 'kill)
  (put ' ...        'delete-selection 'kill)
  ...

(or even better, do a loop with all commands in
a list) is probably more sound than what I did
in [1], especially if the property is used by other
functions. But it should amount to the same...


[1] https://lists.gnu.org/archive/html/help-gnu-emacs/2020-08/msg00146.html

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: Another Emacs incompatibilty

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

> A Lisp symbol is an object of sorts. It has a name
> and possibly other properties/attributes:
>
> * a name - `symbol-name' * a function value -
> `symbol-function' * a variable value - `symbol-value'
> * a property list - `symbol-plist'

Lisp, an OO language!

> You don't need to redefine
> `delete-selection-pre-hook'.
>
> You typically need only put a `delete-selection'
> property on a command's symbol, to get the behavior
> you want for it, which is just delete-the-selection
> in most cases, i.e., value `t'.

OK, now I understand this...

We have a function f that operates on functions a, b,
and c.

If we put configuration in f, it will indeed work for
functions a, b, and c.

However... if someone writes a function d, f will not
be configurable for d, since d didn't exist when
f was written. If we want the same for d, we must
redefine f! Solution: put the configuration in a, b,
c, and d, and it works now and for whatever e, f,
g anyone can come up with. Wonderful!

However (2) ... we can also solve this with
a variable list l that f looks into. Wanna have this
behavior for d, e, f, and g? Just add them to
the list!

This is what my suggestion does [1], only the list is
in f, so yes, it is redefined in that particular
implementation but it is a kill and yank operation
away from having the list a variable instead.

But, for the record, tho I think that solution is
better (easier) _in general_, in this case it is
built to be operated on the command level so here
I recommend a loop which sets the properties...

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal