Re: [AUCTeX-devel] Re: Usability of docTeX-mode

[David Kastrup]

Ralf Angeli <address@hidden> writes:

> * David Kastrup (2006-07-23) writes:
>
>> Uh yes.  One would probably have to check for boundness:
>
> Okay, now it works.
>
>> (defun TeX-local-list-setter (var value)
>
> It's a nice idea, but the implementation you proposed is quite
> fragile.  It breaks if you append values to the end or insert values
> in the middle of the list.

It breaks if you do anything except push values to the beginning of
the list of a local variable.  And we are talking about a local
variable that is supposed to be manipulated _only_ by our own code,
and only by pushing additional stuff on.  That's what the explicitly
named local shadow variables are supposed to effectively provide,
anyway.

So we can easily guarantee that.

There are still problem cases: if the variable is made local and
nothing added to it (for example, if add-to-list is used for an
already existing entry), it will not get identified as being replaced
altogether.  So another check is required.  And also we must be
careful not to pick up buffer-local bindings instead of the default
elsewhere.  This makes it

(defun TeX-local-list-setter (var value)
  (when (default-boundp var)
    (let ((old (default-value var)) tail)
      (dolist (buffer (buffer-list))
        (when (local-variable-p var buffer)
          (with-current-buffer buffer
            (setq tail (symbol-value var))
            (if (eq tail old)
                (set var value)
              (while (consp tail)
                (if (eq (cdr tail) old)
                    (progn
                      (setcdr tail value)
                      (setq tail nil))
                  (setq tail (cdr tail))))))))))
  (custom-set-default var value))


Personally, I'd consider it tolerable to demand from the user
reparsing after customization, but you did not like that.  This code
is just professional courtesy, in a way of speaking.  If it fails,
reparsing the buffer is still an option for the user.

> The scope this is supposed to be applied to is currently quite
> limited, so it's not a big problem.  But it might be nice to have a
> generalized version in case the scope becomes wider.

I don't see a reasonable generalization that is bound to work except
for the case of local push-ons onto the default value.

> At least the limitation should be documented prominently.

Sure.  This is just a sketch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum