Re: CT unit to drill on Mars, Revenue Up 200% - Ref. vj

Re: Custom type for "&rest props" style arguments?

Reiner Steib wrote:
> Hi,
> 
> I'd like to have a customizable list as follows:
> 
> (defcustom rs-test-list
>   '((gnus-summary-save-newsrc "save" nil :visible nil)
>     (gnus-summary-print-article "print")
>         (gnus-summary-edit-article
>      "search" nil :visible (not (gnus-group-read-only-p))))
>   "List of tool bar function items.
> 
> The first element of each item must be a menu command.  The
> second must be an icon file name.  The first two elements are
> required, all other are optinal.  The third argument is a keymap
> or nil (default keymap).  The forth and all following arguments
> are passed as the PROPS argument to `tool-bar-local-item'."
>   :type '(repeat (list (function :tag "Menu Command")
> 		       (string   :tag "Icon file")
> 		       (choice (const :tag "Default map" nil)
> 			       (sexp :tag "Other map"))
> 		       (choice :tag "Properties"
> 			       (const :tag "None" nil)
> 			       (sexp :tag "Other")))))
> 
> My problem is how to express "the forth and all following arguments"
> as a custom type.  My code results in a "mismatch" when calling `M-x
> customize-variable RET rs-test-list RET'.  The "Properties" are
> supposed to be passed as the PROPS argument to `tool-bar-local-item':
> 
> ,----[ <f1> f tool-bar-local-item RET ]
> | tool-bar-local-item is a compiled Lisp function in `tool-bar.el'.
> | (tool-bar-local-item ICON DEF KEY MAP &rest PROPS)
> | 
> | Add an item to the tool bar in map MAP.
> | ICON names the image, DEF is the key definition and KEY is a symbol
> | for the fake function key in the menu keymap.  Remaining arguments
> | PROPS are additional items to add to the menu item specification.  See
> | Info node `(elisp)Tool Bar'.  [...]
> `----
> 
> Here is an attempt for a defcustom of a single element:
> 
> (defcustom rs-test-item
>   '(gnus-summary-save-newsrc "save" nil :visible nil) ;; -> mismatch
>   ;; '(gnus-summary-print-article "print") ;; -> works
>   ;; '(gnus-summary-edit-article
>   ;;   "search" nil :visible (not (gnus-group-read-only-p))) ;; -> mismatch
>   "A single item for testing."
>   :type '(list (function :tag "Menu Command")
> 	       (string   :tag "Icon file name")
> 	       (choice (const :tag "Default map" nil)
> 		       (const :tag "No menu" t)
> 		       (sexp :tag "Other map"))
> 	       (choice :tag "Properties"
> 		       (const :tag "None" nil)
> 		       (sexp  :tag "Other"))))
> 
> (Instead of `:visible test-function' there could also arbitrary other
> arguments accepted by `tool-bar-local-item' such as `:help "Do
> this"')
> 
> Any hints?

I think you need the list widget's :inline keyword, described in the
"composite" node of the widget manual, perhaps like this:

(repeat :tag "Properties" :inline t
         (list :inline t
               ;; is there a keyword type, instead of symbol?
               (symbol :tag "Property") (sexp :tag "Value")))

--

-- 
Kevin Rodgers

Change Alt+Tab

How could I change Alt+Tab into an other key binding?
The Alt+Tab is reserved by the window manager.

I want all the editor modes recognize the new key binding
as the Alt+Tab combination.

Anakreon.

Re: Customize Rogue

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

    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

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

>>>>> Per Abrahamsen writes:

> David Masterson <David.Masterson <at> 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 <teirllm <at> dms.auburn.edu> writes:

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

I didn't.

Re: Customize Rogue

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

Luc Teirlinck <teirllm <at> 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 <lektu <at> terra.es> writes:

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