[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#400: 23.0.60; C-h v should pick up lispified name in Customize
From: |
Drew Adams |
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.