Using "Emacs Configure" **and** modifying .emacs

[Ronald Fischer]

I'm using the Emacs Configure method
(Options/ConfigureEmacs/BrowseCustomizationGroups) to configure Emacs.
However, some configurations settings must be done by manually setting
the customizataion variables (at least according the FAQ) in the .emacs
file.

Now, the interactive emacs configuration **also** modifies .emacs. What
do I have to do to keep my settings and thos Emacs is writing, apart? I
don't want Emacs to override my settings, and I don't want the Emacs
configuration tool to get confused, just because my .emacs file contains
things I have put there.

Ronald

[Drew Adams]

> What do I have to do to keep my settings and thos Emacs is writing, apart? I
> don't want Emacs to override my settings, and I don't want the Emacs
> configuration tool to get confused, just because my .emacs file contains
> things I have put there.

Set variable `custom-file' to a file other than your init file.
Customize will then use that for the settings it writes, instead
of using your init file.

At an appropriate point in your init file, load the value of `custom-file'.
For example:

(setq custom-file "/my/path/to/my-customizations.el")))
(load-file custom-file) ; Load your customizations.

See the Emacs manual, node `Saving Customizations' for more info about
`custom-file'.

Note that even though `custom-file' is a user option, you can't easily
let Customize manage it - just set it using `setq'.

(IMHO, *everyone* should use variable `custom-file', to keep Customize
away from their init file.)

[Óscar Fuentes]

Ronald Fischer <yn...@mm.st> writes:

> I'm using the Emacs Configure method
> (Options/ConfigureEmacs/BrowseCustomizationGroups) to configure Emacs.
> However, some configurations settings must be done by manually setting
> the customizataion variables (at least according the FAQ) in the .emacs
> file.
>

> Now, the interactive emacs configuration **also** modifies .emacs. What

> do I have to do to keep my settings and thos Emacs is writing, apart? I
> don't want Emacs to override my settings, and I don't want the Emacs
> configuration tool to get confused, just because my .emacs file contains
> things I have put there.
>

> Ronald

I don't fully understand your question, but for keeping apart the settings you
make with what you call the "Configure method":

(setq custom-file "~/my-customizations.el")
(load custom-file 't)


If you already have something like

(custom-set-variables
...
)

in your .emacs, move it to the customizations file mentioned above.

[Emanuel Berg]

Ronald Fischer wrote:

> I'm using the Emacs Configure method
> (Options/ConfigureEmacs/BrowseCustomizationGroups)
> to configure Emacs. However, some
> configurations settings must be done by
> manually setting the customizataion variables
> (at least according the FAQ)

True, and the FAQ could also have told you that
doing things "manually" will enable you to do
much more than to specify certain pre-defined
settings, with a crowded and confusing
interface to juggle with in the bargain.

> Now, the interactive emacs configuration
> **also** modifies .emacs. What do I have to do
> to keep my settings and thos Emacs is writing,
> apart? I don't want Emacs to override my
> settings

Good intuition! One of many reasons not to
use Configure.

--
underground experts united
http://user.it.uu.se/~embe8573

[Emanuel Berg]

Drew Adams wrote:

> (IMHO, *everyone* should use variable
> `custom-file', to keep Customize away from
> their init file.)

(IMO, *no one* should use Customize, an even
better way to keep Customize away from their
init files.)

[Dan Espen]

I'm doing fine using customize and manual changes to .emacs.

Emacs keeps all it's changes in one place in the .emacs without
any special care on my part. So far anyway.


--
Dan Espen

[Drew Adams]

