Change `customize-save-variable' to work under "emacs -Q"?

Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

If you run "emacs -Q", and you have a piece of code that calls
`customize-save-variable', it will error out, saying that it won't
overwrite the conf.

Would anybody mind if I changed that function to not error out, but
instead just do a `setq' on the variable in question, if we're running
under -Q?

Otherwise all the callers end up doing this very awkward thing:

	(if (ignore-errors (custom-file))
	    (progn
	      (customize-save-variable 'smtpmail-smtp-server server)
	      (customize-save-variable 'smtpmail-smtp-service port))
	  (setq smtpmail-smtp-server server
		smtpmail-smtp-service port))


-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:

 > If you run "emacs -Q", and you have a piece of code that calls
 > `customize-save-variable', it will error out, saying that it won't
 > overwrite the conf.

If that's not the appropriate thing to do, isn't the piece of code
abusing `customize-save-variable'?  Customize itself is carefully
designed so that the user has the choice of a one-time setting for
this session, and a persistent setting.  Code that calls customize
functions should similarly respect the user, no?

 > Otherwise all the callers end up doing this very awkward thing:

Why would they do that?  Maybe the smtpmail-smtp-* functions are
special in this regard, you can be the judge of that, but I would
think that most callers are simply trying to provide an even
higher-level front-end to Customize, and would respect its conventions
about user intent to make a change persistent.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> If that's not the appropriate thing to do, isn't the piece of code
> abusing `customize-save-variable'?

How is calling `customize-save-variable' to save a user choice abuse of
the function?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > If that's not the appropriate thing to do, isn't the piece of code
 > > abusing `customize-save-variable'?
 > 
 > How is calling `customize-save-variable' to save a user choice abuse of
 > the function?

You propose to silently *not* save the user choice, that's how.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> You propose to silently *not* save the user choice, that's how.

Instead of bugging out under -Q, yes.

And it doesn't have to be silent.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Lars Magne Ingebrigtsen writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
 > 
 > > You propose to silently *not* save the user choice, that's how.
 > 
 > Instead of bugging out under -Q, yes.

De gustibus non est disputandum.  Bon appetit!

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If you run "emacs -Q", and you have a piece of code that calls
> `customize-save-variable', it will error out, saying that it won't
> overwrite the conf.
>
> Would anybody mind if I changed that function to not error out, but
> instead just do a `setq' on the variable in question, if we're running
> under -Q?

I think this is fine.

RE: Change `customize-save-variable' to work under "emacs -Q"?

[Drew Adams]

> > If you run "emacs -Q", and you have a piece of code that calls
> > `customize-save-variable', it will error out, saying that it won't
> > overwrite the conf.
> >
> > Would anybody mind if I changed that function to not error out, but
> > instead just do a `setq' on the variable in question, if 
> > we're running under -Q?
> 
> I think this is fine.

Ouch!  Maybe I'm misunderstanding, but a user in `emacs -Q' who does `M-x
customize-save-variable' and sees no error message will expect that it has been
_saved_, no?  Likewise any code that a user might run that calls
`customize-save-variable'.

How can we _silently_ convert saving to just setq?  The user will think that
something is saved when that is not the case.  Sounds like asking for trouble,
to me.  But maybe I'm missing something.

Why is this better than raising an error and letting the user then use `setq'
etc.?  Why hide the situation from the user?

I would think we would want to take advantage of the opportunity to remind the
user that s?he invoked `emacs -Q', so no init file, so no place to save the
option.

Also, why would we convert to just `setq' and not `customize-set-variable'?  The
latter DTRT wrt :set etc.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[PJ Weisberg]

On Monday, July 11, 2011, Chong Yidong <cyd@stupidchicken.com> wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> If you run "emacs -Q", and you have a piece of code that calls
>> `customize-save-variable', it will error out, saying that it won't
>> overwrite the conf.
>>
>> Would anybody mind if I changed that function to not error out, but
>> instead just do a `setq' on the variable in question, if we're running
>> under -Q?
>
> I think this is fine.
>
If the user asks to save a variable for future sessions, but you can
only set it for the current session, *shouldn't* that be an error?

-- 

-PJ

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Chong Yidong]

PJ Weisberg <pjweisberg@gmail.com> writes:

> On Monday, July 11, 2011, Chong Yidong <cyd@stupidchicken.com> wrote:
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> If you run "emacs -Q", and you have a piece of code that calls
>>> `customize-save-variable', it will error out, saying that it won't
>>> overwrite the conf.
>>>
>>> Would anybody mind if I changed that function to not error out, but
>>> instead just do a `setq' on the variable in question, if we're running
>>> under -Q?
>>
>> I think this is fine.
>>
> If the user asks to save a variable for future sessions, but you can
> only set it for the current session, *shouldn't* that be an error?

Lars had a good point: if we commonly encounter the case where we want
to do a "save if possible, otherwise setq" operation, it makes sense to
make that easy to do.

But, on reflection, maybe

  (ignore-errors (customize-save-variable ...))

would work just as well.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> But, on reflection, maybe
>
>   (ignore-errors (customize-save-variable ...))
>
> would work just as well.

Well, ignoring errors like that is generally not a good idea.  If saving
the .emacs file errors out, you want to know, for instance.

