unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Emacs-Devel devel' <emacs-devel@gnu.org>
Subject: Re: autoload cookies for defcustoms
Date: Mon, 25 Jan 2010 10:31:51 -0500	[thread overview]
Message-ID: <jwvtyuaqk5i.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <380EF0C7255E4FBC86DB13B434D13582@us.oracle.com> (Drew Adams's message of "Sun, 24 Jan 2010 21:13:12 -0800")

>> > Just curious.  Is there a policy, for the Lisp code distributed with
>> > Emacs, about using autoload cookies for defcustoms? If so, 
>> > what is it?
>> AFAIK the policy is: "don't do it".
>> It all too often introduces all kinds of nasty problems.
>> More to the point, I welcome patches that remove tham.
> OK.
> And what about those that use `purecopy'?

AFAIK, `purecopy' has nothing to do with it, except that *if*
a defcustom is preloaded (either because it's in a preloaded file or
because it has an autoload cookie), then it may be desirable to purecopy
parts of its default value.  But it should never be a reason to decide
whether to autoload or not.

> That's very implementation-centric, as opposed to privileging options
> that are somehow considered "important" for users to know about.

Autoloading of some defcustoms should not be used just because some
option is "important".  It should only be used when it's *necessary* for
technical reasons.

> Of course, if users can at least see all option names (all from the
> distributed libraries) as completion candidates, that will go a long
> way toward making them known to users before loading.  That will be
> a welcome improvement.

Yes, that's an improvement that's planned to address the problem that
is sometimes solved by abusing autoloading.


        Stefan




  reply	other threads:[~2010-01-25 15:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-23 18:31 autoload cookies for defcustoms Drew Adams
2010-01-23 20:24 ` Lennart Borgman
2010-01-23 20:38   ` Drew Adams
2010-01-25  2:56 ` Stefan Monnier
2010-01-25  5:13   ` Drew Adams
2010-01-25 15:31     ` Stefan Monnier [this message]
2010-01-25 20:36       ` Drew Adams
2010-01-26  2:05         ` Stefan Monnier
2010-01-26  3:12           ` Drew Adams
2010-01-26 11:51         ` Juanma Barranquero
2010-08-29  9:46   ` Wojciech Meyer
2010-08-29 19:11     ` Glenn Morris
2010-08-30 12:30       ` Wojciech Meyer
2010-08-30 15:54         ` Stefan Monnier
2010-08-30 23:20         ` Glenn Morris
2010-08-30 23:52           ` Wojciech Meyer
2010-08-31  3:32           ` Andy Wingo
2010-08-31  8:04             ` Stefan Monnier

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=jwvtyuaqk5i.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=drew.adams@oracle.com \
    --cc=emacs-devel@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).