On Mon, 09 Apr 2007 10:51:42 +0200, martin rudalics wrote: >>>(defcustom whitespace-check-indent-whitespace indent-tabs-mode > >> "Flag to check indentation whitespace. This is the global for the > >> system. > > > > > > That fails to do the right thing if the user changes indent-tabs-mode > > mode after whitespace.el is loaded -- which is certainly not > > unlikely, especially given that indent-tabs-mode is automatically > > buffer local, and traditionally set on a per-buffer basis! > > I have to admit that I wanted the original poster to describe exactly > this sequence of events.
I set it in custom-set-variables; another likely scenario, I would think. With regard to your request, I'm unfamiliar with -Q and so far I haven't found documentation for it. So, more explicit instructions about what you'd like me to try would be appreciated. > > In general, using another variable as the initial value in a > > defvar/defcustom is almost never the right thing for exactly this > > reason. > > In particular if the variable comes from another group. > > > The right thing to do with whitespace.el is probably support a > > special `auto' value for such settings. For instance, in > > `whitespace-cleanup-internal', instead of just checking the value of > > `whitespace-check-buffer-indent' (the "local" version of > > `whitespace-check-indent-whitespace'), it could do something like: > > > > (if (eq whitespace-check-buffer-indent 'auto) > > indent-tabs-mode > > whitespace-check-buffer-indent) > > IMHO there's no reasonable way to reconcile a user's settings of > `indent-tabs-mode' with those of `whitespace-check-indent-whitespace'. I > think `whitespace-indent-cleanup' should be executed iff > `indent-tabs-mode' is non-nil in the current buffer. But I'm afraid > that anything we change here will break existing customizations. Why isn't it reasonable for whitespace-indent-cleanup to change tabs in indentation to spaces when indent-tabs-mode is nil? -- Braden McDaniel e-mail: <[EMAIL PROTECTED]> <http://endoframe.com> Jabber: <[EMAIL PROTECTED]> _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
