From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Date: Fri, 7 Apr 2017 22:49:29 -0700 (PDT) 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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1491630614 27063 195.159.176.226 (8 Apr 2017 05:50:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Apr 2017 05:50:14 +0000 (UTC) Cc: 26338@debbugs.gnu.org, npostavs@users.sourceforge.net, Marcin Borkowski , Juri Linkov To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 08 07:50:09 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 1cwjGA-00067a-D0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 07:50:06 +0200 Original-Received: from localhost ([::1]:53651 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwjGG-0006cb-77 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 01:50:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38528) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwjG9-0006bI-IE for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 01:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwjG6-0002mn-Fy for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 01:50:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:38791) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwjG6-0002mj-BE for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 01:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cwjG6-00028s-1r for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 01:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Apr 2017 05:50: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.14916305828201 (code B ref 26338); Sat, 08 Apr 2017 05:50:02 +0000 Original-Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 05:49:42 +0000 Original-Received: from localhost ([127.0.0.1]:36990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwjFm-00028C-AD for submit@debbugs.gnu.org; Sat, 08 Apr 2017 01:49:42 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwjFj-00027w-OK for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 01:49:40 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v385nXD9026925 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Apr 2017 05:49:33 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v385nWtJ005941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 8 Apr 2017 05:49:33 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v385nUeq020066; Sat, 8 Apr 2017 05:49:30 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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:131348 Archived-At: > >>> 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 w= ant > >>> 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 ... >=20 > Don't see a problem to have those things. We already point out in the > manual that these are Emacs specific things, so nobody should be fooled > with that. As far as we cover all CL clauses, what problem could be in > having a few more? You make a fair point when you stick to only extension and keep compatibility for the rest. I still disagree with it, for the reasons given below. And because the next enhancement proposal will perhaps just point to this one as more precedent for making changes, without bothering to, itself, ensure that "we cover all CL clauses" etc. As you pointed out: "so far"... Little by little, we've already seen `cl-' diluted from CL by being incrementally "enhanced". Here's my general opinion on this kind of thing: I agree that such things are useful. I have nothing against them, and I'm glad to see Emacs have them. My objection is to using `cl-loop' for it. `cl-loop' - and all of the stuff in `cl-*' - should be for Common Lisp emulation. Nothing more or less. That's my opinion. Emacs should have its _own_, non-cl-* functions, macros, variables, whatever. It can take Common Lisp constructs as a point of departure or inspiration, and extend enhance, limit, or in any way change that point of departure as is most fitting and useful for Emacs. That's normal. I'm all for that kind of thing. But it should not be confused with Common Lisp emulation. `cl-' should be kept for Common Lisp emulation. Users should be able to recognize when they are using CL code (an emulation of it). Users should be able to take existing CL code and use it in Emacs with little or no modification (no, we're not there yet, and never will be completely, but it's a good goal). Put all this stuff - and more - into an `eloop' macro. Since it will be so much better and more Emacsy, with specifics that are especially useful for Emacs, it is what users will (eventually) use instead of `cl-loop'. Since it will do everything that `cl-loop' does (and more), eventually only the rare user who needs, or for some reason really wants, code that is CL or close to it will use `cl-loop'. Everyone else will use `eloop'. No problem. I am sure that my opinion on this is a minority one - perhaps a minority of one. But going the other direction, along lines such as what you suggest: 1. We lose the value of `cl-' as an emulation of CL. And typically we lose compatibility with existing CL code. 2. We lose the ability, when seeing something `cl-', to know we can look it up in the (fine) Common Lisp docs. 3. Where does it stop? What's the point of `cl-', if anything goes and we can stuff whatever into it? What prevents Emacs design from doing the right thing? What do we lose by putting non-CL stuff into an `eloop' that extends `cl-loop' in Emacsy ways? Sure, invent more and better and different. But put it in a different namespace or in no namespace. If `cl-' is just an Emacs thing and no longer a Common Lisp thing then why the pretense of having a CL manual; and using a `cl-' namespace; and pointing to the CL docs for explanation (the Emacs docs explain practically nothing about its `cl-' constructs - there is really no doc for `cl-' in Emacs)? What's the point? Leave `cl-loop' as Common Lisp's `loop'. Create a more-and-better, more Emacsy `eloop' or whatever. Complete freedom - do whatever. My vote is only that `cl-' be kept for CL (and even be cleaned up to be more like it).