Vincent Belaïche <vincent....@hotmail.fr> writes: Hi Vincent,
> 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. That sounds like strange logic to me. Say we have the dialects :a, :b, :c and :d. Then if I do (TeX-add-style-hook "foo" (lambda () ...) (not (or :a :b))) I want it to run for both dialects :c and :d. Same for (nor :a :b). The two dialect expressions should be equivalent in every case. > 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. I don't see why that should be different. With sets, `or' is basically the union. So (not (or :a :b)) would mean "not in the union of the single-element sets :a and :b", i.e., "not in the set (:a :b)" which would still be (:c :d). > 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). I very much hope so. > 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. Well, if it's shorter, simpler and easier to maintain, please do so! Bye, Tassilo _______________________________________________ auctex mailing list auctex@gnu.org https://lists.gnu.org/mailman/listinfo/auctex