unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: juri@jurta.org, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Documentation not clear for the Lisp function set-variable
Date: Tue, 28 Jun 2005 12:09:01 -0400	[thread overview]
Message-ID: <874qbi8p49.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <f7ccd24b05062802171c8d08cf@mail.gmail.com> (Juanma Barranquero's message of "Tue, 28 Jun 2005 11:17:50 +0200")

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

I think we should use the complete-in-turn thingy so that completion first
tries to complete without obsolete vars and only if that fails then it tries
to complete with obsolete vars.

>   - It is OK for `user-variable-p' to return nil for alias loops
> instead of signaling an error?

Looks fine to me.  If it's an alias loop, it's not a user-variable.

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

I recommend not to classify cases as "alias" and "obsolete alias"
but as "alias" and "obsolete" where this latter case can be an alias
or not.  Setting an obsolete var should be discouraged, whether it's aliased
to some other var or not.

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

If you want a warning for aliases, it should come after, in the same way as
the display of shortcuts after M-x foobar RET.

As for warnings of obsoleteness, I would argue to put them before (with
a (sit-for 1)), since we want to send a clear message that they should not
use this variable any more.


        Stefan

  parent reply	other threads:[~2005-06-28 16:09 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-19 11:14 Documentation not clear for the Lisp function set-variable Yoni Rabkin
2005-06-20  3:50 ` Richard Stallman
2005-06-20  8:21   ` Yoni Rabkin
2005-06-20  9:07   ` Juanma Barranquero
2005-06-21  2:00     ` Richard Stallman
2005-06-26 23:23   ` Juri Linkov
2005-06-27 13:04     ` Juanma Barranquero
2005-06-27 15:44       ` Juanma Barranquero
2005-06-27 16:09         ` Luc Teirlinck
2005-06-27 18:17           ` Juanma Barranquero
2005-06-27 18:45             ` Luc Teirlinck
2005-06-27 19:30               ` Juanma Barranquero
2005-06-28 18:47               ` Richard M. Stallman
2005-07-04  1:18                 ` Luc Teirlinck
2005-07-04 16:48                   ` Richard M. Stallman
2005-07-04 17:02                     ` David Kastrup
2005-07-05  1:42                     ` Luc Teirlinck
2005-07-05 16:12                       ` Richard M. Stallman
2005-07-07  1:54                         ` Luc Teirlinck
2005-07-07 21:30                           ` Richard M. Stallman
2005-06-28  0:07             ` Juri Linkov
2005-06-28  8:32               ` Juanma Barranquero
2005-06-28 23:45                 ` Juri Linkov
2005-06-29  9:14                   ` Juanma Barranquero
2005-06-29 23:57                     ` Juri Linkov
2005-06-30  8:16                       ` Juanma Barranquero
2005-06-30 16:55                         ` Luc Teirlinck
2005-06-30 19:34                           ` Juanma Barranquero
2005-07-01 23:57                           ` Juri Linkov
2005-07-02  4:11                             ` Luc Teirlinck
2005-06-28 18:47               ` Richard M. Stallman
2005-06-29  2:32                 ` Juanma Barranquero
2005-06-29 20:42                   ` Richard M. Stallman
2005-06-27 18:39       ` Eli Zaretskii
2005-06-27 18:49         ` Luc Teirlinck
2005-06-27 21:38         ` Juanma Barranquero
2005-06-28  4:37           ` Eli Zaretskii
2005-06-28  8:33             ` Juanma Barranquero
2005-06-28  4:17       ` Richard M. Stallman
2005-06-28  9:17         ` Juanma Barranquero
2005-06-28  9:26           ` Juanma Barranquero
2005-06-28 16:09           ` Stefan Monnier [this message]
2005-06-28 16:19             ` Juanma Barranquero
2005-06-29  3:43               ` Stefan Monnier
2005-06-29  9:18                 ` Juanma Barranquero
2005-06-29  3:59           ` Richard M. Stallman
2005-06-27 16:46     ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874qbi8p49.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).