[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer
From: |
npostavs |
Subject: |
bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer |
Date: |
Sat, 08 Apr 2017 11:38:28 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Philipp Stephani <p.stephani2@gmail.com> writes:
>>> - Coupling of unrelated entities is always an antipattern.
>>> - For N iterables and M looping constructs, you need to implement
>>> N*M integrations.
>
> Yes, I don't care about Common Lisp. The iter-by clause is less of a
> problem than 'buffers' etc. because it's not a one-off that couples a
> looping construct with some random semantics.
It's sort of related to Drew's concerns in that Emacs deals with the N*M
problem by setting M=1, hence why only cl-loop gets the pressure to add
more enhancments.
There are some practical problem with iter-defun though: it has several
bugs on which there doesn't seem to be any movement[1][2][3], it's
reported to be slow[4], and cl-loop's iter-by keyword is not documented
at all (that could be easily fixed, at least). I wonder if streams[5]
is a better direction. It already has stream-regexp, though it returns
match-data rather than a matched string.
(package-install 'stream)
(require 'stream)
(require 'seq)
(seq-do (lambda (m)
(set-match-data m)
(print (match-string 0)))
(stream-regexp (current-buffer) (rx digit)))
(cl-loop with matches = (stream-regexp (current-buffer) (rx digit))
for m = (stream-pop matches) while m
do (set-match-data m) (print (match-string 0)))
[1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26073
[2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25965
[3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26068
[4]: http://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00264.html
[5]: https://elpa.gnu.org/packages/stream.html
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, (continued)
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Drew Adams, 2017/04/07
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Drew Adams, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Drew Adams, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Philipp Stephani, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Philipp Stephani, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/08
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Philipp Stephani, 2017/04/22
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer,
npostavs <=
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Philipp Stephani, 2017/04/22
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Juri Linkov, 2017/04/05
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/07
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Noam Postavsky, 2017/04/07
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Drew Adams, 2017/04/07
- bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer, Tino Calancha, 2017/04/08