> > (IMHO, *everyone* should use variable `custom-file', to
> > keep Customize away from their init file.)
>
> I'm doing fine using customize and manual changes to .emacs.

I guess you mean that you use Customize and make manual
changes to your init file, but you do not use `custom-file'.

> Emacs keeps all it's changes in one place in the .emacs
> without any special care on my part. So far anyway.

Yes, it does. And provided you make your manual changes only
in _other_ places in the file, the two of you can cohabit that
space copacetically. Certainly doable. Been there; done that.

But is it generally a good idea to let a program modify a file
that you also edit manually?

IMO, that's just asking for trouble, like using the same
container for cleaning fluid and fruit juice, making sure to
wash it carefully in between. Doable. But not worth it.

And it provides NO benefit (that I can see). What reason is
there NOT to just point to a separate sandbox for Customize
to play with and mess around in? Simple, one-time. End of
story. No?

[Drew Adams]

> And provided you make your manual changes only in _other_
> places in the file, the two of you can cohabit that space
> copacetically.

Actually, even that is not quite correct. If you use the
same functions Customize uses, `custom-set-variables' and
`custom-set-faces', then Customize will be only too happy
to walk all over your changes.

[Dan Espen]

Drew Adams <drew....@oracle.com> writes:

>> > (IMHO, *everyone* should use variable `custom-file', to
>> > keep Customize away from their init file.)
>>
>> I'm doing fine using customize and manual changes to .emacs.
>
> I guess you mean that you use Customize and make manual
> changes to your init file, but you do not use `custom-file'.
>
>> Emacs keeps all it's changes in one place in the .emacs
>> without any special care on my part. So far anyway.
>
> Yes, it does. And provided you make your manual changes only
> in _other_ places in the file, the two of you can cohabit that
> space copacetically. Certainly doable. Been there; done that.
>
> But is it generally a good idea to let a program modify a file
> that you also edit manually?

Maybe, Emacs seems to manage the situation.

> IMO, that's just asking for trouble, like using the same
> container for cleaning fluid and fruit juice, making sure to
> wash it carefully in between. Doable. But not worth it.
>
> And it provides NO benefit (that I can see). What reason is
> there NOT to just point to a separate sandbox for Customize
> to play with and mess around in? Simple, one-time. End of
> story. No?

The benefit is having all your customizations in one place.

No need to email me, I'm reading Usenet gnu.emacs.help.

--
Dan Espen

[Emanuel Berg]

Dan Espen wrote:

> No need to email me, I'm reading Usenet
> gnu.emacs.help.

Perhaps you should switch to gmane.emacs.help
as gnu.emacs.help seems not to get all messages
anymore and there is no communication as to
what have changed.

[Ronald Fischer]

> > Now, the interactive emacs configuration

> > **also** modifies .emacs. What do I have to do

> > to keep my settings and thos Emacs is writing,
> > apart? I don't want Emacs to override my

> > settings
>
> Good intuition! One of many reasons not to
> use Configure.

... except that the FAQ explicitly suggest using Configure, when you
want to learn from it, how to customize Emacs:

https://www.gnu.org/software/emacs/manual/html_mono/efaq.html#Using-Customize

Funnily, when you search the FAQ how to do certain common
configurations, the suggestions always say that you should modify your
.emacs.... Kind of contradiciting.

Ronald

[Dan Espen]

Emanuel Berg <moa...@zoho.com> writes:

> Dan Espen wrote:
>
>> No need to email me, I'm reading Usenet
>> gnu.emacs.help.
>
> Perhaps you should switch to gmane.emacs.help
> as gnu.emacs.help seems not to get all messages
> anymore and there is no communication as to
> what have changed.

Like my .emacs, gnu.emacs.help seems to be working fine.

no "gmane" on Eternal.september, I'm not ready to slow gnus
down with another server.

--
Dan Espen

[Emanuel Berg]

Dan Espen wrote:

> Like my .emacs, gnu.emacs.help seems to be
> working fine.

It works great for the messages there, and if
they are all or close to all, no harm.

And I have no data as to the actual
discrepancy, if any, just a hunch.

gnu.emacs.help isn't always gnu.emacs.help
either, depending on server. This is something
I noted on nntp.aioe.org.

> no "gmane" on Eternal.september, I'm not
> ready to slow gnus down with another server.

True that, Usenet is faster than Gmane and in
particular gmane.emacs.help is very slow.

I have asked why on gmane.emacs.gnus.general
but no one seems to know or if they do they
ain't telling.

[Emanuel Berg]

Ronald Fischer wrote:

> Funnily, when you search the FAQ how to do
> certain common configurations, the
> suggestions always say that you should modify
> your .emacs.... Kind of contradiciting.

Well, what is it that you want to configure?

I would say that 98% of what people do with
Configure (that is productive, discounting
learning to figure out how to get lost in
the UI) - 98% of this can be done with

(setq whatever some-value)

which is as simple as it gets.

[HASM]

Emanuel Berg <moa...@zoho.com> writes:

> I would say that 98% of what people do with

> Configure ... 98% of this can be done with

> (setq whatever some-value)
> which is as simple as it gets.

I tend to agree with this, and have my init file(s) full of those.

However, and I forgot a bit all the details, but once I asked in the
mail list that handles one of the packages I use how to setq something
and was told to use configure instead, that was why configure was
created, and that using setqs wouldn't do it properly.

-- HASM

[Tomas Nordin]

Emanuel Berg <moa...@zoho.com> writes:

> I would say that 98% of what people do with

> Configure (that is productive, discounting
> learning to figure out how to get lost in

> the UI) - 98% of this can be done with

>
> (setq whatever some-value)
>
> which is as simple as it gets.

I tend to use that approach as well. But I am helped some times using
customize to browse options available in a hierarchical structure.

[notbob]

On 2017-08-11, Tomas Nordin <tom...@posteo.net> wrote:

> Emanuel Berg <moa...@zoho.com> writes:

>> (setq whatever some-value)

> I tend to use that approach as well. But I am helped some times using
> customize to browse options available in a hierarchical structure.

....and that is the problem. What are the "some-value"? I tried 2-3
variables until someone in this newsgroups gave me the proper value,
which at the time I was not even aware.

nb

[Emanuel Berg]

HASM wrote:

> However, and I forgot a bit all the details,
> but once I asked in the mail list that
> handles one of the packages I use how to setq
> something and was told to use configure
> instead, that was why configure was created,
> and that using setqs wouldn't do it properly.

As long as you setq to a value that makes
sense, it shouldn't be a problem.

[Emanuel Berg]

notbob wrote:

> ....and that is the problem. What are the
> "some-value"? I tried 2-3 variables until
> someone in this newsgroups gave me the proper
> value, which at the time I was not
> even aware.

Yes, and that is a fine way of doing it!

1) think
2) use the help system or manual
3) experiment
4) ask a friend (or NG)

[notbob]

On 2017-08-11, Emanuel Berg <moa...@zoho.com> wrote:

> 4) ask a friend (or NG)

Asking this newsgroup is not always a solution.

I've asked the same question 5-6 yrs apart. The first time my
question was not answered. The second time, it was fully answered.

I have zero idea why. ;)

nb

[Emanuel Berg]

notbob wrote:

> Asking this newsgroup is not always
> a solution.
>
> I've asked the same question 5-6 yrs apart.
> The first time my question was not answered.
> The second time, it was fully answered.
>
> I have zero idea why. ;)

Maybe, sometime during those five or six years,
they upgraded the robo-software that
answers questions?

[Drew Adams]

> > ....and that is the problem. What are the
> > "some-value"? I tried 2-3 variables until
> > someone in this newsgroups gave me the proper
> > value, which at the time I was not even aware.
>

> Yes, and that is a fine way of doing it!
> 1) think
> 2) use the help system or manual
> 3) experiment

> 4) ask a friend (or NG)

Thre seems to be some misunderstanding in this thread,
regarding the opposition "use setq" vs "use Customize".

`setq' is fine for setting a user-option value, but *ONLY IF*:

1. The value you set it to is one that "works" (is expected by,
and acceptable to, the code that uses it, so that it causes
that code to do the right thing).

2. The `defcustom' defining the option does not specify a
`:set' function or similar behavior (e.g. `:initialize').

A `:set' function is a trigger invoked by Customize
functions to set the option value. It should (must) be
used to set the option value, for proper behavior (see #1).

It is true that most user options are not defined with a `:set'
function, so you can usually get away with just blindly using
`setq', as long as you respect #1.

But if you want to set a user option using Lisp, then it is far
better to use `customize-set-variable', `customize-set-value',
or `custom-set-variables', than it is to use `setq'. These are
the functions that Customize itself uses.

`defcustom' is not `defvar'. It typically imposes a `:type';
it can impose a `:set' function; and so on. If you want to
use Lisp with user options, you will help yourself by getting
to know `defcustom'. (Which really means getting to know some
Customize functions.)

It is fine to use Lisp. It is generally not advisable to use
it without knowing what the functions you use do (or don't do).
That's one way to learn, of course, - by experimenting, but it
can also help to read the fine manual. Folks went to the trouble
of writing this stuff up to help you. ;-)

[Alan Mackenzie]

Hello, Emanuel.

Emanuel Berg <moa...@zoho.com> wrote:
> HASM wrote:

>> However, and I forgot a bit all the details,
>> but once I asked in the mail list that
>> handles one of the packages I use how to setq
>> something and was told to use configure
>> instead, that was why configure was created,
>> and that using setqs wouldn't do it properly.

> As long as you setq to a value that makes
> sense, it shouldn't be a problem.

There are some custom settings (I'm afraid I can think of anything
specific at the moment) where setting them via `customize-...' also
triggers a setting up function, which incorporates the new setting into
something deeper than just a variable value.

If you're going to be restricting yourself to not using the
`customize-...' interface, you'll have to be aware of which settings
need a setting up function called after their being set, and calling
those functions manually.

