apropos commands for commands, user options, all functions, all variables

apropos commands for commands, user options, all functions, all variables

[Drew Adams]

I think we should do the following (I do it in my own code):

* Rename `apropos-variable' to `apropos-option'.

* Define a new `apropos-variable' command that works for all variables, not
just user options.

* Define an `apropos-function' command that works for all functions, not
just commands.

Users should be able to find and use commands that give them info about (a)
all vars, (b) all functions, (c) just commands, and (d) just user options;
and the names of those commands should reflect what they do.


Similarly, we should rename `set-variable' to `set-option' and define a new
`set-variable' command that sets any variable, not just a user option. (I
have defined such a command in my own code, but I just call it
`set-any-variable', for now.)

Re: apropos commands for commands, user options, all functions, all variables

[Andreas Röhler]

Am Freitag, 19. Oktober 2007 21:08 schrieb Drew Adams:
...
> Users should be able to find and use commands that give them info about (a)
> all vars, (b) all functions, (c) just commands, and (d) just user options;
> and the names of those commands should reflect what they do.
>

That's a good idea.

When examining something new, I like to list the
commands of that code. So I would appreciate to have it
per file or per mode. 

Thanks

Andreas Röhler


....

RE: apropos commands for commands, user options, all functions, all variables

[Drew Adams]

> > Users should be able to find and use commands that give them
> > info about (a) all vars, (b) all functions, (c) just commands,
> > and (d) just user options; and the names of those commands
> > should reflect what they do.
>
> That's a good idea.
>
> When examining something new, I like to list the
> commands of that code. So I would appreciate to have it
> per file or per mode.

Sorry, I don't understand. Are you asking for the `apropos-*' commands to
mention only things that are defined by the current major mode or defined in
the current file?

If so, please start a new thread for that; that is something quite different
from what I proposed.

apropos commands for commands, user options, all functions, all variables

[Stephen J. Turnbull]

Drew Adams writes:

 > Users should be able to find and use commands that give them info about (a)
 > all vars, (b) all functions, (c) just commands, and (d) just user options;
 > and the names of those commands should reflect what they do.

FWIW, XEmacs has had `C-h a' bound to `hyper-apropos' (dunno if this
exists in Emacs) which returns all variables and functions with
non-void values and function cells respectively, for a decade now,
with no complaints about verboseness that I can remember.

 > Similarly, we should rename `set-variable' to `set-option' and define a new
 > `set-variable' command that sets any variable, not just a user option. (I
 > have defined such a command in my own code, but I just call it
 > `set-any-variable', for now.)

Why not just make `setq' interactive?

Re: apropos commands for commands, user options, all functions, all variables

[Richard Stallman]

    * Define an `apropos-function' command that works for all functions, not
    just commands.

There is no need for it.  You can use plain apropos when you want that.

    * Rename `apropos-variable' to `apropos-option'.

    * Define a new `apropos-variable' command that works for all variables, not
    just user options.

It is a bit of an anomaly that `apropos-variable' works only for
user-option variables.  On the other hand, most users are not
interested in any others.  I'd say just define `apropos-option'
as an alias.

    Similarly, we should rename `set-variable' to `set-option' and define a new
    `set-variable' command that sets any variable, not just a user option.

There is no need for such a command; it would be wasted complexity.
We could define `set-option' as an alias for it.

Re: apropos commands for commands, user options, all functions, all variables

[Juri Linkov]

>     Similarly, we should rename `set-variable' to `set-option' and define a new
>     `set-variable' command that sets any variable, not just a user option.
>
> There is no need for such a command; it would be wasted complexity.
> We could define `set-option' as an alias for it.

I often use my own implementation of `set-variable' that doesn't restrict
its argument only to options.  I wonder what is more easy way to
interactively change the variable's value in Emacs?

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

Re: apropos commands for commands, user options, all functions, all variables

[Stefan Monnier]

>> Similarly, we should rename `set-variable' to `set-option' and define a new
>> `set-variable' command that sets any variable, not just a user option.
>> 
>> There is no need for such a command; it would be wasted complexity.
>> We could define `set-option' as an alias for it.

