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

[Tim Cross]

On Tue, Jul 12, 2011 at 11:51 AM, Stephen J. Turnbull
<address@hidden> 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