And it doesn't set the variables in question if you do that.

I think just making `customize-save-variable' set and warn will make the
"emacs -Q" special case work nicely for all use cases.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Juanma Barranquero]

On Mon, Jul 11, 2011 at 20:08, Drew Adams <drew.adams@oracle.com> wrote:

> Ouch!  Maybe I'm misunderstanding, but a user in `emacs -Q' who does `M-x
> customize-save-variable' and sees no error message will expect that it has been
> _saved_, no?  Likewise any code that a user might run that calls
> `customize-save-variable'.
>
> How can we _silently_ convert saving to just setq?

I don't think Lars meant silently.

    Juanma

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Tim Cross]

On Tue, Jul 12, 2011 at 5:28 AM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>
>> But, on reflection, maybe
>>
>>   (ignore-errors (customize-save-variable ...))
>>
>> would work just as well.
>
> Well, ignoring errors like that is generally not a good idea.  If saving
> the .emacs file errors out, you want to know, for instance.
>
> And it doesn't set the variables in question if you do that.
>
> I think just making `customize-save-variable' set and warn will make the
> "emacs -Q" special case work nicely for all use cases.
>

I think your on the right track, but a couple of things worth thinking about.

An important role of -Q is to provide a well defined, understood
environment which is largely common to all users. It is a key first
step in reproducing bugs. While the current situation where
customizing settings may fail or throw an error and look a bit ugly
etc, it at least does have the advantage of providing a consistent
environment across users. However, as soon as we allow customized
variables to be set, either permanently or temporarily, we run the
risk of losing this valuable environment consistency.

At the same time, this can also be a source of frustration. For
example, if you run emacs -Q to test a recipe for a bug and find it
works, you cannot just run report-emacs-bug to submit the bug if your
mail settings depend on anything but the default values. You need to
copy the backtrace and other important information to a temporary
file, exit emacs and start again without the -Q switch and then submit
the bug. Furthermore, the environment setting you include in the bug
report are now likely to be more complex and not a true reflection of
the actual environment that existed when you ran your recipe under
emacs -Q.

I guess we need the best of both worlds.

One possibility might be to modify the code that manages/sets custom
variables check for the -Q switch and take some additional or
different steps if the -Q switch is also detected. Perhaps something
like using setq and adding the variable and value to a special -Q init
list that cold be included in bug reports etc so that anyone wanting
to reproduce the problem or run the recipe could also run a special
bit of -Q init code to ensure at least consistency with the
environment provided by the reporter/tester etc.

The above is not well thought out - just some thoughts that might
trigger better ideas. The main point is that while it might be nice to
have some better way to deal with code that wants to set custom
variables when runnning under -Q, we also need to try and not lose the
important value provided by -Q of a consistent, well understood
environment with known and tested values for core variables.

Tim