> I often use my own implementation of `set-variable' that doesn't restrict
> its argument only to options.  I wonder what is more easy way to
> interactively change the variable's value in Emacs?

You can do

  (put 'set 'interactive-form
       '(interactive "Svariable name: \nxValue: "))

and then M-x set RET <var> RET <val> RET
or just

  M-: (setq <var> <val>) RET

I implemented the functionality for the first, and I personally use the
second.


        Stefan

Re: apropos commands for commands, user options, all functions, all variables

[Juri Linkov]

>> I often use my own implementation of `set-variable' that doesn't restrict
>> its argument only to options.  I wonder what is more easy way to
>> interactively change the variable's value in Emacs?
>
> You can do
>
>   (put 'set 'interactive-form
>        '(interactive "Svariable name: \nxValue: "))
>
> and then M-x set RET <var> RET <val> RET
> or just
>
>   M-: (setq <var> <val>) RET
>
> I implemented the functionality for the first, and I personally use the
> second.

Neither is as convenient as set-variable which

1. picks up the default variable name from the buffer;
2. provides completion;
3. provides the old value as default for editing in the minibuffer;

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

RE: apropos commands for commands, user options, all functions, all variables

[Drew Adams]

> > You can do (put 'set 'interactive-form
> >                 '(interactive "Svariable name: \nxValue: "))
> > and then M-x set RET <var> RET <val> RET
> > or just M-: (setq <var> <val>) RET
> > I implemented the functionality for the first, and I personally use the
> > second.
>
> Neither is as convenient as set-variable which
>
> 1. picks up the default variable name from the buffer;
> 2. provides completion;
> 3. provides the old value as default for editing in the minibuffer;

Exactly.

Someone will no doubt argue that you can anyway use M-TAB with `M-: (setq '
to complete Lisp symbols, including variables, but it's not the same level
of convenience at all.

Users should have available: (1) completion for only option names (with a
`set-option' command) and (2) completion for only (arbitrary) variable names
(with a redefined `set-variable' command). Completion of arbitrary Lisp
symbols is an undirected shotgun blast here.

Completion (`completing-read', not `lisp-complete-symbol') lets you deal
with the right set of thingies (domain), and can hand you a reasonable
default value to play with. There should be completion commands for setting
both options and arbitrary variables.

Re: apropos commands for commands, user options, all functions, all variables

[Richard Stallman]

    I often use my own implementation of `set-variable' that doesn't restrict
    its argument only to options.  I wonder what is more easy way to
    interactively change the variable's value in Emacs?

Do you find it more convenient in practice to use this
rather than eval a setq?  If so, can you explain why it is more
convenient for you?

Re: apropos commands for commands, user options, all functions, all variables

[Juri Linkov]

>     I often use my own implementation of `set-variable' that doesn't restrict
>     its argument only to options.  I wonder what is more easy way to
>     interactively change the variable's value in Emacs?
>
> Do you find it more convenient in practice to use this
> rather than eval a setq?

Yes, `set-variable' is a very convenient method of changing the
variable's value interactively.

> If so, can you explain why it is more convenient for you?

It is convenient for several reasons:

1. picks up the default variable name from the buffer;
2. provides completion for the variable name;
3. provides the old variable's value as default for editing in the
   minibuffer (by typing M-n);

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

Re: apropos commands for commands, user options, all functions, all variables

[Richard Stallman]

I made set-variable read only user option names because I thought
it was mainly useful for non-Lisp-programmers who wouldn't
know about typing setq.  If it is common for experienced users
to prefer set-variable over setq for convenience, then let's
make set-variable allow any variable name.

So far I've heard from 2 or 3 people that want this.
Would others please try it and say if they find they actually use if?

Re: apropos commands for commands, user options, all functions, all variables

[Juri Linkov]

> I made set-variable read only user option names because I thought
> it was mainly useful for non-Lisp-programmers who wouldn't
> know about typing setq.

For non-Lisp-programmers a better way to change values of user options
is by using the Customization interface.  It also provides commands to
change values in the minibuffer: commands `customize-set-value' and
`customize-set-variable' that work very like the current implementation
of `set-variable'.

Since `set-variable' was also intended to change the values of user
options with the leading * in their docstrings, I think a new command
`set-option' should be added with the body of current `set-variable',
and `set-variable' should allow modifying any variable.

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

Re: apropos commands for commands, user options, all functions, all variables

[Richard Stallman]

    Since `set-variable' was also intended to change the values of user
    options with the leading * in their docstrings, I think a new command
    `set-option' should be added with the body of current `set-variable',
    and `set-variable' should allow modifying any variable.

I don't consider that a good reason for such a change.
If I see some additional experienced users who want this as a convenience,
then I will agree to the change.

customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Drew Adams]

>     Since `set-variable' was also intended to change the values of user
>     options with the leading * in their docstrings, I think a new command
>     `set-option' should be added with the body of current `set-variable',
>     and `set-variable' should allow modifying any variable.
>
> I don't consider that a good reason for such a change.
> If I see some additional experienced users who want this as a convenience,
> then I will agree to the change.

Those quotes provide some context, but this is really about
`customize-set-value' and `customize-set-variable'. Here are some proposals
for discussion:

1. Rename `customize-set-value' to `set-option', and
`customize-set-variable' to `set-option-default' (or add aliases). Users
will find these names easier. These commands provide much better interaction
for reading the new value than does the current `set-variable'. Their
interaction subsumes that of `set-variable', which uses only property
`variable-interactive'.

2. Rewrite `set-variable' to set any variable, not just an option, and when
the variable is an option then have the code do what `customize-set-value'
does. That is, provide better value input interaction, when possible.

3. `customize-set-(value|variable)' needs some improvement. Here are some
things I notice:

a. `choice' for a list of `const' is good - it provides completion, which is
very handy - a great improvement over what is available in Customize, IMO.
However, there is no indication in the prompt that completion is (sometimes)
available. And when completion is available, the default value should be the
current value of the option, for possible editing. Currently, there is no
default value.

b. `choice' that includes a non-`const' choice, in addition to `const'
choices: the types of the non-`const' choices apparently govern what
happens:

- If the non-`const' choice types don't provide for completion, then no
completion is available for the `choice' at all. It would be better to have
non-strict completion and allow for the value that doesn't match any `const'
to be read according to its type. If possible.

- And, if the non-`const' choices also provide for completion, then it
should be possible to combine them with the `const' values into a general
completion. E.g. a `choice' of a `function' or (const :tag "None" nil)
currently completes only against function names - neither "None" nor nil are
allowed as completion candidates. Why not just add "None" to the list of
candidates?

c. `repeat' seems to read a sexp and evaluate to obtain the complete list -
the complete value. This is a cop-out and is not very useful. It would be
better to repeatedly read values corresponding to the list elements, and
then combine them to get the overall value. For example `repeat' of `sexp'
should repeatedly read a sexp (until, say, empty RET) and return the list of
sexprs that were read. And I don't see why the command should `eval' at all
for `repeat' - why wouldn't it just read, like it does for the other types?
And the user has no feedback as to what is expected to be input (beyond
"[repeat]" in the prompt) - nothing tells him to input a sexp that will be
evalled to produce the overall list value. (And end users should not need to
think in such terms, anyway.)

c. (choice (const :tag "None" nil) regexp) reads a regexp string, but the
default is "", not nil, which doesn't seem right. And if you type `nil' or
`None', then the literal string "nil" or "None" is interpreted as a regexp.
Again, it would be better to allow lax completion with sole candidate "None"
and allow a regexp string value as well.

d. For type `color', lax completion should be available, choosing from color
names but also allowing input of a #RRRGGBBB hex string.

#3 is the most important of these suggestions. I don't have time to work on
this much myself, but I can contribute a little time if someone else leads
on this. What's really needed is someone knowledgeable in custom and widgets
(ugh!).

I hope that people will not argue that users should not use
`customize-set-value' and `customize-set-variable', that they should
preferably use Customize. I think both have their advantages, and these
commands should be improved to make them viable alternatives. I also think
that Customize itself could be improved to allow for completion where
appropriate.

WDOT?

RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Drew Adams]

Resending.

The basic idea is to (1) let Customize use completion where possible and (2)
improve completion possibilities for `customize-set-value' and
`customize-set-variable'.

> From: Drew Adams Sent: Tuesday, November 06, 2007 2:46 PM
>
> Here are some proposals for discussion:
>
> 1. Rename `customize-set-value' to `set-option', and
>    `customize-set-variable' to `set-option-default' (or
>    add aliases). Users will find these names easier.
>    These commands provide much better interaction
>    for reading the new value than does the current
>    `set-variable'. Their interaction subsumes that of
>    `set-variable', which uses only property
>    `variable-interactive'.
>
> 2. Rewrite `set-variable' to set any variable, not just an
>    option, and when the variable is an option then have
>    the code do what `customize-set-value' does. That is,
>    provide better value input interaction, when possible.
>
> 3. `customize-set-(value|variable)' needs some improvement.
>    Here are some things I notice:
>
> a. `choice' for a list of `const' is good - it provides
>    completion, which is very handy - a great improvement
>    over what is available in Customize, IMO.  However,
>    there is no indication in the prompt that completion
>    is (sometimes) available. And when completion is
>    available, the default value should be the current
>    value of the option, for possible editing. Currently,
>    there is no default value.
>
> b. `choice' that includes a non-`const' choice, in
>    addition to `const' choices: the types of the
>    non-`const' choices apparently govern what happens:
>
>  - If the non-`const' choice types don't provide for
>    completion, then no completion is available for the
>    `choice' at all. It would be better to have non-strict
>    completion and allow for the value that doesn't match
>    any `const' to be read according to its type. If possible.
>
>  - And, if the non-`const' choices also provide for
>    completion, then it should be possible to combine them
>    with the `const' values into a general completion. E.g.
>    a `choice' of a `function' or (const :tag "None" nil)
>    currently completes only against function names -
>    neither "None" nor nil are allowed as completion
>    candidates. Why not just add "None" to the list of
>    candidates?
>
> c. `repeat' seems to read a sexp and evaluate to obtain
>    the complete list - the complete value. This is a
>    cop-out and is not very useful. It would be better to
>    repeatedly read values corresponding to the list
>    elements, and then combine them to get the overall
>    value. For example `repeat' of `sexp' should
>    repeatedly read a sexp (until, say, empty RET) and
>    return the list of sexprs that were read. And I don't
>    see why the command should `eval' at all for `repeat'
>    - why wouldn't it just read, like it does for the
>    other types? And the user has no feedback as to what
>    is expected to be input (beyond "[repeat]" in the
>    prompt) - nothing tells him to input a sexp that will
>    be evalled to produce the overall list value. (And
>    end users should not need to think in such terms, anyway.)
>
> c. (choice (const :tag "None" nil) regexp) reads a
>    regexp string, but the default is "", not nil, which
>    doesn't seem right. And if you type `nil' or `None',
>    then the literal string "nil" or "None" is interpreted
>    as a regexp. Again, it would be better to allow lax
>    completion with sole candidate "None" and allow a
>    regexp string value as well.
>
> d. For type `color', lax completion should be available,
>    choosing from color names but also allowing input of a
>    #RRRGGBBB hex string.
>
> #3 is the most important of these suggestions. I don't
> have time to work on this much myself, but I can
> contribute a little time if someone else lead on this.
> What's really needed is someone knowledgeable in custom
> and widgets (ugh!).
>
> I hope that people will not argue that users should not
> use `customize-set-value' and `customize-set-variable',
> that they should preferably use Customize. I think both
> have their advantages, and these commands should be
> improved to make them viable alternatives. I also think
> that Customize itself could be improved to allow for
> completion where appropriate.
>
> WDOT?

Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> 1. Rename `customize-set-value' to `set-option', and
>>    `customize-set-variable' to `set-option-default' (or
>>    add aliases). Users will find these names easier.

Agree. I have a hard time remember which is which of ..-set-value and 
..-set-variable.

BTW, would it be good if set-option-default had a final question whether 
to save the new value for future sessions?

>>    These commands provide much better interaction
>>    for reading the new value than does the current
>>    `set-variable'. Their interaction subsumes that of
>>    `set-variable', which uses only property
>>    `variable-interactive'.

What is the reason for keeping the current version of set-variable?

>> 2. Rewrite `set-variable' to set any variable, not just an
>>    option, and when the variable is an option then have
>>    the code do what `customize-set-value' does. That is,
>>    provide better value input interaction, when possible.

Sounds good.

>> 3. `customize-set-(value|variable)' needs some improvement.
>>    Here are some things I notice:

I am not sure it is worth the effort to allow completion directly for 
more complicated variables. Why not use the custom buffer in such cases 
(and of course allow good completion there)? Maybe set-option(-default) 
could suggest/ask about that in those cases? Or maybe switch to the 
custom buffer then? (If that is not too confusing.)

RE: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Drew Adams]

> >> 1. Rename `customize-set-value' to `set-option', and
> >>    `customize-set-variable' to `set-option-default' (or
> >>    add aliases). Users will find these names easier.
>
> Agree. I have a hard time remember which is which of ..-set-value and
> ..-set-variable.
>
> BTW, would it be good if set-option-default had a final question whether
> to save the new value for future sessions?

