GNU bug report logs - #64960
Documentation for copy-sequence

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64960 in the body.
You can then email your comments to 64960 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 16:42:28 +0000

Have been reading the documentation for "copy-sequence".  The description,
specifically

"The elements of a list, vector or record are not copied; they are
shared with the original."

is not very clear about what it does and what one gets.

--------------------

copy-sequence is a built-in function in ‘C source code’.

(copy-sequence ARG)

Type: (function (sequence) sequence)

Return a copy of a list, vector, string, char-table or record.
The elements of a list, vector or record are not copied; they are
shared with the original.

If the original sequence is empty, this function may return
the same empty object instead of its copy.

This function does not change global state, including the match data.

Message #8 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 21:36:32 +0300

> Date: Sun, 30 Jul 2023 16:42:28 +0000
> From:  uzibalqa via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Have been reading the documentation for "copy-sequence".  The description,
> specifically
> 
> "The elements of a list, vector or record are not copied; they are
> shared with the original."
> 
> is not very clear about what it does and what one gets.

As the doc string says: the elements are not copied.  You get a new
sequence whose elements are shared with the original one.

Message #11 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 19:20:45 +0000

Sent with Proton Mail secure email.

------- Original Message -------
On Monday, July 31st, 2023 at 6:36 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sun, 30 Jul 2023 16:42:28 +0000
> > From: uzibalqa via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" bug-gnu-emacs <at> gnu.org
> > 
> > Have been reading the documentation for "copy-sequence". The description,
> > specifically
> > 
> > "The elements of a list, vector or record are not copied; they are
> > shared with the original."
> > 
> > is not very clear about what it does and what one gets.
> 
> 
> As the doc string says: the elements are not copied. You get a new
> sequence whose elements are shared with the original one.
> 

So it returns a copy but elements are not copied.  So what happens exactly ?
You get a reference to the original ?  When I modify the copy, the original 
remains intact.  It would help if the description in broadened, it is currently
too cryptic.

Message #14 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: uzibalqa <uzibalqa <at> proton.me>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 22:59:16 +0300

On 30/07/2023 22:20, uzibalqa via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> So it returns a copy but elements are not copied.  So what happens exactly ?
> You get a reference to the original ?  When I modify the copy, the original
> remains intact.

The list (if the sequence is a list) is new (from newly allocated cons 
cells), but the values inside (in cars of those conses) are shared with 
the original list.

Message #17 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 20:09:57 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 7:59 AM, Dmitry Gutov <dmitry <at> gutov.dev> wrote:


> On 30/07/2023 22:20, uzibalqa via Bug reports for GNU Emacs, the Swiss
> army knife of text editors wrote:
> 
> > So it returns a copy but elements are not copied. So what happens exactly ?
> > You get a reference to the original ? When I modify the copy, the original
> > remains intact.
> 
> 
> The list (if the sequence is a list) is new (from newly allocated cons
> cells), but the values inside (in cars of those conses) are shared with
> the original list.

It is not evident what the meaning of "shared" means ?  If I use a string,
I get an exact copy and when I change a single character the newlist is 
changed,  the original string remains the same.  So what is shared exactly ?

Message #20 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 23:15:11 +0300

On 30/07/2023 23:09, uzibalqa wrote:
> It is not evident what the meaning of "shared" means ?  If I use a string,
> I get an exact copy and when I change a single character the newlist is
> changed,  the original string remains the same.  So what is shared exactly ?

A string doesn't share anything because characters are not reference 
values. They are simply copied.

Message #23 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 30 Jul 2023 20:41:07 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 8:15 AM, Dmitry Gutov <dmitry <at> gutov.dev> wrote:


> On 30/07/2023 23:09, uzibalqa wrote:
> 
> > It is not evident what the meaning of "shared" means ? If I use a string,
> > I get an exact copy and when I change a single character the newlist is
> > changed, the original string remains the same. So what is shared exactly ?
> 
> 
> A string doesn't share anything because characters are not reference
> values. They are simply copied.

So why does the description also refer to a string.  With strings, things
do not work like the description.