> --
> underground experts united
> http://user.it.uu.se/~embe8573

--
Alan Mackenzie (Nuremberg, Germany).

[Emanuel Berg]

Drew Adams wrote:

> Thre seems to be some misunderstanding in
> this thread, regarding the opposition "use
> setq" vs "use Customize".
>
> `setq' is fine for setting a user-option
> value, but *ONLY IF*

DANGER!

> It is fine to use Lisp. It is generally not
> advisable to use it without knowing what the
> functions you use do (or don't do).
> That's one way to learn, of course, - by
> experimenting, but it can also help to read
> the fine manual.

For setting single variables, one would think
using common sense, and the kind of common
sense that comes with using computers every day
and evermore pushing the envelope to increase
one's understanding, it would seem this would
be enough, at the very least if the docstring
(help system) also is consulted for the
specific setting. But reading the manual is
always encouraged, of course.

If the docstring isn't enough, but the manual
is, one can report it as a bug and suggest how
the docstring can be improved.

[Drew Adams]

> > It is fine to use Lisp. It is generally not
> > advisable to use it without knowing what the
> > functions you use do (or don't do).
> > That's one way to learn, of course, - by
> > experimenting, but it can also help to read
> > the fine manual.
>
> For setting single variables, one would think
> using common sense, and the kind of common
> sense that comes with using computers every day
> and evermore pushing the envelope to increase
> one's understanding, it would seem this would
> be enough, at the very least if the docstring
> (help system) also is consulted for the
> specific setting. But reading the manual is
> always encouraged, of course.
>
> If the docstring isn't enough, but the manual
> is, one can report it as a bug and suggest how
> the docstring can be improved.

Yes, the doc string for such an option should warn you
not to just use `setq'. But not every doc string is
perfect. ;-)

The Elisp manual, node `Variable Definitions' says:

‘:set SETFUNCTION’
Specify SETFUNCTION as the way to change the value of this option
when using the Customize interface. The function SETFUNCTION
should take two arguments, a symbol (the option name) and the new
value, and should do whatever is necessary to update the value
properly for this option (which may not mean simply setting the
option as a Lisp variable); preferably, though, it should not
modify its value argument destructively. The default for
SETFUNCTION is ‘set-default’.

If you specify this keyword, the variable’s documentation string
should describe how to do the same job in hand-written Lisp code.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

http://www.gnu.org/software/emacs/manual/html_node/elisp/Variable-Definitions.html

Note the second paragraph. If you define an option with a
`defcustom' that uses `:set', help users of your option by
letting them know how to change the value using Lisp. How
to change the value typically does not mean using only `setq'
in such a case.

[HASM]

> If you're going to be restricting yourself to not using the
> `customize-...' interface, you'll have to be aware of which settings
> need a setting up function called after their being set, and calling
> those functions manually.

Yup, that was the problem with one of my settings.

-- HASM

[Emanuel Berg]

Alan Mackenzie wrote:

> There are some custom settings (I'm afraid
> I can think of anything specific at the
> moment) where setting them via
> `customize-...' also triggers a setting up
> function, which incorporates the new setting
> into something deeper than just
> a variable value.

Let's see: a variable that triggers a function
when it (the variable) is set, only that only
works when it is set with a specific function?

And what happens if the variable is the the
old-fashion way? An inconsistent state as there
is now a mismatch between the variable value
and the un-triggered function?

Well, hell. In my experience, bad ideas can't
be circumvent by dealing with them the
supposedly right way. That can only prolong the
time before you realize it is a bad idea.

[Drew Adams]

> > There are some custom settings (I'm afraid
> > I can think of anything specific at the
> > moment) where setting them via
> > `customize-...' also triggers a setting up
> > function, which incorporates the new setting
> > into something deeper than just
> > a variable value.
>

> Let's see: a variable that triggers a function
> when it (the variable) is set, only that only
> works when it is set with a specific function?
>
> And what happens if the variable is the the
> old-fashion way? An inconsistent state as there
> is now a mismatch between the variable value
> and the un-triggered function?
>
> Well, hell. In my experience, bad ideas can't
> be circumvent by dealing with them the
> supposedly right way. That can only prolong the
> time before you realize it is a bad idea.

Yes, it is perhaps unfortunate that there is not a
more pervasive way to detect setting and thus trigger
application of the `:set' function.

On the other hand, this is Lisp, which means that code
can be generated and evaluated later etc., and it might
sometimes not be correct to trigger the function - at
least one can imagine that one size does not fit all
situations.

Still, I think we could improve things in this regard.
Perhaps by a symbol property that is checked when the
variable is set in any way (e.g. including by `set'
and `setq'). And perhaps by checking that some other
property or variable value does not override that
automatic set-triggering behavior. Dunno.

But the lesson _here_ is simply that this is the way
things are, and it behooves a Lisp users to be aware
of it. If you don't want to get bit then it is a good
idea to "deal with them the supposedly right way."

And that's not hard to do: just use `customize-variable'
instead of `setq', for user options. How hard is that?
If you want something shorter, define an alias...

[Drew Adams]

1. Q: What's a use case for a `defcustom' `:set' function?
A1: Add/remove a hook function, depending on the new option value.
A2: Perform some updating or synchronizing, after a value change.

