From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 400@debbugs.gnu.org
Subject: bug#400: 23.0.60; C-h v should pick up lispified name in Customize
Date: Sun, 6 Sep 2020 10:06:06 -0700 (PDT) [thread overview]
Message-ID: <99bc1b95-e4f1-4405-b6b0-f698f642870c@default> (raw)
In-Reply-To: <875z8rum4k.fsf@gnus.org>
> > emacs -Q
> > M-x customize-option Info-hide-note-references
> >
> > Put the cursor on the unlispified option name:
> > Info Hide Note References.
> >
> > C-h v
> >
> > The option name is not picked up as the default value.
>
> The command just calls variable-at-point, which doesn't have any
> machinery to go from the displayed data to the actual symbol (which
> info-look has).
>
> It's trivial to fix (now after bug#41905 was fixed), but I'm not sure at
> what level to do that. The least invasive way to do it would be to just
> redefine `C-h v' in Customize buffers, but the way `describe-variable'
> is defined would require a refactor of that function.
>
> `variable-at-point' could grow some way to allow it to be parameterised,
> for instance via a buffer-local variable-at-point-function, which would
> be kinda clean and is how many similar things are handled...
My feeling, so far: keep it simple.
cus-edit.el should provide the inverse operation
to `custom-unlispify-tag-name', which would give
you the Lisp symbol name that corresponds to the
unlispified name.
If that inverse operation would not be trivial or
well-defined for some reason, for some cases (?),
then the code should just record the association
between the two names - IOW, memoize the result
of calling `custom-unlispify-tag-name', and
thereafter just use lookup, in either direction.
(I think we should anyway have such a two-way
conversion/lookup, regardless of this bug.)
Then, `variable-at-point' would just call that
inverse operation (a lookup) when the mode is
`Custom-mode' and `custom-unlispify-tag-names'
is non-nil.
I don't think we should redefine "`C-h v' in
Customize buffers". And I don't think we need to
provide parameterization for `variable-at-point'.
Not just for this, anyway.
I also don't favor a `display' property approach
here, a priori. I think it's overkill here and
can restrict other possibilities/behavior. (Even
just wanting to copy the "friendly" name of the
option, to paste it somewhere.)
A `display' property can be handy, but it can
really mess with things too - kinda like wrapping
duct tape around things: fixes them but makes
them unmovable and difficult to interact/work with.
But my opinion could change, based on other
arguments.
next prev parent reply other threads:[~2020-09-06 17:06 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 16:27 bug#400: 23.0.60; C-h v should pick up lispified name in Customize Drew Adams
2008-06-12 21:19 ` martin rudalics
2008-06-12 21:28 ` Drew Adams
2020-09-06 12:26 ` Lars Ingebrigtsen
2020-09-06 14:39 ` Eli Zaretskii
2020-09-06 16:33 ` Kévin Le Gouguec
2021-10-20 21:02 ` Stefan Kangas
2021-10-20 21:27 ` bug#400: [External] : " Drew Adams
2021-10-21 6:37 ` Eli Zaretskii
2021-10-21 16:15 ` Drew Adams
2021-10-21 3:09 ` Lars Ingebrigtsen
2021-10-21 3:35 ` Stefan Kangas
2021-10-21 3:38 ` Lars Ingebrigtsen
2021-10-21 5:01 ` bug#400: [External] : " Drew Adams
2021-10-21 7:40 ` Eli Zaretskii
2021-10-21 16:49 ` Stefan Kangas
2021-10-22 14:29 ` Lars Ingebrigtsen
2021-10-22 17:13 ` bug#400: [External] : " Drew Adams
2021-10-21 4:26 ` Drew Adams
2021-10-21 7:36 ` Eli Zaretskii
2021-10-21 6:31 ` Eli Zaretskii
2021-10-21 15:47 ` Howard Melman
2021-10-21 17:02 ` Eli Zaretskii
2021-10-22 2:36 ` Howard Melman
2021-10-22 6:38 ` Eli Zaretskii
2021-10-22 15:38 ` Howard Melman
2021-10-22 17:22 ` bug#400: [External] : " Drew Adams
2021-10-21 16:34 ` Stefan Kangas
2021-10-21 17:09 ` Eli Zaretskii
2021-10-21 17:50 ` Stefan Kangas
2021-10-21 18:00 ` Eli Zaretskii
2021-10-21 19:45 ` Stefan Kangas
2021-10-22 6:05 ` Eli Zaretskii
2021-10-22 8:12 ` Stefan Kangas
2021-10-22 10:49 ` Eli Zaretskii
2021-10-22 16:56 ` bug#400: [External] : " Drew Adams
2021-10-22 3:30 ` Howard Melman
2021-10-22 16:51 ` bug#400: [External] : " Drew Adams
2021-10-23 18:25 ` Juri Linkov
2020-09-06 17:06 ` Drew Adams [this message]
[not found] <<007f01c8cca9$3cbbf770$c2b22382@us.oracle.com>
[not found] ` <<875z8rum4k.fsf@gnus.org>
[not found] ` <<83o8mjnf5n.fsf@gnu.org>
2020-09-06 17:13 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99bc1b95-e4f1-4405-b6b0-f698f642870c@default \
--to=drew.adams@oracle.com \
--cc=400@debbugs.gnu.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.