[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: regexp linting run in Emacs tree
From: |
Mattias Engdegård |
Subject: |
Re: regexp linting run in Emacs tree |
Date: |
Mon, 5 Aug 2019 23:18:11 +0200 |
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.