Feedback on new Customization

Feedback on new Customization

[Lance A. Brown]

I *REALLY* like it.

On my 100Mhz SGI R4000 Indy w/ GNU Emacs 19.34b things take
irritatingly long to happen.  Opening up a customization section is
fast enough, but displaying a face or list of faces takes long enough
to be really irritating.  I thought the elisp files might not be
byte-compiled but they are.  I guess it just takes a bit of time to
process the customizations.

Is the 'Set Default' button at the bottom of the page supposed to Set
Default everything or just the objects in the top level heirarchy?  I
have to select 'Set Default' on all indented objects that I've changed
in order to have the new defaults set.

Is the 'Set Default' button supposed to apply the changes I've made
when I select it?  I have to 'M-x load-file .custom.el' in order to
get my new defaults to activate.

Thanks,
  --[Lance]

Re: Feedback on new Customization

[Richard Pieri]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "LAB" == Lance A Brown <labrown@splat.niehs.nih.gov> writes:

LAB> On my 100Mhz SGI R4000 Indy w/ GNU Emacs 19.34b things take
LAB> irritatingly long to happen.

I have no pity for you, me using my 50Mhz, almost bare-bones
SPARCclassic, or my other machine, an i486-DX2/50.

But maybe you should compile Emacs using a decent C compiler like GCC
with maximal optimizations like -O3.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMlqFS56VRH7BJMxHAQECJQP9Fqe0TheH4WbLNMH+axN1Q9lbmE0oO0nf
FONowspqyWd3rzSlueFYAL86BXebtZ08RfSTNGBtYDgxDIh4L8aiPxtV/6K1O2UI
ad6vQkylWnuAV/qOZFWOyCWG67zc3nxpXax9jjUD2RItPROOQh5S5Jb04rDI9YK2
iUceHQxMAgM=
=sz5q
-----END PGP SIGNATURE-----
-- 
Richard Pieri/Information Services \ Curiosity never killed anything, except
<ratinox@unilab.dfci.harvard.edu>   \ maybe a few hours. -A cat's guide to life
http://www.dfci.harvard.edu/         \ 

Re: Feedback on new Customization

[Per Abrahamsen]

"Lance A. Brown" <labrown@splat.niehs.nih.gov> writes:

> I *REALLY* like it.

Thanks.

> On my 100Mhz SGI R4000 Indy w/ GNU Emacs 19.34b things take
> irritatingly long to happen.  Opening up a customization section is
> fast enough, but displaying a face or list of faces takes long enough
> to be really irritating.  I thought the elisp files might not be
> byte-compiled but they are.  I guess it just takes a bit of time to
> process the customizations.

Well, it takes up to 2 seconds to display the most complicated
structures on my ~100Mhz microsparc, which I believe is equivalent to
100Mhz 486 and quite a bit slower than your Indy.

The code has not been profiled yet, so there might be some savings
there.  However the library was not designed for speed.  Not that I
doesn't like speed, but part of the code stretches my capability as a
programmer, so I have had to concentrate my effort on making the
design and code as clear as possible in order to be able to maintain
it.

> Is the 'Set Default' button at the bottom of the page supposed to Set
> Default everything or just the objects in the top level heirarchy?  I
> have to select 'Set Default' on all indented objects that I've changed
> in order to have the new defaults set.

The `Set Default' button should set the default for all the options
that are currently marked as modified (i.e. [*]).

You also need to save the settings, either by pushing `Save', or
answering `yes' to the question on whether you want to save the
customizations when you leave emacs.

> Is the 'Set Default' button supposed to apply the changes I've made
> when I select it?  I have to 'M-x load-file .custom.el' in order to
> get my new defaults to activate.

The settings are saved in `.emacs', `.custom.el' is no longer used.

Re: Feedback on new Customization

[Raja R Harinath]

I have other problems with custom.  It looks like `defcustom' doesn't
work when loaded from `.emacs'.

I have a `gnus-no-server' in my `.emacs', and it immediately starts
complaining.  Basically, the problem is that `defcustom' symbols aren't
being bound.  When I do a `load-library' on the appropriate file, things
work fine.

A case to point, I have `gnus-use-grouplens', which makes Gnus load
`gnus-gl', which requires `gnus-score', which uses `gnus-read-mark'.
This hiccups, since `gnus-read-mark' isn't bound.  I check the
`features', and, yes `gnus-sum' (where `gnus-read-mark' is declared) has
been loaded.  I do M-x load-library gnus-sum, and restart gnus.  It
passes that point, hits `gnus-article-save-directory', and dies.  Well,
I check features: `gnus-art' is loaded too.  I do M-x load-library
gnus-art, restart gnus, and all works well.

- Hari

-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Problems w/ rgnus-0.49 and tm-7.89 (was Re: Feedback on new Customization)

[Raja R Harinath]

Raja R Harinath <harinath@cs.umn.edu> writes:
> I have other problems with custom.  It looks like `defcustom' doesn't
> work when loaded from `.emacs'.
> 
> I have a `gnus-no-server' in my `.emacs', and it immediately starts
> complaining.  Basically, the problem is that `defcustom' symbols aren't
> being bound.  When I do a `load-library' on the appropriate file, things
> work fine.
> 
> A case to point, I have `gnus-use-grouplens', which makes Gnus load
> `gnus-gl', which requires `gnus-score', which uses `gnus-read-mark'.
> This hiccups, since `gnus-read-mark' isn't bound.  I check the
> `features', and, yes `gnus-sum' (where `gnus-read-mark' is declared) has
> been loaded.  I do M-x load-library gnus-sum, and restart gnus.  It
> passes that point, hits `gnus-article-save-directory', and dies.  Well,
> I check features: `gnus-art' is loaded too.  I do M-x load-library
> gnus-art, restart gnus, and all works well.

I couldn't have been more wrong.

A bit of snooping told me this:  I use tm-7.89, which includes
`gnus-mime.el'.  gnus-mime checks if `gnus-load' has been loaded (as a
test for Red Gnus), and if it is absent, it "helpfully" provides the
features gnus-sum and gnus-art, thus preventing the loading of the
actual files later.  And rgnus-0.49 does away with `gnus-load'.

- Hari

-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

Re: Problems w/ rgnus-0.49 and tm-7.89 (was Re: Feedback on new Customization)

[Jan Vroonhof]

Raja R Harinath <harinath@cs.umn.edu> writes:

> A bit of snooping told me this:  I use tm-7.89, which includes
> `gnus-mime.el'.  gnus-mime checks if `gnus-load' has been loaded (as a
> test for Red Gnus), and if it is absent, it "helpfully" provides the
> features gnus-sum and gnus-art, thus preventing the loading of the
> actual files later.  And rgnus-0.49 does away with `gnus-load'.

<GRIPE>
I think it is a tm problem. It really tries to support to many
versions of gnus. It should just hook itself in to the appropriate
hooks and that's it. I think the relevant hooks have been there and
remained the same for quite some time now,

The sametyhing is true for the installation procedure. It is a pain in
the ass because it dissables loading of all system init files thereby
throwing away information about installed software and then
wants the paths to all relevant reading software to figure out what
versions to have.

<\GRIPE>

Jan

P.S. The last version tm version I have is from june where I just
didn't give it any information about gnus and did the hooking myself.
I am perfectly happy with it now. tm is a great piece of software, it
is really is a pittyit tries to be too smart.

Re: Feedback on new Customization

[Wesley.Hardaker]

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

> "Lance A. Brown" <labrown@splat.niehs.nih.gov> writes:
> 
> > I *REALLY* like it.

Looks cool...  I like it too, but I don't mind editing straight code
so its more questionable for me simply because its so slow...
However, very nicely done!

> The settings are saved in `.emacs', `.custom.el' is no longer used.

You know, I hate things that modify my .emacs...  I hate using the
'save options' menu item for that reason.  Oh well, someday I had to
give in (I did so for 'customize'...).  

Anyway, my last comment is that there are so many variables in gnus
that the customize buffer is massive.  It would be really nice to make
it a bit more hierarchial.  I don't know how difficult this is to do
as I haven't glanced at the code at all.  However, it would be nice to
have some more 'topics', I guess they're called, to seperate the
different sections a bit more.  IE, under gnus-summary you could have
it divided a bit more into 'threads', 'hooks', 'display', 'scoring',
etc...  A decent plan would be to follow the info file(s) hierarchy,
which would make using custom really cool if you were reading the
manual at the same time!

Anyway, its probably too late to start adding more hierarchy huh?

Good job though!
Wes

Re: Feedback on new Customization

[Per Abrahamsen]

>>>>> "WH" == Wesley Hardaker <Wesley.Hardaker@sphys.unil.ch> writes:

WH> You know, I hate things that modify my .emacs...  I hate using the
WH> 'save options' menu item for that reason.  Oh well, someday I had to
WH> give in (I did so for 'customize'...).  

