Re: Customize Rogue

Juanma Barranquero <[email protected]> writes:

> On Mon, 10 Mar 2003 18:16:22 -0600 (CST), Luc Teirlinck <[email protected]> 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.