* David Kastrup (2006-07-22) writes:
> David Kastrup <[EMAIL PROTECTED]> writes:
>
>> Ralf Angeli <[EMAIL PROTECTED]> writes:
>>
>>> * David Kastrup (2006-07-14) writes:
>>>
>>>> But to save the user the work of rescanning the buffer after a change
>>>> of the parsing variables seems a bit pointless.
>>>
>>> Not if you want to spare the user having to think about rescanning the
>>> buffer. That's one thing less the user has to care about. Is there a
>>> reason not to be as userfriendly as possible if that's achievable with
>>> moderate effort?
>>
>> I consider it not userfriendly to double the amount of variables he
>> has to look for. If we want to save the user the trouble of applying
>> his changes manually to existing buffers after customization, we can
>> use an appropriate setter function.
>
> Something like
>
> (defun TeX-local-list-setter (var value)
Evaluating
(progn
(defun TeX-local-list-setter (var value)
(let ((old (symbol-value var)) tail)
(dolist (buffer (buffer-list))
(when (local-variable-p var buffer)
(with-current-buffer buffer
(setq tail (symbol-value var))
(while (consp tail)
(if (eq (cdr tail) old)
(progn
(setcdr tail value)
(setq tail nil))
(setq tail (cdr tail))))))))
(custom-set-default var value))
(defcustom foo nil
"Some var.")
(make-local-variable 'foo)
(TeX-local-list-setter 'foo '(a b))
(customize-variable 'foo))
will result in
foo: Hide Value (a b)
State: CHANGED outside Customize; operating on it here may be unreliable.
That means there are two effects I don't want to happen. First, the
changed value shows up in the customization buffer. If a style file
adds some elements to the respective list I don't want the user to see
them because those additional elements are purely a result of the
LaTex files he loaded before and not the general case. Second, the
State description issues a warning that operating on the value may be
unreliable. That might be confusing for the user. I don't know if
this is intentional, though.
Again, the user has no business in looking at the local variables.
--
Ralf
_______________________________________________
auctex-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/auctex-devel