I'm generally against adding questions like that. If something like that is
needed, I usually prefer to do it only upon explicit user demand - e.g. via
prefix arg. And there are already commands for saving customizations, so I
really don't see the need to add that here.

> >>    These commands provide much better interaction
> >>    for reading the new value than does the current
> >>    `set-variable'. Their interaction subsumes that of
> >>    `set-variable', which uses only property
> >>    `variable-interactive'.
>
> What is the reason for keeping the current version of set-variable?

For me, none.  AFAICT, `customize-set-value' subsumes it.

But I think it's very important to rename `customize-set-*'. When you want
to set the value of a variable, you aren't necessarily thinking of
"customizing" - especially since this is normally used outside a Customize
buffer.

In fact, it took me a long time to discover that `customize-set-*' did
everything I would use `set-variable' for.

The Emacs manual, BTW, does not even mention `customize-set-value' or
`customize-set-variable'. In node Examining and Setting Variables, it says
to use `set-variable' to set a user option: "The most convenient way to set
a specific user option variable is with `M-x set-variable'.". And node Emacs
Server also explicitly advises you to use `set-variable'.

I'm guessing that the manual does not mention these commands because Emacs
developers don't use them (and vice versa). That would mean that I'm not
alone in having continued to use `set-variable' long past its prime. Or
perhaps whoever introduced `customize-set-*' didn't care much about them or
about the manual - dunno.

Knowing that these commands exist is important. If you happen, instead, to
use `set-variable' for a defcustom, and there is no explicit
`variable-interactive' property, then the custom type is not even used to
read the value - it is used only to check that it is of the right type
(IIUC). IOW, `set-variable' is strictly not as good as `customize-set-value'
for defcustoms, and it is equivalent to it for defvars with a
`variable-interactive' property.

> >> 2. Rewrite `set-variable' to set any variable, not just an
> >>    option, and when the variable is an option then have
> >>    the code do what `customize-set-value' does. That is,
> >>    provide better value input interaction, when possible.
>
> Sounds good.
>
> >> 3. `customize-set-(value|variable)' needs some improvement.
> >>    Here are some things I notice:
>
> I am not sure it is worth the effort to allow completion directly for
> more complicated variables.

