From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tino Calancha Newsgroups: gmane.emacs.bugs Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Date: Sun, 9 Apr 2017 00:20:22 +0900 (JST) 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/mixed; BOUNDARY="8323329-870149736-1491664826=:20978" X-Trace: blaine.gmane.org 1491664876 29771 195.159.176.226 (8 Apr 2017 15:21:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Apr 2017 15:21:16 +0000 (UTC) User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Cc: Marcin Borkowski , Tino Calancha , 26338@debbugs.gnu.org, npostavs@users.sourceforge.net, Juri Linkov To: Philipp Stephani Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 08 17:21:11 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 1cwsAo-0006qi-8l for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 17:21:10 +0200 Original-Received: from localhost ([::1]:55551 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsAs-000243-GF for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 11:21:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsAk-00023t-5r for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:21:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwsAg-00010T-QF for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:21:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40062) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwsAg-00010N-L7 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cwsAg-0003Ch-G4 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tino Calancha Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Apr 2017 15:21: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.149166483412260 (code B ref 26338); Sat, 08 Apr 2017 15:21:02 +0000 Original-Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:20:34 +0000 Original-Received: from localhost ([127.0.0.1]:38261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsAE-0003Bf-4M for submit@debbugs.gnu.org; Sat, 08 Apr 2017 11:20:34 -0400 Original-Received: from mail-pf0-f195.google.com ([209.85.192.195]:33833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsAC-0003BS-L9 for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 11:20:33 -0400 Original-Received: by mail-pf0-f195.google.com with SMTP id o126so4175067pfb.1 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 08:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=ErU4BcRitpbSAu1rMWN/xzwGiFdRpANxAyyYgacuqgk=; b=R7IeLpUpQ0gffNHiygKGk3eqDKbGbIQHBwlNs20llf0NU6HQ99Dx4z5Jpbp29uFzK0 0slcasVno4e0LhV+6jTpHRvpNQzsBLdOUqZcrxknq5fnAqT6X0YNfYOEHPiTW5nPWks0 SRp/Q3eJBCJ+kA1M2gn4RnMukDLrUJeeZA50s4xDzabnrqjmye7AtQ07c+493jZPD3GY vSVypN6k2jKFQWHGKqcZgQP5BUI1fieA1Fxf96M+PJBYVxSOKSUxZWU6usNRakBM4KE9 ZbN/CJgSEODz8v/JzsWZImKoO+k9dX5sitylN+cBs/rhQgW5RibmSAaeJ935sx9QCQhx lQxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=ErU4BcRitpbSAu1rMWN/xzwGiFdRpANxAyyYgacuqgk=; b=lKiIZzv+vcgGfYI1NDCF7YZ2pUTDMYRDx9FH3FArhBBBYDCjV4cRFkqbeUVsaK61fC IQ1zh0JA/6rDY8EVclX8Vokrx2Vy3kAQSU7ac2LZX88oL8QN87LZZpzqQuSkFblxNCXQ WQM1smCdNySuycZ4V4+W1TwoXogI2wYll9Y04n7IpWPPotOW4LMAYhLGRH2evKEoPcPW Hk9G4lgZCl3x1eyOMeTCXE4D9DtxlwrwOpf4Xj7c1ZiTmSVjK9AMgHaX8ITp2WMZ8Ynl 5u9SVK8nQ3sE+w6ANrYO75usKBDMqbmdziSDLvZMz877Ua/ZscaHWljDa5f5cZMYXjPM IswQ== X-Gm-Message-State: AN3rC/4hv+vX5Vi4wIH3EAf5mEr6d82+7r71HHoXvDc2USJRqIW4dLOXMN+t+K+BXIdsfw== X-Received: by 10.98.163.75 with SMTP id s72mr55762pfe.227.1491664826900; Sat, 08 Apr 2017 08:20:26 -0700 (PDT) Original-Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id d130sm15685208pga.17.2017.04.08.08.20.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 08:20:26 -0700 (PDT) X-Google-Original-From: Tino Calancha X-X-Sender: calancha@calancha-pc 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:131372 Archived-At: --8323329-870149736-1491664826=:20978 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 8 Apr 2017, Philipp Stephani wrote: > > > Tino Calancha schrieb am Sa., 8. Apr. 2017 um 15:42 Uhr: > > > On Sat, 8 Apr 2017, Philipp Stephani wrote: > > > > > > > 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. > Then, you don't like (as Drew, but for different reasons) that we have: > cl-loop for x being the buffers ... > > > I don't like it, but it's there and cannot be removed for compatibility reasons, so I'm not arguing about it. I'm arguing against > adding more such one-off forms. I see. Thanks for the clarification. >   > > 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. > > > 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. Some people like it and refer about that as the 'expressivity' of the loop facility. I guess it's a matter of taste, don't need to use such constructs if you don't like it. Some people do.   > > Your point is about performance. > > > No, I care mostly about clarity, simplicity, and good API design, including separation of concerns. Expressibity and readability might be some kind of clarity. I totally agree about API design and separation of concerns. >   >   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. > > > Sure: >  (require 'generator) > (iter-defun re-matches (regexp) >   (while (re-search-forward regexp nil t) >     (iter-yield (match-string 0)))) > (iter-do (m (re-matches (rx digit))) >   (print m)) > (cl-loop for m iter-by (re-matches (rx digit)) > do (print m)) Thank you very much for your examples. They are nice. I am not as familiar as you with generators. I must study them more. Between A) and B), the second looks at least as simple and clear as the first one, and probably more readable. A) (iter-defun re-matches (regexp) (while (re-search-forward regexp nil t) (iter-yield (match-string-no-properties 1)))) (cl-loop for m iter-by (re-matches "^(defun \\(\\S +\\)") collect m) B) (cl-loop for m the matches of "^(defun \\(\\S +\\)" collect m) --8323329-870149736-1491664826=:20978--