Re: Change `customize-save-variable' to work under "emacs -Q"?

[chad]

Since we sometimes want custom to set variables in spite of -Q (for reproducing bugs, which I'll guess is probably the most common use of -Q) and sometimes don't want that, can we make it a switch?  

I was hoping to suggest a patch, but setting debug-on-entry for customize-save-variables and running Emacs -Q under MacOSX caused a crash, and I don't have the attention right now to hunt it down *and* suggest a patch.  Customize itself seems to check 'init-file and offers different text if it's not set; is that sufficient for either asking something like ``Can't save setting; set for session anyway?''?

*Chad

P.S. In case someone cares about the crash, I've attached the system's dump; it might just be an artifact of the way I ran Emacs -Q.  If I can reproduce it, I'll file a bug/patch.


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib             	0x00007fff8907f0b6 __kill + 10
1   libSystem.B.dylib             	0x00007fff8911f9f6 abort + 83
2   org.gnu.Emacs                 	0x0000000100194dcf ns_term_shutdown + 79 (nsterm.m:4074)
3   org.gnu.Emacs                 	0x00000001000ab7e5 fatal_error_signal + 293 (emacs.c:344)
4   libSystem.B.dylib             	0x00007fff890911ba _sigtramp + 26
5   libSystem.B.dylib             	0x00007fff8907f0b6 __kill + 10
6   libSystem.B.dylib             	0x00007fff8911f9f6 abort + 83
7   org.gnu.Emacs                 	0x000000010010d337 Fgarbage_collect + 1575 (alloc.c:3969)
8   org.gnu.Emacs                 	0x0000000100125aef eval_sub + 239 (eval.c:2256)
9   org.gnu.Emacs                 	0x000000010014cd6b readevalloop + 907 (lread.c:1814)
10  org.gnu.Emacs                 	0x000000010014ec61 Fload + 1361 (lread.c:1302)
11  org.gnu.Emacs                 	0x000000010013188b Frequire + 539 (fns.c:2690)
12  org.gnu.Emacs                 	0x0000000100126002 eval_sub + 1538 (eval.c:2363)
13  org.gnu.Emacs                 	0x0000000100129065 internal_lisp_condition_case + 517 (eval.c:1440)
14  org.gnu.Emacs                 	0x0000000100161f10 exec_byte_code + 2880 (bytecode.c:981)
15  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
16  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
17  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
18  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
19  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
20  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
21  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
22  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
23  org.gnu.Emacs                 	0x00000001001255b5 Fapply + 485 (eval.c:2457)
24  org.gnu.Emacs                 	0x000000010012f37d Fwidget_apply + 77 (fns.c:2785)
25  org.gnu.Emacs                 	0x0000000100126d5b Ffuncall + 1259 (eval.c:2991)
26  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
27  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
28  org.gnu.Emacs                 	0x00000001001255b5 Fapply + 485 (eval.c:2457)
29  org.gnu.Emacs                 	0x000000010012f37d Fwidget_apply + 77 (fns.c:2785)
30  org.gnu.Emacs                 	0x0000000100126d5b Ffuncall + 1259 (eval.c:2991)
31  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
32  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
33  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
34  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
35  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
36  org.gnu.Emacs                 	0x0000000100128dae call1 + 30 (eval.c:2779)
37  org.gnu.Emacs                 	0x000000010012fee1 mapcar1 + 161 (fns.c:2347)
38  org.gnu.Emacs                 	0x00000001001302f0 Fmapcar + 336 (fns.c:2417)
39  org.gnu.Emacs                 	0x0000000100126d15 Ffuncall + 1189 (eval.c:3012)
40  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
41  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
42  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
43  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
44  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
45  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
46  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
47  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
48  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
49  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
50  org.gnu.Emacs                 	0x0000000100126775 funcall_lambda + 805 (eval.c:3240)
51  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
52  org.gnu.Emacs                 	0x0000000100125727 Fapply + 855 (eval.c:2461)
53  org.gnu.Emacs                 	0x000000010012f37d Fwidget_apply + 77 (fns.c:2785)
54  org.gnu.Emacs                 	0x0000000100126d5b Ffuncall + 1259 (eval.c:2991)
55  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
56  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
57  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
58  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
59  org.gnu.Emacs                 	0x0000000100126165 eval_sub + 1893 (eval.c:2329)
60  org.gnu.Emacs                 	0x00000001001253a9 internal_catch + 217 (eval.c:1247)
61  org.gnu.Emacs                 	0x0000000100161f4a exec_byte_code + 2938 (bytecode.c:966)
62  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
63  org.gnu.Emacs                 	0x0000000100162a8c exec_byte_code + 5820 (bytecode.c:785)
64  org.gnu.Emacs                 	0x0000000100126aa4 Ffuncall + 564 (eval.c:3070)
65  org.gnu.Emacs                 	0x0000000100122f17 Fcall_interactively + 6279 (callint.c:857)
66  org.gnu.Emacs                 	0x0000000100126d02 Ffuncall + 1170 (eval.c:3016)
67  org.gnu.Emacs                 	0x0000000100126ef6 call3 + 38 (eval.c:2810)
68  org.gnu.Emacs                 	0x00000001000bf634 command_loop_1 + 1140 (keyboard.c:1580)
69  org.gnu.Emacs                 	0x00000001001252a5 internal_condition_case + 293 (eval.c:1493)
70  org.gnu.Emacs                 	0x00000001000b4c07 command_loop_2 + 55 (keyboard.c:1157)
71  org.gnu.Emacs                 	0x00000001001253a9 internal_catch + 217 (eval.c:1247)
72  org.gnu.Emacs                 	0x00000001000b539c recursive_edit_1 + 364 (keyboard.c:1136)
73  org.gnu.Emacs                 	0x00000001000b5512 Frecursive_edit + 290 (keyboard.c:821)
74  org.gnu.Emacs                 	0x00000001000ac5c6 main + 3430 (emacs.c:1704)
75  org.gnu.Emacs                 	0x0000000100001c24 start + 52

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Tim Cross writes:

 > At the same time, this can also be a source of frustration. For
 > example, if you run emacs -Q to test a recipe for a bug and find it
 > works, you cannot just run report-emacs-bug to submit the bug if your
 > mail settings depend on anything but the default values. You need to
 > copy the backtrace and other important information to a temporary
 > file, exit emacs and start again without the -Q switch and then submit
 > the bug. 

$ emacs -Q
;; reproduce non-crashing bug
M-x report-emacs-bug RET           ; get the environment right
;; edit the bug buffer as usual
M-: (load-user-init-file) RET      ; YMMV, this is XEmacs-specific IIRC
                                   ; XEmacs GUI provides a button,
                                   ; Emacs can easily do the same if
                                   ; it's not already available
;; fix up own address in bug report and send

works for me.  I do that kind of thing all the time, for the reasons
you give.

 > Furthermore, the environment setting you include in the bug
 > report are now likely to be more complex and not a true reflection of
 > the actual environment that existed when you ran your recipe under
 > emacs -Q.

This isn't a problem if done as above.  There are surely other ways to
accomplish the same thing, too, such as running a separate emacs -Q,
formatting the bug buffer in the emacs -Q session, saving to a file,
then running M-x report-emacs-bug in your main session, delete all the
session information and C-x i the real bug report in.

So this thread isn't about making life easier for bug reporters (who
very likely don't remember the necessary settings the way Lars does,
or even which variables to set, because assistant.el and Customize
handle it for them), it's about making life easier for developers like
Lars.  Nothing wrong with that, but let's remember who benefits here.

 > One possibility might be to modify the code that manages/sets custom
 > variables check for the -Q switch and take some additional or
 > different steps if the -Q switch is also detected.

Another possibility might be putting basic infrastructure stuff like
mail settings in a different file, loaded on demand by the code that
needs it.  (Yeah, I know, deliberately putting all eggs in one basket
is where this whole thing started.)

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Tim Cross]

On Tue, Jul 12, 2011 at 11:51 AM, Stephen J. Turnbull
<stephen@xemacs.org> wrote:
> Tim Cross writes:
>
>  > At the same time, this can also be a source of frustration. For
>  > example, if you run emacs -Q to test a recipe for a bug and find it
>  > works, you cannot just run report-emacs-bug to submit the bug if your
>  > mail settings depend on anything but the default values. You need to
>  > copy the backtrace and other important information to a temporary
>  > file, exit emacs and start again without the -Q switch and then submit
>  > the bug.
>
> $ emacs -Q
> ;; reproduce non-crashing bug
> M-x report-emacs-bug RET           ; get the environment right
> ;; edit the bug buffer as usual
> M-: (load-user-init-file) RET      ; YMMV, this is XEmacs-specific IIRC
>                                   ; XEmacs GUI provides a button,
>                                   ; Emacs can easily do the same if
>                                   ; it's not already available
> ;; fix up own address in bug report and send
>

I have used that technique, but have run into problems with packages
that have already loaded where the variable needs to be set before
they are loaded. The other problem is that it is a solution which
really only works for somewhat experienced/confident users. However,
bug submission was just an example of the point I was trying to make.
The core issue I see is that -Q is useful mainly because it
establishes a standard default environment. I think this is an
important point - it is this standard default environment which allows
developers to try and reproduce bugs without the distraction of local
customizations that may cause/hide such bugs and it allows users to
quickly and easily identify whether their problem is a bug in the core
system or a but in their customization or add-on code/package. Once we
allow local customizations to be applied in this environment, this
standard base default environment no longer exists. This may be fine,
provided there is some mechanism that makes what has been changed
explicit and easy to reproduce.


> works for me.  I do that kind of thing all the time, for the reasons
> you give.
>
>  > Furthermore, the environment setting you include in the bug
>  > report are now likely to be more complex and not a true reflection of
>  > the actual environment that existed when you ran your recipe under
>  > emacs -Q.
>
> This isn't a problem if done as above.  There are surely other ways to
> accomplish the same thing, too, such as running a separate emacs -Q,
> formatting the bug buffer in the emacs -Q session, saving to a file,
> then running M-x report-emacs-bug in your main session, delete all the
> session information and C-x i the real bug report in.
>
> So this thread isn't about making life easier for bug reporters (who
> very likely don't remember the necessary settings the way Lars does,
> or even which variables to set, because assistant.el and Customize
> handle it for them), it's about making life easier for developers like
> Lars.  Nothing wrong with that, but let's remember who benefits here.

Bug reporting was not meant as the central theme - it was just an
example of one thing that could be affected when you allow local
customizations to be applied in a -Q environment. I'm not even against
local customizations being applied, but I think such customizations
need to be very explicit and I would like to see some easy way to
communicate what has been customized and to what so that it can be
reproduced by others. What I don't want to see is one party reporting
something in a -Q environment that is not seen in another -Q
environment (assuming other things, such as platform, version etc
being equal) as this could negate the real value of -Q, which is to
provide a common base that can be used not only for bug reporting, but
also for any development or other discussion where you need to make
sure all parties are coming from the same point. The -Q arg is the
great leveller that puts the novice, intermediate and expert on the
same level and is often critical in establishing good communication.

>
>  > One possibility might be to modify the code that manages/sets custom
>  > variables check for the -Q switch and take some additional or
>  > different steps if the -Q switch is also detected.
>
> Another possibility might be putting basic infrastructure stuff like
> mail settings in a different file, loaded on demand by the code that
> needs it.  (Yeah, I know, deliberately putting all eggs in one basket
> is where this whole thing started.)
>

I think there are probably many different solutions. Mail is just one
area where this issue comes up. There are likely others. The solution
will likely become evident once we understand the issue well. My only
real contribution is to say that for me, the most fundamental property
of -Q is that it is emacs with just the defaults and no local
customization. I don't mind if it also has local customization, but
that customization should be very explicit and I would like it to
include a mechanism that would allow me to bundle that up in a simple
way that would allow someone else to create a similar environment
reliably and consistently. What I don't want is local customizations
that are applied 'behind the scenes' or are only applied to some
things and not others. I also don't want things to fail totally
silently.

Tim

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stefan Monnier]

> Otherwise all the callers end up doing this very awkward thing:

> 	(if (ignore-errors (custom-file))
> 	    (progn
> 	      (customize-save-variable 'smtpmail-smtp-server server)
> 	      (customize-save-variable 'smtpmail-smtp-service port))
> 	  (setq smtpmail-smtp-server server
> 		smtpmail-smtp-service port))

I'd be surprised if `setq' is the right answer (it's probably more like
customize-set or something along these lines), and it deserves
a `message', but other than that I guess it's OK.
We used to actually save, which resulted in overwriting the user's
custom-file with a mostly empty file, so we fixed it by signalling an
error, but I guess that just outputting a message and not saving is
good enough.


        Stefan

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Tim Cross writes:

 > I have used that technique, but have run into problems with packages
 > that have already loaded where the variable needs to be set before
 > they are loaded.

Granted, but that belongs to the "do what's needed to reproduce the
bug" part of my workflow.  I don't see how it's relevant to the
discussion of *excessive* changes to the -Q environment.

 > The core issue I see is that -Q is useful mainly because it
 > establishes a standard default environment.
[...]
 > Once we allow local customizations to be applied in this
 > environment, this standard base default environment no longer
 > exists. This may be fine, provided there is some mechanism that
 > makes what has been changed explicit and easy to reproduce.

I think that Customize already provides some function for listing
variables that are not at their default values, both Customized and
"rogue" values.  Its output could be added to the bug-reporter's
buffer (maybe it's already there in Emacs, but XEmacs doesn't do that
yet).  Perhaps it should be glossed with a comment that only
defcustoms can be listed this way.

 > Bug reporting was not meant as the central theme - it was just an
 > example of one thing that could be affected when you allow local
 > customizations to be applied in a -Q environment.

OK.

 > What I don't want to see is one party reporting something in a -Q
 > environment that is not seen in another -Q environment (assuming
 > other things, such as platform, version etc being equal)

I'm not sure I understand.  Isn't that just a symptom of a poor
report, ie, omitting necessary preparation for reproducing the
behavior from the recipe?  AIUI Lars' code is *not* going to suffer
from the problem you describe: only *necessary* changes to the -Q
environment will be made, and it's the reporter's responsibility, as
usual, to describe them accurately.  I'll let Lars speak to the
details, though.

 > What I don't want is local customizations that are applied 'behind
 > the scenes' or are only applied to some things and not others.

Sure.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> So this thread isn't about making life easier for bug reporters (who
> very likely don't remember the necessary settings the way Lars does,
> or even which variables to set, because assistant.el and Customize
> handle it for them), it's about making life easier for developers like
> Lars.

No, this is about making `M-x mail' (and other commands that (offer to)
save variables via the customisation framework) work in "emacs -Q".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Tim Cross]