Well, that's the main suggestion I'm making - I think completion is very
useful here. Customize is nice, especially for newbies, but with completion
you can move much quicker.

And as I also suggested (and you agree), Customize itself should let you
take advantage of completion. The current dialog is rudimentary without a
mouse. `RET' on `Value Menu' shows you a menu with numbered items and you
must read the items and then choose the right number. Completion, by
contrast, is a flexible and powerful dialog interaction. You need not
mentally map item number to item - just type to match. Completion is of
course even more useful if other kinds of completion matching are also
available (e.g. substring, Ido, Icicles).

[BTW, the `RET' menu is in fact broken if `pop-up-frames' is non-nil,
because the dialog leaves the `widget-choose' menu displayed (as a separate
frame) after you hit one of the menu-item numbers - it is never deleted.]

`customize-set-*' already provides some completion, but in only a limited
way. It is a good command, but some of the existing dialog is IMO a bit of a
cop-out. It looks as if someone just didn't have time to finish the job
(nothing wrong with that), which might also explain the incomplete state of
the manual. The treatment of `repeat' is a case in point - to me, that even
seems like a bug (why `eval' the user's input?). In any case, things could
be a lot better if some more effort were expended to provide completion
where possible. I hope someone will be interested in my suggestions
(previous mail).

> Why not use the custom buffer in such cases
> (and of course allow good completion there)? Maybe set-option(-default)
> could suggest/ask about that in those cases? Or maybe switch to the
> custom buffer then? (If that is not too confusing.)