(copy-sequence ARG)

Message #26 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>, uzibalqa <uzibalqa <at> proton.me>
Cc: Eli Zaretskii <eliz <at> gnu.org>,
 "64960 <at> debbugs.gnu.org" <64960 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 01:13:41 +0000

> > It is not evident what the meaning of "shared" means ?  If I use a
> > string, I get an exact copy and when I change a single character
> > the newlist is changed,  the original string remains the same.
> > So what is shared exactly ?
> 
> A string doesn't share anything because characters are not reference
> values. They are simply copied.

Yes and no.
Chars are not shared, but char properties are.

(setq foo (propertize "abcd" 'p1 t 'p2 42))
;; -> #("abcd" 0 4 (p2 42 p1 t))
(setq bar (copy-sequence foo))
;; -> #("abcd" 0 4 (p1 t p2 42))
(aset foo 1 ?W) ; -> ?W, aka 87
foo ; -> #("aWcd" 0 4 (p2 42 p1 t))
bar ; -> #("abcd" 0 4 (p1 t p2 42))

Message #29 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 "64960 <at> debbugs.gnu.org" <64960 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 01:22:06 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 1:13 PM, Drew Adams <drew.adams <at> oracle.com> wrote:


> > > It is not evident what the meaning of "shared" means ? If I use a
> > > string, I get an exact copy and when I change a single character
> > > the newlist is changed, the original string remains the same.
> > > So what is shared exactly ?
> > 
> > A string doesn't share anything because characters are not reference
> > values. They are simply copied.
> 
> 
> Yes and no.
> Chars are not shared, but char properties are.
> 
> (setq foo (propertize "abcd" 'p1 t 'p2 42))
> ;; -> #("abcd" 0 4 (p2 42 p1 t))
> 
> (setq bar (copy-sequence foo))
> ;; -> #("abcd" 0 4 (p1 t p2 42))
> 
> (aset foo 1 ?W) ; -> ?W, aka 87
> 
> foo ; -> #("aWcd" 0 4 (p2 42 p1 t))
> 
> bar ; -> #("abcd" 0 4 (p1 t p2 42))

Ok, meaning that the actual string becomes different, yet changing
the a property, changes the property on both foo and bar ?

Message #32 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 "64960 <at> debbugs.gnu.org" <64960 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 01:36:49 +0000

> > > A string doesn't share anything because characters are not reference
> > > values. They are simply copied.
> >
> >
> > Yes and no.
> > Chars are not shared, but char properties are.
> >
> > (setq foo (propertize "abcd" 'p1 t 'p2 42))
> > ;; -> #("abcd" 0 4 (p2 42 p1 t))
> > (setq bar (copy-sequence foo))
> > ;; -> #("abcd" 0 4 (p1 t p2 42))
> > (aset foo 1 ?W) ; -> ?W, aka 87
> > foo ; -> #("aWcd" 0 4 (p2 42 p1 t))
> > bar ; -> #("abcd" 0 4 (p1 t p2 42))
> 
> Ok, meaning that the actual string becomes different, yet changing
> the a property, changes the property on both foo and bar ?

No.  I didn't change a property.  I swapped one
char for another.  The doc says that the arg's
"elements" are shared.  A string's "elements"
are its chars.  But as Yuri pointed out, the
chars themselves aren't shared, because they
aren't sharable: they aren't references.

Strings can also have properties.  We sometimes
say that it's the characters that have the
properties, but really it's that the properties
are attached to the characters in the string or
buffer - the properties are associated with
string or buffer positions.  The chars themselves
don't really have properties.  The properties are
shared when you copy a string; the chars are not.

This is really more of a natural-language nuance,
about what it means for string elements to be
shared.  You can ignore it, if what I'm saying
just confuses things.

Message #35 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>,
 "64960 <at> debbugs.gnu.org" <64960 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 01:50:17 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 1:36 PM, Drew Adams <drew.adams <at> oracle.com> wrote:


