bug#70525: [PATCH] Make auto-reveal customizations easier to extend

[Paul Nelson]

(Sorry Arash, I noticed just now that I forgot to reply-all)

On Tue, Apr 30, 2024 at 12:55 PM Arash Esbati <arash@gnu.org> wrote:
>
> Paul Nelson <ultrono@gmail.com> writes:
>
> > I think essentially the same criticism applies.  What if the user has
> > customized *-reveal to, say, '(eval (my-cool-function (my-arg-1
> > my-arg-2))), with totally different semantics than the default?  Then
> > the tweaks under "Clause added" would become meaningless.
>
> Well, my answer would be: Don't use `eval' and do
>
>   '(my-cool-function (my-arg-1 my-arg-2))

I don't see how this helps.  We can't add commands as additional
arguments to the user-provided my-cool-function, because we don't know
its semantics.  (Maybe it only takes two arguments, and maybe those
arguments are strings or the time of day or the moon cycle rather than
commands that should be compared against this-command.)


>
> > Is the intent behind your suggestions that you'd like to keep the
> > number of customizable variables low, or something else?
>
> No, I think I'm trying to avoid the case where we introduce a new list
> (custom option) which is probably not needed and we have to deal with it
> only because of that `eval'.  Is that eval actually needed at all?

I suppose the "eval" could be moved from the customization option into
*-reveal-p function, but I don't see what this gains (other than
forcing anyone who has customized this option to adjust their config).

I don't see any way to allow the user to do everything they want (the
current behavior), keep the interface the same, and make the list of
commands easily extensible other than by adding an additional list
variable.  The variable seemed best to me as a customization option,
since the user might wish to add to it in their own config, but could
just as well be a defvar as far as I'm concerned.  Other suggestions
would be welcome.

Thanks, best,

Paul