[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Customize Rogue

From: Juanma Barranquero
Subject: Re: Customize Rogue
Date: Tue, 11 Mar 2003 02:07:44 +0100

On Mon, 10 Mar 2003 18:16:22 -0600 (CST), Luc Teirlinck <address@hidden> 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') :)

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

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

> 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? If I set
variable-x in my .emacs and then enter customize and get "variable-x set
outside customize buffer", I'm getting redundant info, unless it means
"you shouldn't do that", or "that could cause problems", or "you aren't
supposed to do that", or perhaps "you'd better set it through customize
so things are properly done", or maybe "There Are Things You Don't Know
About Setting This Variable"... If the *only* meaning is "You haven't
forgotten you set it up in your .emacs, did you?", then I could
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".

> If you intend to use the customize buffer to change the value (as most
> people do when they use M-x customize-variable), then you are doing
> something wrong, and should be alerted to this.

I'd bet I'm in a minority, but I mostly enter customize to peruse a
group and get a feeling of what kinds of options there exists (like
taking a look into the source module, but easier if the defcustoms are
scattered inside a large module, or several). I'd much prefer, *if* I
decide to change the value in customize *and* save it, to get at this
moment a message asking if I want to preserve my custom-setq, or
surrender my existing customization to the customize ways.

> I believe you want customize to respect your right not to use it.  How
> can it possibly do that if you fool it into believing that you do use it?

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). Rest
assured that if calling a function to set a mode will do, I won't waste
the effort of setting the variable (via custom-setq or M-x customize).

But what about those cases where you either use customize, or delve into
the source to know what to do (like `utf-fragment-on-decoding',
`utf-translate-cjk', `bs-default-sort-name', `image-file-name-extensions',

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.

> Yes, but this is exactly the problem set-activate is trying to
> address.

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.

> Why?  To avoid the above "State: " line?  As pointed out, there are
> situations where the user needs that information.

Yes, to avoid the "State: " line. Why? Because I don't believe there are
situations where a user, that willingly used "set-activate", needs that
information. I'm extremely inclined to believe, thought, that there are
such situations when a user used simply `setq'.

> You can easily achieve that effect by putting the custom-set-variables
> and custom-set-faces forms early in your .emacs, before any
> set-activate forms.

I'm more radical. I have:

 (setq custom-file "~/.emacs.custom")
 (when (file-readable-p custom-file)
   (warn "Customization file %s found" custom-file))

in my .emacs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]