No. The whole point is to have a quick and powerful command that you can use
*outside* Customize. There are already commands to use Customize to
customize things.

Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Lennart Borgman (gmail)]

Drew Adams wrote:
>> Why not use the custom buffer in such cases
>> (and of course allow good completion there)? Maybe set-option(-default)
>> could suggest/ask about that in those cases? Or maybe switch to the
>> custom buffer then? (If that is not too confusing.)
> 
> No. The whole point is to have a quick and powerful command that you can use
> *outside* Customize. There are already commands to use Customize to
> customize things.

I think it will be unusable for more complex defcustoms.

Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Richard Stallman]

    1. Rename `customize-set-value' to `set-option', and
    `customize-set-variable' to `set-option-default' (or add aliases). Users
    will find these names easier.

We don't currently suggest to users that they use those commands,
so making them easier to use does not seem like an important goal.

However, I agree that it is hard to remember which is which, so maybe
we should rename `customize-set-variable' to `customize-set-default'.

We could consider the suggestion that we start inviting users to use
those commands (in which case renaming them would be desirable), but
that is a different question.

    These commands provide much better interaction
    for reading the new value than does the current `set-variable'.

It doesn't seem to work very well at all.

I tried it with `case-fold-search' and it asked a y-or-n question.  I
can guess that the two answers correspond to the values t and nil, but
that wasn't clear.

I tried it with `yank-excluded-properties', and it displayed a garbled
prompt, which started with `[repeat] [choice]'.

If those bugs were fixed, would it be better or worse than
`set-variable'?  I am not sure.

    2. Rewrite `set-variable' to set any variable, not just an option,

If a bunch of people want it, ok.

								       and when
    the variable is an option then have the code do what `customize-set-value'
    does. That is, provide better value input interaction, when possible.

As I said above, I am not sure that is an improvement (and at present
it doesn't really work).

    3. `customize-set-(value|variable)' needs some improvement. Here are some
    things I notice:

I see you also ran into bugs in it.

Would someone like to fix them.

Re: customize-set-(value|variable) [was: apropos commands for commands, user options, all functions, all variables]

[Robert J. Chassell]

       1. Rename `customize-set-value' to `set-option', and
       `customize-set-variable' to `set-option-default' ...

   We don't currently suggest to users that they use those commands,
   so making them easier to use does not seem like an important goal.

As a rule, no one ever should use the customize commands unless they
are a novice or unless they do not understand a feature like fonts.
They are to help, not to replace `setq'.

The reason is that the customize commands provide even less an
increment of knowledge than `setq' because they are so readily
interactive and do not require additional knowledge.  In a .emacs
file, you must read the documentation on a variable although that
often tells little.  I fear that I still do not understand fonts
because my interactions with them has been through customize ...

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: customize-set-(value|variable) [was: apropos commands forcommands, user options, all functions, all variables]

[Drew Adams]

>        1. Rename `customize-set-value' to `set-option', and
>        `customize-set-variable' to `set-option-default' ...
>
>    We don't currently suggest to users that they use those commands,
>    so making them easier to use does not seem like an important goal.
>
> As a rule, no one ever should use the customize commands unless they
> are a novice or unless they do not understand a feature like fonts.
> They are to help, not to replace `setq'.
>
> The reason is that the customize commands provide even less an
> increment of knowledge than `setq' because they are so readily
> interactive and do not require additional knowledge.  In a .emacs
> file, you must read the documentation on a variable although that
> often tells little.  I fear that I still do not understand fonts
> because my interactions with them has been through customize ...