RMS wanted it that way.  You can customize it though, by setting the
`custom-file' option.  You will then have to load the new custom file
from `.emacs' explicitly.

WH> However, it would be nice to have some more 'topics', I guess
WH> they're called, to seperate the different sections a bit more.

They are called customization groups.

WH> I don't know how difficult this is to do as I haven't glanced at
WH> the code at all.

I think you will find the code for adding customization support pretty
intuitive.  Maybe you could try to add customization support to
smiley.el?  I don't touch the files that don't have Lars as the
primary author, and would really appreciate if someone else would try
to use the custom API before it gets added to Emacs.

WH> IE, under gnus-summary you could have it divided a bit more into
WH> 'threads', 'hooks', 'display', 'scoring', etc...  

Yes.  I have just basically created one group per lisp file, since
that was the easiest to do.  But I hope someone will organize it a bit
further. 

WH> A decent plan would be to follow the info file(s) hierarchy, which
WH> would make using custom really cool if you were reading the manual
WH> at the same time!

Yes it is.  I also want to be able to attach info-links and perhaps
url-links to each option or group, but haven't figured out how to do
that without cluttering up the display even more.

I already dislike that the help button and the state button look too
similar, and too much like checkboxes.  How and where would a info
button fit?  And additionally, you might want to have multiple info
and url buttons.

At some point, you should be able to edit the options directly in the
online manual.

WH> Anyway, its probably too late to start adding more hierarchy huh?

