From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Change `customize-save-variable' to work under "emacs -Q"?
Date: Wed, 13 Jul 2011 20:02:33 +0900 [thread overview]
Message-ID: <874o2qtpdi.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <CAC=50j_6RVizTEBycrokUPHP5CK1JTx-EuExsMAqkBO5bh2nAw@mail.gmail.com>
Tim Cross writes:
> I *think* I agree, though am not clear what 'saving' means compared to
> 'setting' within the context of the -Q switch
I think it should mean an error, while the maintainers seem to be (and
Lars clearly is) happy with a warning. Nobody *wants* silence.
> OK, but that does not affect my point regarding the importance of -Q
> representing a standard, well defined and consistent configuration.
Right. I think there is consensus on that. My point is simply that
in many cases, -Q will not be a useful environment. Lars proposes to
make it somewhat more useful, at the cost of complexifying the
behavior of custom-save-variable, and making pollution of the -Q
environment a bit less painful.
> Hmm. That wasn't my impression - at least not initially. What I
> understood was that he wanted to modify how the save operation worked
> under the -Q switch so that it only set the variable and did not warn
> the user the value was not saved.
Indeed, that was my impression too, as well as Drew Adams'. But Lars
clarified that he just didn't bother to mention adding a warning, I
guess because he wanted to focus on the major change from signaling an
"unwritable" error to handling it within `custom-save-variable'.
> However, my concern was whether having code actually change
> variables from their default state under the -Q switch was a good
> idea at all as it does change the fundamental meaning of -Q.
I think there is a consensus that this should be avoided when possible
and done very carefully when necessary.
> whether we are better off leaving -Q to mean EVERYTHING at its
> default state and doing something else, like having the custom
> functions do something other than raise an error when code tries to
> save custom values under -Q
Of course that's what it means. So the problem is what do you do when
what you need to do *requires* changing state? I think it's plausible
that almost anything to do with mail will *require* changes to the -Q
state before you get useful behavior.
Note that saving custom values does not change the -Q environment.
It's just that you're unlikely to bother saving in the virgin -Q
environment (you can always reproduce that with -Q!), so an attempt to
save pretty much implies you've already changed state in a significant
way.
> (maybe a warning they are not saved rather than an error) or
> perhaps it already does the right thing and what the code is trying
> to do is incorrect and needs refactoring.
My position is that the code needs refactoring, because I don't like
the idea of facilitating exceptions here, and I think that changing
`custom-save-variable' will make doing customizations in the -Q
environment more attractive. But that doesn't seem to be the position
of the maintainers.
next prev parent reply other threads:[~2011-07-13 11:02 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-10 12:22 Change `customize-save-variable' to work under "emacs -Q"? Lars Magne Ingebrigtsen
2011-07-11 2:30 ` Stephen J. Turnbull
2011-07-11 7:49 ` Lars Magne Ingebrigtsen
2011-07-11 9:52 ` Stephen J. Turnbull
2011-07-11 9:53 ` Lars Magne Ingebrigtsen
2011-07-11 13:52 ` Stephen J. Turnbull
2011-07-11 17:36 ` Chong Yidong
2011-07-11 18:08 ` Drew Adams
2011-07-11 19:32 ` Juanma Barranquero
2011-07-11 18:27 ` PJ Weisberg
2011-07-11 19:04 ` Chong Yidong
2011-07-11 19:28 ` Lars Magne Ingebrigtsen
2011-07-12 0:03 ` Tim Cross
2011-07-12 1:07 ` chad
2011-07-12 1:51 ` Stephen J. Turnbull
2011-07-12 2:57 ` Tim Cross
2011-07-12 4:12 ` Stephen J. Turnbull
2011-07-12 10:30 ` Tim Cross
2011-07-13 0:31 ` Stephen J. Turnbull
2011-07-13 5:38 ` Tim Cross
2011-07-13 11:02 ` Stephen J. Turnbull [this message]
2011-07-13 23:46 ` Tim Cross
2011-07-14 2:13 ` Stephen J. Turnbull
2011-07-12 6:46 ` Lars Magne Ingebrigtsen
2011-07-12 3:32 ` Stefan Monnier
2011-07-15 17:01 ` Dave Abrahams
2011-07-17 14:33 ` Christoph Scholtes
2011-07-17 19:13 ` Lars Magne Ingebrigtsen
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=874o2qtpdi.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=theophilusx@gmail.com \
/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).