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

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

[David Combs]

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


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.

Should would make custom easier!

Thanks!

David

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

[Kevin Rodgers]

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

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

[Drew Adams]

> > Unlike most everyone else, I find "custom" basically UNUSABLE.

That is hardly an exceptional point of view. ;-) The Customize UI leaves a lot
to be desired.

The framework underlying the UI is actually pretty good, however - in
particular, it provides typing.

> > (Actually, I'd much prefer a super-LONG edit-options -- at least
> > I could run M-x occur on it, see where things were.

Well, `M-x edit-options' is certainly available. And it can be quite useful.

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

1. Kevin's answer is a good one.

The point is that you don't necessarily _want_ a HUGE tree of all options, just
because there is a problem finding which options might be appropriate for some
use. What you really want is a way to focus on the parts of the tree that might
be of interest at the moment. How to do that is the real problem.

One way to do it is by checking the option names, and `apropos-variable' lets
you match names using a regexp (a substring is of course a trivial regexp).


2. Icicles can help here also.

* Command `icicle-apropos-option' is similar to `apropos-variable', but before
actually committing a regexp using `RET' you can just type it and use `S-TAB' to
see what the matching options are (will be). At the same time, you can use
`C-next' or `C-RET' to see the doc for any of the matching options.

You can adjust the regexp on the fly until you see the options you want. IOW,
WYSIWYG: change the regexp and see the matches immediately. Commit the regexp
only when you've got something you want.

* Rather than using a single fancy regexp, you can use multiple simple match
patterns (regexps or substrings) to narrow down your search progressively, a
piece at a time. If you're looking for an option whose name contains, say, both
`buffer' and `window', but in either order, then just match both of those
patterns.

http://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion

* Command `icicle-customize-apropos-options' is similar to
`customize-apropos-options' but, like `icicle-apropos-option', you can adjust
the regexp on the fly to see which options match.

* Command `icicle-customize-apropos-options-of-type' is similar, but it lets you
also specify the types of the options. That is, you can match not only against
option names but also against their types: their type names or their type specs.

http://www.emacswiki.org/emacs/Icicles_-_Help_on_Candidates#OtherAproposCommands

* If matching names and types isn't good enough then you can try matching terms
that are used in doc strings. The standard Emacs command for this is
`apropos-documentation'. Icicles command `icicle-vardoc' is similar, but you can
use all of the features described above: on-the-fly matching, progressive
refinement, help (doc) for individual matches.

http://www.emacswiki.org/emacs/Icicles_-_Multi-Completions

HTH.

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

[Ilya Zakharevich]

On 2010-01-18, David Combs <dkcombs@panix.com> wrote:
> subj: M-x custom: *PLEASE*, someone, have it build an INDEX (as in *info*)
>
>
> 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.

???  Can you be more specific: in which way (customize-browse) does not work?

Ilya

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

[David Combs]

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

David

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

[David Combs]

In article <slrnhlf2pn.enk.nospam-abuse@powdermilk.math.berkeley.edu>,
Ilya Zakharevich  <nospam-abuse@ilyaz.org> wrote:
>On 2010-01-18, David Combs <dkcombs@panix.com> wrote:
>> subj: M-x custom: *PLEASE*, someone, have it build an INDEX (as in *info*)
>>
>>
>> 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.
>
>???  Can you be more specific: in which way (customize-browse) does not work?
>
>Ilya

Not really.  I guess my mind was grabbed eons ago by edit-options,
that's all.

David

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

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

[Kevin Rodgers]

David Combs wrote:
> 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.
> 
> You mean with a regexp like "."?  To get EVERYTHING?

No, I mean if you want to search the virtual index for "foo", type
`M-x apropos-variable RET foo RET'.

>    (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?)

There are autoloaded variables, just like autoloaded functions.

-- 
Kevin Rodgers
Denver, Colorado, USA