Defcustoms, how do users find them?

Defcustoms, how do users find them?

[Lennart Borgman]

There was a discussion right now on emacs help mailing list. Someone
mentioned that you could customize uniquify-buffer-name-style.

This defcustom is not autoloaded. How are users supposed to find it?
Should all defcustoms be autoloaded?

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> Should all defcustoms be autoloaded?

No, please god, no!


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 12:05 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Should all defcustoms be autoloaded?
>
> No, please god, no!


Maybe you have explained why, but I do not know. Why? Is the cost for
autoloading them to high in some way, or?

Re: Defcustoms, how do users find them?

[Stefan Monnier]

>>> Should all defcustoms be autoloaded?
>> No, please god, no!
> Maybe you have explained why, but I do not know. Why? Is the cost for
> autoloading them to high in some way, or?

I don't really care to explain, but I hate autoloaded variables and
autoloaded defcustoms even more so.


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 3:52 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>>> Should all defcustoms be autoloaded?
>>> No, please god, no!
>> Maybe you have explained why, but I do not know. Why? Is the cost for
>> autoloading them to high in some way, or?
>
> I don't really care to explain, but I hate autoloaded variables and
> autoloaded defcustoms even more so.


It might be so, but what is the reason not to autload defcustoms in
Emacs ... ? ;-)

There are around 7000 defcustoms in Emacs. That probably make memory
consumption a bit troublesome. But perhaps the doc strings can be
stored on file for those, they do not have to go into the dumped
Emacs. So I guess that is not your reason to hate autoloaded vars.

And the elisp files do not get loaded just because the defcustoms are
autoloaded (as long as you have not set them) - or do they?

Or is it the size of obarray? In a bare Emacs the number of symbols is
around 13 000. In my current Emacs it is around 40 000. Does adding 7
000 (or is it maybe 5000 to add) make a big difference in lookup?

Defcustoms can be complex, but does that matter in the case of
autoloading? It is only defcustoms that are at their default values
that will be in an autoloaded state.


I would be a bit surprised if there was strong reasons to autoload
vars that are not defcustoms, but defcustoms are a bit different. They
are meant to be used and found by the users. I would like to see
something like "apropos-options".

If it is really annoying to autoload defcustoms then maybe autoloading
just defgroups would be a possibility? (Or are they already autoloaded
in some way?)

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> If it is really annoying to autoload defcustoms then maybe autoloading
> just defgroups would be a possibility? (Or are they already autoloaded
> in some way?)

Yes, groups are autoloaded, thanks to cus-load.el.
We could make customize-variable's completion complete to all
defcustoms, using a similar scheme (and have customize-variable
automatically load the var's package if it's not yet loaded).
But autoloading the defcustoms is out of the question.


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 4:38 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> If it is really annoying to autoload defcustoms then maybe autoloading
>> just defgroups would be a possibility? (Or are they already autoloaded
>> in some way?)
>
> Yes, groups are autoloaded, thanks to cus-load.el.
> We could make customize-variable's completion complete to all
> defcustoms, using a similar scheme (and have customize-variable
> automatically load the var's package if it's not yet loaded).
> But autoloading the defcustoms is out of the question.

I think that would solve the problem - if help/apropos functions also
loaded the var's package.

Re: Defcustoms, how do users find them?

[Juri Linkov]

> This defcustom is not autoloaded. How are users supposed to find it?
> Should all defcustoms be autoloaded?

Autoloading of defcustom causes problems with default values.
For autoloaded defcustoms the default is computed at the startup time
before loading .emacs and calling custom-set-variables where other variables
get their values that may be used for computing the default value of
the autoloaded defcustom.

Please see the related bug#4387 for more information:
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4387

There is the following etc/TODO task:

  ** Remove unnecessary autoload cookies from defcustoms.
  This needs a bit of care, since often people have become used to
  expecting such variables to always be defined, eg when they modify
  things in their .emacs.

