[boruch_baum@xxxxxxx: Re: Re: w3m-pop-up-windows and w3m-use-tab]

[Boruch Baum <boruch_baum@xxxxxxx>]

I had a problem with my internet connection while trying to send this,
and it seems that it wasn't transmitted, so here goes a second time...

----- Forwarded message from Boruch Baum <boruch_baum@xxxxxxx> -----

Date: Thu, 15 Mar 2018 23:50:30 -0400
From: Boruch Baum <boruch_baum@xxxxxxx>
To: emacs-w3m@xxxxxxxxxx
Subject: Re: [emacs-w3m:12939] Re: w3m-pop-up-windows and w3m-use-tab
User-Agent: NeoMutt/20180223

On 2018-03-16 09:39, Katsumi Yamaoka wrote:
> In [emacs-w3m:12938]
> To change the display mode immediately while emacs-w3m is running, a
> user has to use `M-x customize-option'

That can have undesirable side-effects. The one that comes to mind
immediately is that if one is in a w3m session and wants to permanently
change an option using customize-option, the change is saved to a data
structure in the user's init file, not the user's emacs-w3m-init file or
wherever else the user has decided to set it. This can result in
configuration information in multiple places, generating conflicts and
confusion. Part of the problem is alluded to in a comment that emacs
itself attaches to the data structure in your .emacs file:

 ;; custom-set-variables was added by Custom.
 ;; If you edit it by hand, you could mess it up, so be careful.
 ;; Your init file should contain only one such instance.
 ;; If there is more than one, they won't work right.

You could respond by advising the user "remember not to do that", but as
a statistic, many users will forget, and other users who come to emacs
to be able do things their own way will find it alien to be asked by
emacs-w3m to do it one way only.

Another problem of that data structure is that it organizes variables
alphabetically, not by package. I think at some point years ago I
submitted a bug report / feature request about that, for naught (emacs
doesn't seem to have a public bug report database; maybe I have a record
in an old email archive).

> Because defcustom is the main user's tool to modify user options,

I challenge that it is the *main* tool. I would agree that it is a
*convenience feature* added to emacs.

> there are more than a few variables that require a user to use
> `customize-option' to modify the actual behavior of Emacs. Try ``grep
> ':set' *.el'' in the Emacs source.

Does that mean a user is *required* to use `customize-option' for all of
them, or just that it's an option? I've never seen emacs documentation
or docstrings requiring that, only offering the option.

>
> > Now, changing any of the variables at any time has an immediate
> > effect.
>
> I know your approach aims to do it, but I don't like to do it for
> the feature that wouldn't be used so frequently because it can
> make the emacs-w3m code complicated[1] and force an overhead.

It strikes me as inconsistent, in that up until now, for all other
emacs-w3m variables (and for that matter all variables everywhere in
emacs) I have always felt free to manually evaluate variables. It is
rare indeed for me to ever use `customize-option' anywhere in emacs, and
when I do I almost always immediately move the result out to somewhere
else (see my note to your footnote [1]).

> But if you don't like to use `customize-option'[2], how about
> making it a special minor mode?  Using `define-minor-mode' would
> be cool; it provides the ones equivalent to:
>
> (defcustom w3m-display-mode nil
>   "A variable.")
>
> (defun w3m-display-mode (&optional mode)
>   "A function."
>   (interactive (list (completing-read "Mode: " ...)))
>   (setq w3m-use-tab 'foo)
>   (setq w3m-pop-up-windows 'bar)
>   (setq w3m-pop-up-frames 'baz))

That looks elegant! I do like that very much. Users would still need to
be warned how the new variable would interact with the other three.
Would their definitions be changed from decustom to defvar?

> [1] It's already complicated enough? ;-)

Quite agreed. Apropos that, I wanted to insert my own footnote here in
my response, but that would *really* have been complicated and
confusing, so I'll mention here that the only entries in my
`customize-set-variables' data structure are long color vectors and
`custom-safe-themes', whose nature make their output and manipulation
more convenient to use a gui-style interface. But that's not the case in
our situation.

> [2] I don't like to use `customize-option' so much, but I like
> designing :type, :set, and :get forms of defcustom very much. ;-)

Off-topic, but if you like those, you might appreciate the features of
`use-package'.

----- End forwarded message -----

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0