;; hooking/unhooking
(lambda (sym val)
(custom-set-default sym val)
(if val
(add-hook 'isearch-update-post-hook
'isearchp-repeat-search-if-fail)
(remove-hook 'isearch-update-post-hook
'isearchp-repeat-search-if-fail)))

;; updating
(lambda (sym val)
(custom-set-default sym val)
(echo-bell-update))

;; synchronizing
(lambda (sym val) ; Synchronize an associated variable.
(custom-set-default sym val)
(setq isearchp-current-filter-preds-alist
isearchp-filter-predicates-alist))

2. Q: Wouldn't some `defcustom' features (`:set', :type', `:group',
etc.) be useful also for other, non-option Lisp variables?

A: Yes, I think so. (But it seems I'm a minority of one, here.)

See bug #27348, which provides a patch to let you do the same
things with `defvar' that you can do with `defcustom'.

(Actually, it provides a new macro, `defvarc', which is
`defcustom' with, by default, no interactive Customizing).

Here's the blurb motivating this feature (from bug #27348):

The ability to type-check, provide :set and :initialize
trigger functions, automatically :require libraries, add
links to doc, associate with one or more :groups, etc. -
these are useful things to be able to do with at least
some defvars, not just with defcustoms. Similarly, the
ability to persist non-option variables in a user's
custom file can be useful.

In sum, this enhancement makes it possible to uncouple
interactive customization from the other features that
`custom.el' offers, in particular, type-checking and
persistence, and to provide the latter for non-option
variables.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27348

[Emanuel Berg]

Drew Adams wrote:

> And that's not hard to do: just use
> `customize-variable' instead of `setq', for
> user options. How hard is that? If you want
> something shorter, define an alias...

I don't think it is about being difficult, or
long, rather what is the benefit?

What kind of function(s) get triggered? Is it
to ensure the new value of the variable makes
sense? That is, some variant of validating
the input?

Or is it to control behavior in a wider sense,
so that some function, that does something, is
set to something depending on the value of
the variable?

If so (the second case), I would simply have
a function, one umbrella function, that
branches depending on the variable value and
executes the desired function - i.e. no need to
change anything, but only act differently
depending on the value.

It could simply signal an error if the value
doesn't make sense, or if there is no
corresponding function to execute yet
implemented, which amounts to practically
the same.

If it is about validation, i.e. making sure the
variable value makes sense (is within some
range or have a certain type; is a member of
the input domain set) then I never bothered
with that.

Some people say you should "always" validate
input, but I never bothered. Errors come up to
surface anyway almost immediately and I never
had a problem with "ghost errors" that linger
on in the system for ages... at least none that
I'm aware of :)

[Emanuel Berg]

Another interesting thing is, if you write
a module, why would you write it so that it is
dependent on Customize?

Or should one consider `customize-option' to be
a part of Emacs rather than Customize per se?

It is in cus-edit.el, and the docstring only
says that

Customize SYMBOL, which must be
a user option.

No mention of triggering functions or the
purpose of using it.

It sure sounds like it is something Customize
does, and not something the user does
thru Elisp.

So back to what I would do, if I wanted this
"variable to trigger a function", why not write
it as part of the new module?

On the one hand, don't do the same thing, on
the other, don't interlink big software bodies
for such a small, potentially minimal
intersection...

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Aug 12, 2017 at 02:15:22AM +0200, Emanuel Berg wrote:
> Drew Adams wrote:
>
> > And that's not hard to do: just use
> > `customize-variable' instead of `setq', for
> > user options. How hard is that? If you want
> > something shorter, define an alias...
>
> I don't think it is about being difficult, or
> long, rather what is the benefit?

I think Drew has explained that pretty well. Besides,
the "defcustom" ("15.3 Defining Customization Variables"
node in the elisp doc does a good job, too.

> What kind of function(s) get triggered? Is it
> to ensure the new value of the variable makes
> sense? That is, some variant of validating
> the input?

Yes. (The :type arg of defcustom)

> Or is it to control behavior in a wider sense,
> so that some function, that does something, is
> set to something depending on the value of
> the variable?

Yes. (Among others, :set, but also perhaps :initialize,
:set-after, etc.)

> If it is about validation, i.e. making sure the
> variable value makes sense (is within some
> range or have a certain type; is a member of
> the input domain set) then I never bothered
> with that.

Some dont want a validation to explode deep whithin
the guts of some module loaded by another module,
where the user has no clue about what the heck is
going on, but next to the place where a variable
is being set to a value it's not supposed to have.

Sometimes I can sympathize with that :-)

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmOrrEACgkQBcgs9XrR2kYlOwCeJjt5XlKO4xweDzvtKcMktnu+
xB8AmwcmuNAVe6aIVWzLmQLR0VkLj2AQ
=Ubb4
-----END PGP SIGNATURE-----

[Emanuel Berg]

tomas wrote:

> Some dont want a validation to explode deep
> whithin the guts of some module loaded by
> another module, where the user has no clue
> about what the heck is going on, but next to
> the place where a variable is being set to
> a value it's not supposed to have.
>
> Sometimes I can sympathize with that :-)

One could also put validation at the beginning
of the functions that use the value, where it
(the function) checks its own parameters rather
than some global loose-cannon variable!

Which is also a much better design this
specific issue aside...

[to...@tuxteam.de]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Aug 12, 2017 at 09:43:23AM +0200, Emanuel Berg wrote:
> tomas wrote:
>
> > Some dont want a validation to explode deep
> > whithin the guts of some module loaded by
> > another module, where the user has no clue
> > about what the heck is going on, but next to
> > the place where a variable is being set to
> > a value it's not supposed to have.
> >
> > Sometimes I can sympathize with that :-)
>
> One could also put validation at the beginning
> of the functions that use the value, where it
> (the function) checks its own parameters rather
> than some global loose-cannon variable!

This is waht I meant by "guts": imagine Tramp, which
uses some access method deep in another module, which
then, for the first time, needs the variable. That
happens dynamically, at the moment you try to access
a file dependent on this method, long (perhaps weeks)
after you set the variable. Not very debugging-friendly.

Similarly (just another aspect of the same thing), this
can do away with that pesky "eval-after-load" you'd
need with the setq approach.

> Which is also a much better design this
> specific issue aside...

Hm. I get your point, but I get the opposite point,
too. "Better design" isn't always an absolute.

Cheers
- -- tomás

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlmOtfwACgkQBcgs9XrR2kaaiACdGSmdNM0CO+gN3cTuzbOk2m8e
rMUAnA26pe7Oyk1yYJN/h9OPX/pNExBl
=C1Ds
-----END PGP SIGNATURE-----

[Emanuel Berg]

tomas wrote:

> This is waht I meant by "guts": imagine
> Tramp, which uses some access method deep in
> another module, which then, for the first
> time, needs the variable. That happens
> dynamically, at the moment you try to access
> a file dependent on this method, long
> (perhaps weeks) after you set the variable.
> Not very debugging-friendly.

It is 50/50 if all this
superstructure/post-processing really does it
more debugging-friendly *or* if it just makes
it more complicated around a situation that is
bad to begin with.

Better to cut the head of the snake that take
your chances with the cobra dance.

> Similarly (just another aspect of the same
> thing), this can do away with that pesky
> "eval-after-load" you'd need with the
> setq approach.

If you `require' all the stuff that you need
step one, you don't need to bother with that.
(And it is also a good idea in general to do
so.) Find out where the variable is defined
(with the help system), require the module that
corresponds with the file, set the variable,
byte compile, done.

Also, on things that are pesky. I think it is
good pesky stuff are around. Or, well...
perhaps not "good". But I don't want to dispose
of any of them. You should be able to write
anything with Lisp, including horrible program
in even worse a style!

An example is indentation. I always do that and
rearrange stuff until it is exactly like I want
it. Perhaps someday long ago, this was a time
loss. But now, with functions, shortcuts,
finger habits (muscle memory), and typing, it
is actually a time-and-pleasure *gain* since it
makes me more relaxed and less prone to have
bugs, and quicker to find them. And you know,
"may I indent your code?" is the No. 1 hacker
insult. Still, when I wrote Python some ten
years ago, I don't know maybe that has changed,
but then indentation was mandatory in a certain
way and this happened as you typed! Which was
horrible and took the whole joy out of it, not
to mention there are tons of "indentation
schemes" that I use which I couldn't use.
So what this long story is telling you is - you
understand what I mean, right?

[Tomas Nordin]

Emanuel Berg <moa...@zoho.com> writes:

> insult. Still, when I wrote Python some ten
> years ago, I don't know maybe that has changed,
> but then indentation was mandatory in a certain

inconsistent indentation is a syntax error in Python, have you ever
heard of such a genius idea -- enforcing readable code

[Emanuel Berg]

Tomas Nordin wrote:

> inconsistent indentation is a syntax error in
> Python, have you ever heard of such a genius
> idea -- enforcing readable code

Indentation can be consistent in many ways, and
those many ways can co-exist at different
places, even next to each other in the
same file!

The enforcer cannot handle this but makes
everything the same.

Moving stuff around is also a way of writing
code, like a work method.

[Emanuel Berg]

tomas wrote:

> Similarly (just another aspect of the same
> thing), this can do away with that pesky
> "eval-after-load" you'd need with the
> setq approach.

In my Elisp, I have 231 `setq' and zero
`eval-after-load'. The secret? 242 `requires'!

And this message buffer has 1024 chars.

[ken]

Excellent idea. Here's a practical example:

Having a fairly large screen and often many windows open, it's sometimes
difficult to find the cursor in an emacs window. So I thought limegreen
would be a more discernible color for a cursor than the default black.
So I put this in my .emacs:

(set-cursor-color "limegreen")

However, the result is that only the first emacs window loaded has a
limegreen cursor. All the others subsequent have the default black
cursor. Running the same function in each emacs buffer does correctly
yield a limegreen cursor, but not a practical solution when I have
twenty or thirty buffers open, each in its own window (or frame).

The help documention (C-h f set-cursor-color) shows:

-----------------------------------------------------------------------
set-cursor-color is an interactive compiled Lisp function.

(set-cursor-color COLOR-NAME)

Set the text cursor color of the selected frame to COLOR-NAME.
When called interactively, prompt for the name of the color to use.
This works by setting the `cursor-color' frame parameter on the
selected frame.

You can also set the text cursor color, for all frames, by
customizing the `cursor' face.
-----------------------------------------------------------------------

If someone preferred to place a statement in .emacs to accomplish the
goal-- rather than "customizing"-- what should the above documentation say?

[Drew Adams]

> > Some dont want a validation to explode deep
> > whithin the guts of some module loaded by
> > another module, where the user has no clue
> > about what the heck is going on, but next to
> > the place where a variable is being set to
> > a value it's not supposed to have.
> >
> > Sometimes I can sympathize with that :-)
>
> One could also put validation at the beginning
> of the functions that use the value, where it
> (the function) checks its own parameters rather
> than some global loose-cannon variable!

You are presuming that only you and your functions
use or set the value.

If your variable is used by others then all bets
are off in this respect - you do not control how
it is used, set, etc.

> Which is also a much better design this
> specific issue aside...

If you are coding only for yourself then design is
a simpler question. In that context, do whatever
you think works best for you. Only you will know
or care.

[Drew Adams]

> Some dont want a validation to explode deep whithin
> the guts of some module loaded by another module,
> where the user has no clue about what the heck is
> going on, but next to the place where a variable
> is being set to a value it's not supposed to have.
>
> Sometimes I can sympathize with that :-)

Indeed.

TL;DR: Few start out embracing `defcustom'. Some end up
realizing how to live with it and take advantage of it.

At the risk of belaboring this (if that hasn't been
done already - if it has, apologies):

If you do everything you do with Emacs Lisp code only
for your own use then, yes, you can take care of all
places where a variable is used/set. You can find them
and make them do the right thing, even in situations
where dependent behavior is involved.

But if you provide code that others (people or libraries)
use then the situation can be a bit different. You have
no real control over all of the places and ways that a
variable might be set.

Declaring some things about the variable, its intended
behavior/uses (or non-behavior/non-uses) can serve to
_let others know what to expect_. It gives them a
heads-up, similar to how a code comment can do that.

If nothing else, you can think of `defcustom' as
providing such a declaration of intent - about the
types of values expected by your code, dependencies
wrt value changes, etc. `defcustom' is a way of
letting users (people, libraries) know stuff about
_your_ uses of the variable - what your code does
with it.

In the context of others who use your variable,
features provided by `defcustom' can be helpful.
Provided, that is, that they understand that it is
a variable that is helped by `defcustom', so that
they use `custom-*' and `customize-*' functions to
set and save it.

That's really the point, I think.

A library author uses `defcustom' to:

1. Let human users, especially but not only
non-Lispers, use Customize to _interactively_
browse, test, set, and persistently save the
variable.

2. Let other code take advantage of type-checking
(`:type'); setup, updating, synchronizing, etc.
trigger functions (`:set' etc.); linking to doc,
download, Commentary, etc. URLS (`:link');
persistence, etc.

That's all. No one is trying to make you use `custom*'
functions or Customize.

One point is that you will likely be interacting with
variables that someone has defined using `defcustom',
so it behooves you to understand what that means: what
`defcustom' offers and how you might take advantage of
that.

A second point is that if you write code that might be
used by others then you can take advantage of what
`defcustom' offers you and your users (people & code).
Not that you must; only that you can. Again, it can
help you to be aware of what `defcustom' offers;
that's all.

The same things apply to faces and `defface'.
`defface', `defcustom', and `defgroup' are your friends -
or they can be, if you are interested.

FWIW, many of us wrote Elisp code mainly for ourselves,
to start with. And many of us didn't care about or use
`defcustom'. And many of us didn't bother with Customize
interactively.

Later, some of us started sharing some of our code, and
we eventually started using `defcustom' to easily give
users a way to persist their choices. But we still
didn't really care about the various features `defcustom'
offers.

At some point, some of us fell upon the gotcha of trying
to set a user option created by someone else and not
realizing there was more going on than just changing the
value - e.g. a `:set' function.

We've all been pretty much where you are, I think
(Emmanuel), in case that helps. No one, I think, starts
out as a fan of Customize. Few, I think, realize or care
about the benefits of `defcustom' features, at the outset.

My bet is that as you share your code more with others
(people & libraries), those _users_ will help you learn
the benefits of `defcustom', and little by little you
will change your view: something like
i-dont-need-it--i-can-do-all-i-want-in-my-own-corner
will become something more like
i-can-do-this-to-make-things-easier-for-myself-and-users.

[Emanuel Berg]

ken wrote:

> (set-cursor-color COLOR-NAME)
>
> [...]

>
> If someone preferred to place a statement in
> .emacs to accomplish the goal-- rather than
> "customizing"-- what should the above
> documentation say?

Good question. That function doesn't do
anything for me. Maybe a Linux VT thing?

But don't you want the cursor to take on the
color of text? Here, for example, the cursor is
white (no or default face); in the citation
above, it is gnus-cite-1 which is blue; and
so on.

As for your issue, instead play with these:

(modify-face 'mode-line "white" "blue" nil t)
(modify-face 'mode-line-buffer-id "white" nil nil t)
(modify-face 'mode-line-emphasis "red" nil nil nil)
(modify-face 'mode-line-highlight "red" nil nil nil)
(modify-face 'mode-line-inactive "white" "green" nil t)

[Emanuel Berg]

Drew Adams wrote:

> If you are coding only for yourself then
> design is a simpler question. In that
> context, do whatever you think works best for
> you. Only you will know or care.

Oh, yeah?

And those poor techno-aristos that code for
a world audience have no choice but to stick
with a stupid idea which is having loose-cannon
global variables all fended up with a mechanism
that make sure no one fiddles with them the
wrong way?

Lucky us outlaws so far from the techno-capital
we can afford to do things in a sound way.
Here in the cyber-wild, not even the
techno-technos bother to hunt us down!

[ken]

On 08/12/2017 12:11 PM, Emanuel Berg wrote:
> ken wrote:
>
>> (set-cursor-color COLOR-NAME)
>>
>> [...]
>>
>> If someone preferred to place a statement in
>> .emacs to accomplish the goal-- rather than
>> "customizing"-- what should the above
>> documentation say?

> ...

>
> But don't you want the cursor to take on the
> color of text?

No, as I said, I want the color of the cursor to be limegreen:

> Having a fairly large screen and often many windows open, it's
> sometimes difficult to find the cursor in an emacs window. So I
> thought limegreen would be a more discernible color for a cursor than
> the default black. So I put this in my .emacs:
>
> (set-cursor-color "limegreen")
>
> However, the result is that only the first emacs window loaded has a
> limegreen cursor. All the others subsequent have the default black
> cursor. Running the same function in each emacs buffer does correctly
> yield a limegreen cursor, but not a practical solution when I have
> twenty or thirty buffers open, each in its own window (or frame).

It's really quite simple... to understand at least. Maybe though the
elisp which is needed to put in my .emacs is too complicated to determine?

[John Ankarström]

Emanuel Berg <moa...@zoho.com> writes:

> (IMO, *no one* should use Customize, an even
> better way to keep Customize away from their
> init files.)

I'll agree that the interface of Customize is a bit clunky, but
it's a good way to learn what values are available for each
option.

I don't think it's good to teach newcomers that `setq' is better,
because many user options depend on custom setters that aren't
fired by a simple `setq'. Customize is more portable and works
with everything.

- John

[John Ankarström]

Emanuel Berg <moa...@zoho.com> writes:

> (IMO, *no one* should use Customize, an even
> better way to keep Customize away from their
> init files.)

Sorry, Emanuel, I didn't

[Emanuel Berg]

John Ankarström wrote:

> I don't think it's good to teach newcomers
> that `setq' is better, because many user
> options depend on custom setters that aren't
> fired by a simple `setq'. Customize is more
> portable and works with everything.

If I'm allowed to deliberately misunderstand,
nothing is more portable than the Lisp REPL,
which is why there are so many dialects of
Lisp :)

I don't think Customize should be recommended
for newcomers, as it is so frustrating and
unpleasant to deal with, to the point they
might never return for a second Emacs session,
thinking the whole software is like that.

>> (IMO, *no one* should use Customize, an even
>> better way to keep Customize away from their
>> init files.)
>

> I'll agree that the interface of Customize is
> a bit clunky, but it's a good way to learn
> what values are available for each option.

This aspect is confusing at best. Because it
should be apparent from the context if for
example the value associated with a variable
should be for example a string or an integer.

And step two should be even less a concern,
because all strings and digits should be valid!
(Not all strings or digits need to be
practical, of course. But people understand
this. They don't assign crazy values.)

So I never had any problem whatsoever with
"what values are available"!

If it (the variable) should take on a data
structure to be processed, that needs to be in
a specific form to work - say, a list of lists,
this should be explained and exemplified in the
docstring. Again, no problems!

For example, with `nnmail-split-methods', the
docstring says:

Incoming mail will be split according to
this variable.

If you'd like, for instance, one mail group
for mail from the "4ad-l" mailing list, one
group for junk mail and one for everything
else, you could do something like this:

(setq nnmail-split-methods
'(("mail.4ad" "From:.*4ad")
("mail.junk" "From:.*Lars\\|Subject:.*buy")
("mail.misc" "")))

As you can see, this variable is a list of
lists, where the first element in each
"rule" is the name of the group (which, by
the way, does not have to be called
anything beginning with "mail", "yonka.zow"
is a fine, fine name), and the second is
a regexp that nnmail will try to match on
the header to find a fit.

The second element can also be a function.
In that case, it will be called narrowed to
the headers with the first element of the
rule as the argument. It should return
a non-nil value if it thinks that the mail
belongs in that group.

The last element should always have "" as
the regexp.

This variable can also have a function as
its value, and it can also have a fancy
split method as its value.
See `nnmail-split-fancy' for an explanation
of that syntax.

You can customize this variable.

[Emanuel Berg]

ken wrote:

> It's really quite simple... to understand at
> least. Maybe though the elisp which is needed
> to put in my .emacs is too complicated
> to determine?

Just like with Python and mandatory
indentation, perhaps there is an enforcer in
Lisp that makes it impossible to realize ideas
that the Lisper does not believe in?

[Emanuel Berg]

Drew Adams wrote:

> And that's not hard to do: just use
> `customize-variable' instead of `setq', for
> user options. How hard is that? If you want
> something shorter, define an alias...

In all honesty, one could actually do
just this, and it doesn't mean one would have
to use the Customize UI which will never happen
for many people anyway.

It will be interesting to see how many `setq'
has to be changed, and also if something
"breaks" after changing it to the right way!

[Emanuel Berg]

Emanuel Berg wrote:

> In all honesty, one could actually do just
> this, and it doesn't mean one would have to
> use the Customize UI which will never happen
> for many people anyway.
>
> It will be interesting to see how many `setq'
> has to be changed, and also if something
> "breaks" after changing it to the right way!

Here is something that can help speed up the
tracking down of user variables in code already
written:

(defun echo-user-variable ()
(interactive)
(let ((var (variable-at-point t))) ; ANY-SYMBOL
(if (custom-variable-p var)
(message "user variable")
(message "something else") )))
(defalias 'euv 'echo-user-variable)

[Emanuel Berg]

Emanuel Berg wrote:

> Here is something that can help speed up the
> tracking down of user variables in code already
> written:
>
> (defun echo-user-variable ()
> (interactive)
> (let ((var (variable-at-point t))) ; ANY-SYMBOL
> (if (custom-variable-p var)
> (message "user variable")
> (message "something else") )))
> (defalias 'euv 'echo-user-variable)

Another interesting thing is, because as we see
above it is easy to find out if a symbol is
a user variable or not, so why doesn't the
byte compiler warn when `setq' is used if it
really is a problem doing so?

[John Mastro]

Emanuel Berg <moa...@zoho.com> wrote:
> Here is something that can help speed up the
> tracking down of user variables in code already
> written:
>
> (defun echo-user-variable ()
> (interactive)
> (let ((var (variable-at-point t))) ; ANY-SYMBOL
> (if (custom-variable-p var)
> (message "user variable")
> (message "something else") )))
> (defalias 'euv 'echo-user-variable)

Here's a quick & dirty [and wrong in some way(s)] command you could use
to actively search for such variables. It only reports ones that, in
addition to meeting `custom-variable-p', have a `custom-set' property.

(cl-defun find-custom-set-variable ()
(interactive)
(let (sexp)
(while (and (re-search-forward "([ \t]*set[fq]\\_>" nil t)
(not (or (nth 3 (syntax-ppss))
(nth 4 (syntax-ppss))))
(setq sexp (ignore-errors
(save-excursion
(goto-char (match-beginning 0))
(read (current-buffer))))))
(cl-loop for (sym val) on (cdr sexp) by #'cddr
when (and (custom-variable-p sym) (get sym 'custom-set))
do (progn (message "`%s'" sym)
(cl-return-from find-custom-set-variable))))))

Besides any errors, one limitation is that it will of course only work
for variables defined in packages that have been loaded.

John

[Emanuel Berg]

John Mastro wrote:

> It only reports ones that, in addition to
> meeting `custom-variable-p', have
> a `custom-set' property.

Perhaps I should add that (`custom-set') to
mine as well...

> Besides any errors, one limitation is that it
> will of course only work for variables
> defined in packages that have been loaded.

That limitation is rather with the style of the
code that is examined, if it sets variables
before their respective packs have been loaded.
At least the byte compiler warns about that!

[Emanuel Berg]

> Perhaps I should add that (`custom-set') to
> mine as well...

;; The result:

;; erc-my.el, line 9: erc-user-full-name
;; erc-my.el, line 55: erc-header-line-format
;; mode-line.el, line 6: column-number-mode
;; mode-line.el, line 7: line-number-mode
;; spell-new.el, line 5: ispell-program-name
;; w3m-tabs.el, line 5: w3m-tab-width

;; 6 hits! :)

(require 'search-regexp-in-files) ; http://user.it.uu.se/~embe8573/emacs-init/search-regexp-in-files.el

(defun find-custom-set-vars (&optional buffer)
(interactive)
(let ((bfr (or buffer (current-buffer)))
(out-bfr (get-buffer-create "*CustomSetVariables*")) )
(with-current-buffer bfr
(save-excursion
(goto-char (point-min))
(while (re-search-forward "([[:space:]]*set[fq][[:space:]]*" nil t)
(let ((var (variable-at-point t)) ; ANY-SYMBOL
(line (line-number-at-pos)) )
(when (and (custom-variable-p var)
(get var 'custom-set) )
(with-current-buffer out-bfr
(insert
(format "%s, line %s: %s\n" bfr line var))) )))))
(pop-to-buffer out-bfr) ))

(defun fcsv-check-all-elisp ()
(let ((fs (files-as-list (format "%s%s" "~/.emacs.d/emacs-init/" "**/*.el"))))
(dolist (f fs)
(find-custom-set-vars (find-file-noselect f)))))

;; (fcsv-check-all-elisp)

[Emanuel Berg]

The program just written that was supposed to
track down mutants came up with the following
user variables that were incorrectly set with
`setq':

.emacs, 39: show-paren-delay
erc-my.el, 9: erc-user-full-name
erc-my.el, 72: erc-header-line-format
mode-line.el, 6: column-number-mode
mode-line.el, 7: line-number-mode
spell-new.el, 5: ispell-program-name
w3m-tabs.el, 5: w3m-tab-width

The other program just written confirms this -
possibly because they use the same criteria...

According to the thread,
`customize-set-variable' should be used rather
than setq. However that doesn't work - it won't
evaluate, and the byte compiler - which doesn't
mention the supposed "setq error" by the way -
the byte compiler doesn't accept the New Deal,
saying either

Wrong type argument: symbolp

or

Attempt to set a constant symbol: nil

The customize-set-variable interface is

(customize-set-variable VARIABLE VALUE
&optional COMMENT)

which sounds a lot like the setq interface,
namely

(setq [SYM VAL]...)

so why doesn't that work?

[Drew Adams]

> `customize-set-variable' should be used rather
> than setq. However that doesn't work - it won't
> evaluate, and the byte compiler - which doesn't
> mention the supposed "setq error" by the way -
> the byte compiler doesn't accept the New Deal,
> saying either
> Wrong type argument: symbolp
> or
> Attempt to set a constant symbol: nil
>
> The customize-set-variable interface is
> (customize-set-variable VARIABLE VALUE &optional COMMENT)
>
> which sounds a lot like the setq interface, namely
> (setq [SYM VAL]...)
> so why doesn't that work?

Hint, it's called `customize-set-variable', not `customize-setq-variable'. ;-)

You need to quote the symbol, if you want to pass a literal symbol.

(setq alpha 42) = (set 'alpha 42)

[John Mastro]

Emanuel Berg <moa...@zoho.com> wrote:
> According to the thread, `customize-set-variable' should be used
> rather than setq.

I would put it differently: it's fine to use `setq' on any variable,
it's just that there may be more to be done. You could therefore use
`customize-set-variable', but my preference is generally to view the
variable's definition, see whether a custom setter is defined, and
decide if I need to do anything about it.

> However that doesn't work - it won't evaluate, and the byte compiler -
> which doesn't mention the supposed "setq error" by the way - the byte
> compiler doesn't accept the New Deal, saying either

It's not an error to use `setq' on variables with custom setters.

> Wrong type argument: symbolp
>
> or
>
> Attempt to set a constant symbol: nil

`customize-set-variable' is a function, so its arguments are evaluated.
In other words, it's like `set' rather than `setq'.

John

[Drew Adams]

> > According to the thread, `customize-set-variable' should be used
> > rather than setq.
>
> I would put it differently: it's fine to use `setq' on any variable,
> it's just that there may be more to be done.

Maybe, maybe not.

A `:set' function for a given `defcustom' can do anything it wants.
It need not set the option value at all (surprise!). It can do
anything - or nothing.

Typically it does set the value. And typically it uses a function
such as `custom-set-default' to set it, which does what you might
expect. And often, as you say, it does something additional, often
after setting the value (or before, or both).

But you can't count on a typical case, any more (well maybe a
little more) than you can count on just using `setq' to DTRT.

> You could therefore use `customize-set-variable', but my
> preference is generally to view the variable's definition,
> see whether a custom setter is defined, and
> decide if I need to do anything about it.

That's fine. Extra work, in general, but it shouldn't hurt,
at least not in the short term.

Not sure why you would prefer that, but it sounds like it is so
that if you find you can get away with `setq' in some case then
you prefer to use that. Is that it?

And what if the library changes the `:set' function and you
upgrade? I'm not being facetious - I really don't see the
advantage/motivation.

[Emanuel Berg]

John Mastro wrote:

> my preference is generally to view the
> variable's definition, see whether a custom
> setter is defined, and decide if I need to do
> anything about it.

Oh, no!

Now we need a couple of programs to do that
as well!

You know when you say something to a female
that is appreciated and after that you are not
allowed to say anything because she is afraid
any elaboration will "ruin" it? It is the same
thing here! ... Or is it the other way around?

> It's not an error to use `setq' on variables
> with custom setters.

The byte compiler agrees.

[Emanuel Berg]

Drew Adams wrote:

> Hint, it's called `customize-set-variable',
> not `customize-setq-variable'. ;-)
>
> You need to quote the symbol, if you want to
> pass a literal symbol.

I'm already starting to dislike this whole idea
even more...

[Drew Adams]

> > Hint, it's called `customize-set-variable',
> > not `customize-setq-variable'. ;-)
> > You need to quote the symbol, if you want to
> > pass a literal symbol.
>
> I'm already starting to dislike this whole idea even more...

What whole idea? Lisp? `set'? Symbols?
Functions that evaluate their arguments?

(defmacro my-custom-setq (variable value)
"..."
`(customize-set-variable ',variable ,value))

(macroexpand '(my-custom-setq fill-column (1+ 41)))

--> (customize-set-variable 'fill-column (1+ 41))

[John Mastro]

Drew Adams <drew....@oracle.com> wrote:
>> You could therefore use `customize-set-variable', but my

>> preference is generally to view the variable's definition,
>> see whether a custom setter is defined, and
>> decide if I need to do anything about it.
>

> That's fine. Extra work, in general, but it shouldn't hurt,
> at least not in the short term.
>
> Not sure why you would prefer that, but it sounds like it is so
> that if you find you can get away with `setq' in some case then
> you prefer to use that. Is that it?

To be honest, I suppose I just find the whole customize mechanism a bit
ugly. If I need to e.g. call a function to recompute some things after
setting a variable, I'd rather do that directly.

Of course it doesn't generally make sense to give much weight to such a
vague aesthetic concern, but in this case it's cost me very little so
far to humor myself.

> And what if the library changes the `:set' function and you
> upgrade? I'm not being facetious - I really don't see the
> advantage/motivation.

Something in my configuration would break and eventually I'd realize it
and fix it :)

It's obviously a valid concern, but in practice it's never been an issue
in the 6-7 years I've been using Emacs so far. That's not very long
relative to Emacs, so I admit my practice is likely to allow some sort
of problem at some point.

John

[John Mastro]

You could even use something like the `csetq' defined here:
https://oremacs.com/2015/01/17/setting-up-ediff/

John

[Emanuel Berg]

The program that examined the source found only
7 variables. I thought maybe the low digit was
due to not all setqs being examined. So I added
a counter and sure enough, 218 cases were
examined. According to another program, I have
216 setqs. (The discrepancy of 2 will remain
a mystery.) Perhaps those customized variables
aren't that common! And why not? I never liked
the idea to begin with, and it would seem not
a lot of people did, at least not those who
wrote the components that I use the most.

[Emanuel Berg]

John Mastro wrote:

> To be honest, I suppose I just find the whole
> customize mechanism a bit ugly.

No doubt.

> Of course it doesn't generally make sense to
> give much weight to such a vague aesthetic
> concern, but in this case it's cost me very
> little so far to humor myself.

The "vague aesthetic concern" is also known as
*intuition*, which is something one should
train along any activity, and whose input one
should always consider...

[Robert Thorpe]

I don't have any problems with the Customize interface. It's usually
easier for me to find options through the Customize interface than using
the info manual or other methods. That's especially true now there's the
search bar.

The problem I have with Customize is the way that it modifies the init
file. It puts all of the settings into a single block. That block can
be in the init file or it can be in another file. It's always all in
one place.

In my view that makes it difficult to partition the init file well. I
want related things to be together. For example, I have a little code
that deals with Dired-X. I could customize the variable
dired-omit-files. If I do that though then they'll be info in two
places, in the customize block and the part of my code that deals with
Dired-X. That makes maintenance harder. So, I only use Customize for
finding options, once I've found them I set the manually. I use setq or
customize-set-variable if that's necessary.

What would improve Customize for me would be if it could search through
the init file and find places where a variable is being set and put the
modification there.

BR,
Robert Thorpe

[Emanuel Berg]

Robert Thorpe wrote:

> I don't have any problems with the
> Customize interface.

The problem with the interface is there are
a bunch of text and buttons all over and many
people come to Emacs because they have had it
with text and buttons all over. The buttons on
the keyboard are sufficient, thank you.

> It's usually easier for me to find options
> through the Customize interface than using
> the info manual or other methods.

Did you try C-h v and then auto-completion?
Or `apropos' and then search? If the package
has sound naming (prefix and then standard
computer lingo) I never had a problem finding
the variables. Often making a qualified guess
plus search is quicker than using the manual or
some other documentation to find it.

> The problem I have with Customize is the way
> that it modifies the init file. It puts all
> of the settings into a single block.
> That block can be in the init file or it can
> be in another file. It's always all in
> one place.

Indeed: extreamly ugly and impractical in
every sense.

> In my view that makes it difficult to
> partition the init file well.

Even more so if you have several files for
different packages, libraries, and so on!

The whole argument that ~"Customize hides its
edits in another file, so it doesn't matter how
it looks and it doesn't influence your init
files" - it *does* influence the init file(s)
in the sense that it displaces the configs from
there, you can't see what settings you have,
and you can't quickly go to the specific file,
change the one and only one setting you wish to
change, re-eval, and be done with it.

> I want related things to be together.

Everyone wants that and the easiest way to
achieve it is to instead of using tools to
write code use the keyboard for that.