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: Sat, 8 Apr 2017 08:42:32 -0700 (PDT) Message-ID: <7bb265fb-daa0-4308-a5ac-76952fecfecf@default> 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 1491666198 579 195.159.176.226 (8 Apr 2017 15:43:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Apr 2017 15:43:18 +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 17:43:13 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 1cwsW3-0007HY-Lv for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 17:43:07 +0200 Original-Received: from localhost ([::1]:55613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsW9-0006Hb-8n for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Apr 2017 11:43:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35170) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwsW1-0006HI-D1 for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:43:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwsVy-0001hV-9c for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:43:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40110) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwsVy-0001hL-6S for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cwsVx-0003nn-RZ for bug-gnu-emacs@gnu.org; Sat, 08 Apr 2017 11:43:01 -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 15:43:01 +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.149166616514590 (code B ref 26338); Sat, 08 Apr 2017 15:43:01 +0000 Original-Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:42:45 +0000 Original-Received: from localhost ([127.0.0.1]:38309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsVh-0003nG-Eq for submit@debbugs.gnu.org; Sat, 08 Apr 2017 11:42:45 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:43101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsVf-0003n0-Ap for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 11:42:43 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v38Fgavf027992 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Apr 2017 15:42:37 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v38FgaLm014474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Apr 2017 15:42:36 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 v38FgXWV004347; Sat, 8 Apr 2017 15:42:33 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: aserv0021.oracle.com [141.146.126.233] 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:131377 Archived-At: > > 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 guess that might cause a lot of duplication of code. Why? The implementation of `cl-loop' or `eloop' could leverage the implementation of the other, or they could both leverage the implementation of a helper macro or function. > IMO experts CL lispers will be more sad with this emulation > for the lack of returning multiple values than for the addition > of some extensions. They can chose not to use them if they > don't like them. Just one opinion too. It's not about expert CL users. It's about whether we want to provide a CL emulation library or not, regardless of how complete that emulation might be. If we go the way we're headed, `cl-*' loses all meaning. It's just a namespace that happens to also include some constructs that emulate CL constructs, along with lots of other stuff that does not. AND along with stuff that kind of emulates but also kind of does not, i.e., does something that confuses things by seeming, in some cases, to emulate CL functionality but in other cases (for the same construct) does something completely un-CL. I do, completely, see the advantage of adding helpful functionality, building on CL constructs. I disagree that that should be done to what are supposed to be CL-constuct emulations. I do not understand the reticence to do such enhancement in separate, non-`cl-' functions and macros. What would be lost in doing that? And wrt implementation, IMO that would end up being simpler, not more complex. The `cl-' emulation code is already quite complex. Separating out non-`cl-' features from it could only make it simpler. And any Emacs feature that builds on and enhances an existing `cl-' feature need not continue to emulate all of the `cl-' behavior - it has no such obligation. It can still leverage commonalities that would be factored out to serve as helpers for both `cl-' and non-`cl-'. What's the downside to what I'm suggesting?