Re: regexp linting run in Emacs tree

["Mattias Engdegård" <mattiase@acm.org>]

5 aug. 2019 kl. 19.17 skrev Paul Eggert <eggert@cs.ucla.edu>:
> 
> I'm afraid that'd still be more clutter than it's worth, at least to me.

Well, it's faster than the current code in the common case[*]. It also reflects the intended semantics better; the current code relies on the implicit tolerance for duplicates in skip-chars-forward.

> Instead, how about changing the delinter to omit this particular warning if the regexp was computed from a configurable variable (as opposed to an ordinary variable)?

That's a very ad-hoc rule which just happens to fit this very situation but isn't really causally connected to the false positive in a reasonable way. It could just as well have occurred in a different way, or resulted in a different warning. It just goes to show how hard it is to make an algorithm understand when a human programmer knowingly breaks the rules to achieve a certain effect.

As I see it, it's either the proposed memq change which makes the code faster and (arguably) clearer, a formal suppressive comment, or seeing this instance every time (and remembering to ignore it).

[*] Benchmarked:

(defun f (c) (string c ?\s ?\t))
(defun g (c) (if (memq c '(?\s ?\t)) " \t" (string c ?\s ?\t)))

g is about twice as fast as f for c=32; less allocation, and memq is a bytecode op while string isn't.