GNU bug report logs -
#76055
29.4; Doc of string-empty-p
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Tue, 4 Feb 2025 20:29:01 UTC
Severity: minor
Tags: wontfix
Found in version 29.4
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76055 in the body.
You can then email your comments to 76055 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Tue, 04 Feb 2025 20:29:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 04 Feb 2025 20:29:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The doc string should tell you that it treats a symbol for arg STRING,
instead of a string, by checking its `symbol-name'. E.g., like what is
done for `string=':
Symbols are also allowed; their print names are used instead.
This should be done for _each_ function where a string is said to be the
expected arg but where we also allow a symbol.
In GNU Emacs 29.4 (build 2, x86_64-w64-mingw32) of 2024-07-05 built on
AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.5371)
Configured using:
'configure --with-modules --without-dbus --with-native-compilation=aot
--without-compress-install --with-sqlite3 --with-tree-sitter
CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 12:13:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 4 Feb 2025 20:28:00 +0000
> From: Drew Adams via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> The doc string should tell you that it treats a symbol for arg STRING,
> instead of a string, by checking its `symbol-name'. E.g., like what is
> done for `string=':
>
> Symbols are also allowed; their print names are used instead.
>
> This should be done for _each_ function where a string is said to be the
> expected arg but where we also allow a symbol.
I'm not sure we want to advertise this, certainly not "for _each_
function". Who says this is not a side effect of the particular
implementation, which can therefore be changed without notice?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 17:14:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > Symbols are also allowed; their print names are used instead.
> >
> > This should be done for _each_ function where a string is said to be the
> > expected arg but where we also allow a symbol.
>
> I'm not sure we want to advertise this, certainly not "for _each_
> function". Who says this is not a side effect of the particular
> implementation, which can therefore be changed without notice?
Fair enough, wrt your last sentence.
I didn't say "for each function". I said
each function where..." - something quite
different.
To be more precise: Please do it for each
such function where you can guess that this
behavior isn't just a side effect or that's
likely to be changed without notice.
My guess is that 90% or more of the cases
where we do this are intentional - we
explicitly _want_ to let users use a symbol
in place of a string. That means it's in
the _design_, not just an implementation
side effect.
So for all _such_ functions (i.e., where you
can consider that this is something users
should be aware of), please make the change.
It's a judgment call, up to you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 20:15:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "76055 <at> debbugs.gnu.org" <76055 <at> debbugs.gnu.org>
> Date: Wed, 5 Feb 2025 17:13:17 +0000
>
> To be more precise: Please do it for each
> such function where you can guess that this
> behavior isn't just a side effect or that's
> likely to be changed without notice.
How can anyone know that?
> My guess is that 90% or more of the cases
> where we do this are intentional - we
> explicitly _want_ to let users use a symbol
> in place of a string. That means it's in
> the _design_, not just an implementation
> side effect.
That a function calls string= doesn't yet mean its author meant to
allow symbols.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 21:14:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > To be more precise: Please do it for each
> > such function where you can guess that this
> > behavior isn't just a side effect or that's
> > likely to be changed without notice.
>
> How can anyone know that?
By looking at the name of the function and the
function definition, and thinking about how
the function is used and expected to be used?
A function such as `string-empty-p' is a prime
candidate for checking and adding such mention.
Its name (and its current doc string) provides
no clue that it handles a symbol argument as
if you were passing (symbol-name <the symbol>).
If a function name shouts that the function's
only about a string, its doc should mention it if
that's not the case.
> > My guess is that 90% or more of the cases
> > where we do this are intentional - we
> > explicitly _want_ to let users use a symbol
> > in place of a string. That means it's in
> > the _design_, not just an implementation
> > side effect.
>
> That a function calls string= doesn't yet mean its author meant to
> allow symbols.
Of course not. It requires thinking about the
function's definition and how it's expected to
be used.
At least for _new_ functions that use primarily
strings as args, the _author_ should know why it
was decided to allow symbols instead of just
strings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 21:28:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 76055 <at> debbugs.gnu.org (full text, mbox):
A function such as `string-empty-p' is a prime
candidate for checking and adding such mention.
Its name (and its current doc string) provides
no clue that it handles a symbol argument as
if you were passing (symbol-name <the symbol>).
Why should it? Lisp is a dynamic language, and predicates generally
accept anything. If anything, if the notion is that string-empty-p
should _reject_ anything but strings, it should be an assert! (Not
saying that should be the case ...)
If a function name shouts that the function's
only about a string, its doc should mention it if
that's not the case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 21:42:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 76055 <at> debbugs.gnu.org (full text, mbox):
Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:
> The doc string should tell you that it treats a symbol for arg STRING,
> instead of a string, by checking its `symbol-name'. E.g., like what is
> done for `string=':
>
> Symbols are also allowed; their print names are used instead.
FWIW, I'm not suggesting any changes, but I admit that I never really
understood this design decision.
This is what I get in Guile:
scheme@(guile-user)> (string=? "foo" 'foo)
ice-9/boot-9.scm:1676:22: In procedure raise-exception:
In procedure string=: Wrong type argument in position 2 (expecting
string): foo
And in SBCL:
* (string= "foo" 'foo)
NIL
* (string= "foo" 123)
debugger invoked on a SIMPLE-TYPE-ERROR in thread
#<THREAD tid=259 "main thread" RUNNING {7004FF0003}>:
123 is not a string designator.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 23:29:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> A function such as `string-empty-p' is a prime
> candidate for checking and adding such mention.
>
> Its name (and its current doc string) provides
> no clue that it handles a symbol argument as
> if you were passing (symbol-name <the symbol>).
>
> Why should it? Lisp is a dynamic language, and
> predicates generally accept anything. If anything,
> if the notion is that string-empty-p should _reject_
> anything but strings, it should be an assert!
> (Not saying that should be the case ...)
This is essentially a type predicate (per its
name, if nothing else): test whether the arg is
an empty string.
Of _course_ you can pass it a value of any type.
But what should its behavior be for a non-string
arg?
There was a choice made of whether to return nil
for an arbitrary non-string or to raise an error.
Emacs chose the latter, and I have _no problem_
with that.
(string-empty-p [1 2]) ; -> error
(string-empty-p 42) ; -> error
(string-empty-p (cons 1 2)) ; -> error
(string-empty-p nil) ; -> error
But if the non-string is a symbol then we have
a different story:
(string-empty-p "cat") ; -> nil
(string-empty-p 'cat) ; -> nil
(string-empty-p "") ; -> t
(string-empty-p (intern "")) ; -> t
The handling of a symbol arg isn't something
someone would expect, just by looking at the
function name and reading the doc.
It raises an error for a non-string argument,
showing that it is, indeed, an empty-string
type predicate...
...EXCEPT for a non-string argument that's a
symbol. If the `symbol-name' of the symbol
is "" then it returns t. If the name is "x"
it returns nil.
That's what's missing. It's not _at all_
obvious it would do this - neither from its
name nor from its doc. It presents itself
as just an empty-string type predicate.
Just what is this function? It's simply a
`string=' test for "". And lo and behold,
the doc string of `string=' tells us loud
and clear:
Symbols are also allowed; their print
names are used instead.
Thank you very much, Emacs doc! I have no
problem with this choice of behavior. And
the doc is nice enough to make the behavior
clear.
The doc of `string-empty-p' should obviously
do the same - for the same reason: because
this exceptional non-string behavior is not
obvious, and the predicate's name and doc
suggests a different behavior (so far).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Wed, 05 Feb 2025 23:31:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > The doc string should tell you that it treats a symbol for arg STRING,
> > instead of a string, by checking its `symbol-name'. E.g., like what is
> > done for `string=':
> >
> > Symbols are also allowed; their print names are used instead.
>
> FWIW, I'm not suggesting any changes, but I admit that I never really
> understood this design decision.
>
> This is what I get in Guile:
>
> scheme@(guile-user)> (string=? "foo" 'foo)
> ice-9/boot-9.scm:1676:22: In procedure raise-exception:
> In procedure string=: Wrong type argument in position 2 (expecting
> string): foo
>
> And in SBCL:
>
> * (string= "foo" 'foo)
> NIL
>
> * (string= "foo" 123)
>
> debugger invoked on a SIMPLE-TYPE-ERROR in thread
> #<THREAD tid=259 "main thread" RUNNING {7004FF0003}>:
> 123 is not a string designator.
I'm not at all raising the question of it raising or
not raising an error if the arg isn't a string (i.e.,
"rejecting" the arg, as Alfred put it).
Elisp does the same as Scheme and SBCL for a non-symbol
non-string. (But note SBCL's handling of a symbol, BTW.)
I _like_ Elisp's `string=' behavior and doc. It says:
I'm a function that checks whether two strings are equal.
The args must be strings or I'll raise an error.
Oh wait, I do also accept symbols, and for them I use
their `symbol-name's, but that's the only non-string
exception.
[ I could also like a behavior that raised an error for
all non-string args, i.e., including symbols. I could
also like a behavior that returned nil for a non-string
arg (any non-string arg). That latter behavior would
just be a test whether the args are strings AND if so,
are equal. ]
`string-empty-p' should be just as polite and user
friendly as `string='.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Thu, 06 Feb 2025 08:07:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "76055 <at> debbugs.gnu.org" <76055 <at> debbugs.gnu.org>
> Date: Wed, 5 Feb 2025 21:13:05 +0000
>
> > > To be more precise: Please do it for each
> > > such function where you can guess that this
> > > behavior isn't just a side effect or that's
> > > likely to be changed without notice.
> >
> > How can anyone know that?
>
> By looking at the name of the function and the
> function definition, and thinking about how
> the function is used and expected to be used?
Feel free to do this and suggest which functions you think should
document their support of symbols. I personally think that you are
greatly underestimating how large and complex this job is, and
therefore I don't plan doing it myself, and would not encourage anyone
to do it. I think the benefits are quite small compared with the
efforts.
> At least for _new_ functions that use primarily
> strings as args, the _author_ should know why it
> was decided to allow symbols instead of just
> strings.
You assume that it was a conscious decision, but that is not given at
all. I dare to think that this assumption is simply false in most, if
not all, cases.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Thu, 06 Feb 2025 08:13:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 5 Feb 2025 16:41:47 -0500
>
> Drew Adams via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> > The doc string should tell you that it treats a symbol for arg STRING,
> > instead of a string, by checking its `symbol-name'. E.g., like what is
> > done for `string=':
> >
> > Symbols are also allowed; their print names are used instead.
>
> FWIW, I'm not suggesting any changes, but I admit that I never really
> understood this design decision.
It's too late to change that: this function supported symbols since
the very beginning. I'm guessing there were good practical reasons
for that behavior.
However, while extending to strings comparison to symbol names could
make sense, telling whether a string is empty (the subject of this
report) is NOT: what symbol could have an empty name?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Thu, 06 Feb 2025 20:20:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> However, while extending to strings comparison to symbol names could
> make sense, telling whether a string is empty (the subject of this
> report) is NOT: what symbol could have an empty name?
That's easy.
(intern "") gives you such a symbol.
It's written ## (dunno why).
(symbol-name '##) ; => ""
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Thu, 06 Feb 2025 20:20:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 76055 <at> debbugs.gnu.org (full text, mbox):
Please fix the doc for `string-empty-p', at least.
Thx.
Added tag(s) wontfix.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Thu, 06 Feb 2025 22:19:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Thu, 06 Feb 2025 22:24:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 76055 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 5 Feb 2025 16:41:47 -0500
>>
>> FWIW, I'm not suggesting any changes, but I admit that I never really
>> understood this design decision.
>
> It's too late to change that: this function supported symbols since
> the very beginning.
Agreed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 07:18:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "76055 <at> debbugs.gnu.org" <76055 <at> debbugs.gnu.org>
> Date: Thu, 6 Feb 2025 20:19:50 +0000
>
> Please fix the doc for `string-empty-p', at least.
As I said, I don't think it's needed.
I didn't yet hear any opinions supporting your request.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 07:19:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "76055 <at> debbugs.gnu.org" <76055 <at> debbugs.gnu.org>
> Date: Thu, 6 Feb 2025 20:19:03 +0000
>
> > However, while extending to strings comparison to symbol names could
> > make sense, telling whether a string is empty (the subject of this
> > report) is NOT: what symbol could have an empty name?
>
> That's easy.
>
> (intern "") gives you such a symbol.
> It's written ## (dunno why).
>
> (symbol-name '##) ; => ""
And where did you see such symbols used in Emacs?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 09:12:01 GMT)
Full text and
rfc822 format available.
Message #55 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
>
> FWIW, I'm not suggesting any changes, but I admit that I never really
> understood this design decision.
[...]
> And in SBCL:
>
> * (string= "foo" 'foo)
> NIL
Common Lisp has the concept of "designators"
(https://www.lispworks.com/documentation/HyperSpec/Body/01_dae.htm).
The arguments of string= are documented to be "string designators"
(https://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#string_designator).
I'm not suggesting that Emacs Lisp should introduce designators, just
trying to clear up what SBCL is doing here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 16:48:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > > However, while extending to strings comparison to symbol names could
> > > make sense, telling whether a string is empty (the subject of this
> > > report) is NOT: what symbol could have an empty name?
> >
> > That's easy.
> >
> > (intern "") gives you such a symbol.
> > It's written ## (dunno why).
> >
> > (symbol-name '##) ; => ""
>
> And where did you see such symbols used in Emacs?
I didn't say I see uses in Emacs (whatever that
might mean). I haven't looked for them.
Who introduced the symbol `##' into Elisp?
I have no idea. But yes, symbols with
empty-string names have long existed in Lisps.
There's no reason they wouldn't or shouldn't.
Do you know of a reason? If so, do you propose
to change Elisp to remove their possibility?
_I_ didn't design `string=' or `string-empty-p'
to accept symbols. I'm OK with that, provided
it's documented.
As I said, other reasonable definitions could
do either of the following:
* Return nil for any arg that's not a string.
* Raise an error for any arg that's not a string.
But neither is the choice that Emacs made.
What's not helpful is to name the function as
being about strings, and document it only as
being about strings. `string=' doc doesn't
have that doc bug, at least.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 16:50:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > Please fix the doc for `string-empty-p', at least.
>
> As I said, I don't think it's needed.
Did you? Did you say why? Do you think
someone will suppose that symbols can be
tested by it for an empty symbol name?
You, who at the same time questions the
utility of a symbol with an empty name?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Fri, 07 Feb 2025 17:16:01 GMT)
Full text and
rfc822 format available.
Message #64 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "76055 <at> debbugs.gnu.org" <76055 <at> debbugs.gnu.org>
> Date: Fri, 7 Feb 2025 16:49:48 +0000
>
> > > Please fix the doc for `string-empty-p', at least.
> >
> > As I said, I don't think it's needed.
>
> Did you?
Yes, I did.
> Did you say why?
Yes, I did.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Sun, 09 Feb 2025 03:58:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > > However, while extending to strings comparison to symbol names could
> > > make sense, telling whether a string is empty (the subject of this
> > > report) is NOT: what symbol could have an empty name?
> >
> > That's easy.
> >
> > (intern "") gives you such a symbol.
> > It's written ## (dunno why).
> >
> > (symbol-name '##) ; => ""
>
> And where did you see such symbols used in Emacs?
Serendipitously, just came across this use of it today:
https://github.com/tarsius/llama
Linked from this Reddit thread:
https://www.reddit.com/r/emacs/comments/1il4itl/what_does_the_double_pound_mean_in_emacs_lisp/?ref=share&ref_source=link
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Sun, 09 Feb 2025 07:33:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
> "76055 <at> debbugs.gnu.org"
> <76055 <at> debbugs.gnu.org>
> Date: Sun, 9 Feb 2025 03:57:36 +0000
>
> > > (symbol-name '##) ; => ""
> >
> > And where did you see such symbols used in Emacs?
>
> Serendipitously, just came across this use of it today:
>
> https://github.com/tarsius/llama
>
> Linked from this Reddit thread:
>
> https://www.reddit.com/r/emacs/comments/1il4itl/what_does_the_double_pound_mean_in_emacs_lisp/?ref=share&ref_source=link
Doesn't sound like a reason good enough to say potentially confusing
things in a doc string.
So no, still no justification and still no other opinions except
yours.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Sun, 09 Feb 2025 07:45:03 GMT)
Full text and
rfc822 format available.
Message #73 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> Serendipitously, just came across this use of it today:
>
> https://github.com/tarsius/llama
Its syntax (##foo %1 &*) looks like dot syntax
for vectorizing functions in Julia:
https://docs.julialang.org/en/v1/manual/functions/#man-vectorized
where `foo.(x)` applies `foo` to each element of x.
PS: this is not to be confused with `foo.(x)` in Elixir
that simply calls an anonymous function by value,
i.e. that corresponds just to `(funcall foo x)`.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Mon, 17 Feb 2025 21:16:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> -----Original Message-----
> From: Eli Zaretskii <eliz <at> gnu.org>
> Sent: Saturday, February 8, 2025 11:32 PM
> To: Drew Adams <drew.adams <at> oracle.com>
> Cc: stefankangas <at> gmail.com; 76055 <at> debbugs.gnu.org
> Subject: [External] : Re: bug#76055: 29.4; Doc of string-empty-p
>
> > From: Drew Adams <drew.adams <at> oracle.com>
> > CC: "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
> > "76055 <at> debbugs.gnu.org"
> > <76055 <at> debbugs.gnu.org>
> > Date: Sun, 9 Feb 2025 03:57:36 +0000
> >
> > > > (symbol-name '##) ; => ""
> > >
> > > And where did you see such symbols used in Emacs?
> >
> > Serendipitously, just came across this use of it today:
> >
> >
> https://urldefense.com/v3/__https://github.com/tarsius/llama__;!!ACWV5N9M2
> RV99hQ!MeDkTcQ8UVc95uTLaVLNrICJSfOp9SC_VeY2u0xGgWRk5ctKV-
> 7CcA6Ydi4pmdXAGdk-Smfp1vY$
> >
> > Linked from this Reddit thread:
> >
> >
> https://urldefense.com/v3/__https://www.reddit.com/r/emacs/comments/1il4it
> l/what_does_the_double_pound_mean_in_emacs_lisp/?ref=share&ref_source=link
> __;!!ACWV5N9M2RV99hQ!MeDkTcQ8UVc95uTLaVLNrICJSfOp9SC_VeY2u0xGgWRk5ctKV-
> 7CcA6Ydi4pmdXAGdk-Mp-7kQk$
>
> Doesn't sound like a reason good enough to say potentially confusing
> things in a doc string.
>
> So no, still no justification and still no other opinions except
> yours.
What's "potentially confusing" about the doc
saying exactly what the doc of `string=' says
about this oddity (corner case)? It's all the
_more_ important for `string-empty-p' to mention
it, as that predicate is all about the thing
being empty!
Again:
What's not helpful is to name the function as
being about strings, and document it only as
being about strings. `string=' doc doesn't
have that doc bug, at least.
Common Lisp and previous Lisps have symbols with
empty names. This is "normal" for Lisps.
What could be argued is not so normal is Elisp's
use of string functions that act also on symbols
(by way of their `symbol-name's). That might be
a bit odd, but it's what you (Emacs maintainers)
decided to do. That's OK - except that it's a
gotcha (unexpected). The doc should call it out.
Silently providing unexpected behavior isn't
helpful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Tue, 18 Feb 2025 12:39:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
> "76055 <at> debbugs.gnu.org"
> <76055 <at> debbugs.gnu.org>
> Date: Mon, 17 Feb 2025 21:15:01 +0000
>
> > Doesn't sound like a reason good enough to say potentially confusing
> > things in a doc string.
> >
> > So no, still no justification and still no other opinions except
> > yours.
>
> What's "potentially confusing" about the doc
> saying exactly what the doc of `string=' says
> about this oddity (corner case)?
The fact that the "empty string" notion is applied to symbols, of
course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Tue, 18 Feb 2025 17:50:04 GMT)
Full text and
rfc822 format available.
Message #82 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> > > Doesn't sound like a reason good enough to say potentially confusing
> > > things in a doc string.
> > >
> > > So no, still no justification and still no other opinions except
> > > yours.
> >
> > What's "potentially confusing" about the doc
> > saying exactly what the doc of `string=' says
> > about this oddity (corner case)?
>
> The fact that the "empty string" notion is
> applied to symbols, of course.
That's not confusion from the doc. It's from
the function that the doc describes.
What's unexpected and possibly confusing is
that the function _does_ apply that "notion"
to symbols, as well as strings. Which is why
it's important for the function's doc to tell
you about this oddity.
Exactly the same reason that the doc for
`string=' tells you about it. But for
`string-empty-p' it's even more important,
since the _point_ of that predicate is to
test for emptiness (and the predicate's name
suggests it's about testing only strings).
The current doc gives the impression that
for a symbol (as for other non-strings) the
predicate would raise an error.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#76055; Package
emacs.
(Tue, 18 Feb 2025 19:45:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 76055 <at> debbugs.gnu.org (full text, mbox):
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
> "76055 <at> debbugs.gnu.org"
> <76055 <at> debbugs.gnu.org>
> Date: Tue, 18 Feb 2025 17:49:52 +0000
>
> > > > Doesn't sound like a reason good enough to say potentially confusing
> > > > things in a doc string.
> > > >
> > > > So no, still no justification and still no other opinions except
> > > > yours.
> > >
> > > What's "potentially confusing" about the doc
> > > saying exactly what the doc of `string=' says
> > > about this oddity (corner case)?
> >
> > The fact that the "empty string" notion is
> > applied to symbols, of course.
>
> That's not confusion from the doc. It's from
> the function that the doc describes.
A doc string is always supposed to describe its function.
> What's unexpected and possibly confusing is
> that the function _does_ apply that "notion"
> to symbols, as well as strings.
Like I said at the very beginning: this is not intentional. It is
just a side effect of the implementation.
> Which is why it's important for the function's doc to tell you about
> this oddity.
No, it's the other way around. Which I also said at the very
beginning.
So we have now completed a full circle, which is a clear sign that
this discussion exhausted itself, and should be discontinued.
> The current doc gives the impression that
> for a symbol (as for other non-strings) the
> predicate would raise an error.
Actually, the current doc string says nothing at all about what would
happen if you call the function with a symbol as its argument.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility.
(Tue, 04 Mar 2025 02:50:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Drew Adams <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Tue, 04 Mar 2025 02:50:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 76055-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Drew Adams <drew.adams <at> oracle.com>
>> CC: "stefankangas <at> gmail.com" <stefankangas <at> gmail.com>,
>> "76055 <at> debbugs.gnu.org"
>> <76055 <at> debbugs.gnu.org>
>> Date: Tue, 18 Feb 2025 17:49:52 +0000
>>
>> > > > Doesn't sound like a reason good enough to say potentially confusing
>> > > > things in a doc string.
>> > > >
>> > > > So no, still no justification and still no other opinions except
>> > > > yours.
>> > >
>> > > What's "potentially confusing" about the doc
>> > > saying exactly what the doc of `string=' says
>> > > about this oddity (corner case)?
>> >
>> > The fact that the "empty string" notion is
>> > applied to symbols, of course.
>>
>> That's not confusion from the doc. It's from
>> the function that the doc describes.
>
> A doc string is always supposed to describe its function.
>
>> What's unexpected and possibly confusing is
>> that the function _does_ apply that "notion"
>> to symbols, as well as strings.
>
> Like I said at the very beginning: this is not intentional. It is
> just a side effect of the implementation.
>
>> Which is why it's important for the function's doc to tell you about
>> this oddity.
>
> No, it's the other way around. Which I also said at the very
> beginning.
>
> So we have now completed a full circle, which is a clear sign that
> this discussion exhausted itself, and should be discontinued.
Agreed. I'm therefore closing this bug report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 01 Apr 2025 11:25:19 GMT)
Full text and
rfc822 format available.
This bug report was last modified 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.