If you just leave this function unchanged and install the rest,
it should work. However, it would be good to make one additional
change: the same commands should display a message of the form
`%s' is an alias for `%s'
in the echo area.
What about the foll
Richard Stallman wrote:
If you just leave this function unchanged and install the rest,
it should work. However, it would be good to make one additional
change: the same commands should display a message of the form
`%s' is an alias for `%s'
in the echo area.
What about the fol
(defun custom-variable-prompt ()
"Prompt for a custom variable, defaulting to the variable at point.
+ If that variable is an alias, the default is the actual custom variable
+ at the end of the chain of aliases.
Return a list suitable for use in `interactive'."
!
Richard Stallman wrote:
Actually, I forgot that, unlike customize-face, customize-variable
does not allow to enter variables that are defvarred or defvaraliased,
rather than defcustomed.
I think that is partly a bug--it should allow an alias if its "real"
name has a def
"Richard M. Stallman" <[EMAIL PROTECTED]> writes:
> Actually, I forgot that, unlike customize-face, customize-variable
> does not allow to enter variables that are defvarred or defvaraliased,
> rather than defcustomed.
>
> I think that is partly a bug--it should allow an alias if its "
Actually, I forgot that, unlike customize-face, customize-variable
does not allow to enter variables that are defvarred or defvaraliased,
rather than defcustomed.
I think that is partly a bug--it should allow an alias if its "real"
name has a defcustom.
__
Richard Stallman wrote:
I think it is right to use the "real" name rather than the alias in
the customization buffer, for variables as well as for faces.
So please do make that change in customize-variable.
Actually, I forgot that, unlike customize-face, customize-variable
does not allow
Juri Linkov wrote:
I don't remember what the decision was, but if it was to postpone this
until the next release, then perhaps this should be added to etc/TODO.
We decided to put it off until after the release, because the exact
details of what we really wanted to do were not clear. There
>> so why wouldn't it also run a setter specified
>> by the `:set' custom keyword?
>
>It probably should. I'll take a look at it. I'm not custom expert,
>though; I hardly use the stuff.
>
> I have not been following this thread. Are you discussing making
> set-variable calling any
On 6/30/05, Luc Teirlinck <[EMAIL PROTECTED]> wrote:
> Are you discussing making
> set-variable calling any :set function?
Juri proposed that, yes.
> We decided quite a while ago to do that.
Glad to hear (because I won't have to implement it...)
> We decided to put it off till after the releas
Juanma Barranquero wrote:
On 6/30/05, Juri Linkov <[EMAIL PROTECTED]> wrote:
> so why wouldn't it also run a setter specified
> by the `:set' custom keyword?
It probably should. I'll take a look at it. I'm not custom expert,
though; I hardly use the stuff.
I have not been followi
On 6/30/05, Juri Linkov <[EMAIL PROTECTED]> wrote:
> so why wouldn't it also run a setter specified
> by the `:set' custom keyword?
It probably should. I'll take a look at it. I'm not custom expert,
though; I hardly use the stuff.
--
/L/e/k/t/u
>> I agree that filtering is not very necessary, and
>> think that it would be sufficient to display a warning for obsolete
>> variables and obsolete aliases after selecting the variable but before
>> setting its value.
>
> Cool. That's what my latest patch does. Please take a look to see if
> it m
- allows setting aliases of user options
- does *not* filter out obsolete variables
- shows a 3-seconds warning when the variable (alias or not) being
set is obsolete;
the warning includes the CURRENT-NAME information from
`make-variable-obsolete'
- does not show
> C-h f complete-in-turn RET
Oops, sorry. As you casually said "the complete-in-turn thingy" I
(erroneously) assumed you were describing something, not giving the
precise name of the function :-)
Anyway, I've implemented the change to `set-variable' without it. You
seem to want the two-phase com
On 6/29/05, Juri Linkov <[EMAIL PROTECTED]> wrote:
> I agree that filtering is not very necessary, and
> think that it would be sufficient to display a warning for obsolete
> variables and obsolete aliases after selecting the variable but before
> setting its value.
Cool. That's what my latest pa
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
alias
>> I think we should use the complete-in-turn thingy
> Hmm. Some more info, please? :-)
C-h f complete-in-turn RET
Try C-s complete-in-turn in the lisp/ChangeLog file as well to see where
it's used.
> If I understand correctly, you're OK'ing the `user-variable-p' patch
> and we're now discussing
> 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 somewher
On 6/28/05, Richard M. Stallman <[EMAIL PROTECTED]> wrote:
> I don't like that idea. The command should accept *all* names,
> whether obsolete or not. But it would be nice to inform the user in
> the echo area that the name is obsolete, and give the new name if any.
With the installed changes f
Maybe set-variable should first try to complete non-obsolete aliases,
and filter out obsolete aliases (but still accept them).
I don't like that idea. The command should accept *all* names,
whether obsolete or not. But it would be nice to inform the user in
the echo area that the name is
`M-x customize-face RET diary-face' brings uo a customization buffer
for the face `diary' instead of for the typed alias `diary-face'.
_Assuming_, of course, that diary is loaded. If not, customize-face
will not recognize diary, nor diary-face. I proposed doing something
simil
> I think we should use the complete-in-turn thingy
Hmm. Some more info, please? :-)
> so that completion first
> tries to complete without obsolete vars and only if that fails then it tries
> to complete with obsolete vars.
OK, once I understand what are you referring to with the
"complete-in-t
> - 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 var
> The patch below modifies `user-variable-p' [etc, etc.]
That would be more convincing if I really attached the patch...
(BTW, the patch uses diff -b because most of user-visible-p is now
inside a while loop, but otherwise unchanged.)
--
/L/e/k/t/u
Index: src/eval.c
==
On 6/28/05, Richard M. Stallman <[EMAIL PROTECTED]> 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
On 6/28/05, Eli Zaretskii <[EMAIL PROTECTED]> wrote:
> A variable is a user variable if
>
> it would be better yet.
OK, I've fixed my patch. Thanks.
--
/L/e/k/t/u
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.g
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
> bet
Try this patch, please. It doesn't modify `set-variable' but
`user-variable-p', so it returns t for non-obsolete aliases of user
variables.
Please install your patch.
(Anyway, is that a new feature or a bug fix?)
It is a bug fix.
Would you like to change set-variable to give a w
> Date: Mon, 27 Jun 2005 23:38:52 +0200
> From: Juanma Barranquero <[EMAIL PROTECTED]>
> Cc: emacs-devel@gnu.org
>
> What about this patch? Do you like it a bit more?
>
> +VARIABLE is considered to be a `user variable' if
> +\(1) the first character of its documentation is `*', or
> +\(2) it is c
>> I do not know whether or not it is important for `set-variable' to be
>> consistent with that. Maybe not. I just wanted to be sure that you
>> are aware of the `customize' situation.
>
> AFAICS, customize-face does nothing special, other than filtering out
> aliases (but accepts them if the us
> This patch produces the following text:
>
>Determined by whether the first character of the documentation
> for the variable is `*', the variable is customizable (has a non-nil
> value of `standard-value' or of `custom-autoload' on its property list),
> or it is a non-obsolete alias fo
> `M-x customize-face RET diary-face' brings uo a customization buffer
> for the face `diary' instead of for the typed alias `diary-face'.
> _Assuming_, of course, that diary is loaded. If not, customize-face
> will not recognize diary, nor diary-face.
As set-variable is not bringing any buffer,
Juanma Barranquero wrote:
AFAICS, customize-face does nothing special, other than filtering out
aliases (but accepts them if the user types them).
`M-x customize-face RET diary-face' brings uo a customization buffer
for the face `diary' instead of for the typed alias `diary-face'.
_Assum
Eli Zaretskii wrote:
This patch produces the following text:
Determined by whether the first character of the documentation
for the variable is `*', the variable is customizable (has a non-nil
value of `standard-value' or of `custom-autoload' on its property list),
or it i
> I do not know whether or not it is important for `set-variable' to be
> consistent with that. Maybe not. I just wanted to be sure that you
> are aware of the `customize' situation.
AFAICS, customize-face does nothing special, other than filtering out
aliases (but accepts them if the user types
> Date: Mon, 27 Jun 2005 15:04:58 +0200
> From: Juanma Barranquero <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], emacs-devel@gnu.org
>
> Try this patch, please. It doesn't modify `set-variable' but
> `user-variable-p', so it returns t for non-obsolete aliases of user
> variables.
This patch produc
There is one problem with `set-variable'. When called interactively
it doesn't accept aliased user options.
It should accept aliases, even if they are obsolete. Could you fix that?
(It would be useful to notify the user that the name he used is an alias.)
__
You might want to try out `customize-face(-other-window)' and see how
it handles face aliases. (This behavior has been changed relatively
recently.) I believe that I will adapt `customize-variable' and
`customize-variable-other-window' to follow the new
`customize-face(-other-window)' behavior.
On 6/27/05, Juanma Barranquero <[EMAIL PROTECTED]> wrote:
> Try this patch, please. It doesn't modify `set-variable' but
> `user-variable-p', so it returns t for non-obsolete aliases of user
> variables.
Well, it is also necessary to detect alias loops. The problem is:
what should `user-variable-
On 6/27/05, Juri Linkov <[EMAIL PROTECTED]> wrote:
> IMO, `set-variable' should
> accept an alias when it is not marked as obsolete.
Try this patch, please. It doesn't modify `set-variable' but
`user-variable-p', so it returns t for non-obsolete aliases of user
variables.
(Anyway, is that a new
> How about this doc string?
>
> (defun set-variable (var val &optional make-local)
> "Set VARIABLE to VALUE. VALUE is a Lisp object.
> VARIABLE should be a user option variable name, a Lisp variable
> meant to be customized by users. You should enter VALUE in Lisp syntax,
> so if you want VALU
If you change the docstring, it'd be great to also change the argument
names to match the ones in the docstring, or at least to add \(fn
VARIABLE VALUE &optional MAKE-LOCAL).
Ok, I will. Thanks.
___
Emacs-devel mailing list
Emacs-devel@gnu
On 6/20/05, Richard Stallman <[EMAIL PROTECTED]> wrote:
> How about this doc string?
>
> (defun set-variable (var val &optional make-local)
> "Set VARIABLE to VALUE. VALUE is a Lisp object.
[...]
If you change the docstring, it'd be great to also change the argument
names to match the ones in
On 6/20/05, Richard Stallman <[EMAIL PROTECTED]> wrote:
> How about this doc string?
>
> (defun set-variable (var val &optional make-local)
> "Set VARIABLE to VALUE. VALUE is a Lisp object.
> VARIABLE should be a user option variable name, a Lisp variable
> meant to be customized by users. You
How about this doc string?
(defun set-variable (var val &optional make-local)
"Set VARIABLE to VALUE. VALUE is a Lisp object.
VARIABLE should be a user option variable name, a Lisp variable
meant to be customized by users. You should enter VALUE in Lisp syntax,
so if you want VALUE to be a str
46 matches
Mail list logo
