Re: regexp linting run in Emacs tree

[Mattias Engdegård]

5 aug. 2019 kl. 19.17 skrev Paul Eggert <address@hidden>:
> 
> 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.