bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Thierry Volpiatto]

Hello,

after having hard time getting the longhand name of a shorthand symbol
at point (with regexp and the local value of read-symbol-shorthands) I
discover it is easy to get this information with:

    (symbol-name (intern-soft (thing-at-point 'symbol)))

Is this the right way to get this information and if so is it
possible to document it?

Thanks.



In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, Motif Version 2.3.8, cairo version 1.16.0)
 of 2022-09-12 built on IPad-S340
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Linux Mint 20.3

Configured using:
 'configure CFLAGS=-O8 --with-mailutils --with-cairo --without-dbus
 --without-gconf --without-gsettings --with-x-toolkit=motif'

Configured features:
ACL CAIRO FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG JSON LCMS2
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE
XIM XPM MOTIF ZLIB

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*

Minor modes in effect:
  bug-reference-prog-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  psession-mode: t
  psession-savehist-mode: t
  global-git-gutter-mode: t
  git-gutter-mode: t
  display-time-mode: t
  winner-mode: t
  helm-epa-mode: t
  helm-descbinds-mode: t
  helm-adaptive-mode: t
  helm-mode: t
  helm-minibuffer-history-mode: t
  helm-ff-icon-mode: t
  shell-dirtrack-mode: t
  helm-popup-tip-mode: t
  async-bytecomp-package-mode: t
  dired-async-mode: t
  minibuffer-depth-indicate-mode: t
  override-global-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow epa-mail face-remap addressbook-bookmark tv-mu4e-config
mu4e-contrib eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util mu4e-patch mu4e mu4e-org mu4e-main
mu4e-view gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum
gnus-group gnus-undo gnus-start gnus-dbus gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win
mu4e-headers mu4e-compose mu4e-draft mu4e-actions smtpmail mu4e-search
mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr kinsoku svg
flow-fill hl-line mu4e-contacts mu4e-update mu4e-folders mu4e-server
mu4e-context mu4e-obsolete mu4e-vars mu4e-helpers mu4e-config ido
emacsbug sendmail helm-command cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs tabify image-file
image-converter char-fold tramp-cache tramp-archive tramp-gvfs dbus
flymake-shellcheck flymake-proc flymake project warnings sh-script smie
executable jka-compr bug-reference naquadah-theme solar cal-dst holidays
hol-loaddefs tv-utils osm dom yaml-mode undo-tree diff queue psession
frameset log-view pcvs-util bash-completion cl-indent pcase ffap
thingatpt autocrypt-message message rmc puny rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader autocrypt-gnus gnus nnheader gnus-util rmail rmail-loaddefs
rfc2047 rfc2045 mail-utils mm-util mail-prsvr autocrypt-mu4e autocrypt
ietf-drums config-w3m git-gutter mule-util appt diary-lib diary-loaddefs
gud wdired dired-extension org-config ob-gnuplot org-crypt net-utils
time winner autotest-mode autoconf-mode woman man ediff ediff-merg
ediff-mult ediff-wind ediff-diff ediff-help ediff-init ediff-util
init-helm helm-ls-git vc-git diff-mode vc vc-dispatcher helm-fd epa
derived epg rfc6068 epg-config helm-epa helm-imenu imenu
helm-elisp-package helm-find helm-org org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol rx org-keys
oc org-compat advice org-macs org-loaddefs cal-menu calendar
cal-loaddefs helm-external isearch-light helm-descbinds helm-wikipedia
all-the-icons all-the-icons-faces data-material data-weathericons
data-octicons data-fileicons data-faicons data-alltheicons wfnames
cus-edit wid-edit helm-ipython helm-elisp helm-eval edebug backtrace
find-func python tramp-sh popup helm-bookmark helm-net xml helm-info
bookmark pp helm-adaptive helm-mode helm-misc helm-files image-dired
image-mode exif filenotify tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat shell pcomplete parse-time
iso8601 time-date ls-lisp helm-buffers helm-occur helm-tags helm-locate
helm-grep wgrep-helm wgrep grep compile text-property-search comint ring
helm-regexp format-spec ansi-color helm-utils helm-help helm-types
helm-extensions-autoloads helm-config helm-autoloads helm
helm-global-bindings helm-easymenu helm-core async-bytecomp helm-source
helm-multi-match helm-lib dired-async dired-aux dired dired-loaddefs
async diminish cl-extra help-mode mb-depth server edmacro kmacro avoid
cus-load use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key easy-mmode
use-package-core finder-inf package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json subr-x map url-vars seq
byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib info w3m-load
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads inotify
lcms2 dynamic-setting font-render-setting cairo motif x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 769108 63304)
 (symbols 48 42224 5)
 (strings 32 254146 3495)
 (string-bytes 1 7680349)
 (vectors 16 78013)
 (vector-slots 8 1043432 53462)
 (floats 8 2878 703)
 (intervals 56 9109 2020)
 (buffers 992 114))
