unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).