I'm not sure what does mean "This needs a bit of care"?
So I hesitate to remove the autoload cookie from `find-name-arg'
to fix the bug#4387.

PS: Removing the autoload cookie from `find-name-arg' also means
adding (require 'find-dired) to rgrep where it is used, but it seems
this is not a problem.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 4:41 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Tue, Nov 17, 2009 at 4:38 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> If it is really annoying to autoload defcustoms then maybe autoloading
>>> just defgroups would be a possibility? (Or are they already autoloaded
>>> in some way?)
>>
>> Yes, groups are autoloaded, thanks to cus-load.el.
>> We could make customize-variable's completion complete to all
>> defcustoms, using a similar scheme (and have customize-variable
>> automatically load the var's package if it's not yet loaded).
>> But autoloading the defcustoms is out of the question.
>
> I think that would solve the problem - if help/apropos functions also
> loaded the var's package.


As I understand it we then first have to modify
custom-make-dependencies so that it also collects defcustoms. Changing
the part where it write 'custom-loads to cus-dep.el should is enough
for this I guess, see below. Is this the way to do it? (And then add
the corresponding pieces to custom-variable-prompt etc.)

*** In custom-make-dependencies change to this ****

  (mapatoms (lambda (symbol)
	      (let ((members (get symbol 'custom-group))
                    where found
                    (option (get symbol 'standard-value))
                    option-where option-found
                    )
		(when members
		  (dolist (member
                           ;; So x and no-x builds won't differ.
                           (sort (mapcar 'car members) 'string<))
		    (setq where (get member 'custom-where))
		    (unless (or (null where)
				(member where found))
		      (push where found)))
		  (when found
		    (insert "(put '" (symbol-name symbol)
                            " 'custom-loads '")
                    (prin1 (nreverse found) (current-buffer))
                    (insert ")\n")))
                (when option
                  (setq option-where (get option 'custom-where))
                  (push option-where option-found)
                  (insert "(put '" (symbol-name symbol)
                          " 'custom-option-loads '")
                  (prin1 (nreverse found) (current-buffer))
                  (insert ")\n"))
                )))

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 3:22 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Tue, Nov 17, 2009 at 4:41 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Tue, Nov 17, 2009 at 4:38 AM, Stefan Monnier
>> <monnier@iro.umontreal.ca> wrote:
>>>> If it is really annoying to autoload defcustoms then maybe autoloading
>>>> just defgroups would be a possibility? (Or are they already autoloaded
>>>> in some way?)
>>>
>>> Yes, groups are autoloaded, thanks to cus-load.el.
>>> We could make customize-variable's completion complete to all
>>> defcustoms, using a similar scheme (and have customize-variable
>>> automatically load the var's package if it's not yet loaded).
>>> But autoloading the defcustoms is out of the question.
>>
>> I think that would solve the problem - if help/apropos functions also
>> loaded the var's package.
>
>
> As I understand it we then first have to modify
> custom-make-dependencies so that it also collects defcustoms. Changing
> the part where it write 'custom-loads to cus-dep.el should is enough
> for this I guess, see below. Is this the way to do it? (And then add
> the corresponding pieces to custom-variable-prompt etc.)
>
> *** In custom-make-dependencies change to this ****
>
>  (mapatoms (lambda (symbol)
>              (let ((members (get symbol 'custom-group))


And that was not a very good idea for how to modify
custom-make-dependencies. Something like this should make it easier to
write the rest since there is already a lot of stuff handling
'custom-loads:

  (mapatoms (lambda (symbol)
	      (let ((members (get symbol 'custom-group))
                    where found
                    (sym-name (symbol-name symbol))
                    (option (get symbol 'standard-value)))
		(when members
		  (dolist (member
                           ;; So x and no-x builds won't differ.
                           (sort (mapcar 'car members) 'string<))
		    (setq where (get member 'custom-where))
		    (unless (or (null where)
				(member where found))
		      (push where found)))
		  (when found
                    (insert "(put '" sym-name " 'custom-unloaded 'group)\n")))
                (when option
                  (setq where (get option 'custom-where))
                  (insert "(put '" sym-name " 'custom-unloaded 'option)\n")
                  (unless (or (null where)
                              (member where found))
                    (push where found)))
                (when found
                  (insert "(put '" sym-name
                          " 'custom-loads '")
                  (prin1 (nreverse found) (current-buffer))
                  (insert ")\n"))
                )))

Re: Defcustoms, how do users find them?

[Glenn Morris]

Juri Linkov wrote:

>   ** Remove unnecessary autoload cookies from defcustoms.
>   This needs a bit of care, since often people have become used to
>   expecting such variables to always be defined, eg when they modify
>   things in their .emacs.
>
> I'm not sure what does mean "This needs a bit of care"?

I had in mind situations like bug#2150. Sometimes people have got used
to doing things like:

(setq foo-var (concat "more-foo\\|" foo-var))

or

(add-to-list 'foo-var "more-foo")

ie assuming foo-var is bound before foo-mode is loaded. There's no
compatible way to change such things to being non-autoloaded, nor is
there a way to warn "this won't be autoloaded in future".

RE: Defcustoms, how do users find them?

[Drew Adams]

> > This defcustom is not autoloaded. How are users supposed to find it?
> > Should all defcustoms be autoloaded?
> 
> Autoloading of defcustom causes problems with default values.
> For autoloaded defcustoms the default is computed at the startup time
> before loading .emacs and calling custom-set-variables where 
> other variables
> get their values that may be used for computing the default value of
> the autoloaded defcustom.
> 
> Please see the related bug#4387 for more information:
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4387
> 
> There is the following etc/TODO task:
> 
>   ** Remove unnecessary autoload cookies from defcustoms.
>   This needs a bit of care, since often people have become used to
>   expecting such variables to always be defined, eg when they modify
>   things in their .emacs.
> 
> I'm not sure what does mean "This needs a bit of care"?
> So I hesitate to remove the autoload cookie from `find-name-arg'
> to fix the bug#4387.
> 
> PS: Removing the autoload cookie from `find-name-arg' also means
> adding (require 'find-dired) to rgrep where it is used, but it seems
> this is not a problem.

I'll generally keep out of this discussion. I'm no expert on Customize. I will
add my 2c now, though.

I agree with Lennart that it would be beneficial for users to have the _doc
strings_ of all (or at least most, if there are particular problems for some)
vanilla Emacs options available at startup.

IMO, this is as important (no - more important) for `C-h v' and apropos as it is
for `customize-variable'. The latter would let you see a list of options, but it
wouldn't tell you anything about them. In this I disagree with Lennart, who said
that providing all options for completion by `customize-variable' would be
sufficient.

IIUC, the difficulties Juri refers to have to do only (?) with the _values_ of
those options, not with their doc strings. IOW, there is an implementation
concern here, but it does not necessarily have to do with doc/help. (It might
have to do also with doc the way things are implemented today, but does it
_necessarily_ have to do with doc?)

Couldn't we find some way to more or less "autoload" (note the quotes) only the
doc strings and not also pre-initialize the values, since that could be
problematic (:set, :initialize etc.)?

`C-h v', apropos, etc. could then let you know what options are available and
what each option is for, even if the info these help commands provide might be
limited by not letting you know a value until the variable is bound.

IOW, being known wrt doc/help isn't, conceptually at least, the same thing as
having a value. Must we couple the two in a rigid way, so that users can know
about variables only if they have values?

The Emacs UI, more than any other I know of, makes it easy to discover what's
there - what's available on the surface as well as what's available under the
covers. It's too bad that we have this doc limitation. It's a shame we don't
provide doc strings for more options (and for more commands) from the get-go. By
such a limitation, we put (unnecessary?) obstacles in the way of user discovery
of what's possible.

I recognize that if we did what I'm asking then a simple `boundp' wouldn't be
sufficient, in commands that provide help, to distinguish variables from
non-variables. And I'm sure there are other implementation concerns and this is
not necessarily a simple thing. But we could at least think about it and not
just have the reaction "No, please god, no!".

And maybe this wouldn't really be a big deal in terms of implementation. We can
already provide doc for a variable without defining it (i.e. no defvar, no
defcustom, no setq, no let - no value):

(put 'foo 'variable-documentation "Helpful doc for `foo'.")
C-h v foo

 foo is void as a variable.

 Documentation:
 Helpful doc for `foo'.

Couldn't we use something similar as the basis for defcustom documentation,
somehow gathering all of the defcustoms for a vanilla Emacs session initially,
defining only the doc strings (not the values) for those that are not loaded?

It would of course be good if the help provided could also point to the
variable's library (automatically), but even without that info it would be
useful.

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 6:49 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I agree with Lennart that it would be beneficial for users to have the _doc
> strings_ of all (or at least most, if there are particular problems for some)
> vanilla Emacs options available at startup.
>
> IMO, this is as important (no - more important) for `C-h v' and apropos as it is
> for `customize-variable'. The latter would let you see a list of options, but it
> wouldn't tell you anything about them. In this I disagree with Lennart, who said
> that providing all options for completion by `customize-variable' would be
> sufficient.

I also said that help and apropos should load the libraries like
customize do. That would provide the doc strings for those functions,
or?

If it does not then using

  (put 'foo 'variable-documentation "Helpful doc for `foo'.")

as you suggested might be a way.

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Tue, Nov 17, 2009 at 3:45 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Tue, Nov 17, 2009 at 3:22 PM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Tue, Nov 17, 2009 at 4:41 AM, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>> On Tue, Nov 17, 2009 at 4:38 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca> wrote:
>>>>> If it is really annoying to autoload defcustoms then maybe autoloading
>>>>> just defgroups would be a possibility? (Or are they already autoloaded
>>>>> in some way?)
>>>>
>>>> Yes, groups are autoloaded, thanks to cus-load.el.
>>>> We could make customize-variable's completion complete to all
>>>> defcustoms, using a similar scheme (and have customize-variable
>>>> automatically load the var's package if it's not yet loaded).
>>>> But autoloading the defcustoms is out of the question.
>>>
>>> I think that would solve the problem - if help/apropos functions also
>>> loaded the var's package.
>>
>>
>> As I understand it we then first have to modify
>> custom-make-dependencies so that it also collects defcustoms. Changing
>> the part where it write 'custom-loads to cus-dep.el should is enough
>> for this I guess, see below. Is this the way to do it? (And then add
>> the corresponding pieces to custom-variable-prompt etc.)
>>
>> *** In custom-make-dependencies change to this ****
>>
>>  (mapatoms (lambda (symbol)
>>              (let ((members (get symbol 'custom-group))
>
>
> And that was not a very good idea for how to modify
> custom-make-dependencies. Something like this should make it easier to
> write the rest since there is already a lot of stuff handling
> 'custom-loads:
>
>  (mapatoms (lambda (symbol)
>              (let ((members (get symbol 'custom-group))
>                    where found
>                    (sym-name (symbol-name symbol))
>                    (option (get symbol 'standard-value)))
>                (when members
>                  (dolist (member
>                           ;; So x and no-x builds won't differ.
>                           (sort (mapcar 'car members) 'string<))
>                    (setq where (get member 'custom-where))
>                    (unless (or (null where)
>                                (member where found))
>                      (push where found)))
>                  (when found
>                    (insert "(put '" sym-name " 'custom-unloaded 'group)\n")))
>                (when option
>                  (setq where (get option 'custom-where))
>                  (insert "(put '" sym-name " 'custom-unloaded 'option)\n")
>                  (unless (or (null where)
>                              (member where found))
>                    (push where found)))
>                (when found
>                  (insert "(put '" sym-name
>                          " 'custom-loads '")
>                  (prin1 (nreverse found) (current-buffer))
>                  (insert ")\n"))
>                )))
>


I tested this a little. Loading the new cus-load.el now takes about
2.5 times longer time than before. (This is an old pc, it now takes
0.5 sec.) There are approx 15 000 put statements (before there were
approx 1000).

Byte compiling will bring down load time to the same time as before
(or even less, it was not byte-compiled before), but I do not know if
there are any adverse effects from byte compiling it.

Is this the way to go to get completion etc for unloaded options (and faces)?

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> I tested this a little. Loading the new cus-load.el now takes about
> 2.5 times longer time than before. (This is an old pc, it now takes
> 0.5 sec.) There are approx 15 000 put statements (before there were
> approx 1000).

> Is this the way to go to get completion etc for unloaded options (and faces)?

I think the basic idea is right, but I think that using `put' for those
variables is not a good idea (it makes the cus-load.el file large and
slow).  It's probably preferable to build a single alist associating
file names to the list of vars defined in them (or maybe a hash-table).

Of course, I haven't tried it, so it may end up being just as slow/big.


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Wed, Nov 18, 2009 at 4:26 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I tested this a little. Loading the new cus-load.el now takes about
>> 2.5 times longer time than before. (This is an old pc, it now takes
>> 0.5 sec.) There are approx 15 000 put statements (before there were
>> approx 1000).
>
>> Is this the way to go to get completion etc for unloaded options (and faces)?
>
> I think the basic idea is right, but I think that using `put' for those
> variables is not a good idea (it makes the cus-load.el file large and
> slow).  It's probably preferable to build a single alist associating
> file names to the list of vars defined in them (or maybe a hash-table).
>
> Of course, I haven't tried it, so it may end up being just as slow/big.


Maybe, I just tried to build on what is there. It turns out that after
byte compiling the new cus-load.el loads in 0.1 sec on my quite old
pc.

Are there other aspects that makes it worth investigating this more?
Maybe memory use? I can't see that efficiency in loading could be
affected very much.

Re: Defcustoms, how do users find them?

[Juri Linkov]

>>   ** Remove unnecessary autoload cookies from defcustoms.
>>   This needs a bit of care, since often people have become used to
>>   expecting such variables to always be defined, eg when they modify
>>   things in their .emacs.
>>
>> I'm not sure what does mean "This needs a bit of care"?
>
> I had in mind situations like bug#2150. Sometimes people have got used
> to doing things like:
>
> (setq foo-var (concat "more-foo\\|" foo-var))
>
> or
>
> (add-to-list 'foo-var "more-foo")
>
> ie assuming foo-var is bound before foo-mode is loaded. There's no
> compatible way to change such things to being non-autoloaded, nor is
> there a way to warn "this won't be autoloaded in future".

So there is "no way back" and removing autoload will cause another
bug report about failures in ~/.emacs that customizes that option.
Then I don't how to fix bugs like bug#4387.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> Maybe, I just tried to build on what is there. It turns out that after
> byte compiling the new cus-load.el loads in 0.1 sec on my quite
> old pc.

Great.

> Are there other aspects that makes it worth investigating this more?

Checking memory use of your scheme would be a good idea, yes, because
the main problem I see now is that if you want it to be available for
C-h v and apropos as well, then it'll end up being loaded into memory in
many/most circumstances (e.g. in every one of my Emacs sessions, for
example).  For C-h v I can imagine we can circumvent the problem by
not providing completion for unloaded vars, but for apropos, there's no
shortcut tht I can think of.


        Stefan


PS: BTW, whenever you send code here, if it's a modification of existing
  code, it helps tremendously if you send it as a patch.

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> So there is "no way back" and removing autoload will cause another
> bug report about failures in ~/.emacs that customizes that option.
> Then I don't how to fix bugs like bug#4387.

In the case of bug#4387, removing the autoload should be pretty safe,
but it's very unlikely that someone *modifies* the variable in her
.emacs rather than just setting it to some constant value.


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Wed, Nov 18, 2009 at 3:34 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> Checking memory use of your scheme would be a good idea, yes, because

How do I do that?

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Thu, Nov 26, 2009 at 1:51 PM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Wed, Nov 18, 2009 at 3:34 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>
>> Checking memory use of your scheme would be a good idea, yes, because
>
> How do I do that?

I tried using garbage-collection to get memory use. Is this output of
some value? I have just ran my version of cus-load.el with all the
defcustom:s.

(message "gc => %S" (garbage-collect))
(load-file "my-cus-load.el")
(message "gc => %S" (garbage-collect))

;;; after emacs -Q
;; gc => ((64567 . 8541) (14423 . 0) (726 . 107) 88519 295966 (50 .
70) (347 . 97) (5376 . 3255))
;; Loading c:/emacs/p/091105/emacs/lisp/my-cus-load.el (source)...done
;; gc => ((91214 . 17541) (21758 . 0) (722 . 111) 258011 294763 (50 .
70) (348 . 96) (13174 . 4466))

Re: Defcustoms, how do users find them?

[Stefan Monnier]

>> Checking memory use of your scheme would be a good idea, yes, because
> How do I do that?

You try an Emacs with it and an Emacs without it, and compare their
memory use (that can be done by checking the return value of
(garbage-collect) OT1H, and your OS's description of the amount of
virtual and physical memory used by the process OTOH).


        Stefan

Re: Defcustoms, how do users find them?

[Stefan Monnier]

> ;;; after emacs -Q
> ;; gc => ((64567 . 8541) (14423 . 0) (726 . 107) 88519 295966 (50 .
> 70) (347 . 97) (5376 . 3255))
> ;; Loading c:/emacs/p/091105/emacs/lisp/my-cus-load.el (source)...done
> ;; gc => ((91214 . 17541) (21758 . 0) (722 . 111) 258011 294763 (50 .
> 70) (348 . 96) (13174 . 4466))

So it's (/ 91214 64567.0) => 40% more cons-cells
        (/ 21758 14423.0) => 50% more symbols
        no significant change in markers
        (/ 258011 88519.0) => 3x times the string chars.
        no significant change in vectors
        no change in floats
        no significant change in intervals (aka text-properties)
        (/ 13174 5376.0) => 2.5 times the strings

It can also be counted as 26K additional cons cells, 7K additional
symbols, 170KB additional string chars, 8K additional strings, for
a total of about:

   (+ (* 26000 8) (* 7000 24) 170000 (* 8000 16)) => 650KB

So it ends up increasing Emacs's footprint by a bit less than
a megabyte.  It's not the end of the world, but it might be worthwhile
trying to avoid loading this data unless it's really needed.
Of course, maybe there's a way to represent the same info
more compactly or to load it piecemeal (e.g. I've been using a local
hack where C-h v foo-bar RET will try to load foo.el if foo-bar is not
yet defined).


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Thu, Nov 26, 2009 at 6:30 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> So it ends up increasing Emacs's footprint by a bit less than
> a megabyte.  It's not the end of the world, but it might be worthwhile
> trying to avoid loading this data unless it's really needed.


The easiest seems to be to split cus-load.el in two part and only load
this extra part in C-h v etc.


> Of course, maybe there's a way to represent the same info
> more compactly


I doubt it is possible, but I do not understand all the figures. Does
it help to erase the data again after C-h v?


> or to load it piecemeal (e.g. I've been using a local
> hack where C-h v foo-bar RET will try to load foo.el if foo-bar is not
> yet defined).


Doesn't it need this data?

Re: Defcustoms, how do users find them?

[Stefan Monnier]

>> So it ends up increasing Emacs's footprint by a bit less than
>> a megabyte.  It's not the end of the world, but it might be worthwhile
>> trying to avoid loading this data unless it's really needed.
> The easiest seems to be to split cus-load.el in two part and only load
> this extra part in C-h v etc.

I think C-h v, C-h f and very common operations which most of the time
do not need this info, so I'd like to avoid eating up 1MB just for that.

>> Of course, maybe there's a way to represent the same info
>> more compactly
> I doubt it is possible, but I do not understand all the figures.
> Does it help to erase the data again after C-h v?

Erasing the data after use might be a way around the problem.
Note that in the form in which you currently store the data (Customize
symbol properties), it's difficult to unload it.

If you additionally split the data (e.g. based on the first letter),
you'd end up only loading a tenth of the data at a time, which would
seem a lot more reasonable.

>> or to load it piecemeal (e.g. I've been using a local
>> hack where C-h v foo-bar RET will try to load foo.el if foo-bar is not
>> yet defined).
> Doesn't it need this data?

No it does it by guessing that "foo-bar" is probably in file foo.el
based on the prefix, so it doesn't need any data at all, but then it
only works in some cases.  And doesn't provide any completion at all.

Obviously, this is just a hack.  But maybe it can be turned into
something more robust.  E.g. we could collect a list of unique prefixes
for each file, so we could then easily figure out from a variable name
(or from a prefix) which (set of) files might provide variables of
that name.  And this data should be fairly compact.  Better yet: it
could be used to check/encourage use of the coding convention that
asks to use unique prefixes for namespace management: well-coded
packages will use less prefixes/less resources.

The main interest for me here is that this should work for defvars and
defuns as well, without much additional cost.

Ideally such a feature should use autoload.el rather than cus-dep.el, so
it can also work for unbundled packages.


        Stefan

Re: Defcustoms, how do users find them?

[Lennart Borgman]

On Fri, Nov 27, 2009 at 3:09 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>> So it ends up increasing Emacs's footprint by a bit less than
>>> a megabyte.  It's not the end of the world, but it might be worthwhile
>>> trying to avoid loading this data unless it's really needed.
>> The easiest seems to be to split cus-load.el in two part and only load
>> this extra part in C-h v etc.
>
> I think C-h v, C-h f and very common operations which most of the time
> do not need this info, so I'd like to avoid eating up 1MB just for that.
>
>>> Of course, maybe there's a way to represent the same info
>>> more compactly
>> I doubt it is possible, but I do not understand all the figures.
>> Does it help to erase the data again after C-h v?
>
> Erasing the data after use might be a way around the problem.
> Note that in the form in which you currently store the data (Customize
> symbol properties), it's difficult to unload it.


Maybe load this data only when needed and erase them always afterwards.

What is the problem with erasing the data? It is just a simple loop
erasing it all, or?


> If you additionally split the data (e.g. based on the first letter),
> you'd end up only loading a tenth of the data at a time, which would
> seem a lot more reasonable.


Aren't these data only needed in custom operations? Then just
loading/unloading them seems not be operations that will be very
frequent. They are not more frequent than commands if flag them and
erase them at command level. And a 0.1 seconds delay for certain
commands that either load libraries or are meant as information
commands is not very much.