No, it is quite easy to change.  You can also have the same options
appear in multiple groups, so there could be a `gnus-visual' group
containing all the faces.

Re: Feedback on new Customization

[Brent B. Powers]

Per Abrahamsen writes:
 > From: Per Abrahamsen <abraham@dina.kvl.dk>
 > To: ding@ifi.uio.no
 > Subject: Re: Feedback on new Customization
 > Date: 09 Oct 1996 15:45:04 +0200
 > 
 > 
 > >>>>> "WH" == Wesley Hardaker <Wesley.Hardaker@sphys.unil.ch> writes:
 > 
 > WH> You know, I hate things that modify my .emacs...  I hate using the
 > WH> 'save options' menu item for that reason.  Oh well, someday I had to
 > WH> give in (I did so for 'customize'...).  
 > 
 > RMS wanted it that way.  You can customize it though, by setting the
 > `custom-file' option.  You will then have to load the new custom file
 > from `.emacs' explicitly.

Wouldn't it be lovely if one could have a custom-file attached to
particular customization groups? {ahem, hint, hint}  In that way, I
could have my gnus stuff go to either .custom or .gnus, my
customization stuff go to .custom, et alia

 > 
 > WH> However, it would be nice to have some more 'topics', I guess
 > WH> they're called, to seperate the different sections a bit more.
 > 

Re: Feedback on new Customization

[Per Abrahamsen]

"Brent B. Powers" <powers@ml.com> writes:

> Wouldn't it be lovely if one could have a custom-file attached to
> particular customization groups?

That would be a major bother.

Re: Feedback on new Customization

[William Perry]

Brent B. Powers writes:
>Per Abrahamsen writes:
> > From: Per Abrahamsen <abraham@dina.kvl.dk>
> > To: ding@ifi.uio.no
> > Subject: Re: Feedback on new Customization
> > Date: 09 Oct 1996 15:45:04 +0200
> > 
> > 
> > >>>>> "WH" == Wesley Hardaker <Wesley.Hardaker@sphys.unil.ch> writes:
> > 
> > WH> You know, I hate things that modify my .emacs...  I hate using the
> > WH> 'save options' menu item for that reason.  Oh well, someday I had to
> > WH> give in (I did so for 'customize'...).  
> > 
> > RMS wanted it that way.  You can customize it though, by setting the
> > `custom-file' option.  You will then have to load the new custom file
> > from `.emacs' explicitly.
>
>Wouldn't it be lovely if one could have a custom-file attached to
>particular customization groups? {ahem, hint, hint}  In that way, I
>could have my gnus stuff go to either .custom or .gnus, my
>customization stuff go to .custom, et alia

  Ohhh ohhh - I like this idea.

-Bill "Thinking about making W3 use defcustom" Perry

Re: Feedback on new Customization

[Per Abrahamsen]

William Perry <wmperry@aventail.com> writes:

> Brent B. Powers writes:
>
> >Wouldn't it be lovely if one could have a custom-file attached to
> >particular customization groups? {ahem, hint, hint}  In that way, I
> >could have my gnus stuff go to either .custom or .gnus, my
> >customization stuff go to .custom, et alia
> 
>   Ohhh ohhh - I like this idea.

Guess I have to explain *why* it would be a major bother, then. 

Using groups would be the wrong mechanism.  Each customization option
can belong to any number of groups, from zero and upward.  The same is
true for the groups, so the result is not a nice hierarchy, but a
directed graph.  It can even be cyclic.

One add an extra keyword argument to defcustom and defface indicating
for each option which file they belong to, but that would be a lot of
extra work for the customizer, for no gain I can see.

> -Bill "Thinking about making W3 use defcustom" Perry

Are you willing to make Red Gnus a prerequisite for w3?

I'm not changing AUC TeX until Red Gnus has become Gnus 5.5.

Re: Feedback on new Customization

[William Perry]

Per Abrahamsen writes:
>
>William Perry <wmperry@aventail.com> writes:
>
>> Brent B. Powers writes:
>>
>> >Wouldn't it be lovely if one could have a custom-file attached to
>> >particular customization groups? {ahem, hint, hint}  In that way, I
>> >could have my gnus stuff go to either .custom or .gnus, my
>> >customization stuff go to .custom, et alia
>> 
>>   Ohhh ohhh - I like this idea.
>
>Guess I have to explain *why* it would be a major bother, then. 
>
>Using groups would be the wrong mechanism.  Each customization option
>can belong to any number of groups, from zero and upward.  The same is
>true for the groups, so the result is not a nice hierarchy, but a
>directed graph.  It can even be cyclic.
>
>One add an extra keyword argument to defcustom and defface indicating
>for each option which file they belong to, but that would be a lot of
>extra work for the customizer, for no gain I can see.
>
>> -Bill "Thinking about making W3 use defcustom" Perry
>
>Are you willing to make Red Gnus a prerequisite for w3?

  Well, it _is_ beta. :)

-Bill P.

Re: Feedback on new Customization

[Wesley.Hardaker]

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

> Using groups would be the wrong mechanism.  Each customization option
> can belong to any number of groups, from zero and upward.  The same is
> true for the groups, so the result is not a nice hierarchy, but a
> directed graph.  It can even be cyclic.

Speaking of groups...

One of the problems with customization as exsists at the moment is
that you won't see new options until the appropriate file is
loaded...  IE, until a function is actually called and autoload loads
the file, the customization vars aren't found for that section.  

The only solution I can see for this is to define the groups in a
different file (all of them in one maybe) and then tell each group
which file to load when its visiblity is toggled...  Ugly...  Hard to
implement...  Makes you keep track of files when you shouldn't...
Bad...

Any other ideas?
Forget it?
Wes

Re: Feedback on new Customization

[Per Abrahamsen]

Wesley.Hardaker@sphys.unil.ch writes:

> The only solution I can see for this is to define the groups in a
> different file (all of them in one maybe) and then tell each group
> which file to load when its visiblity is toggled...  Ugly...  Hard to
> implement...  Makes you keep track of files when you shouldn't...
> Bad...

No, it is not difficult.  I plan to it like this:

	;;; In the file gnus-foo.el
	
	;;;###autoload
	(defgroup gnus-foo nil
	  "Foos for gnus"
	  :group 'gnus
	  :file "gnus-foo")
	
The ;;;###autoload is a standard emacs mechanism that ensures the
following declaration is always loaded. 

Re: Feedback on new Customization

[Wesley.Hardaker]

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

> RMS wanted it that way.  You can customize it though, by setting the
> `custom-file' option.  You will then have to load the new custom file
> from `.emacs' explicitly.

Thanks.  I found this right after sending that last message...

I'll refrain from commenting on RMS dictatorship.  Opps.  Too late.
Well, at least its happening while in *red* gnus.

> I think you will find the code for adding customization support pretty
> intuitive.  Maybe you could try to add customization support to
> smiley.el?

I'll look into doing it for both that and for gnus-picon.el

> Yes it is.  I also want to be able to attach info-links and perhaps
> url-links to each option or group, but haven't figured out how to do
> that without cluttering up the display even more.

Hmm.  Maybe a variable to dictate if their displayed?   At least that
way its user-customizable.  Then you can customize the customize
procedure!!!!  Wheeee...

> No, it is quite easy to change.  You can also have the same options
> appear in multiple groups, so there could be a `gnus-visual' group
> containing all the faces.

Cool.  This should definately be done.  Volunteers?

Wes