GNU bug report logs - #400
23.0.60; C-h v should pick up lispified name in Customize

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 400 <at> 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)

> > 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.