> > > > A string doesn't share anything because characters are not reference
> > > > values. They are simply copied.
> > > 
> > > Yes and no.
> > > Chars are not shared, but char properties are.
> > > 
> > > (setq foo (propertize "abcd" 'p1 t 'p2 42))
> > > ;; -> #("abcd" 0 4 (p2 42 p1 t))
> > > (setq bar (copy-sequence foo))
> > > ;; -> #("abcd" 0 4 (p1 t p2 42))
> > > (aset foo 1 ?W) ; -> ?W, aka 87
> > > foo ; -> #("aWcd" 0 4 (p2 42 p1 t))
> > > bar ; -> #("abcd" 0 4 (p1 t p2 42))
> > 
> > Ok, meaning that the actual string becomes different, yet changing
> > the a property, changes the property on both foo and bar ?
> 
> 
> No. I didn't change a property. I swapped one
> char for another. The doc says that the arg's
> "elements" are shared. A string's "elements"
> are its chars. But as Yuri pointed out, the
> chars themselves aren't shared, because they
> aren't sharable: they aren't references.

You only changed a character, which is not actually sharable.
But if I go change a property value for foo, I should see the
change also in bar, or not ?
 
> Strings can also have properties. We sometimes
> say that it's the characters that have the
> properties, but really it's that the properties
> are attached to the characters in the string or
> buffer - the properties are associated with
> string or buffer positions. The chars themselves
> don't really have properties. The properties are
> shared when you copy a string; the chars are not.

Meaning that I can make a copy of a string just to have 
the same properties (e.g, colour).
 
> This is really more of a natural-language nuance,
> about what it means for string elements to be
> shared. You can ignore it, if what I'm saying
> just confuses things.

Not too confusing, but required some attention.

Currently I am only interested in the actual characters
in my implementation where properties are not important.

Yet in my permute implementation I have seen that whether
I just use string or (copy-sequence string) does make a huge
difference.  Quite difficult to understand what's going on.

Message #38 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 05:21:44 +0300

> Date: Sun, 30 Jul 2023 19:20:45 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: 64960 <at> debbugs.gnu.org
> 
> > As the doc string says: the elements are not copied. You get a new
> > sequence whose elements are shared with the original one.
> 
> So it returns a copy but elements are not copied.  So what happens exactly ?
> You get a reference to the original ?

Yes.

> When I modify the copy, the original remains intact.

No, if you modify an element of the copy, the corresponding element of
the original is also changed.  That's what "shared" means.

Message #41 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 02:31:18 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 2:21 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sun, 30 Jul 2023 19:20:45 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: 64960 <at> debbugs.gnu.org
> > 
> > > As the doc string says: the elements are not copied. You get a new
> > > sequence whose elements are shared with the original one.
> > 
> > So it returns a copy but elements are not copied. So what happens exactly ?
> > You get a reference to the original ?
> 
> 
> Yes.
> 
> > When I modify the copy, the original remains intact.
> 
> 
> No, if you modify an element of the copy, the corresponding element of
> the original is also changed. That's what "shared" means.

Except for strings

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, uzibalqa <uzibalqa <at> proton.me>,
 64960 <at> debbugs.gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 07:24:21 +0200

uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> > > When I modify the copy, the original remains intact.
> >
> >
> > No, if you modify an element of the copy, the corresponding element of
> > the original is also changed. That's what "shared" means.
>
> Except for strings

It is irrelevant what happens when you modify elements of a copied
string because it is impossible.  The statement is simply not applicable
to strings.  That's why the docstring only speaks of "list, vector or
record".

Note that substituting a character in a string is not the same as
modifying the character.  You are substituting a sequence element with
another one and not modifying an element in that case.

The same is true for the list (1 2 3) for example.  Exactly the same
situation as for a string: You can replace the number 2 in a copy with
another one but you can't modify the number 2 in the list.  Numbers and
characters are not mutable.

Michael.

Message #50 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 06:19:46 +0000

------- Original Message -------
On Monday, July 31st, 2023 at 5:24 PM, Michael Heerdegen <michael_heerdegen <at> web.de> wrote:


> uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" bug-gnu-emacs <at> gnu.org writes:
> 
> > > > When I modify the copy, the original remains intact.
> > > 
> > > No, if you modify an element of the copy, the corresponding element of
> > > the original is also changed. That's what "shared" means.
> > 
> > Except for strings
> 
> 
> It is irrelevant what happens when you modify elements of a copied
> string because it is impossible. The statement is simply not applicable
> to strings. That's why the docstring only speaks of "list, vector or
> record".

> Note that substituting a character in a string is not the same as
> modifying the character. You are substituting a sequence element with
> another one and not modifying an element in that case.

That I understand.  I am substituting, but still one gets a different string
nevertheless.
 
> The same is true for the list (1 2 3) for example. Exactly the same
> situation as for a string: You can replace the number 2 in a copy with
> another one but you can't modify the number 2 in the list. Numbers and
> characters are not mutable.

This is the difficult part.  You have a copy of a list and you can swap
elements but not make new ones.  So what you share is the address, where
element 2 say uses the address of element 3.

All this copy-sequence is then quite restrictive in its capabilities.
It does not allow much changes.   
 
> Michael.
>

Message #53 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>, "64960 <at> debbugs.gnu.org"
 <64960 <at> debbugs.gnu.org>
Cc: "eliz <at> gnu.org" <eliz <at> gnu.org>, "uzibalqa <at> proton.me" <uzibalqa <at> proton.me>
Subject: RE: [External] : bug#64960: Documentation for copy-sequence
Date: Mon, 31 Jul 2023 14:34:19 +0000

> > > > When I modify the copy, the original remains intact.
> > >
> > > No, if you modify an element of the copy, the corresponding element of
> > > the original is also changed. That's what "shared" means.
> >
> > Except for strings
> 
> It is irrelevant what happens when you modify elements of a copied
> string because it is impossible.  The statement is simply not applicable
> to strings.  That's why the docstring only speaks of "list, vector or
> record".
> 
> Note that substituting a character in a string is not the same as
> modifying the character.  You are substituting a sequence element with
> another one and not modifying an element in that case.
> 
> The same is true for the list (1 2 3) for example.  Exactly the same
> situation as for a string: You can replace the number 2 in a copy with
> another one but you can't modify the number 2 in the list.  Numbers and
> characters are not mutable.

Well put.

Message #56 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Tue, 01 Aug 2023 05:56:56 +0200

uzibalqa <uzibalqa <at> proton.me> writes:

> > The same is true for the list (1 2 3) for example. Exactly the same
> > situation as for a string: You can replace the number 2 in a copy with
> > another one but you can't modify the number 2 in the list. Numbers and
> > characters are not mutable.
>
> This is the difficult part.  You have a copy of a list and you can swap
> elements but not make new ones.  So what you share is the address, where
> element 2 say uses the address of element 3.
>
> All this copy-sequence is then quite restrictive in its capabilities.
> It does not allow much changes.

I must admit that I don't understand this answer.  What does "can't make
new elements" mean?  "Does not allow changes"...you lost me here.

Michael.

Message #59 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Sun, 13 Aug 2023 06:27:04 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I must admit that I don't understand this answer.  What does "can't make
> new elements" mean?  "Does not allow changes"...you lost me here.

We seem to have finished this discussion, and I think all questions have
been answered.  Is there anything, from your side, that you expect we
should do?


TIA,

Michael.

Message #62 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 14 Aug 2023 10:14:52 +0000

------- Original Message -------
On Sunday, August 13th, 2023 at 4:27 PM, Michael Heerdegen <michael_heerdegen <at> web.de> wrote:


> Michael Heerdegen michael_heerdegen <at> web.de writes:
> 
> > I must admit that I don't understand this answer. What does "can't make
> > new elements" mean? "Does not allow changes"...you lost me here.
> 
> 
> We seem to have finished this discussion, and I think all questions have
> been answered. Is there anything, from your side, that you expect we
> should do?

Although I understand what it does, I om not sure if it would benefit
about some of the details we discussed.
 
> TIA,
> 
> Michael.

Message #65 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Tue, 15 Aug 2023 01:46:37 +0200

