Ok, now I look into Tassilo's feedback on the patch itself... > To: auctex@gnu.org > From: t...@gnu.org > Date: Tue, 9 Sep 2014 08:49:26 +0200 > Subject: Re: [AUCTeX] Problem with latex2e style hook --- LaTeX/Texinfo > collision > > Vincent Belaïche <vincent....@hotmail.fr> writes: > > Hi Vincent, > > > Please ignore the previous patch attachment: I had not made all the > > corresponding updates in the ChangeLog. > > Ok. Some last nitpicks below. > > > diff --git a/tex.el b/tex.el > > index f3316d5..9bbcb29 100644
[...] > > +For supported dialects, see variables `TeX-style-hook-dialect'.") > > Could you please add a comment here that you don't manipulate that > variable directly but only via `TeX-add-style-hook' and friends which > will take care of the correct sorting? > Good idea, I will do that... > > +(defun TeX-shdex-nor (&rest args) > > + "NOR operator for style hook dialect expressions. The returned > > +value is a list of dialects that are in > > +`TeX-style-hook-dialect-list' but not in ARGS." > > + (setq args (apply 'TeX-shdex-or args)) > > Shouldn't that apply `TeX-shdex-eval' on the args? > No, I need `or' because it does more than just evaluating each elements in the args list, it also sorts the output of evaluation, and this is needed by the sequel of the nor algorithm. BTW, in my previous email I proposed a defun for (not...), but please note that with this defun `not' must have one single *dialect* argument (`dialect' as opposed to `dialect expression'). So (nor x y) is equivalent to (not (or x y)) only in the case when (or x y) is a one element list. Please note that in my initial contribution you told that `not' would be better named `nor', and this is why I did rename it. However I think that it could have kept the original name `not' even if not unary. After all, the SORTED-DIALECT-LIST element of the hook vector is a particular implementation of a `set' object. These SORTED-DIALECT-LIST are just non empty sets. Maybe it would have been preferable to implement this `set' thing as a bitmap: it is quite unlikely that AUCTeX will ever have to handle more dialects than there are bits in an integer (currently 23). Bitwise logical operators are maybe better suited to make the job. That would be simpler, shorter, easier to maintain code, and if you wish I can update the patch towards this. Anyway, as a minimal change I will update the patch so that TeX-style-hook-dialect-list is defined like (TeX-shdex-or :bibtex :latex :texinfo ) to remove the dependancy on a particular sorted-list based implementation. In the same vein, within `TeX-run-style-hooks', I will replace: (memq TeX-style-hook-dialect (aref hook 2)) (TeX-shdex-in-p TeX-style-hook-dialect (aref hook 2)) with (defalias 'TeX-shdex-in-p 'memq) > > +(defun TeX-shdex-eval (&rest args) > > + "Evaluate a style hook dialect expression ARGS." > > + (sort (apply 'append (mapcar > > + (lambda (dialect-expr) > > + (cond > > + ((symbolp dialect-expr) > > + (list dialect-expr)) > > + ((and (consp dialect-expr) > > + (memq (car dialect-expr) '(or and nor))) > > + (apply (intern > > + (concat "TeX-shdex-" (symbol-name (car dialect-expr)))) > > + (cdr dialect-expr))) > > + (t > > + (error "Invalid dialect expression : %S." dialect-expr)))) > > + args)) > > + 'string<)) > > Please move that before the operator functions because they call it to > remove some undefined function warnings. > Ok, I will do that also. > Bye, > Tassilo > Bye, Vincent. > > _______________________________________________ > auctex mailing list > auctex@gnu.org _______________________________________________ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex
