Hello Paul, On 02/12/2025, Paul D. Nelson wrote: > One worry is that I have found it tricky to reason about code when one > setting controls many logically unrelated features.
I take your point. However, I think from a user-perspective `preview-visibility-style` is logical enough by simply controlling visibility of the preview on and off-point, especially if we drop `off-point-deferred`. > One compromise would be to keep the individual knobs S/D/P and layer > 'preview-visibility-style' as a preset that simply sets S/D/P to the > combinations you listed. That saves users from juggling three booleans, > but allows the code to read in terms of simple predicates and retains > flexibility for users who might want some "nonstandard" combination. > (There's some precedent for such presets in cc-mode, org, ...) I think this is a good compromise in theory, but my worry is that by having /custom variables/ as you suggest, it indicated that all value combinations are valid and supported (if not otherwise documented). This means that we and future contributors to preview will have to make sure that any changes are compatible with all possible values of the custom variables even if only a smaller subset is in active use by most users -- I got tripped up by this multiple times forgetting to test a particular combination or another. This is why I prefer having fewer points of user customizations that give concrete and limited use-cases which are easily configurable and testable. So my thinking is that if you want to keep these individual knobs for maximum hackability as you suggest they should be defvar's instead of defcustom's (possibly documenting that they are internal), though my preference is still to simply have a single customization variable which we can use directly in the code. Best regards, -- Al _______________________________________________ bug-auctex mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-auctex
