Re: M-x custom: *PLEASE*, someone, have it build an INDEX (as in *info*)

[Tim X]

dkcombs@panix.com (David Combs) writes:

> In article <mailman.1677.1263871922.18930.help-gnu-emacs@gnu.org>,
> Kevin Rodgers  <kevin.d.rodgers@gmail.com> wrote:
>>David Combs wrote:
>>> Unlike most everyone else, I find "custom" basically UNUSABLE.
>>> 
>>> (Actually, I'd much prefer a super-LONG edit-options -- at least
>>> I could run M-x occur on it, see where things were.
>>> 
>>> This custom thing -- I have no idea where things are, how far
>>> down I have to go.
>>> 
>>> Maybe if someone could code it to draw one HUGE tree (lying on its
>>> side, of course), but the current scheme doesn't work for me.
>>> 
>>> So, an INDEX would help -- each one being a LINK to the thing
>>> it's about.  Custom would make the index each time it started up.
>>
>>Why not `M-x apropos-variable' to generate the *Apropos* buffer as a
>>virtual index?  Then click on one of the links to display the *Help*
>>buffer for any variable, which has a link to customize the variable.
>>
>>-- 
>>Kevin Rodgers
>>Denver, Colorado, USA
>>
>>
>>
>
> You mean with a regexp like "."?  To get EVERYTHING?
>
>    (everything that emacs knows about, anyway, at that time
>     I guess that custom works the same way -- if a .el file
>     hasn't yet been read in, emacs won't know any of its
>     variables?
>
>    Or is that just plain wrong.  Isn't there something that
>   is predefined, and if referenced, it's then read in?
>   Or is that just for defuns?  Or not even emacs-lisp?)
>
 Unfortunately, it seems to depend on how the author wrote their mode.
 Many well written modes do auto load their mode custom stuff, so it is
 there even if you have not used the mode. However, other modes don't
 and their custom definitions will only show up if the mode has been
 loaded. 

I doubt a full listing of all custom settings will be at all usable.
There are already single modes where it takes considerable time to load
all the custom definitions and some of them use sub-modes, so all of
them are not being created at once. The issue is really formatting of
the custom buffers, which can be a bit slow if there are lots of
elements to render. 

I would not be surprised if building the custom buffer with all custom
options in it would take in the order of minutes to render, making it
almost unusable. 

While I can understand everyone likes to work in their own way, this
request still feels like an approach that is looking at custom settings
from the wrong angle. I suspect this could be due to bad documentation.
In reality, you usually don't go browsing through customize buffers
looking for things to change. Rather, you use the docs and manual to
learn about the mode and pick up how it can be customized from there.
Then you either do a customize group or customize variable to change
what you need to change. 

browsing the custom settings without a good understanding or any
background can often lead to really unexpected results. You get tempted
to change some value because, based on its current setting and name, you
*believe* its not correct. However, often what you think the name means
and what you think the different settings do are not quite in line with
reality. What tends to happen is you then modify things and later find
out something isn't working correctly or isn't working how it use to or
some other weird unexpected thngs happen and now you have to try and
work out what it was you changed that is the cause. 

the other problem with this approach is that often the user will change
the mode settings to work the way they think the mode should work 
before they have gotten to understand and possibly appreciate the way
the author intended the mode to work. This then results in either the
user getting frustrated with the mode and giving up or worse still,
writing another mode that is 80% equivalent rather than adding to the
existing mode and making it better. 

The customize interface is certainly on the clunky side and possibly not
the best looking customization interface, but given that it works under
X and on text consoles or inside an xterm, I think it does a pretty good
job. It is also evolving and becoming better over time. Now we have a
GTK based interface, maybe the X/GUI version will become even better. 

What would probably help is for developers to know more about why there
is a desire to have the ability to list all options in one huge buffer.
Rather than asking for a particular solution, maybe it would be better
to provide more explination regarding why the existing solution is
lacking and see if anyone can come up with a better solution. 

In the meantime, I'd use M-x customize-browse, which gives you the full
tree of currently available custom option settings that you can traverse
to see what is available and if desired, make changes. As it uses the
tree widgets, it doesn't have the rendering overhead of a buffer with
all custom settings. 

HTH

Tim

>
>

-- 
tcross (at) rapttech dot com dot au