[Top][All Lists]

[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: Philipp Stephani
Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer
Date: Sat, 08 Apr 2017 11:46:50 +0000

Tino Calancha <address@hidden> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]