GNU bug report logs - #26338
26.0.50; Collect all matches for REGEXP in current buffer

Previous Next

Package: emacs;

Reported by: Tino Calancha <tino.calancha <at> gmail.com>

Date: Sun, 2 Apr 2017 12:42:01 UTC

Severity: wishlist

Tags: wontfix

Found in version 26.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #65 received at 26338 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Tino Calancha <tino.calancha <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Cc: 26338 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>,
 Marcin Borkowski <mbork <at> mbork.pl>, npostavs <at> users.sourceforge.net
Subject: Re: bug#26338: 26.0.50;
 Collect all matches for REGEXP in current buffer
Date: Sat, 08 Apr 2017 11:46:50 +0000
[Message part 1 (text/plain, inline)]
Tino Calancha <tino.calancha <at> gmail.com> schrieb am Sa., 8. Apr. 2017 um
06:46 Uhr:

>
>
> On Fri, 7 Apr 2017, Drew Adams wrote:
>
> >>> Or an addition to cl-loop that would allow doing something like
> >>>
> >>>    (cl-loop for m being the matches of "foo\\|bar"
> >>>             do ...)
> >>>
> >>> Then you could easily 'collect m' to get the list of matches if you
> want
> >>> that.
> >>
> >> Your proposals looks nice to me ;-)
> >
> > (Caveat: I have not been following this thread.)
> >
> > I think that `cl-loop' should be as close to Common Lisp `loop'
> > as we can reasonably make it.  We should _not_ be adding other
> > features to it or changing its behavior away from what it is
> > supposedly emulating.
> >
> > If you want, create a _different_ macro that is Emacs-specific,
> > with whatever behavior you want.  Call it whatever you want
> > that will not be confused with Common Lisp emulation.
> >
> > Please keep `cl-' for Common Lisp emulation.  We've already
> > seen more than enough tampering with this - people adding
> > their favorite thing to the `cl-' namespace.  Not good.
> Drew, i respect your opinion; but so far the change
> would just extend `cl-loop' which as you noticed has being already
> extended before.
> For instance, we have:
> cl-loop for x being the overlays/buffers ...
>
> Don't see a problem to have those things.


I do. They couple the idea of an iterable with a looping construct, and
such coupling is bad for various reasons:
- Coupling of unrelated entities is always an antipattern.
- For N iterables and M looping constructs, you need to implement N*M
integrations.
Instead this should use an iterable, e.g. a generator function
(iter-defun). cl-loop supports these out of the box.
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 250 days ago.

Previous Next


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