bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Tino Calancha
Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer
Date: Sat, 8 Apr 2017 22:42:41 +0900 (JST)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)



On Sat, 8 Apr 2017, Philipp Stephani wrote:



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.
Then, you don't like (as Drew, but for different reasons) that we have:
cl-loop for x being the buffers ...

but it seems you are fine having iter-by clause in cl-loop, which seems an Emacs extension (correctme if i am wrong). So in principle, you are happy with adding useful extensions to CL, not just keep it an emulation as Drew wants.

Your point is about performance.  I am driven by easy to write code.
Maybe you can provide an example about how to write those things using
the iter-by cl-loop clause.

reply via email to

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