<#secure method=pgpmime mode=sign>

-- 
Thierry

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Date: Sun, 06 Nov 2022 20:16:48 +0000
> 
> after having hard time getting the longhand name of a shorthand symbol
> at point (with regexp and the local value of read-symbol-shorthands) I
> discover it is easy to get this information with:
> 
>     (symbol-name (intern-soft (thing-at-point 'symbol)))
> 
> Is this the right way to get this information and if so is it
> possible to document it?

João, any comments?

Thanks.

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

Thierry is correct. Intern-soft is Emacs way to go from a string
representation to the symbol itself (or nowhere, if there's no match). This
is not new with shorthands.

Should we document this in the Elisp manual? Maybe, but where? Shorthand
section? Not sure. This is a feature of Lisp in general and the correct way
to go from strings to symbols. Before shorthands we got away without this
step for obvious reasons. Curiously, I was pleasantly surprised that much
code of key symbol processing facilities was already using this indirection
and shorthands automatically worked in those facilities because of that.

João

On Sat, Nov 12, 2022, 12:43 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Thierry Volpiatto <thievol@posteo.net>
> > Date: Sun, 06 Nov 2022 20:16:48 +0000
> >
> > after having hard time getting the longhand name of a shorthand symbol
> > at point (with regexp and the local value of read-symbol-shorthands) I
> > discover it is easy to get this information with:
> >
> >     (symbol-name (intern-soft (thing-at-point 'symbol)))
> >
> > Is this the right way to get this information and if so is it
> > possible to document it?
>
> João, any comments?
>
> Thanks.
>

[-- Attachment #2: Type: text/html, Size: 1728 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Thierry Volpiatto]

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


João Távora <joaotavora@gmail.com> writes:

> This is a feature of Lisp in general and the correct way to go from
> strings to symbols.

Great, thanks to confirm.

> Curiously, I was pleasantly surprised that much code of key symbol
> processing facilities was already using this indirection and
> shorthands automatically worked in those facilities because of that.

`substitute-command-keys` at least doesn't handle this.

Say you have the file foo.el with 
`read-symbol-shorthands` == (("f-" . "foo-")) and containing definitions
like `f-dothis`, `f-dothat` etc... and a var `f-help-string` containing string like
"\<f-map>\[f-dothis]: Description", if you define a function `f-help`
containing (substitute-command-keys f-help-string) it will fail
complaining `f-dothis` is void.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

Hmm, not sure we should be using shorthands in docstrings, which aren't
read by the Lisp reader, but by something else... This is what is at stake,
right?

Maybe if good reasonable semantics can be found, but not sure.

On Sat, Nov 12, 2022, 16:20 Thierry Volpiatto <thievol@posteo.net> wrote:

>
> João Távora <joaotavora@gmail.com> writes:
>
> > This is a feature of Lisp in general and the correct way to go from
> > strings to symbols.
>
> Great, thanks to confirm.
>
> > Curiously, I was pleasantly surprised that much code of key symbol
> > processing facilities was already using this indirection and
> > shorthands automatically worked in those facilities because of that.
>
> `substitute-command-keys` at least doesn't handle this.
>
> Say you have the file foo.el with
> `read-symbol-shorthands` == (("f-" . "foo-")) and containing definitions
> like `f-dothis`, `f-dothat` etc... and a var `f-help-string` containing
> string like
> "\<f-map>\[f-dothis]: Description", if you define a function `f-help`
> containing (substitute-command-keys f-help-string) it will fail
> complaining `f-dothis` is void.
>
> --
> Thierry
>

[-- Attachment #2: Type: text/html, Size: 1699 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

We can/should of course document the decision that they aren't supported in
rubbed in the manual though (if we make that decision)...

João

On Sat, Nov 12, 2022, 16:46 João Távora <joaotavora@gmail.com> wrote:

> Hmm, not sure we should be using shorthands in docstrings, which aren't
> read by the Lisp reader, but by something else... This is what is at stake,
> right?
>
> Maybe if good reasonable semantics can be found, but not sure.
>
> On Sat, Nov 12, 2022, 16:20 Thierry Volpiatto <thievol@posteo.net> wrote:
>
>>
>> João Távora <joaotavora@gmail.com> writes:
>>
>> > This is a feature of Lisp in general and the correct way to go from
>> > strings to symbols.
>>
>> Great, thanks to confirm.
>>
>> > Curiously, I was pleasantly surprised that much code of key symbol
>> > processing facilities was already using this indirection and
>> > shorthands automatically worked in those facilities because of that.
>>
>> `substitute-command-keys` at least doesn't handle this.
>>
>> Say you have the file foo.el with
>> `read-symbol-shorthands` == (("f-" . "foo-")) and containing definitions
>> like `f-dothis`, `f-dothat` etc... and a var `f-help-string` containing
>> string like
>> "\<f-map>\[f-dothis]: Description", if you define a function `f-help`
>> containing (substitute-command-keys f-help-string) it will fail
>> complaining `f-dothis` is void.
>>
>> --
>> Thierry
>>
>

[-- Attachment #2: Type: text/html, Size: 2248 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 12 Nov 2022 16:46:51 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 59082@debbugs.gnu.org
> 
> Hmm, not sure we should be using shorthands in docstrings, which aren't read by the Lisp reader, but by
> something else... This is what is at stake, right?

References to functions and variables in doc strings are a matter of
routine.

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

Of course. And for blue the programmer should just use the names of the
symbols there, as always. Shorthands are not the names of symbols, as i
keep reminding.

If the docstring reader is ever enhanced, then maybe programmers can refer
to symbols there using shorthands. Until then, shorthands are Lisp-only.

On Sat, Nov 12, 2022, 17:01 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 12 Nov 2022 16:46:51 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, 59082@debbugs.gnu.org
> >
> > Hmm, not sure we should be using shorthands in docstrings, which aren't
> read by the Lisp reader, but by
> > something else... This is what is at stake, right?
>
> References to functions and variables in doc strings are a matter of
> routine.
>

[-- Attachment #2: Type: text/html, Size: 1422 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 12 Nov 2022 17:18:57 +0000
> Cc: thievol@posteo.net, 59082@debbugs.gnu.org
> 
> Of course. And for blue the programmer should just use the names of the symbols there, as always.
> Shorthands are not the names of symbols, as i keep reminding.
> 
> If the docstring reader is ever enhanced, then maybe programmers can refer to symbols there using
> shorthands. Until then, shorthands are Lisp-only.

I don't understand this response.  Are you saying that the problem
doesn't exist, or are you saying that you just don't care?  Or are you
saying something else?

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

On Sat, Nov 12, 2022, 17:49 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Sat, 12 Nov 2022 17:18:57 +0000
> > Cc: thievol@posteo.net, 59082@debbugs.gnu.org
> >
> > Of course. And for blue the programmer
>

Sorry, it probably didn't help that this "for blue" slipped in when typing
on my phone.

> If the docstring reader is ever enhanced, then maybe programmers can
> refer to symbols there using
> > shorthands. Until then, shorthands are Lisp-only.
>
> I don't understand this response.  Are you saying that the problem
> doesn't exist, or are you saying that you just don't care?  Or are you
> saying something else?
>

I understand. I'm saying docstrings are outside the functional scope of
shorthands, so you should just use longhand there for now. Same as you must
use in M-x and other "global" contexts. Because shorthands are not new
names for symbols.

But I'm also saying that, perhaps, for the particular case of docstrings,
which are inherently file-local constructs, the "docstring reader",
whenever it lives, could be enhanced to allow shorthands, too. So the
intermediate representation of the  docstring mini-language could
understand that the text x-foo actually references the symbol xeno-foo. And
then C-h f would display the true symbol name as it usually does.

But this would basically be a new feature, not strictly necessary to enable
the things that shorthands are originally designed for. But convenient, for
sure.

João

>

[-- Attachment #2: Type: text/html, Size: 2757 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I understand. I'm saying docstrings are outside the functional scope of
  > shorthands, so you should just use longhand there for now. Same as you must
  > use in M-x and other "global" contexts. Because shorthands are not new
  > names for symbols.

Is this really a problem?

Let's consider the case of s.el.  `s.el' says s-foo, and we use a
shorthand to make that read as `string-foo'.  As far as I can see,
anything which uses the symbol's name will use `string-foo'.  That is
the desired behavior.

But if a doc string in s.el actually says "Calls the function
`s-foo'", nothing will translate that to `string-foo', So we will get
incorrect and confusing output.

Does any doc string in s.el actually use the name of a function or
variable in s.el?  I got an explanation of how to obtain the
source code but I have not had time to do it yet.

Maybe we need a construct to use in doc strings
that requests shorthands processing on a part of the doc string.
This would have to happen at read time, when the doc string is read,
so that the proper shorthands are in effect there.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

On Mon, Nov 14, 2022 at 3:13 AM Richard Stallman <rms@gnu.org> wrote:

> Maybe we need a construct to use in doc strings
> that requests shorthands processing on a part of the doc string.
> This would have to happen at read time, when the doc string is read,
> so that the proper shorthands are in effect there.

Correct, but this "read time" is "docstring read time", which I don't think
is technically the same as "Lisp read time".

And I also agree that maybe we don't "need" this urgently, for s.el
or at all. But it would be a nice-to-have, especially if it's easy to
implement.

João

[-- Attachment #2: Type: text/html, Size: 871 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, thievol@posteo.net, 59082@debbugs.gnu.org
> Date: Sun, 13 Nov 2022 22:13:00 -0500
> 
> But if a doc string in s.el actually says "Calls the function
> `s-foo'", nothing will translate that to `string-foo', So we will get
> incorrect and confusing output.
> 
> Does any doc string in s.el actually use the name of a function or
> variable in s.el?

It does.  Here are a few examples:

  (defun s-split-up-to (separator s n &optional omit-nulls)
    "Split S up to N times into substrings bounded by matches for regexp SEPARATOR.

  If OMIT-NULLS is non-nil, zero-length substrings are omitted.

  See also `s-split'."

  (defun s-ends-with? (suffix s &optional ignore-case)
    "Does S end with SUFFIX?

  If IGNORE-CASE is non-nil, the comparison is done without paying
  attention to case differences.

  Alias: `s-suffix?'"

  (defun s-presence (s)
    "Return S if it's `s-present?', otherwise return nil."

  (defun s-count-matches-all (regexp s &optional start end)
    "Count occurrences of `regexp' in `s'.

  `start', inclusive, and `end', exclusive, delimit the part of `s' to
  match.  `start' and `end' are both indexed starting at 1; the initial
  character in `s' is index 1.

  This function starts looking for the next match from the second
  character of the previous match.  Hence, it counts matches that
  overlap a previously found match.  To ignore matches that overlap a
  previously found match, use `s-count-matches'."

I think it really is such a widespread (and good) practice to include
cross-references in doc strings that it should be a no-brainer to
decide that supporting this practice is important.

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 14 Nov 2022 06:39:04 +0000
> Cc: eliz@gnu.org, thievol@posteo.net, 59082@debbugs.gnu.org
> 
> On Mon, Nov 14, 2022 at 3:13 AM Richard Stallman <rms@gnu.org> wrote:
> 
> > Maybe we need a construct to use in doc strings
> > that requests shorthands processing on a part of the doc string.
> > This would have to happen at read time, when the doc string is read,
> > so that the proper shorthands are in effect there.
> 
> Correct, but this "read time" is "docstring read time", which I don't think 
> is technically the same as "Lisp read time".
> 
> And I also agree that maybe we don't "need" this urgently, for s.el
> or at all. But it would be a nice-to-have, especially if it's easy to
> implement.

The natural place to do that is where we prepare the Help buffer and
generate the cross-links.

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

On Mon, Nov 14, 2022 at 1:05 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I think it really is such a widespread (and good) practice to include
> cross-references in doc strings that it should be a no-brainer to
> decide that supporting this practice is important.
>

OK, are these the only examples? Because my brain also tells me
that these could be fixed by hand, for example:

-previously found match, use `s-count-matches'."
+previously found match, use `magnars-string-count-matches'."

Of course, I agree that if we have this support in the docstring
logic, it is more convenient to _not_ have to do this edit.

Anyway, I hope everyone here is on the same page that
whatever the implementation of that support is, when typing
C-h f s-count-matches OR C-h f magnars-string-count-matches
in a buffer where read-symbol-shorthands is non-nil, then what appears
in the subsequent _global_ *Help* buffer is sth like:

  magnars-string-count-matches-all is a function defined in
magnars-string.el

  Blabla... see, also magnars-string-count-matches.

I.e. the name of the symbol is `magnars-string-count-matches`,
not `s-count-matches`: that's just a local shorthand in that particular
hypothetical buffer (the local shorthand s- being particularly popular
for the library in question).

IOW it would be plainly wrong to print the symbol as s-count-matches
in the *Help* buffer.  Even though that's a popular shorthand, another
buffer where `s-` is already taken for `sandworms-` might have decided
to use the shorthand `str-` instead for `magnar-string.el`

I know I keep reminding this, I just want to make sure everyone
understands this.

João

[-- Attachment #2: Type: text/html, Size: 2353 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[João Távora]

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

On Mon, Nov 14, 2022 at 1:11 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Correct, but this "read time" is "docstring read time", which I don't
> think
> > is technically the same as "Lisp read time".
> >
> > And I also agree that maybe we don't "need" this urgently, for s.el
> > or at all. But it would be a nice-to-have, especially if it's easy to
> > implement.
>
> The natural place to do that is where we prepare the Help buffer and
> generate the cross-links.
>

If, by then, the link to the original value of `read-symbol-shorthands` in
the original buffer (where the definition with the docstring was loaded
from) has been severed, then it's not a good place.

If this link still exists, then it's a good place.

João

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

bug#59082: 28.2; Undocumented `intern-soft` feature with shorthands symbols

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Mon, 14 Nov 2022 13:36:15 +0000
> Cc: rms@gnu.org, thievol@posteo.net, 59082@debbugs.gnu.org
> 
>  I think it really is such a widespread (and good) practice to include
>  cross-references in doc strings that it should be a no-brainer to
>  decide that supporting this practice is important.
> 
> OK, are these the only examples?

No, there are more.