I don't know what to say, except that I disagree 100%.

An interactive function that provides completion and a degree of type
checking is much, much handier than using `setq' with `M-:'.

"As a rule, no one ever should use" rules like the one you propose, IMO.

Re: customize-set-(value|variable) [was: apropos commands forcommands, user options, all functions, all variables]

[Robert J. Chassell]

    An interactive function that provides completion and a degree of
    type checking is much, much handier than using `setq' with `M-:'.

Why would you use M-: (eval-expression) each time you want to evaluate
an expression rather than write it in a .emacs file?  In such a file,
you only need to write it once.  

To check it, I place point after it and run the command eval-last-sexp
(`C-x C-e') which I find easier to evoke than M-:.  (On my keyboard a
colon requires me to press a shift key.)  After I have written the
expression right, I leave it in my .emacs file.

In my .emacs file I have completion with the command
lisp-complete-symbol.

For temporary expressions, like
    (format "%c" ?\x8b8) 
and
    (ascii-display)
I use the *scratch* buffer.  (That is what is in it now.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

RE: customize-set-(value|variable) [was: apropos commandsforcommands, user options, all functions, all variables]

[Drew Adams]

>     An interactive function that provides completion and a degree of
>     type checking is much, much handier than using `setq' with `M-:'.
>
> Why would you use M-: (eval-expression) each time you want to evaluate
> an expression rather than write it in a .emacs file?  In such a file,
> you only need to write it once.

= When did I stop beating my wife?

I don't use `M-:' each time I want to evaluate an expression. I do use an
init file. Why do you assume otherwise?

I also use `M-:' sometimes. So what? Why would I write each expression I
want to evaluate in .emacs, just to be able to evaluate it using C-x C-e?

There is no one way to use Emacs. I think `customize-set-value', Customize,
and completion are all handy at times. You presumably prefer to write only
Lisp, and only in files or *scratch*. Vive la difference - Emacs has room
for us all.

> To check it, I place point after it and run the command eval-last-sexp
> (`C-x C-e') which I find easier to evoke than M-:.  (On my keyboard a
> colon requires me to press a shift key.)  After I have written the
> expression right, I leave it in my .emacs file.

Yes, and?  Did someone say you shouldn't do that? Nothing stops you from
doing all your customization in .emacs.

This discussion is about interacting with custom.el features. You're not
proposing that we remove Customize, `custom-file', `defcustom', and all the
rest, are you? Their existence doesn't prevent anyone from ignoring them and
using .emacs for everything.

> In my .emacs file I have completion with the command
> lisp-complete-symbol.

My hat is old. My teeth are gold. I have a bird I like to hold. (One Fish
Two Fish - T. Seuss Geisel)

No relation to the present discussion of using completion with custom.

> For temporary expressions, like (format "%c" ?\x8b8)
> and (ascii-display) I use the *scratch* buffer. (That is
> what is in it now.)

I use .emacs, *scratch*, and other, temporary and permanent Lisp files too.
I use C-x C-e et compagnie as well. They are all wonderful fellows. So what?

Re: customize-set-(value|variable) [was: apropos commandsforcommands, user options, all functions, all variables]

[Robert J. Chassell]

    I don't use `M-:' each time I want to evaluate an expression. I do
    use an init file. Why do you assume otherwise?

Because you said, "much handier than using `setq' with `M-:'".

I agree, "There is no one way to use Emacs."  Put another way, the
customise functions modify .emacs without the novice (or a more
experienced person) necessarily learning the Emacs Lisp that underlies
the modification.

I agree, different people use Emacs differently.  But the hope still
is that just about everyone will learn to set variables, write simple
defuns in their .emacs -- that sort of thing.  It is like the
adaptation to cars, which Americans made several generations ago:
everyone has to learn to drive on the correct side of the road because
many drivers cannot avoid a collision if you do not.

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc