Customize Rogue

Customize Rogue

[Per Abrahamsen]

I wrote this function as a transition tool from "setq" to customize,
it list all "rogue" variables, that is, variables that have been
declared by defcustom but changed outside customize.

OK to add to to cus-edit.el?

Ideally, the only "rogue" variables would be those the user have set
in .emacs himself, unfortunately there are a number of rogue variables
even in a fresh Emacs.  These are all potential problems.  For some
it is just a question of initialization, menu-bar-mode was an example
of that.  Others are changed later from Lisp code, those should
probably not be declared with defcustom, as changed from Lisp will
conflict with changed made by the user.

;;;###autoload
(defun customize-rogue ()
  "Customize all user variable modified outside customize."
  (interactive)
  (let ((found nil))
    (mapatoms (lambda (symbol)
		(let ((cval (or (get symbol 'customized-value)
				(get symbol 'saved-value)
				(get symbol 'standard-value))))
		  (when (and cval 	;Declared with defcustom.
			     (default-boundp symbol) ;Has a value.
			     (not (equal (eval (car cval)) 
					 ;; Which does not match customize.
					 (default-value symbol))))
		    (push (list symbol 'custom-variable) found)))))
    (if (not found)
	(error "No rogue user options")
      (custom-buffer-create (custom-sort-items found t nil)
			    "*Customize Rogue*"))))

Re: Customize Rogue

[Juanma Barranquero]

On Thu, 06 Mar 2003 09:39:18 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> I wrote this function as a transition tool from "setq" to customize,

Transition?

> it list all "rogue" variables, that is, variables that have been
> declared by defcustom but changed outside customize.

I'd much prefer a customize-set-value lookalike which would set the
value of the variable, and trick the customize machinery into believing
I did the right thing, *without* having to load cus-edit.

I certainly don't want to use Customize and I don't consider customize
something I should "transition" too...

I'm not attacking customize, I'm sure it's wonderful for a lot of people,
and beginners most of all. I just don't like having to use a form to set
what I could do with a line or two on my .emacs.

                                                           /L/e/k/t/u

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> On Thu, 06 Mar 2003 09:39:18 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
> I certainly don't want to use Customize and I don't consider customize
> something I should "transition" too...

I don't think you should do so either, but some people want to do so
for whatever reason, and the command is useful for them.

> I'd much prefer a customize-set-value lookalike which would set the
> value of the variable, and trick the customize machinery into believing
> I did the right thing, *without* having to load cus-edit.

What do you hope to accomplish by tricking customize?

Re: Customize Rogue

[Juanma Barranquero]

On Thu, 06 Mar 2003 16:15:07 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> I don't think you should do so either, but some people want to do so
> for whatever reason, and the command is useful for them.

Yes, sure.

I reacted to the word "transition"**, but of course I'm not opposing
customize-rogue in any way.

**And the reason I reacted is that I hate finding those variables whose
docstrings say "Don't set this directly, use customize".

> What do you hope to accomplish by tricking customize?

Two things:

 1.- Not getting the "modified outside of customize" messages that I get
the odd time I use it. If the value is right, I don't see the point of
knowing i.e. if I set custom-file to ".emacs.custom" via setq or through
M-x customize-variable; the message makes me wonder if anything's wrong...

 2.- Using the customized initialization/setting/getting/whatever code
for those variables that have special needs. I'd like to do

  (custom-setq variable value)   ; or whatever

and get customize to check the value against the type spec, etc.


                                                           /L/e/k/t/u

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> I reacted to the word "transition"**, 

Does the word have any special positive or negative connotations?

>  1.- Not getting the "modified outside of customize" messages that I get
> the odd time I use it. 

They are there for a reason.

> If the value is right, I don't see the point of
> knowing i.e. if I set custom-file to ".emacs.custom" via setq or through
> M-x customize-variable; the message makes me wonder if anything's wrong...

Which is good, because if you have set it with setq and you try to
save it with customize, the customize save will be overwritten by the
setq.

custom-file probably should not have been declared with defcustom, as
it make no sense to change it throug customize.

>  2.- Using the customized initialization/setting/getting/whatever code
> for those variables that have special needs. I'd like to do
>
>   (custom-setq variable value)   ; or whatever
>
> and get customize to check the value against the type spec, etc.

customize-set-value only make type-checks when used interactively,
when used from Lisp is works just like setq.

customize-set-variable will tell customize the variable has been set
interactively, and call any speciel ":set" functions.

The first property means it should never be called from ".emacs", but
the second could be generally useful.  

Maybe we should have a function that does the second (obey :set)
without doing the first.  I'm not a Common Lisp programmer, but I
suspect it would be natural to use setf for that purpose.  This way we
could do things like

  (setf menu-bar-mode nil)

and it would just work.

Re: Customize Rogue

[Richard Stallman]

It seems like a good idea to me.

Re: Customize Rogue

[Richard Stallman]

    I'd much prefer a customize-set-value lookalike which would set the
    value of the variable, and trick the customize machinery into believing
    I did the right thing, *without* having to load cus-edit.

If it can do the job without loading cus-edit, I guess that is an
advantage.  It is not the most important thing though.

Perhaps some of the Custom commands might want to ask the user whether
to do this.  If we can choose the right situations to do that, it would
mean users don't have to remember a command name for it, which would
be a big advantage.

    I certainly don't want to use Customize and I don't consider customize
    something I should "transition" too...

If you don't want to use Customize, I guess you would have no wish
to redo your variable settings using Customize.

Re: Customize Rogue

[Juanma Barranquero]

On Fri, 07 Mar 2003 14:40:57 -0500, Richard Stallman <rms@gnu.org> wrote:

> If you don't want to use Customize, I guess you would have no wish
> to redo your variable settings using Customize.

That I don't want to use Customize does not mean I'm not forced to use
it sometimes, or go 'round it.

For example, I have in my .emacs the following:

 (put 'inhibit-startup-echo-area-message 'saved-value t)
 (setq inhibit-startup-echo-area-message (user-login-name))

Yes, I'm misusing `inhibit-startup-echo-area-message'. But I *know* what
I'm doing, and I use the exact same .emacs on several machines. That's
exactly what I want to do.

I've had to take a look into startup.el to know how to subvert the
check; in my view, I shouldn't have to. I should just have to do

(custom-setq inhibit-startup-echo-area-message (user-login-name))

and be done with it.

                                                           /L/e/k/t/u

Re: Customize Rogue

[Luc Teirlinck]

Juanma Barranquero wrote:

   That I don't want to use Customize does not mean I'm not forced to use
   it sometimes, or go 'round it.

   For example, I have in my .emacs the following:

    (put 'inhibit-startup-echo-area-message 'saved-value t)
    (setq inhibit-startup-echo-area-message (user-login-name))

   Yes, I'm misusing `inhibit-startup-echo-area-message'. But I *know* what
   I'm doing, and I use the exact same .emacs on several machines. That's
   exactly what I want to do.

   I've had to take a look into startup.el to know how to subvert the
   check; in my view, I shouldn't have to. I should just have to do

   (custom-setq inhibit-startup-echo-area-message (user-login-name))

   and be done with it.

It seems to me that in the above example you are not at all trying to
get around roadblocks put in your way by customize, quite to the
contrary, you are taking advantage of the way customize is implemented
in startup.el to get around what you really want to get around, namely
the intentional disabling of code like:

(setq inhibit-startup-echo-area-message (user-login-name))

Customize itself does not let you get around that: it requires a
string constant.

The reason to disable

(setq inhibit-startup-echo-area-message (user-login-name))

is out of fear that somebody else might blindly copy your .emacs.

(custom-setq inhibit-startup-echo-area-message (user-login-name))

would not get around that problem.

Of course, you may be confident that nobody is going to blindly copy
your .emacs.  But there are plenty of ways that you can achieve what
you want to achieve.  For instance, it would seem that:

(defun startup-echo-area-message ())

in .emacs would work, as would plenty of other (maybe better) stuff.

Anyway, this is a completely separate issue, unrelated to customize.

I am not necessarily saying that you do not have a point, only that if
you do, your example seems badly chosen.  (Unless I am completely
misunderstanding it.)

Sincerely,

Luc.

Re: Customize Rogue

[Juanma Barranquero]

On Sun, 9 Mar 2003 11:16:08 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> It seems to me that in the above example you are not at all trying to
> get around roadblocks put in your way by customize

No. I'm trying to get around the fact that I have to go through
the customize interface (or fake it) to get the effect of customization.
And what I want is to get them without going through the interface.

> The reason to disable
> 
> (setq inhibit-startup-echo-area-message (user-login-name))
> 
> is out of fear that somebody else might blindly copy your .emacs.

I know that.

> (custom-setq inhibit-startup-echo-area-message (user-login-name))
> 
> would not get around that problem.

Wouldn't? The custom-setq I'm talking about would have the *exact*
semantics of doing M-x customize-variable MY-VAR, setting the value to
VALUE and then chosing "Save for Future Sessions"... So it would, by
definition.

> Of course, you may be confident that nobody is going to blindly copy
> your .emacs.

Really, the fact that I've chosen inhibit-startup-echo-area-message for
the example is irrelevant.

> I am not necessarily saying that you do not have a point, only that if
> you do, your example seems badly chosen.  (Unless I am completely
> misunderstanding it.)

The first one that crossed my mind. But what about those variables whose
docstring says "Setting this variable directly will have no effect, you
have to use customize"...? I want to have the option of setting the
variable directly and getting the customization effect.


                                                           /L/e/k/t/u

Re: Customize Rogue

[Luc Teirlinck]

Juanma Barranquero wrote:

   No. I'm trying to get around the fact that I have to go through
   the customize interface (or fake it) to get the effect of customization.

Let me first make sure that I understand your problem:

Your login name is, say, lektu on one machine, barranj on another.
You want to use one .emacs for both, hence you can not do

(setq inhibit-startup-echo-area-message "lektu")

nor:

(setq inhibit-startup-echo-area-message "barranj")

Or at least not just one of them.
What I suggested before:
(defun startup-echo-area-message ())
now seems stupid.

The solution to the problem I describe would be to put both lines
above in .emacs.  It works and people could blindly copy your .emacs,
no problem, at least not in as far as
inhibit-startup-echo-area-message is concerned.  

But is the above your real problem?

Sincerely,

Luc.

Re: Customize Rogue

[Luc Teirlinck]

Juanma Barranquero wrote:

   I know that.

   > (custom-setq inhibit-startup-echo-area-message (user-login-name))
   > 
   > would not get around that problem.

   Wouldn't? The custom-setq I'm talking about would have the *exact*
   semantics of doing M-x customize-variable MY-VAR, setting the value to
   VALUE and then chosing "Save for Future Sessions"... So it would, by
   definition.

If I copy that line literally from your .emacs, then what is going to
prevent that line from having exactly the same effect in my .emacs
than it has in yours?  The VALUE you are going to enter through
customize would be "lektu" or whatever, so that value would really
have no effect in my .emacs, where "teirllm" would be required.

   > I am not necessarily saying that you do not have a point, only that if
   > you do, your example seems badly chosen.  (Unless I am completely
   > misunderstanding it.)

   The first one that crossed my mind. But what about those variables whose
   docstring says "Setting this variable directly will have no effect, you
   have to use customize"...? I want to have the option of setting the
   variable directly and getting the customization effect.

I actually agree with the above.  But what does this have to do with
`inhibit-startup-echo-area-message'?  It definitely is not one of
those variables.

Sincerely,

Luc.

Re: Customize Rogue

[Juanma Barranquero]

On Sun, 9 Mar 2003 12:25:06 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> Your login name is, say, lektu on one machine, barranj on another.

Yes.

> The solution to the problem I describe would be to put both lines
> above in .emacs.

Yes, that's an aswer, because startup looks for a precise text in
.emacs; setting the 'saved-value property, as I do, is another one.

> But is the above your real problem?

No. Please *forget* inhibit-startup-echo-area-message. Is *irrelevant*
to the discussion.

The "problem" is that I *don't* like the customization interface, but
some modules want to force the user to set variables through the
interface. I don't want to do that. I want to set them directly.


                                                           /L/e/k/t/u

Re: Customize Rogue

[Luc Teirlinck]

Juanma Barranquero wrote:

   No. I'm trying to get around the fact that I have to go through
   the customize interface (or fake it) to get the effect of customization.
   And what I want is to get them without going through the interface.

Now I understand.  You can enter (user-login-name) in customize and it
will fool the entire machinery.  That seems to me to be a bug in
customize.  (Unless I am misunderstanding something)  That bug is,
however completely unrelated to the problems with customize you are
describing.

Sincerely,

Luc.

Re: Customize Rogue

[Juanma Barranquero]

On Sun, 9 Mar 2003 12:40:04 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> If I copy that line literally from your .emacs, then what is going to
> prevent that line from having exactly the same effect in my .emacs
> than it has in yours?  The VALUE you are going to enter through
> customize would be "lektu" or whatever, so that value would really
> have no effect in my .emacs, where "teirllm" would be required.

When I say that

(custom-setq VARIABLE VALUE)

should have the same semantics that going through the customization
interface, I'm not saying that VALUE is a constant, or non-evaluated.

(custom-setq my-var (user-full-name))

would evaluate `user-full-name', pass the value (let's say it is
"jbarran") to custom-seq, and then it would do the *same* thing that if
I did M-x customize-variable my-var and typed "jbarran" and then
selected "Save for Future Sessions". But if the same code is executed in
another environment, custom-setq would be called with another arguments.

> I actually agree with the above.  But what does this have to do with
> `inhibit-startup-echo-area-message'?  It definitely is not one of
> those variables.

Luc, forgive me if I'm starting to get a bit fed up with this, but I
think I've been saying for about four messages now that it's *not*
particularly related to inhibit-startup-echo-area-message. That variable
must be set through customization:

> Setting this variable takes effect
> only if you do it with the customization buffer
> or if your `.emacs' file contains a line of this form:
>  (setq inhibit-startup-echo-area-message "YOUR-USER-NAME")

so I chose it as an example. That's all. Please assume I said
"current-language-environment" instead.


                                                           /L/e/k/t/u

Re: Customize Rogue

[Juanma Barranquero]

On Sun, 9 Mar 2003 12:50:28 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> Now I understand.  You can enter (user-login-name) in customize and it
> will fool the entire machinery.  That seems to me to be a bug in
> customize.

I hadn't even thought of that, but if it works, I'd call it a feature.
But still...

>(Unless I am misunderstanding something)

...Yes, you're mistunderstanding me. My problem is *not* related to what
can or cannot be done through the forms-like interface of customize,
because I very emphatically *don't* want to use it.

My "problem" is that if setting a variable through the interface causes
side effects, I want to be able to get those very same side effects
through a simple asignment in my .emacs.

Not for `inhibit-startup-echo-area-message'. For *every* customizable
option.


                                                           /L/e/k/t/u

Re: Customize Rogue

[Luc Teirlinck]

Juanma Barranquero wrote:

   Luc, forgive me if I'm starting to get a bit fed up with this, but I
   think I've been saying for about four messages now that it's *not*
   particularly related to inhibit-startup-echo-area-message.

Sorry about that.  I somehow am a slow typist and was still reacting
to your old messages when I should have been forgetting about them and
concentrating on your latest ones.  Also there is a delay between
receiving mail and the `Mail' appearing in the mode line.  Some of our
messages seem to have crossed each other "in transit".

Also, there seems to be some problem with customize completely
bypassing safeguards put into .emacs.  Either both .emacs and
customize need those safeguards or neither does.  This does not seem
to be consistent.  The fact that this was not the problem you are
interested in, but instead was one you completely inadvertently
"bumped into", does not mean that it is not a problem.

Sincerely,

Luc.

Re: Customize Rogue

[Robert J. Chassell]

   The "problem" is that I *don't* like the customization interface, but
   some modules want to force the user to set variables through the
   interface.

Said a different way:  Emacs has been a `virtual lisp machine', but
the customization interface prevents it being one.  In the past, you
could evaluate any Emacs Lisp expression; but in some circumstances,
the customization interface does not permit this.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Customize Rogue

[Juanma Barranquero]

On Sun, 9 Mar 2003 13:37:45 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:

> The fact that this was not the problem you are
> interested in, but instead was one you completely inadvertently
> "bumped into", does not mean that it is not a problem.

Glad to help :)

                                                           /L/e/k/t/u

Customize and inhibit-startup-echo-area-message

[Luc Teirlinck]

>From my previous message:

   Now I understand.  You can enter (user-login-name) in customize and it
   will fool the entire machinery.  That seems to me to be a bug in
   customize.

To begin with, I fully understand that this as nothing to do with the
problem Juanma is discussing.  I am discussing a specific problem
with inhibit-startup-echo-area-message.  The statement I made above is
wrong.  If you enter (user-login-name) through customize, then
inhibit-startup-echo-area-message gets set to the unevaluated string
"(user-login-message)" which has no effect whatsoever.  The only ways
to get an equivalent of

(setq inhibit-startup-echo-area-message (user-login-name))

executed through the customize machinery that I know of are to use it
indirectly, either the way Juanma did or by adding manually the line:
  '(inhibit-startup-echo-area-message (user-login-name))
to one's custom-set-variables form in .emacs.

Since both ways seem rather deliberate, I would not consider them
bugs, even though they would yield problems in case of completely
thoughtless copying.

I do not know whether Juanma actually bumped into a less deliberate
way to use customize to get a
(setq inhibit-startup-echo-area-message (user-login-name))
equivalent.

Sincerely,

Luc.

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> The "problem" is that I *don't* like the customization interface, but
> some modules want to force the user to set variables through the
> interface. I don't want to do that. I want to set them directly.

If any module force the user to go through Customize, that is simply a
bug in that module.  Rather than implementing workarounds, the module
should be fixed.

Note that most cases where people notice this is for minor modes,
which used to work like this

(defvar foo-bar-mode nil) ;; Internal state variable, do not touch

(defun foo-bar-mode (flag) ...) ;; Command to turn foo bar mode on or off.

and now work like this

(defcustom foo-bar-mode nil
  "State of foo bar mode, only change this through customize." ...)

(defun foo-bar-mode (flag) ...) ;; Command to turn foo bar mode on or off.

because Customize requires a variable to work.

This means an internal variable have become visible but only for
customize users.  It does not mean foo bar mode suddenly only can be
set through customize, but the Lisp interface is now as always a
function, not a variable.  The doc-string just makes people jump to
the conclusion that no Lisp interface is available.

With Luc's set-activate function, there will be to Lisp interfaces
with identical semantics.  But it will help people who us customize to
search for options, but not to set them, so I think it is very useful.

Re: Customize Rogue

[Kai Großjohann]

storm@cua.dk (Kim F. Storm) writes:

> I like custom-set (or custom-setq) better, as is emphasizes that
> this does indeed work just as if the variable was set interactively
> through customize (as the doc string of some variables say is
> required).

I like custom-setq, too.
-- 
A preposition is not a good thing to end a sentence with.

Re: Customize Rogue

[Luc Teirlinck]

Kim Storm wrote:

   And I think it was exactly what was asked for -- except for the name.

   I like custom-set (or custom-setq) better, as is emphasizes that
   this does indeed work just as if the variable was set interactively
   through customize (as the doc string of some variables say is
   required).

There is one difference.  All side effects will be the same, but, as
the function is written, customize will consider the option as being
"changed outside the customize buffer".  Hence "custom-" in the name
might be misleading.

The following documentation string follows Emacs' conventions better
than the original:

(defun set-activate (variable value)
  "Set VARIABLE to VALUE.  If there is a set-function, call it."
  (custom-load-symbol variable)
  (funcall (or (get variable 'custom-set) 'set-default) variable value)) 
 
Maybe some further lines could be added to make clear that this is a
valid alternative to using a customization buffer and that customize
will consider an option set in this way to be changed outside the
customize buffer.

Sincerely,

Luc.

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> The custom-setq I'm talking about would have the *exact* semantics
> of doing M-x customize-variable MY-VAR, setting the value to VALUE
> and then chosing "Save for Future Sessions"...

That would be an a very bad idea, the *only* example where that would
is when you want to bypass code that *deliberately* make it hard to
use setq, and I'd be very surprised if that is the case for any other
variable than 'inhibit-startup-echo-area-message'.  That variable is
difficult to modify non-interactively for political reasons, RMS want
every user to see the message at least once, so he made it hard for a
system administrator to deactivate it for all users.

Luc's set-activate should cover all the variables that are
*accidentally* made hard (or non-intuitive) to set from outside
customize.

> Really, the fact that I've chosen inhibit-startup-echo-area-message for
> the example is irrelevant.

Not if it is the only variable in Emacs for which your example makes
sense. 

> The first one that crossed my mind. But what about those variables whose
> docstring says "Setting this variable directly will have no effect, you
> have to use customize"...? I want to have the option of setting the
> variable directly and getting the customization effect.

There is always, modulo bugs, a specific function you need to call
instead.  However, set-activate will relieve you of the problem of
finding it (fixing the doc-string to mention the function would also
be a good idea).  It will also make it much easier to transition
*from* customize to Lisp, in fact you will be able to automate it
entirely.

Re: Customize Rogue

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

> It seems like a good idea to me.

I have committed it.

Re: Customize Rogue

[Andreas Schwab]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

|> Juanma Barranquero <lektu@terra.es> writes:
|> 
|> > Really, the fact that I've chosen inhibit-startup-echo-area-message for
|> > the example is irrelevant.
|> 
|> Not if it is the only variable in Emacs for which your example makes
|> sense. 

See utf-fragment-on-decoding for an extreme example.  It has a huge and
complicated :set function, and no way to do the same thing outside
customize.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Customize Rogue

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> There is always, modulo bugs, a specific function you need to call
> instead.  However, set-activate will relieve you of the problem of
> finding it (fixing the doc-string to mention the function would also
> be a good idea).  It will also make it much easier to transition
> *from* customize to Lisp, in fact you will be able to automate it
> entirely.

Maybe Customize could be changed to maintain a list of set-activate
statements instead of the current custom-set-variables thingy.  Then
people could just copy and paste set-activate statements...

-- 
A preposition is not a good thing to end a sentence with.

Re: Customize Rogue

[Kim F. Storm]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> 
> > Would that be a lot more difficult than say:
> >
> > (defun set-activate (variable value)
> >   "Sets variable to value.  If there is a set-function, calls it."
> >   (custom-load-symbol variable)
> >   (funcall (or (get variable 'custom-set) 'set-default) variable value)) 
> >  
> > To be used like:
> >
> > (set-activate 'tool-bar-mode t)
> 
> I think that would be an excellent addition to custom.el.
> 

And I think it was exactly what was asked for -- except for the name.

I like custom-set (or custom-setq) better, as is emphasizes that
this does indeed work just as if the variable was set interactively
through customize (as the doc string of some variables say is
required).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Customize Rogue

[Stefan Monnier]

> The "problem" is that I *don't* like the customization interface, but
> some modules want to force the user to set variables through the
> interface. I don't want to do that. I want to set them directly.

I think clearly, the problem is in the way those modules
use customize.
Most uses of :set are for things like minor-mode (where using
define-minor-mode has the advantage of providing a standard way
to deal with it), the others should be replaced.

I.e. we could provide set-activate, but I think we should
instead encourage people to avoid :set or at least use very
simple :set expressions and document the lisp-way to do things
in the docstring (as is done by define-minor-mode and as was done
before custom).


	Stefan


PS: How about we add `write-watchers' to variables ?  These would be
    hooks that get called when a specific variable is `setq'd.
    It'd have "zero performance impact" if we put it in the "setq-ing
    a read-only variable" error handling path.

Re: Customize Rogue

[Juanma Barranquero]

On Tue, 11 Mar 2003 14:07:40 -0500, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> I think clearly, the problem is in the way those modules
> use customize.

I agree, but...

> [...] I think we should
> instead encourage people to avoid :set or at least use very
> simple :set expressions [...]

...I think that's difficult to enforce.

> PS: How about we add `write-watchers' to variables ?  These would be
>     hooks that get called when a specific variable is `setq'd.

IIRC, hooks to be called when a variable is called where proposed
several times and rejected by Richard on the grounds that setting a
variable should be clearly different from calling a subroutine. I wonder
where does defcustom's :set enters the picture... :)

                                                           /L/e/k/t/u

Re: Customize Rogue

[Luc Teirlinck]

Stefan Monnier wrote:

   Most uses of :set are for things like minor-mode (where using
   define-minor-mode has the advantage of providing a standard way
   to deal with it), the others should be replaced.

Since every Lisp symbol can at the same time be a variable and a
function, it would have been nice if every variable my_favorite_symbol
with a :set function, would have an associated function
my_favorite_symbol and if that function behaved in exactly the same
way as minor mode functions for variables of boolean type and if, for
non-boolean type variables, (my_favorite_symbol value) would be
equivalent with setting the variable my_favorite_symbol to VALUE
through customize:

:set #'funcall

But I guess it is much too late to enforce anything like this, even if
it were deemed desirable.

Sincerely,

Luc.

Re: Customize Rogue

[Kai Großjohann]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> But I guess it is much too late to enforce anything like this, even if
> it were deemed desirable.

It could be stated as a desirable goal, and then slowly all uses of
Customize could be changed in that direction.

It seems that the Emacs Lisp way is to have coding conventions rather
than enforecements, and that seemed to have worked well so far.  So
why should it fail in this case?
-- 
A preposition is not a good thing to end a sentence with.

Re: Customize Rogue

[Per Abrahamsen]

Andreas Schwab <schwab@suse.de> writes:

> See utf-fragment-on-decoding for an extreme example.  It has a huge and
> complicated :set function, and no way to do the same thing outside
> customize.

And how does that rely on the 'saved-value' property?

Luc's 'set-activate' function obeys the 'custom-set' property which is
what :set specifes.  The example I answered manually set the
'saved-value' property which is what customize uses to remind itself
to save the value in .emacs.

Emacs check the 'saved-value' property specifically for
inhibit-startup-echo-area-message to ensure that the variable was
changed by the user, not by a system administrator.

Re: Customize Rogue

[Per Abrahamsen]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> Maybe Customize could be changed to maintain a list of set-activate
> statements instead of the current custom-set-variables thingy.  Then
> people could just copy and paste set-activate statements...

Not with the semantics Luc has, it doesn't do everything
custom-set-variables does.

Splitting custom-set-variables into many seperate forms would be a
good idea though, since it would make it easier to share
customizations.  I.e. "put this into your .emacs at top level" instead
of "merge this into your own custom-set-variables form, or create one
if you don't have it".  It would make the "save customizations"
function somewhat more complex though.

Of course, it would also encourage people even more to put the
statements other places than the top-level of custom-file, which would
be dsirable but hard if not impossible to support in the "save
customizations" function

I believe it was a mistake to save the customizations as Lisp, people
have expectations of what they can do with Lisp code that is
impossible to fullfil from a simple form based interface.

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> In that light, getting a message that says "Value changed
> outside of customize buffer" 

You only get that message if you actually use the Customize form based
interface.  If you use the Customize form based interface, the message
is useful.  If you don't use it, the message is not useful, but you
will not see it either.

> all to do with the fact that I want the "right" to make customize
> believe that I did M-x customize, even if I didn't.

You have that "right" (since you already have code in your .emacs that
do exactly that), but Emacs should have not contain extra code to
support functions that are never useful to any people, but does things
only people who do not know what they are doing believe is a good
idea.

Remember that you have only been able to name a *single* variable
where setting custom-saved manually from .emacs is useful in any
sense, and that variable has been *deliberately* made hard to set from
.emacs.

Emacs should provide functions because they are useful, and not for
any other reasons, including philosophical reasons.

Re: Customize Rogue

[Per Abrahamsen]

Juanma Barranquero <lektu@terra.es> writes:

> On Mon, 10 Mar 2003 18:16:22 -0600 (CST), Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>
>> As opposed to what?
>
> To a disjoint way to interact with Emacs, of course. As it is now, when
> some things can only be set through customize, or are better set through
> it. To me, customize is trying to do way too much (vide the docstring of
> `defcustom') :)

Yes, which is why the ":set" functionality probably shouldn't be
considered part of customize proper, and a "set-activate" function
that obeyed it without setting the 'customized-value' or 'saved-value'
property would be a a good thing for philosophical reasons (and yes, I
believe there are practical reasons as well).

>> It is a complete mystery to me how you can see all kinds of ominous
>> hidden meanings in a straightforward statement like:
>> 
>> "State: this option has been changed outside the customize buffer."

Well, internally it call the variable "rogue", which *does* imply a
moral judgement.  If I had known people would be this touchy, I would
have used another term.

> I suppose I have a hidden, ominous streak...

Yes.  It is very frustrating to have my code not judged by its
functionality, but by supposedly hidden meanings and inferred
philosophical implications.

I'd much rather have it judged by

1) Is it useful to some people?

2) Is it harmful to people who does not use it?

and even

3) Does it use loaded words to describe its function?

>> This is supposed to tell you the current customization status.  If you
>> changed it outside the customize buffer, then why would you want it to
>> give you false information?  That is what it is: information, not a
>> moral judgment.
>
> Well. What is this information for? What am I learning from it?

It means that if you edit the form and push the save button, there is
a chance that it will not have the value you just saved next time you
start Emacs.

Do you think this is useful for the target audience for the form based
interface?

Do you think this will harm people who never see the message because
they never use the form based interface.

> I'm getting redundant info, unless it means

Believe it or not, there are people out there who is not you, and
whose needs differs from you.  Some of the information you see that is
redundant to you is intended for those people who are not you.

I.e. people who might actually press "save" in a Customize buffer.

> understand for customize to be so arrogant if I used a vulgar setq, but
> if I did take the effort to use custom-setq, for *sure* I'd like
> customize to get the message: "No, I didn't, so close your mouth and
> don't ever mention it again, thanks".

So you want customize to lie to you?  You (or some other Lisp package
you may not be aware of) *did* set it outside customize, so all the
potential problems with saving the variable will *still* occur.

In any case, I believe it is always useful to distinguish between
variables that have been saved with the customize form based
interface, and thus make sense to edit from the customize form based
interface, and variables that have been set outside the customize form
based interface, and which is thus (often) does not make sense to save
from the customize form based interface.

The information should be there.  It is true that it is useful for
people who use the customize form based interface to browse
information only, but that interface *is* an editor, not a browser.

Writing an alternative browser interface would be more useful than
complaining that the edit interface provides information that is
useful for people who want to edit.  In fact, a browser-only interface
could be far more lightweight than the editor, especially if it
present values as Lisp expressions.  It could also present the
information more compactly.

> Because I'm fooling it into believing I used it *only* in those cases
> where I don't have the option not to use it (at least, easily). 

Which is exactly *one* variable made *deliberately* hard to set.

> And I don't buy the argument that those cases are bugs that should be
> fixed by providing a convenience function. The very existance of :set,
> :get, :initialize, etc. in the defcustom syntax means that people out
> there will use it as they see fit.

All of these cases are handled by Luc's set-activate.

However, they are still bugs because we have decided they are bugs.
Providing 'set-activate' is a convenient workaround for the bugs,
which may mean the bugs will take longer to get fixed.

I personally believe the advantages of 'set-activate' outweigh the
disadvantages though.

> I know. I haven't said "set-activate" wouldn't be useful (but I agree
> with people who prefer a name like custom-set(q?) or equivalent). I'm
> saying that it should do more.

If it did more, it wouldn't be useful to *any* people (including you).

> Yes, to avoid the "State: " line.

You will still get a "State: " line, the content will just make it
impossible to distinguish the variable with those that are safe to set
from customize.  I.e. all that happens is that you lose information.

> Why? Because I don't believe there are situations where a user, that
> willingly used "set-activate", needs that information.

You are mistaken.  It is quite possible for a user to forget that he
added a set-activate in his .emacs.  It is also possible for the user
to not know that a Lisp package he loaded used set-activate on the
option in question.  I don't believe this, I know this, because I
have done both accidentally with setq, and there is nothing magical
about the name 'set-activate' that will prevent me or others from
doing it with that function.

Re: Customize Rogue

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I believe that this is a good idea and would eliminate the need for
> set-activate, custom-setq or whatever.

It would still be a useful tool for transition from the Customize
form based interface to Lisp, as you would not have to look up every
docstring in order to find what, if any, function you need to call to
get the desired effect.

Of course, for it to be useful for anything (apart from fooling
'inhibit-startup-echo-area-message'), it must *not* set
'custom-saved'.

Re: Customize Rogue

[Juanma Barranquero]

On Wed, 12 Mar 2003 15:19:22 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> Yes, which is why the ":set" functionality probably shouldn't be
> considered part of customize proper, and a "set-activate" function
> that obeyed it without setting the 'customized-value' or 'saved-value'
> property would be a a good thing for philosophical reasons (and yes, I
> believe there are practical reasons as well).

I'm not entirely sure how to view :set functionality, if not a customize
thing. AFAICS, it is something used from defcustom for customize reasons.

> Well, internally it call the variable "rogue", which *does* imply a
> moral judgement.  If I had known people would be this touchy, I would
> have used another term.

I can accept that I'm touchy, but I don't think I've been wrt the use of
words in customize. I think I've complained about exactly *one* message,
and on the grounds that I consider it redundant.

Well, to be honest, I complained too about the wording of "transition
tool". But that was no code, just a message describing a new command.

> Yes.  It is very frustrating to have my code not judged by its
> functionality, but by supposedly hidden meanings and inferred
> philosophical implications.

I don't ever remember judging your code. I complained about a thing that
I don't like. I've also said that I don't like customize, *but* I've
also said that I understand pretty well that it is useful and liked by
many people.

> 1) Is it useful to some people?

Sure.

> 2) Is it harmful to people who does not use it?

Some things are "harmful" to me if forced to use customize. Of course is
not your fault that people :set's things that cannot be easily invoked
through a lisp function. But it is a consequence of customize
nonetheless.

> It means that if you edit the form and push the save button, there is
> a chance that it will not have the value you just saved next time you
> start Emacs.
> 
> Do you think this is useful for the target audience for the form based
> interface?

Yes. The target audience would *not* use custom-setq. I would.

> Believe it or not, there are people out there who is not you,

I fail to see how did I imply otherwise. It is very difficult to discuss
what *I* do find wrong in customize without using 1st person pronouns.
Sorry if English limitations (or my lack of skills) is disturbing you.

> Some of the information you see that is
> redundant to you is intended for those people who are not you.

Yes. That's why I've suggested that should be a way for them to get it,
and for me not to get it. And you're insisting that I should because
they should.

> So you want customize to lie to you?  You (or some other Lisp package
> you may not be aware of) *did* set it outside customize, so all the
> potential problems with saving the variable will *still* occur.

If I do custom-setq, I'm setting it "outside the customization buffer",
but *most certainly not* "outside of customize", so what I really want
is customize to stop lying to me.

> Which is exactly *one* variable made *deliberately* hard to set.

No. And sorry, but I'm not going to repeat the arguments.

> All of these cases are handled by Luc's set-activate.

Sure. But I'd still get the message in M-x customize.

> However, they are still bugs because we have decided they are bugs.
> Providing 'set-activate' is a convenient workaround for the bugs,
> which may mean the bugs will take longer to get fixed.

There's, to this point, nothing in the documentation to suggest that
using :set for complex things not available through a function interface
is a bug, or wrong, or discouraged.

> If it did more, it wouldn't be useful to *any* people (including you).

Excuse me if I disagree.

> You will still get a "State: " line, the content will just make it
> impossible to distinguish the variable with those that are safe to set
> from customize.  I.e. all that happens is that you lose information.

Only if they aren't safe to use from customize. They shouldn't. A
custom-setq'd variable should be saved as a custom-setq. When I edit the
value, I'm *seeing* what it is. If I "lose" it is because I'm actively
modifying it.

> You are mistaken.  It is quite possible for a user to forget that he
> added a set-activate in his .emacs.

And so what? If he changes it, what's wrong with it?

                                                           /L/e/k/t/u

Re: Customize Rogue

[Juanma Barranquero]

On Wed, 12 Mar 2003 14:23:19 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> Remember that you have only been able to name a *single* variable
> where setting custom-saved manually from .emacs is useful in any
> sense

No, you're wrong. Every variable I set in my .emacs and gets a message
through customize is one where silencing the message would be useful.
That you don't consider it so does not make it less true for me.

                                                           /L/e/k/t/u

Re: Customize Rogue

[Stefan Monnier]

>    Most uses of :set are for things like minor-mode (where using
>    define-minor-mode has the advantage of providing a standard way
>    to deal with it), the others should be replaced.
> 
> Since every Lisp symbol can at the same time be a variable and a
> function, it would have been nice if every variable my_favorite_symbol
> with a :set function, would have an associated function
> my_favorite_symbol and if that function behaved in exactly the same
> way as minor mode functions for variables of boolean type and if, for
> non-boolean type variables, (my_favorite_symbol value) would be
> equivalent with setting the variable my_favorite_symbol to VALUE
> through customize:
> 
> :set #'funcall
> 
> But I guess it is much too late to enforce anything like this, even if
> it were deemed desirable.

Hey, now, there's a great idea.
We could add some code in defcustom so that it complains when the
value of :set is not a symbol (which would ensure that whatever the
:setter is, it can always be called easily from elisp).


	Stefan

Re: Customize Rogue

[Richard Stallman]

    PS: How about we add `write-watchers' to variables ?  These would be
	hooks that get called when a specific variable is `setq'd.
	It'd have "zero performance impact" if we put it in the "setq-ing
	a read-only variable" error handling path.

I don't like the idea of changing the semantics of Lisp variables
in this way.

Re: Customize Rogue

[Luc Teirlinck]

Richard Stallman wrote:

   I can see one possible purpose for a function that would be called
   custom-setq: a way to set a customizable variable and tell Custom to
   regard it as "set by Custom" rather than as "set outside of Custom".

Telling Custom that a variable was "set by Custom" by setting
'custom-saved will make Custom and its users believe that the variable
is under Custom's control and that changing the variable using Custom
will work.  That is OK if the variable was set in such a way that this
is really true, as can currently be achieved by manually editing
`custom-set-variables' or `custom-set-faces' (which will automatically
also set 'custom-saved).  As long as Custom sets its variables through
these two forms, setting 'custom-saved manually for variables set in
some other way will produce bugs and create severe problems for users
who either always or sometimes use Custom to set variables (as
opposed to as a mere browser).

   It might be nice if Custom wrote out a series of custom-setq 
   calls into .emacs, one per variabl, rather than writing a single
   sexp that sets all the variables.

That would indeed change the situation.  In this situation a user-set
custom-setq would indeed be indistinguishable from a Custom set one
and hence would and should set 'custom-saved.  This is not the current
situation however.  It seems to me that changing this situation can
not be done in a simple function with a few lines of code.  To me it
seems to require a careful rewrite of Custom.  Per touched on this
possibility in another message.  Per is way more qualified than me to
judge the feasibility of actually doing this.

Sincerely,

Luc.

Re: Customize Rogue

[David Masterson]

>>>>> Per Abrahamsen writes:

> Juanma Barranquero <lektu@terra.es> writes:

>> In that light, getting a message that says "Value changed outside
>> of customize buffer"

> You only get that message if you actually use the Customize form
> based interface.  If you use the Customize form based interface, the
> message is useful.  If you don't use it, the message is not useful,
> but you will not see it either.

One potential you might be missing is that other Emacs "packages"
could "dump" a "customization" for a user.  That is, during the
installation of a package, the package may create a (set of) custom
calls that fit the package to the environment of the user.  Later, if
the user chooses to (re-)customize his Emacs, would he be "confused"
by the message?  (too many quotes :-\ )

> Emacs should provide functions because they are useful, and not for
> any other reasons, including philosophical reasons.

If a function causes confusion in it's results, it will be avoided
regardless of its usefulness.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Customize Rogue

[Luc Teirlinck]

Per Abrahamsen wrote:
   
   All of these cases are handled by Luc's set-activate.

   However, they are still bugs because we have decided they are bugs.
   Providing 'set-activate' is a convenient workaround for the bugs,
   which may mean the bugs will take longer to get fixed.

I believe the latter is the reason why Richard (and others) are not
terribly enthusiastic about set-activate, even in renamed form.
(Assuming I understood correctly.)

   I personally believe the advantages of 'set-activate' outweigh the
   disadvantages though.

Maybe these advantages can be achieved in other ways.  I made a
proposal to suggest that the function used by :set should normally not
only be named, but actually use the same symbol as the variable.  In
other words, normally the :set function would be either set-default,
funcall or a slight variation on funcall for variables of boolean
type, which would behave exactly like minor modes.  After sending that
message, I saw that you were not on the CC list, but I assume that you
read emacs-devel.

Sincerely,

Luc.

Re: Customize Rogue

[Luc Teirlinck]

Stefan Monnier wrote:

   We could add some code in defcustom so that it complains when the
   value of :set is not a symbol (which would ensure that whatever the
   :setter is, it can always be called easily from elisp).

What would you do with minor-mode type variables for which
define-minor-mode currently produces:

:set
    (lambda
      (symbol value)
      (funcall symbol
             (or value 0)))

to replace a value of nil of the variable by 0?  Name that lambda
function for internal use by defcustom?

Sincerely,

Luc.

Re: Customize Rogue

[Richard Stallman]

    We could add some code in defcustom so that it complains when the
    value of :set is not a symbol (which would ensure that whatever the
    :setter is, it can always be called easily from elisp).

I think there are many simple :set lambdas that are ok and need
not be changed.

Re: Customize Rogue

[Juanma Barranquero]

On Thu, 13 Mar 2003 12:32:32 +0100, Per Abrahamsen <abraham@dina.kvl.dk> wrote:

> It is not possible to argue rationally about purely subjective
> matters.

User interface issues are mostly subjective matters (notice I said
"mostly"). You seem to believe otherwise.

                                                           /L/e/k/t/u

Re: Customize Rogue

[Per Abrahamsen]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I am not sure you understand what I meant though, 

I didn't.

Re: Customize Rogue

[David Masterson]

>>>>> Per Abrahamsen writes:

> David Masterson <David.Masterson@synopsys.com> writes:

>> John Wiegley has a tool called initsplit.el on his web-site for
>> breaking customizations into multiple files. 

>> However, you've got a good point that I can't think how customize
>> would be able to find and set the customizations once they've been
>> "split" into multiple locations -- regardless whether the split was
>> done in customize fashion (a la initsplit.el) or via setq like
>> things (a la set-activate).

> Uh, does initsplit.el use multiple custom-set-variables?  That is
> guarenteed to cause problems whenever the user tries to modify the
> variables.  If so, it *really* should use setq (or a set-activate
> woralike) instead.

Yes, it does appear that initsplit.el uses multiple, package specific,
custom-files which (I suspect) the package is expected to load as
needed.  For instance, he splits his Gnus customizations out into his
gnus-init-file.

BTW, initsplit.el plus a couple of examples of its use are at:

  http://www.gci-net.com/users/j/johnw/emacs.html

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Customize Rogue

[Luc Teirlinck]

Per Abrahamsen wrote:
   
   Uh, does initsplit.el use multiple custom-set-variables?  That is
   guarenteed to cause problems whenever the user tries to modify the
   variables.  If so, it *really* should use setq (or a set-activate
   woralike) instead.

   Maybe the existence if initsplit.el is an argument for including
   set-activate in Emacs, to make it easier to write such tools.  It is
   hard for automated tools to read doctrings to find the proper Lisp
   function to set the variable.

Even if the current custom-set-variables and custom-set-faces forms
would be replaced by a series of custom-setq calls (which would be a
big plus for people who like to combine use of Custom with Lisp based
customizations) there still would, as is apparent from David's
messages, be a legitimate need to perform customizations that are
outside of Custom's control (and hence could not be done using
custom-setq).  If done by hand, it is sufficient if a Lisp alternative
is available and mentioned in the documentation string, although it
would help if the alternative was a function with the same name as the
variable (as is the case for minor modes), to avoid having to remember
two different names for exactly the same functionality and to
eliminate the need for a C-h v.

I do not know whether it would be possible to standardize such a naming
convention sufficiently to make it safe for automated use.  If not,
then I believe that there is indeed a need for set-activate.  It is
possible to abuse that function.  But the documentation string could
make clear what it is intended to be used for and what not.  In
particular, the documentation string would clearly state that it is
definitely not meant to set parameters from Lisp code, but instead for
customizations that are outside Custom's control, mainly in automated
use.  It is a very small function, it is not exactly going to "bloat"
custom.el.

Sincerely,

Luc.

Re: Customize Rogue

[Richard Stallman]

    What I propose is that, if somebody writes a defcustom for a variable
    `foo' with a :set function, then, unless there already is an obvious
    well-known Lisp alternative, in which case there is no problem, the
    author of the defcustom should provide a function `foo' such that
    (foo value) is equivalent with setting foo to VALUE using defcustom.

This naming convention would be a bad one.  A name that fits well
for the variable would be wrong for the function.

    I don't think that is reasonable, the function signature expected by
    :set is slightly different from the the function signature that would
    be most natural from Lisp.

That is true also.  In fact

      (decustom foo-bar-mode nil
	"Foo bar minor mode.
      Must be set with (foo-bar-mode VALUE) or through Customize."
	:type 'boolean
	:set (lambda (symbol value) (foo-bar-mode value)))

is a good example of a simple lambda that is reasonable to use in a :set.

Re: Customize Rogue

[David Masterson]

>>>>> Luc Teirlinck writes:

> I downloaded initsplit.el.  I did not really read through the code.
> But does initsplit-customizations-alist not tell initsplit.el where
> everything is supposed to be?  If the user tries to fool the
> automated tool, the automated tool looses, no doubt about that.  Now
> initsplit somehow has to tell this to Custom through advice, hooks,
> whatever.  I am not interested in personally writing such a tool,
> but it does not seem theoretically impossible.  Whether it is easy
> is another matter.

I just took a look at it again (it's been awhile).  The alist does
tell initsplit where everything is supposed to be (based upon regexps
against the defcustom variables).  There is also a write-file-hook
that checks to see if the file that is being written is a custom-file
or user-init-file and, if so, runs it through initsplit.  The comment
says (I think) that, if you run Custom after initsplit, the new
customizations (which could include updates to old ones) will again be
put into the custom-file, but, because of the write-file-hook,
initsplit will put it back where it belongs according to the alist.
The only issue is that you have load all the split custom-files in
your .emacs to ensure that all the customizations are known to Custom.

John apparently uses this to split out Gnus and Viper customizations,
but I guess you could apply it to VM, Rmail, JDE, and so on.  Hmmm,
maybe I ought to look at using this again...  ;-)

What was the issue that Per mentioned about multiple calls to
custom-set-variables again?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Customize Rogue

[John Wiegley]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> David Masterson <David.Masterson@synopsys.com> writes:
>
>> John Wiegley has a tool called initsplit.el on his web-site for
>> breaking customizations into multiple files.
>
> Fine, but the user should not then try to change these values
> permanently through the Customize interface, as this will have no
> effect.  Therefore the 'saved-value' attribute *not* be set for
> these values, which was what I stated in the message you replied
> to.

There seems to be confusion about what initsplit.el does.

It is in fact possible to use M-x customize after things have been
split by initsplit.el.  What it does is let Emacs write all of the
customizations to a single custom-set-variables form in .emacs, then
it walks through that form, stripping out everything it thinks should
go elsewhere, inserting the relevant forms into those elsewhere's
along the way.

So that I still use M-x customize to customize gnus, even though I
have all of my gnus/mail/supercite/mailcrypt, etc., customizations
being saved in .gnus.el.  Add the auto-byte-compilation feature of
initsplit.el, and I've yet to run into problems.

John

Re: Customize Rogue

[David Masterson]

>>>>> John Wiegley writes:

> So that I still use M-x customize to customize gnus, even though I
> have all of my gnus/mail/supercite/mailcrypt, etc., customizations
> being saved in .gnus.el.  Add the auto-byte-compilation feature of
> initsplit.el, and I've yet to run into problems.

What was the motivation for writing initsplit.el?  Was there more to
it than just "to be tidy"?

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Customize Rogue

[John Wiegley]

David Masterson <David.Masterson@synopsys.COM> writes:

> The only issue is that you have load all the split custom-files in
> your .emacs to ensure that all the customizations are known to
> Custom.

Actually, you do not.  Say you split your settings into .emacs, file
A and file B.  If only .emacs has been loaded, then the
customizations in file A haven't been loaded, *so they won't be
written out when you save your customizations*.  They will be "out of
the loop".

If you do load them, then when you save the customizations, it will
split them back out to whatever files were loaded.  It is a very
straightforward concept, but turns out to work very well.  In three
years of usage, I have not found any complications.

> What was the motivation for writing initsplit.el?  Was there more
> to it than just "to be tidy"?

Nope, just tidyness.  I love things to be beautiful.

John