On Tue, Jul 12, 2011 at 2:12 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Tim Cross writes:
>
>  > I have used that technique, but have run into problems with packages
>  > that have already loaded where the variable needs to be set before
>  > they are loaded.
>
> Granted, but that belongs to the "do what's needed to reproduce the
> bug" part of my workflow.  I don't see how it's relevant to the
> discussion of *excessive* changes to the -Q environment.
>

I don't think "'excessive' changes" is an accurate reflection of what
has been discussed her. The issue is about a package which needs local
settings which are normally handled by the 'custom' framework.
However, when you are running with -Q (and possibly -q), your .emacs
is not loaded and no cusotmizations are in effect. To complicate
matters, some of the functions in the custom package do not work well
or do not work at all if the user's .emacs is not loaded or cannot be
saved to. I think Lars wants to find a way to make code, such as
smtpmail (I'm gussing) work in a 'clean' way under -Q.

My contribution (FWIW) was to try and emphasize that as soon as you
allow local configuration settings within the -Q environment, you are
fundamentally changing the familiar semantics of that environment. It
is no longer the stock standard, out of the box environment which can
be duplicated by anyone simply through adding the -Q switch. To get
consistency between two environments, it would now be necessary to
perform additional steps.

[..]

>
>  > Bug reporting was not meant as the central theme - it was just an
>  > example of one thing that could be affected when you allow local
>  > customizations to be applied in a -Q environment.
>
> OK.
>
>  > What I don't want to see is one party reporting something in a -Q
>  > environment that is not seen in another -Q environment (assuming
>  > other things, such as platform, version etc being equal)
>
> I'm not sure I understand.  Isn't that just a symptom of a poor
> report, ie, omitting necessary preparation for reproducing the
> behavior from the recipe?  AIUI Lars' code is *not* going to suffer
> from the problem you describe: only *necessary* changes to the -Q
> environment will be made, and it's the reporter's responsibility, as
> usual, to describe them accurately.  I'll let Lars speak to the
> details, though.

You could look at it as a symptom of poor bug reporting, but that
isn't sufficient. Bugs are often reported by people with little
experience and it can be difficult to know what to include and what
not to. A consistent -Q environment helps by creating a consistent
setup that can be communicated easily as "start with emacs -Q".  We
even tell people to see if the issue they have continues when you run
under -Q. However, once we lose this standard environment because it
may have local configuration settings, we cannot know for certain.
Someone reports a problem they see under -Q, but which someone else
does not see and now we don't know if its due to local customization
or some other issue.

However, please, move past bug reporting. The -Q is useful in many
other scenarios. Think of it as the ultimate emacs reset button. With
-Q everything goes back to the factor defaults.  Ironically, I only
really mentioned bug reporting as it was an example of how allowing
local customization could make that process easier, but at the same
time, potentially make other things harder - a double edged sword if
you like.

Once you change default settings in any way, this property of the -Q
switch is lost. Yes, in many cases, it may not be an issue and yes, it
may make some things, such as mail, work. However, this is irrelevant
to the fact it fundamentally changes -Q in subtle ways that could have
other side effects. This may well be acceptable, but if this is the
case, it needs to be a decision made after considering such factors.
An alternative solution is to accept that some packages, those that
require local configuration, just don't work under -Q.


I also think it is dangerous to just consider what Lars requires.
While we may modify/add a feature to address the specific problem he
is encountering, we also need to consider whether over time, others
may use that facility incorrectly or in ways that were not thought of
when it was implemented and what the consequences of that may be.

My view is that the objective Lars is after is reasonable and we need
to support his efforts. At the same time, I would like to do this in a
way that does not change the semantics of -Q, or if it must, does so
in a way where it is easy to get the environment consistency that -Q
previously provided. There are numerous ways I think this could be
done. An additional switch may be worth considering (either to force a
'only factory defaults' type setting or allow some 'customization' for
specific packages - my only hesitation is contributing to emacs
becoming a program that has such complex and numerous command line
switches that they themselves become an issue!

Tim

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Tim Cross writes:
 > On Tue, Jul 12, 2011 at 2:12 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > saved to. I think Lars wants to find a way to make code, such as
 > smtpmail (I'm gussing) work in a 'clean' way under -Q.

The right way is to use different functions to do the `set' part,
which Customize already provides.

As an Olde Farte, I am often nonplussed by software that doesn't offer
to set or save, but simply reflects changes in the dialog in the
settings immediately, and saves them when the dialog is dismissed (or
perhaps before).  It seems to me that a better approach than screwing
with the semantics of "save" and turning it into "save in some
circumstances but not others and you'd better remember which you're
in, until the end of the session which may be a long time from now",
simply do that set (which AFAIK can't fail) and then do a separate
save, which makes it clear WTF the code is doing.

 > > I'm not sure I understand.  Isn't that just a symptom of a poor
 > > report, ie, omitting necessary preparation for reproducing the
 > > behavior from the recipe?
 > 
 > You could look at it as a symptom of poor bug reporting, but that
 > isn't sufficient.

I very carefully removed "bug".  This is not about bug reporting, it's
about communication including bug reporting but not limited to it.  I
use the word "report" to indicate that certain aspects of the
communication need to be precisely stated.

 > Once you change default settings in any way, this property of the -Q
 > switch is lost.

Sure.  I don't see how anything I said depends on *bug* reporting.
What it depends on is making changes to the environment.  In the case
of mail, this may mean choosing a non-default transport (smtpmail
vs. sendmail) and setting user options (full name and mail address)
and so on.

 > An alternative solution is to accept that some packages, those that
 > require local configuration, just don't work under -Q.

Well, sure.  All that means is that people will continue to use -Q as
"the ultimate Emacs reset" (quote of the week!) and proceed to modify
that environment as necessary to do the work they're going to do.  It
will be their responsibility to report those modifications in order
for others to reproduce the behavior ....

 > My view is that the objective Lars is after is reasonable and we need
 > to support his efforts.

We already do.  There's nothing hard or unclear about 

    (customize-set-variable VAR ...)
    (condition-case
        (customize-save-variable VAR ...)
      (whatever-error-c-s-v-throws
       (warn "VAR set but not saved because you haven't loaded custom file")))

Lars just thinks that Emacs should be smart enough to do that itself.
I think, as the Japanese say, this is ten years too early for that
kind of smartness.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Tim Cross]

On Wed, Jul 13, 2011 at 10:31 AM, Stephen J. Turnbull
<stephen@xemacs.org> wrote:
> Tim Cross writes:
>  > On Tue, Jul 12, 2011 at 2:12 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>
>  > saved to. I think Lars wants to find a way to make code, such as
>  > smtpmail (I'm gussing) work in a 'clean' way under -Q.
>
> The right way is to use different functions to do the `set' part,
> which Customize already provides.
>
> As an Olde Farte, I am often nonplussed by software that doesn't offer
> to set or save, but simply reflects changes in the dialog in the
> settings immediately, and saves them when the dialog is dismissed (or
> perhaps before).  It seems to me that a better approach than screwing
> with the semantics of "save" and turning it into "save in some
> circumstances but not others and you'd better remember which you're
> in, until the end of the session which may be a long time from now",
> simply do that set (which AFAIK can't fail) and then do a separate
> save, which makes it clear WTF the code is doing.
>

I *think* I agree, though am not clear what 'saving' means compared to
'setting' within the context of the -Q switch - if it is just a
'no-op' type of operation, it could cause confusion for the user and
if it means something else, I'm not sure what that is.


>  > > I'm not sure I understand.  Isn't that just a symptom of a poor
>  > > report, ie, omitting necessary preparation for reproducing the
>  > > behavior from the recipe?
>  >
>  > You could look at it as a symptom of poor bug reporting, but that
>  > isn't sufficient.
>
> I very carefully removed "bug".  This is not about bug reporting, it's
> about communication including bug reporting but not limited to it.  I
> use the word "report" to indicate that certain aspects of the
> communication need to be precisely stated.

OK, but that does not affect my point regarding the importance of -Q
representing a standard, well defined and consistent configuration.

>
>  > Once you change default settings in any way, this property of the -Q
>  > switch is lost.
>
> Sure.  I don't see how anything I said depends on *bug* reporting.
> What it depends on is making changes to the environment.  In the case
> of mail, this may mean choosing a non-default transport (smtpmail
> vs. sendmail) and setting user options (full name and mail address)
> and so on.

This is getting weird. It seems we both agree that -Q and any changes
to that environment are about more than bug reporting. I think its
about more than reporting. For example, I find it extremely useful in
a diagnostic role and have even found it useful in teaching or
explaining concepts as it ensures everyone is in the same basic
environment.

>
>  > An alternative solution is to accept that some packages, those that
>  > require local configuration, just don't work under -Q.
>
> Well, sure.  All that means is that people will continue to use -Q as
> "the ultimate Emacs reset" (quote of the week!) and proceed to modify
> that environment as necessary to do the work they're going to do.  It
> will be their responsibility to report those modifications in order
> for others to reproduce the behavior ....
>

I think we must have very different views on how -Q is used. I do not
see -Q being a switch you would normally use in day-to-day operation.
It is something you do when trying to diagnose a problem, formulate a
recipe for a bug or possibly do some testing/benchmarking/profiling
etc. On some levels, it is reasonable to assume some functionality
which depends on local customization will not work, but that could be
OK given the current context.

>  > My view is that the objective Lars is after is reasonable and we need
>  > to support his efforts.
>
> We already do.  There's nothing hard or unclear about
>
>    (customize-set-variable VAR ...)
>    (condition-case
>        (customize-save-variable VAR ...)
>      (whatever-error-c-s-v-throws
>       (warn "VAR set but not saved because you haven't loaded custom file")))
>
> Lars just thinks that Emacs should be smart enough to do that itself.
> I think, as the Japanese say, this is ten years too early for that
> kind of smartness.
>
>

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.  I thought the objective was to make
code that needed to set custom variables at load time able to handle
the -Q situation without the need to jump through extra hoops to avoid
it throwing an error. Others mentioned that having code 'silently'
fail to do what would be expected i.e. save, was perhaps not a great
idea and I tend to agree. 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. It means that -Q would no longer mean emacs in a fully default
state to emacs in a default state with some things set to local
values. It is the 'some things set to local values" which I think
could be problematic and my suggestion was that if we do go down that
road, we need a convenient way to know what those some things are and
possibly a reliable way to communicate that information. The overall
point was to question whether this was even a good road to go down at
all or 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 (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.

Tim

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

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.

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Tim Cross]

On Wed, Jul 13, 2011 at 9:02 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>  > 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.
>

Agree, but perhaps disagree on how those changes occur. I would prefer
that the individual has to explicitly (even manually) make those
changes rather than have emacs attempt to anticipate what the user may
need when running under a -Q environment. Of course, the downside with
this approach is that those who are less comfortable/familiar with
emacs will find this difficult.

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

I guess your saying that saving and setting are different operations
and saving without setting would not affect the current environment?
What I'm not clear about is where you would save the values to. The
default location I gues swould be the users .emacs file. However,
quite a few users also customize this and have the custom variable
stuff in a different file because they don't want it mixed up with
other stuff in .emacs. Now we have a problem. The -Q switch does not
read the .emacs file and therefore we cannot tell which aproach this
user prefers and therefore, don't know where we should save these
values to. This is why I don't understand what 'save' means in this
context or how it would work. Worse yet would be a situation where the
user becomes confused when they believe they have saved settings while
under -Q, but then next time they run emacs (with or without -Q) their
changes have not been saved.  To some extent, I would guess this is
primarily why you would argue for an error rather than a warning -
making it very clear to the user their save action has failed?

>  > (maybe a warning they are not saved rather than an error) or
>  > perhaps it al> 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.
>

I'm divided on error v's warning. On one hand, an error is good as it
grabs user attention and makes it clear the values have not been saved
- avoiding later confusion. The downside is that it can make the code
more complex for developers when -Q is invoked. On the other hand, it
could be argued that as this is a known and understood situation, a
warning is sufficient. The advantage is that some code would become
less complex. The downside is that users may easily overlook the error
and then get confused when their settings don't seem to be persisting
over sessions etc.

I personally think an error is better. However, I also don't fully
understand how often package maintainers run into problems
initializing their packages when they are run under -Q. If this
problem is relatively rare and really only comes up when you would
like a package to have some level of functionality under -Q and that
can only be achieved by setting values, then an error would certainly
seem to be the right choice. However, if this is a frequent issue and
an error is resulting in frequently more complex initialization code,
then there could be a case to downgrade it to a warning. On the other
hand, I would be tempted to look at refactoring how defaults and
custom work as this would indicate a deeper design issue IMO.

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

Yes - I worry about it becoming easier to pollute the -Q environment
and whether this will reuslt in -Q becoming less useful over time. I
think it is reasonable to expect the -Q environment to be less
'useful' than the standard environment. It is a special purpose
environment and losing some functionality in such an environment is
acceptable - especially if the lost functionality is functionality
that depends on local configuration.

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

It would seem we are of similar opinions. I too am concerned that
making it easier for code to change custom variables under -Q
environments will result in -Q losing its important quality of
representing a standard default environment. The suggested changes to
custom functions certainly feels wrong in the sense that it seems to
be muddying their definition and making matters more complex than
desirable. I also suspect that the desire to make -Q more functional
may be misplaced.

I guess we will have to wait and see what evolves.

Tim

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Stephen J. Turnbull]

Tim Cross writes:
 > On Wed, Jul 13, 2011 at 9:02 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > > 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.
 > 
 > Agree, but perhaps disagree on how those changes occur.

I think you and I agree that having M-x sendmail prompt for values is
implicit, but I'm pretty sure Lars would consider that to be an
explicit change.

 > I guess your saying that saving and setting are different operations
 > and saving without setting would not affect the current environment?
 > What I'm not clear about is where you would save the values to.

Well, in XEmacs it's not really a problem because by default
customizations are saved to ~/.xemacs/custom.el, so I haven't really
thought about it.  A bit of reflection suggests that if the default is
.emacs, this is a real hairball.  However, neither of the options
currently being advocated (status quo with an error before setting the
variable vs. catch the error, set the variable, issue warning)
actually does save so the point is moot, I think.

That issue aside, IMO if a failure to save customizations in the -Q
environment is a problem for some code, that code should handle it.
In general, I want to discourage use of Customize in the -Q
environment because Customize does way too much magic behind the
scenes (a Customize setter can do *anything*).  As soon as a recipe
says "Customize variable X to Y," you're in a situation where you must
analyze Customize as well as the main code.

 > changes have not been saved.  To some extent, I would guess this is
 > primarily why you would argue for an error rather than a warning -
 > making it very clear to the user their save action has failed?

No, my primary reason is the above.  If the warning is obstrusive, the
user won't miss it, and it's unlikely that much harm will be done even
if they do.  They just have to redo the customization in a session
without -Q, and only if that is "hard" is there a real loss.

 > I personally think an error is better. However, I also don't fully
 > understand how often package maintainers run into problems
 > initializing their packages when they are run under -Q.

Lars says it's not about the package maintainers, it's about the
users.  It's none of our business why the user is running a mail
command in -Q environment, but we should make that as painless as
possible.

I agree, I just think that it's better to have the burden of handling
errors occasioned by operating in the -Q environment placed on
developers rather than done behind the scenes by Emacs.

 > Yes - I worry about it becoming easier to pollute the -Q environment
 > and whether this will reuslt in -Q becoming less useful over time.

Exactly.

 > I guess we will have to wait and see what evolves.

Sure.  But although Lars may have long since killed this subthread, I
suspect Stefan and/or Yidong lurked long enough to get the point.
That doesn't mean they'll agree with us, of course.

Until next time :-),

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Dave Abrahams]

on Sun Jul 10 2011, Lars Magne Ingebrigtsen <larsi-AT-gnus.org> wrote:

> If you run "emacs -Q", and you have a piece of code that calls
> `customize-save-variable', it will error out, saying that it won't
> overwrite the conf.
>
> Would anybody mind if I changed that function to not error out, but
> instead just do a `setq' on the variable in question, if we're running
> under -Q?
>
> Otherwise all the callers end up doing this very awkward thing:
>
> 	(if (ignore-errors (custom-file))
> 	    (progn
> 	      (customize-save-variable 'smtpmail-smtp-server server)
> 	      (customize-save-variable 'smtpmail-smtp-service port))
> 	  (setq smtpmail-smtp-server server
> 		smtpmail-smtp-service port))

My usual workaround for that and related issues is never to run emacs
with -Q.  Instead I create an empty directory in /tmp and set HOME to
point there:

   HOME=/tmp/test emacs

I think that *could* be a much better behavior for emacs -Q even if it
means you can't access anything you normally reach via ~.
Another option of course would be to populate the test directory with
symlinks to make it look more like my home directory, but I actually
never needed anything like that.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Christoph Scholtes]

On 7/10/2011 6:22 AM, Lars Magne Ingebrigtsen wrote:
> If you run "emacs -Q", and you have a piece of code that calls
> `customize-save-variable', it will error out, saying that it won't
> overwrite the conf.
>
> Would anybody mind if I changed that function to not error out, but
> instead just do a `setq' on the variable in question, if we're running
> under -Q?

I am not sure if this is related to this, but I just encountered a 
rather awkward situation. I run on Windows with my configuration stored 
in `~/.emacs.d/init.el'.

I did a recipe for a bug from `emacs -Q' and tried to submit a bug 
report. It asked me whether I wanted to save the SMTP setup, which I 
replied no to. It then proceeded to pop up the configured MUA 
(Thunderbird) to send the bug report.

Next time I launched Emacs it did not load any of my custom configurations.

Turns out it wrote a `.emacs' to to ~/, which contained the

'(sendmail-query-once-function (quote mailclient-send-it) t)

and was loaded in favor of my configuration in `.emacs.d'.

I can see this potentially being very confusing for people.

Do we have to save this custom variable even when running `emacs -Q'?

Christoph

Re: Change `customize-save-variable' to work under "emacs -Q"?

[Lars Magne Ingebrigtsen]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> Turns out it wrote a `.emacs' to to ~/, which contained the
>
> '(sendmail-query-once-function (quote mailclient-send-it) t)
>
> and was loaded in favor of my configuration in `.emacs.d'.

Yes, that's not nice.  Perhaps `customize-save-variable' shouldn't save
anything at all under -Q, even if the (default) startup file doesn't
exist? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/