Received: (at 81702) by debbugs.gnu.org; 25 Aug 2026 11:28:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 25 07:28:00 2026
Received: from localhost ([127.0.0.1]:52118 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wypJw-0001J6-JN
for submit <at> debbugs.gnu.org; Tue, 25 Aug 2026 07:28:00 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:33410)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1wypJu-0001Io-Q5
for 81702 <at> debbugs.gnu.org; Tue, 25 Aug 2026 07:27:59 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1wypJo-00056S-KF; Tue, 25 Aug 2026 07:27:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=C4zTrdiVLN4GmQDDlRB5R3jg6eVWEKrwOmDwflaP5P8=; b=cWa0fDLuqKkoz4Pd0GVM
EmiWD/db2tQK6AgU4jKHFmCHin/2P/HsprLI4OsAERlqH2lQvEQsLZQ2SUpCZIPUuzhAC4EWlD2Cq
a0wwgQrIypCsY2iKXPSQCfrFTvFSyC7whrXcfpDQpC/bOnshTBohCFvK1BJSFcNblraQvdNUSkmFf
ClZqofDaUnE9Y3paXRzPuCXEcB3q+AkhA3npqUcLt8CpqsshUMgkKgSJcpUrGMi+kk96i4EYUci/D
jCQuEN20b2bzaBGebUkHYBy/AcT+TslKWOD/GIHT+TPf/synMMpWLeJJb6s2kmbOebTughXFQt+dV
LqkcOhv9hLJ4AA==;
Date: Tue, 25 Aug 2026 14:27:47 +0300
Message-Id: <86pkz6phho.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: "Drew Adams" <drew00000001@HIDDEN>
In-Reply-To: <005201dd343d$c1206cc0$43614640$@gmail.com>
(drew00000001@HIDDEN)
Subject: Re: bug#81702: 30.2; Doc about empty string(s), empty sequences...
References: <005201dd343d$c1206cc0$43614640$@gmail.com>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 81702
Cc: 81702 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
> From: "Drew Adams" <drew00000001@HIDDEN>
> Date: Mon, 24 Aug 2026 19:59:32 -0700
>
> It seems that Emacs now has only one empty string. This should be
> documented. If it's not the case then that should be documented
> instead.
I don't see why we should document this implementation detail. The
ELisp manual says not to expect anything in this case:
If OBJECT1 and OBJECT2 are symbols with the same name, they are
normally the same object--but see *note Creating Symbols:: for
exceptions. For other non-numeric types (e.g., lists, vectors,
strings), two arguments with the same contents or elements are not
necessarily ‘eq’ to each other: they are ‘eq’ only if they are the
same object, meaning that a change in the contents of one will be
reflected by the same change in the contents of the other.
So whether any two strings with the same contents are the same object
is not known in advance, and programs should not depend on that.
There's no bug here.
bug-gnu-emacs@HIDDEN:bug#81702; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 25 Aug 2026 02:59:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 24 22:59:46 2026
Received: from localhost ([127.0.0.1]:48255 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wyhO5-0004UT-LG
for submit <at> debbugs.gnu.org; Mon, 24 Aug 2026 22:59:46 -0400
Received: from lists1p.gnu.org ([2001:470:142::17]:36702)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <drew00000001@HIDDEN>)
id 1wyhO3-0004Tu-Hp
for submit <at> debbugs.gnu.org; Mon, 24 Aug 2026 22:59:44 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <drew00000001@HIDDEN>)
id 1wyhNy-0003zB-6g
for bug-gnu-emacs@HIDDEN; Mon, 24 Aug 2026 22:59:38 -0400
Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <drew00000001@HIDDEN>)
id 1wyhNw-0007lM-Hh
for bug-gnu-emacs@HIDDEN; Mon, 24 Aug 2026 22:59:37 -0400
Received: by mail-pj1-x102e.google.com with SMTP id
98e67ed59e1d1-38e08baf860so4775821a91.2
for <bug-gnu-emacs@HIDDEN>; Mon, 24 Aug 2026 19:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20251104; t=1787626774; x=1788231574; darn=gnu.org;
h=content-language:thread-index:content-transfer-encoding
:content-type:mime-version:message-id:date:subject:to:from:from:to
:cc:subject:date:message-id:reply-to:content-type;
bh=wRH6981jAx3ImbikHfO4JvZXP7Sn5miL1LgCTtRJAtg=;
b=HiakRWROSXfu+m3udjQZVkfARmxaapWa4Vni/kPXAmX/0AaZordY7+v0AM9TDaPNJW
3VrmwykknA7Br1MQvhkUyYf3J19/3GWjw5/C0qsvs3s5xFSPhqvYxrZ1z9x7R4CL2+vH
kImJ8XfBrpMLiO7JJOpaswWOMJyo1JsPqmJ0wJ8La91GyaIGQ67EcKmLQhp0+49ferQD
jIB0ZppQuMSAc6kipJd/695UKlwf2wVnHAeT7aYi9P0NidUdWeMRYvphxjvI532+9URd
qDdx61BwQLQ6jnS9lBPuBlBm2L8LiMXJmnjySCceYHBu7waoKV6YxXdujloP+ZF4ndU9
QqFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1787626774; x=1788231574;
h=content-language:thread-index:content-transfer-encoding
:content-type:mime-version:message-id:date:subject:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to
:content-type;
bh=wRH6981jAx3ImbikHfO4JvZXP7Sn5miL1LgCTtRJAtg=;
b=nHnu+InPdkRqyIQ4icXEE2/LPMVsrtQP4IEyJzNn5yIdYL4vwieKYbmcYqZxMLhrwq
7ENeB+QTQoZZcsUSMbdrM99i4PK1EZE0iJAKiqiYqMiqitcia/gBiShSrPbE1cYF09Q8
QnWaGxb4KOPX1LHsRKYwUSfBxCD9/TZ9B2YdwVZ3y4XTEFQxLcsm+bWIvh5DzfCM+Ax+
EQjmuGDxa6QUHEiZmO+Zh0sxCE/r+r+/VaxeH1BSdW06QWq8zPLLH1ZcZvLxOTZx1bxU
/TkpjUi10848CFSHjypncZHomMVhOlbbzqLsFTqOmDn8jZhVwpk0a88ZIaLyrC11DTc2
qk0w==
X-Gm-Message-State: AFuF++kzzgveJ61sxnxSIp88J/iOTa7QcGHEoAxUnSTlLRD1yBKsc4Y9
5Y5MXtjIU7lRyJNtDhIQMjv8Zn7lglRz7RCU5EuYg0chydOw5kLKkxaMOLn7Mn09
X-Gm-Gg: AR+sD13dOvNHimJfQuYFo77C4KdPduPCAF+GxKj/fja4MeohkSvTC1LB7mKsxUBXRL4
CsJaAEnpH8ty0i/h2Hjq6OZc7m5dB7qPUDGXZ62d1AepMjYPwyOd45AxtyEqljLQ/BLjKDuKADV
aSQqarQoHfMxKHgxogHyxdM+xFIez4oLf7r9RfNlESDp+teeTh5DMZ0FCUBTpggcwwAaHylyQjO
0iaoJU8xFONMXxGlC4lYXAyAxCocBuBffT9AuHRgOqdfGpOpR3fWWHm/wjd7LrnKu41+L6hR1lt
VfWns8py2y8h9WbA5o1c/Ov2I7dKmWmpItZ7IOPUnAt7eTdOqJ4YTLoLzYrNo28HcIInGrrKHHo
1Jp820anTerjck9MA1o7dFUuMmhqv/9OrCZcS/aDMSzbs3OHrM6ENRj97/Opj62LDfL0oVpQaHK
kMKR0+JEGckDLlTgcaaP6WrEtLk+g69UHsYxeE10YY/SQodlD2A1ag6KAFc2Uvg0zWTZd7lA==
X-Received: by 2002:a17:90b:1d01:b0:38f:5801:dc0e with SMTP id
98e67ed59e1d1-395df5e8426mr45162798a91.15.1787626774380;
Mon, 24 Aug 2026 19:59:34 -0700 (PDT)
Received: from Bufflehead ([2601:640:8d01:4270:1cea:4f01:c5c5:6e05])
by smtp.gmail.com with ESMTPSA id
5a478bee46e88-327f9236166sm30900905eec.28.2026.08.24.19.59.33
for <bug-gnu-emacs@HIDDEN>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 24 Aug 2026 19:59:33 -0700 (PDT)
From: "Drew Adams" <drew00000001@HIDDEN>
To: <bug-gnu-emacs@HIDDEN>
Subject: 30.2; Doc about empty string(s), empty sequences...
Date: Mon, 24 Aug 2026 19:59:32 -0700
Message-ID: <005201dd343d$c1206cc0$43614640$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: Ad00PU8ml1I92Nv3RB2I7/AXxfFEMA==
Content-Language: en-us
Received-SPF: pass client-ip=2607:f8b0:4864:20::102e;
envelope-from=drew00000001@HIDDEN; helo=mail-pj1-x102e.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: It seems that Emacs now has only one empty string. This
should
be documented. If it's not the case then that should be documented instead.
Sometimes the doc speaks of "an" empty string, suggesting there can be more
than one. Sometimes it speaks of "the" empty string, suggesting there is
only ever one.
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (drew00000001[at]gmail.com)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (drew00000001[at]gmail.com)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: It seems that Emacs now has only one empty string. This should
be documented. If it's not the case then that should be documented instead.
Sometimes the doc speaks of "an" empty string, suggesting there can be more
than one. Sometimes it speaks of "the" empty string, suggesting there is
only ever one.
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2001:470:142:0:0:0:0:17 listed in]
[list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends
in digit (drew00000001[at]gmail.com)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (drew00000001[at]gmail.com)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
It seems that Emacs now has only one empty string. This should be
documented. If it's not the case then that should be documented
instead.
Sometimes the doc speaks of "an" empty string, suggesting there can be
more than one. Sometimes it speaks of "the" empty string, suggesting
there is only ever one.
Both "an" and "the" are even used in the same node, (elisp) "Creating
Strings":
If 'concat' receives no arguments, it returns an empty string.
However, when SEPARATORS can match the empty string, ...
Each of "an" and "the" (empty string) can also be found in other nodes.
It looks like each one is used about half the time.
I haven't searched much further, but the doc should be fixed wherever it
gives the wrong impression (presumably it's wrong to suggest that there
can be multiple empty strings?).
More importantly, the doc should say explicitly what the case is: (a)
there's only one or (b) there can be more than one.
A similar situation exists wrt the sequence doc, but since a sequence is
a union type what needs to be made clear is whether there's only one
empty element of each base sequence type: list, vector, string, char
table, Bool vector. There's only one empty list, for example (and yet
the doc speaks quite often of "an empty list").
[ Actually, maybe there are more kinds of base sequence, beyond those
shown in the sequence type diagram? Rings, for instance, are presented
in the sequences chapter. (Maybe even hash tables? There, we speak of
"the empty" hash table.) ]
Currently, the doc for sequences speaks of "an empty object of the same
type" etc., suggesting that for at least one kind of sequence there can
be more than one empty object. Is that in fact the case?
Whether it is or not, the sequence doc has other places where it speaks
of "an empty" object - e.g. "an empty list" in nodes "Sequence
Functions" and "Combining Conditions".
Again, this somewhat loose language could be tolerated if there were at
least an explicit statement for each sequence type saying whether or not
it can have multiple empty objects. E.g., node "Vector Functions"
speaks of "the empty vector", but an explicit statement that there's
only one empty vector would help.
(Nit: the doc uses both "nonempty" and "non-empty".)
____
Not directly connected with the doc, but related to possible confusion
about single-vs-multiple empty elements:
Binding `print-circle' to `t', and printing the empty list always shows
`nil' (which is good). But printing the empty list shows references to
a shared empty string:
(let ((print-circle t)) (pp '((a nil) (b nil) (c "") (d ""))))
That produces this:
((a nil) (b nil) (c #1=\"\") (d #1#))
It would be better to just print "", if indeed there can only ever be
one empty string. In that case, like nil, it's always shared, and using
the shared-element syntax #1 just confuses more than helps.
If you want a separate bug report for that problem, let me know.
In GNU Emacs 30.2 (build 2, x86_64-w64-mingw32) of 2025-08-14 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.26200
System Description: Microsoft Windows 10 Home (v10.0.2009.26200.9168)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-tree-sitter CFLAGS=-O2
prefix=/g/rel/install-emacs-30.2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
"Drew Adams" <drew00000001@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#81702; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.