From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Date: Sat, 08 Apr 2017 11:46:50 +0000 Message-ID: References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> <874ly3vw1p.fsf@users.sourceforge.net> <943bd0fd-c4ad-48f4-a803-f832b5bf0edf@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1147c434d27591054ca64c83 X-Trace: blaine.gmane.org 1491652112 24832 195.159.176.226 (8 Apr 2017 11:48:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Apr 2017 11:48:32 +0000 (UTC) Cc: 26338@debbugs.gnu.org, npostavs@users.sourceforge.net, Marcin Borkowski , Juri Linkov To: Tino Calancha , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 08 13:48:24 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwoqg-0004Cv-V2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 13:48:11 +0200 Original-Received: from localhost ([::1]:54295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwoqj-0001Ik-OC for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 07:48:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwoqd-0001If-UZ for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 07:48:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwoqZ-0000IS-2u for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 07:48:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38930) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwoqY-0000IN-U2 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 07:48:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cwoqY-0004CX-Dv for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 07:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Apr 2017 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26338 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26338-submit@debbugs.gnu.org id=B26338.149165202916050 (code B ref 26338); Sat, 08 Apr 2017 11:48:02 +0000 Original-Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 11:47:09 +0000 Original-Received: from localhost ([127.0.0.1]:37129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwopg-0004Ao-NM for submit@debbugs.gnu.org; Sat, 08 Apr 2017 07:47:08 -0400 Original-Received: from mail-wm0-f50.google.com ([74.125.82.50]:38263) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwope-0004AB-Kf for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 07:47:07 -0400 Original-Received: by mail-wm0-f50.google.com with SMTP id t189so8481490wmt.1 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 04:47:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fXV/Px4FP1k8vG90B/tIEvv3xprDQVHuHEaBAUWJi64=; b=oKXoUmijBqqOB4PI3jsg1mHX0ILD9fSkHtGspMV3p34MYPlVScnNg0SfIVuDQbrDEO Dv5Nud/eqBxyJbUjeO6BeAeRkR/3CSM7ZDS8D7twSH7013i2DE9NEsfEWcda5WBmfq9l y3Zrf8xzbfSy1YSciXHShgbm8b0z+ZuQ2c+XY+ciaTzDF6ixCkGHIZu3cW49IZ0CxeYt VCAICYpMPtBN7o1igkirhp2EH3o3jIVZaTwDqCeQANwKLNFFCsuHxOXu8jYxTvgPJxZ8 nVCO7fquZJJ4n++MJ9aIFYGKQriXF1r0v3bVGzrMgzDBvUZ5/Ro52bdy+P3Rwzc3uYxi hASg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fXV/Px4FP1k8vG90B/tIEvv3xprDQVHuHEaBAUWJi64=; b=o1R6XIBdduRZKaQTPdoLBsVSp7GWzJa1dxRfwvIgm3YkbwUvdSCRU7vNoh68B63uV5 HM3bZy0GsuG1LfnQiV/qM60i3oXRnUaR6Yxs9fsioNmLYz796x8tT85ADaMidWv+M04E zzFZgov6eajuQiRzbFn5DB7xgKzjNMwwNNXs22/1rS0gQpCh5JIRnvjtk5UCK6JamNMm vMGGrk8KN81o/4TMqbfpkcWwO1WP7mZpxHYdDQLOkTfhxck2LFUqIkN+fbpA87RZ843n fBf19pImqBcG0Lc3E/Soya4RD6OK3uinHvKrhww/Dg/zTO30OPn6h2oBjES+qsIloesF 4EQQ== X-Gm-Message-State: AN3rC/6nSRUjuzUuysm0tdDmAR1HUFXiFNkFjJXEtd3rSmOvlMgcuoU4 5ffgL33vkg0eu6xgaK/a2A93a0/BLw== X-Received: by 10.28.109.93 with SMTP id i90mr3111578wmc.44.1491652020694; Sat, 08 Apr 2017 04:47:00 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:131359 Archived-At: --001a1147c434d27591054ca64c83 Content-Type: text/plain; charset=UTF-8 Tino Calancha 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. --001a1147c434d27591054ca64c83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Tino C= alancha <tino.calancha@gmail.= com> schrieb am Sa., 8. Apr. 2017 um 06:46=C2=A0Uhr:


On Fri, 7 Apr 2017, Drew Adams wrote:

>>> Or an addition to cl-loop that would allow doing something lik= e
>>>
>>>=C2=A0 =C2=A0 (cl-loop for m being the matches of "foo\\|b= ar"
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0do ...)
>>>
>>> Then you could easily 'collect m' to get the list of m= atches 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.=C2=A0 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.=C2=A0 Call it whatever you want
> that will not be confused with Common Lisp emulation.
>
> Please keep `cl-' for Common Lisp emulation.=C2=A0 We've alrea= dy
> seen more than enough tampering with this - people adding
> their favorite thing to the `cl-' namespace.=C2=A0 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.=C2=A0

I do. They couple the idea of an iterable with a looping construct= , and such coupling is bad for various reasons:
- Coupling of unr= elated entities is always an antipattern.
- For N iterables and M= looping constructs, you need to implement N*M integrations.
Inst= ead this should use an iterable, e.g. a generator function (iter-defun). cl= -loop supports these out of the box.
--001a1147c434d27591054ca64c83--