(Sorry Arash, I noticed just now that I forgot to reply-all) On Tue, Apr 30, 2024 at 12:55 PM Arash Esbati <[email protected]> wrote: > > Paul Nelson <[email protected]> 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 _______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
