On Fri, 4 Nov 2011 23:51:55 -0400, Austin Clements <amdragon@mit.edu> wrote: > This seems like a good option to have, but your approach seems > unnecessarily complicated. I'm always wary of defcustom's :set because > it means you can't just setq the variable, which defeats the > underlying beauty of the customize system. Actually I use it with setq without any problem. But yes, it's too complicated... > You could eliminate the other two variables and compute them on the > fly, or, if you really feel they may need to be controlled > independently, make the custom variable a pair or alist (which you can > hide behind a few const choices). Computing them on the fly is probably cleaner. But I'm not sure if the switch-function and dedicated flag must be independent or not. From what I've tested it's *much* more pleasant to use with the dedicated flag, but I don't know how other people feel about this... > Alternatively, it seems like the variable could instead > take a single function (basically what notmuch-mua-switch-function is > now) and you could provide two new functions that simply combine > switch-to-buffer-other-x and set-window-dedicated-p. I've tried that, but for some reason it doesn't work when forwarding a message: the dedicated flag is reset somewhere inside message-forward, but I don't know where nor why. (I haven't investigated much though.) > The defcustom would be more user-friendly if it gave a choice between > const values, rather than requiring the user to enter a symbol value > (and then possibly rejecting it on validation). Something like > :type '(choice (const :tag "Compose in the current window" current-window) > (const :tag "Compose mail in a new window" new-window) > (const :tag "Compose mail in a new frame" new-frame)) Yep, that's much better. I'll try to rewrite this patch using this and on-the-fly computations of the switch-function and dedicated flag. Thank you for the review! Regards, -- Thomas/Schnouki