uzibalqa <uzibalqa <at> proton.me> writes:

> Although I understand what it does, I om not sure if it would benefit
> about some of the details we discussed.

What in particular?  A lot of the stuff discussed is a direct
consequence of the copy being a new sequence object whose elements have
not been copied.  The manual tries to describe some implications.

Or should we try to find a better wording (to make more clear that
"modify" doesn't mean "replace") - for what part(s)?  What concretely
would have helped you to understand that part of the manual better?

What parts of the documentation have you read so far?


Thx,

Michael.

Message #68 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Tue, 15 Aug 2023 00:43:49 +0000

Sent with Proton Mail secure email.

------- Original Message -------
On Tuesday, August 15th, 2023 at 11:46 AM, Michael Heerdegen <michael_heerdegen <at> web.de> wrote:


> uzibalqa uzibalqa <at> proton.me writes:
> 
> > Although I understand what it does, I om not sure if it would benefit
> > about some of the details we discussed.
> 
> 
> What in particular? A lot of the stuff discussed is a direct
> consequence of the copy being a new sequence object whose elements have
> not been copied. The manual tries to describe some implications.
> 
> Or should we try to find a better wording (to make more clear that
> "modify" doesn't mean "replace") - for what part(s)? What concretely
> would have helped you to understand that part of the manual better?

I found the following is mostly targeted at experienced users.

"The elements of a list, vector or record are not copied; they are
shared with the original."
 
Adding additional wording that it means that not everything is actually copied. 
Some aspects are actually reference values.  Meaning that if you change the
copied sequence, you could inadvertently change the original sequence.

> What parts of the documentation have you read so far?
> 
> 
> Thx,
> 
> Michael.
>

Message #71 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 64960 <at> debbugs.gnu.org, uzibalqa <uzibalqa <at> proton.me>, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Wed, 16 Aug 2023 01:28:25 +0200

uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> "The elements of a list, vector or record are not copied; they are
> shared with the original."
>
> Adding additional wording that it means that not everything is
> actually copied.
> Some aspects are actually reference values.  Meaning that if you change the
> copied sequence, you could inadvertently change the original sequence.

That's the normal behavior in a Lisp, so this belongs into the manual.
After reading (info "(elisp) Sequence Functions") (where this function
is introduced) I think, as far as I understand, that that page tries to
explain this aspect you mention thoroughly.

Michael.

Message #77 received at 64960 <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 64960 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Wed, 16 Aug 2023 04:35:46 +0000

Sent with Proton Mail secure email.

------- Original Message -------
On Wednesday, August 16th, 2023 at 11:28 AM, Michael Heerdegen <michael_heerdegen <at> web.de> wrote:


> uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" bug-gnu-emacs <at> gnu.org writes:
> 
> > "The elements of a list, vector or record are not copied; they are
> > shared with the original."
> > 
> > Adding additional wording that it means that not everything is
> > actually copied.
> > Some aspects are actually reference values. Meaning that if you change the
> > copied sequence, you could inadvertently change the original sequence.
> 
> 
> That's the normal behavior in a Lisp, so this belongs into the manual.
> After reading (info "(elisp) Sequence Functions") (where this function
> is introduced) I think, as far as I understand, that that page tries to
> explain this aspect you mention thoroughly. - Michael.

Is it not customary to include any cross references to the relevant parts
of the manual.  The help using 'C-h f' would benefit if there could be
some links that get you to the relevant part of the manual directly.

Message #82 received at 64960-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 64960-done <at> debbugs.gnu.org,
 eliz <at> gnu.org
Subject: Re: bug#64960: Documentation for copy-sequence
Date: Mon, 11 Sep 2023 08:55:53 -0700

Version: 29.2

uzibalqa <uzibalqa <at> proton.me> writes:

> Is it not customary to include any cross references to the relevant parts
> of the manual.  The help using 'C-h f' would benefit if there could be
> some links that get you to the relevant part of the manual directly.

Such a cross-reference was added in commit a8c8a4e3680d, so I'm closing
this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.