Re: Documentation not clear for the Lisp function set-variable

[Juanma Barranquero <lekktu@gmail.com>]

On 6/28/05, Richard M. Stallman <rms@gnu.org> wrote:

> Please install your patch.

After all this discussion, I'm not sure what's to be installed, so let
me recapitulate.  The patch below modifies `user-variable-p' so it
also considers as user variables these aliases that point, directly or
indirectly, to other user variables; that includes also obsolete
aliases, I'm not filtering them out. It also returns nil for alias
loops, irrespective of whether any of the aliases in the loop would
qualify as a user variable or not.

This patch fixes the problem originally reported by Juri, i.e., that
`set-variable' didn't allow setting aliases to user options.

Questions remaining:

  - Is there a consensus whether obsolete aliases should be shown or
not? In a recent message Juri proposed that obsolete aliases were not
shown by default, but could be set anyway. Currently `set-variable'
does not accept unknown variable names (to prevent the user setting
misspelled variables, I suppose). Doing what Juri proposes would mean
either changing that, or modifying `read-variable' to check after the
fact whether a given symbol is an obsolete alias or not; all that for
no clear added benefit, and with the added inconvenience that the user
will end typing more if he really wants to set an obsolete alias and
not the current variable the alias points to.

  - It is OK for `user-variable-p' to return nil for alias loops
instead of signaling an error? I think yes because `user-variable-p'
is not a user command, ant its main use is with `mapatoms' and
completion, where the idea is filtering out uninteresting variables.

 - Should `set-variable' give warnings for all aliases, for obsolete
aliases only? Should o it for obsolete variables even if they aren't
aliases?

 - What's the right moment to give the warning? Before setting the
value or after it?

Sorry for being so prolix, but I prefer to ask everything and try to
avoid multi-headed hydras... er, threads where no clear conclusion is
reached :)

-- 
                    /L/e/k/t/u