GNU bug report logs - #36237
Support (rx (and (regexp EXPR) (regexp-quote EXPR)))

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattiase <at> acm.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 36237 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>, kevin.legouguec <at> gmail.com
Subject: bug#36237: Support (rx (and (regexp EXPR) (regexp-quote EXPR)))
Date: Sun, 23 Jun 2019 13:09:46 +0200

23 juni 2019 kl. 00.05 skrev Noam Postavsky <npostavs <at> gmail.com>:
> 
> Yeah, that applies to most of the examples actually.  Updated (and I
> found a couple of mistakes in them).

Very good, thank you! I double-checked them with xr and only found one error (see below).

>> The paragraph on `eval' uses FORM, which is too generic
> 
> No, it's not generic, see (info "(elisp) Intro Eval"):
> 
>       A Lisp object that is intended for evaluation is called a "form" or
>    "expression"(1).

You are entirely correct, of course; what I meant is that the docs frequently use "form" for the `rx' whatchamacallits even though they aren't Lisp expressions. The terminology is a mess; use whatever you find understandable.

>squash! Support (rx (and (regexp EXPR) (literal EXPR))) (Bug#36237)

Remnants of rebase editing?

 ;; "[ \t\n]*:\\([^:]+\\|$\\)"
-;; (rx (and (zero-or-more (in " \t\n")) ":"
-;;          (submatch (or line-end (one-or-more (not (any ?:)))))))
+;; (rx (* (in " \t\n")) ":"
+;;     (submatch (or line-end (+ (not (in ?:))))))

The correct translation of the `or'-pattern is

  (or (+ (not (any ":"))) eol)

since the order of the branches matters. Maybe it's the regexp string that should be the other way around; hard to tell without any context.

 ;; "^;;\\s-*\n\\|^\n"
-;; (rx (or (and line-start ";;" (0+ space) ?\n)
-;;         (and line-start ?\n)))
+;; (rx (or (seq line-start ";;" (0+ space) ?\n)
+;;         (seq line-start ?\n)))

This should be correct. The regexp compiler translates `[[:space:]]` and `\s-` to different bytecodes, but as far as I can tell they end up having identical semantics in the end. Same goes for `[[:word:]]' vs `\sw' (alias `\w'), and so on.

+`(literal STRING-EXPR)'
+     matches STRING-EXPR literally, where STRING-EXPR is any lisp
+     expression that evaluates to a string.
+
+`(regexp REGEXP-EXPR)'
+     include REGEXP-EXPR in string notation in the result, where
+     REGEXP-EXPR is any lisp expression that evaluates a string
+     containing a valid regexp.

Missed "to" after "evaluate"?

I'm happy with the patch after the obvious fixes.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.