On 6/28/05, Juri Linkov <[EMAIL PROTECTED]> wrote:
> Maybe set-variable should first try to complete non-obsolete aliases,
> and filter out obsolete aliases (but still accept them).
Completing to all non-obsolete variables and/or aliases should be
easy, but... [see below]
> The distinction
> between obsolete variables and aliases is essential. Users should not
> see obsolete variables by default, but should be able to use them
...I don't buy this argument. Users do not go randomly typing chars
into `set-variable' just to see what variables they can set (at least,
I don't think that's the most common use pattern). IMO, the user does
M-x set-variable because he already knows the variable he wants to set
(and it's even likely he read the doc and knows whether it is obsolete
or not, though I'm willing to accept there are users who simply set a
variable because they read about it in an old doc somewhere) and
completion is just a help to do less typing. So in my view,
`set-variable' should not filter out any user variable, whether it is
an obsolete variable or an obsolete alias. I certainly would be very
pissed if I wanted to set `messages-buffer-max-lines' and had to type
it fully because `set-variable' had decided that `message-log-max' was
the way to go.
> (with possible notification about their obsoleteness).
That's another matter entirely. I think is a good idea to warn about
the variable being obsolete. But with the current `completing-read'
mechanism, that can no be easily and elegantly done while the user is
selecting the variable, only afterwards (unless I'm missing
something).
> Also it makes sense to introduce a new property byte-obsolete-face
> to mark obsolete faces, so completion would work similarly for
> customize-face.
I support the idea about byte-obsolete-face, but not for face
completion's sake, but because perhaps the byte-compiler could be
coaxed into giving warnings about old faces' uses.
Anyway, I'm not planning to delve into face completion (or customize),
so that's a matter for whomever wants to implement it to ponder.
--
/L/e/k/t/u
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
