From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 08:41:51 2017 Received: (at submit) by debbugs.gnu.org; 2 Apr 2017 12:41:51 +0000 Received: from localhost ([127.0.0.1]:56485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuepK-0005X0-V0 for submit@debbugs.gnu.org; Sun, 02 Apr 2017 08:41:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuepJ-0005Wk-1f for submit@debbugs.gnu.org; Sun, 02 Apr 2017 08:41:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cuepC-00049p-Na for submit@debbugs.gnu.org; Sun, 02 Apr 2017 08:41:43 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:45425) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cuepC-00049e-KK for submit@debbugs.gnu.org; Sun, 02 Apr 2017 08:41:42 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cuepB-0002EX-C5 for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2017 08:41:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cuep6-00047J-A9 for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2017 08:41:41 -0400 Received: from mail-pg0-x236.google.com ([2607:f8b0:400e:c05::236]:35171) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cuep6-000471-3V for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2017 08:41:36 -0400 Received: by mail-pg0-x236.google.com with SMTP id 81so97888066pgh.2 for ; Sun, 02 Apr 2017 05:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=zBEku83rOn40gJX1A4nArF72TIXa2PwLjP6x+6i1a5g=; b=FXNh/XMSsrvMF46tI35nfITZlgfEH8oqzD/vwiru3g/T06VGf9oAFauHvYKla5JmT2 WWda8wqFI4FTvuDQA6SF8NEEHC9ZnK1Ayih6a1rZesh0hHVTy7M2sFlyRz1vAgviBGK+ do+3b8Ycb6ePt1FDtfTJAeTNYbLnweLc8lsnFjw6UY8v6JoYUW3SGEaIZSCtUGs+nPFq YcQ6bJbvSfCQHC25DeBfAJiZrjtp+lhLM5D7+JyQKcuve7pyE+CAXtB6bOsFI4zhFIMN H90bSsJ4l9uqYGv4nMYDLvMNDztjAsn5H5RE05V0Mj9jNouR+wMixzKPRucYguVVb3iX iDHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=zBEku83rOn40gJX1A4nArF72TIXa2PwLjP6x+6i1a5g=; b=Yf+hXJBdfTMWwI+ABXIEHfkBK8WGTmfrrtNKBr25tTzm3vF+Zi0ZfcPSQ5n3Vj0gxp lfjY3/2cs/FCgMqIeCSS3t7K4YB0P4w8EpyGcVuPrzfdUiME0DuLdil/5gV58E6WksAG 70GkKc24FHvy91vWgNJNJkTnssXFQH+t4S8GemK2qosf7ItPUaeoqAc1WKErkrtfDWeT QpjOxbS8f/0iPahd7MrRiC98mDONbP6nH9qVo5AyQrIXbCiytRjUOyrdcJOInlQnnmKq OlY9xhzIzasnvjsAJ3ya82MQ0t+yBMcypiiag54JxcdFS0nANwcEkZuesYiYYzs3PVN2 FqaQ== X-Gm-Message-State: AFeK/H099nx7zeHRA0NTq7a9pQAvj7Hnw8S6cVpSFx/EyZlMdG71hUhRZzTzDD+/VlM+Ow== X-Received: by 10.98.201.77 with SMTP id k74mr11636419pfg.74.1491136894967; Sun, 02 Apr 2017 05:41:34 -0700 (PDT) Received: from calancha-pc (234.204.100.220.dy.bbexcite.jp. [220.100.204.234]) by smtp.gmail.com with ESMTPSA id t66sm20236203pfk.53.2017.04.02.05.41.33 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 02 Apr 2017 05:41:34 -0700 (PDT) From: Tino Calancha To: bug-gnu-emacs@gnu.org Subject: 26.0.50; Collect all matches for REGEXP in current buffer Date: Sun, 02 Apr 2017 21:41:30 +0900 Message-ID: <8737dr6kxx.fsf@calancha-pc> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) X-Debbugs-CC: Juri Linkov Severity: wishlist Hi, we have `count-matches' in replace.el, which returns the number of matches of a regexp. Why not to have an standard function `collect-matches' as well? I know `xref-collect-matches' but it uses grep program: some users might not have grep installed, or they may prefer to use Emacs regexps. I've being using for a while something similar than the patch below. Probably it doesn't need to be a command, just a normal function. What do you think? Regards, Tino --8<-----------------------------cut here---------------start------------->8--- commit ccc78b19aa044f6bdb27875937320ed06c2b517a Author: Tino Calancha Date: Sun Apr 2 21:37:19 2017 +0900 collect-matches: New command Collect all matches for REGEXP in current buffer (Bug#26338). * lisp/replace.el (collect-matches): New command. diff --git a/lisp/replace.el b/lisp/replace.el index a7b8ae6a34..6f2c6c9a2b 100644 --- a/lisp/replace.el +++ b/lisp/replace.el @@ -1002,6 +1002,44 @@ how-many (if (= count 1) "" "s"))) count))) +(defun collect-matches (regexp &optional region group limit) + "Collect matches for REGEXP following point. +Optional arg REGION, if non-nil, mean restrict search to the + specified region. Otherwise search the entire buffer. + REGION must be a list of (START . END) positions as returned by + `region-bounds'. +Interactively, in Transient Mark mode when the mark is active, operate + on the contents of the region. Otherwise, operate from point to the + end of (the accessible portion of) the buffer. +Optional GROUP if non-nil, then is the regexp group to save. Otherwise, + save the whole match. Interactively, a numeric prefix set GROUP. +Optional LIMIT if non-nil, then stop after such number of matches. + Otherwise collect all of them." + (interactive + (list (read-regexp "Collect matches for regexp: ") + (and (use-region-p) (region-bounds)) + (if current-prefix-arg (prefix-numeric-value current-prefix-arg) 0) + nil)) + (unless group (setq group 0)) + (let* ((count 0) + (start (if region (max (caar region) (point-min)) (point))) + (end (if region (min (cdar region) (point-max)) (point-max))) + res) + (save-excursion + (goto-char start) + (catch '--collect-matches-end + (while (re-search-forward regexp nil t) + (unless (>= (point) end) + (push (match-string-no-properties group) res) + (cl-incf count)) + (when (or (>= (point) end) + (and (natnump limit) (>= count limit))) + (throw '--collect-matches-end nil))))) + (message "%d Match%s: %s" + count (if (= count 1) "" "es") + (mapconcat 'identity (setq res (nreverse res)) " ")) + res)) + (defvar occur-menu-map (let ((map (make-sparse-keymap))) --8<-----------------------------cut here---------------end--------------->8--- In GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.9) of 2017-04-02 Repository revision: afabe53b562675b6279cc670ceba32357fac2214 From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 11:57:12 2017 Received: (at 26338) by debbugs.gnu.org; 2 Apr 2017 15:57:12 +0000 Received: from localhost ([127.0.0.1]:57667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuhsO-0007TD-6t for submit@debbugs.gnu.org; Sun, 02 Apr 2017 11:57:12 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:36095) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuhsM-0007Sy-IN for 26338@debbugs.gnu.org; Sun, 02 Apr 2017 11:57:10 -0400 Received: by mail-wr0-f176.google.com with SMTP id w11so136760804wrc.3 for <26338@debbugs.gnu.org>; Sun, 02 Apr 2017 08:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UD7zI2lcU3+lec/2BJ0TaIfCCiyBlpYFwOp68co9rX0=; b=ltyt62cedHi9ljy1A/OOIuwNGfOHo0YK7Miy+nHCO8rYfzWaG+KMUiI7bH7SMOjVwm GU0LWZ4GyaPnrgFy5687MI6QiCukqsA46rpIxrOlNjZnXHM7VgSBbW9FSAfrD52ffjdF RVr9lz5x+VKdLTN2rersrWsgxMTxbsaDwRZJIZ3/tn/stLErfh2Ay7DF+8nMHkVoDPKn MqS0u50J/jAMr9+hnqlHpErPoIRniYTw+GkumM0PpEAFjBZeHC0hA5tMS0F9UaOYjc0U GPszb0YhJ4SqBksHvRnYpsE42zFMzPRp2VAiy1TaE+OpCYacyy9KjBHXHLLbe2RRmau7 r59A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UD7zI2lcU3+lec/2BJ0TaIfCCiyBlpYFwOp68co9rX0=; b=pBchjUm3SN/l5V/W9Y4NbJ8bZ0cnBWFi/5oFQFHeprS3CKjNd7yRL33+k5NAF0Gq7m 30GEja2t670fWQc/TDaeoJLbYqAsIVD1BVw69llp0XkSsUWId1xiGHFWcC9/nURxn/lv Pr7rOZi6+aYJmVbC1gEPc9oQto/FQ5f5AZnG/f8n2yxgYyghTeZoSr9RrglVfxD+m5MP kaRrrv66J4HZJd1+FQNxg3GwZtMyKrJvU1jWOABVuzll9XRRZFri7w1g8Ric+746Q9uD +3l42mVFyuL4xHTjmHtS9l+ldzext8QFUPkiUo2H0YzgrYhwCLOOlbPPodpqIADzxjKS Ptlw== X-Gm-Message-State: AFeK/H0+IDcXJh8CTasFo5vmW6kEhQuotMBzuUzgFOa8MHaFsrGv0ILqFkbnEknuHq0oxA== X-Received: by 10.223.129.183 with SMTP id 52mr12095403wra.112.1491148624684; Sun, 02 Apr 2017 08:57:04 -0700 (PDT) Received: from [192.168.1.3] ([185.105.173.156]) by smtp.googlemail.com with ESMTPSA id m201sm10749638wmd.15.2017.04.02.08.57.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 08:57:03 -0700 (PDT) Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: Tino Calancha , 26338@debbugs.gnu.org References: <8737dr6kxx.fsf@calancha-pc> From: Dmitry Gutov Message-ID: <4723d923-102a-685c-9145-7e08ca3498bb@yandex.ru> Date: Sun, 2 Apr 2017 18:57:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <8737dr6kxx.fsf@calancha-pc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 26338 Cc: juri linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) On 02.04.2017 15:41, Tino Calancha wrote: > we have `count-matches' in replace.el, which returns the > number of matches of a regexp. Why not to have an standard > function `collect-matches' as well? > > I know `xref-collect-matches' but it uses grep program: some users might > not have grep installed, or they may prefer to use Emacs regexps. > > I've being using for a while something similar than the patch below. > Probably it doesn't need to be a command, just a normal function. > > What do you think? When used interactively, isn't M-x occur doing something like this? And for Elisp programs, (while (re-search-forward ...)) is usually sufficient. That's a three-liner at worst. And I've never had a need to limit the number of matches, personally. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 18:12:16 2017 Received: (at 26338) by debbugs.gnu.org; 2 Apr 2017 22:12:16 +0000 Received: from localhost ([127.0.0.1]:57850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cunjM-0001MY-CR for submit@debbugs.gnu.org; Sun, 02 Apr 2017 18:12:16 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:43689 helo=homiemail-a20.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cunjK-0001MQ-ND for 26338@debbugs.gnu.org; Sun, 02 Apr 2017 18:12:15 -0400 Received: from homiemail-a20.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTP id 3EC497EC061; Sun, 2 Apr 2017 15:12:10 -0700 (PDT) Received: from localhost.linkov.net (m83-179-201-25.cust.tele2.ee [83.179.201.25]) (Authenticated sender: jurta@jurta.org) by homiemail-a20.g.dreamhost.com (Postfix) with ESMTPA id 63E727EC064; Sun, 2 Apr 2017 15:12:09 -0700 (PDT) From: Juri Linkov To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Organization: LINKOV.NET References: <8737dr6kxx.fsf@calancha-pc> Date: Mon, 03 Apr 2017 01:10:02 +0300 In-Reply-To: <8737dr6kxx.fsf@calancha-pc> (Tino Calancha's message of "Sun, 02 Apr 2017 21:41:30 +0900") Message-ID: <87h926cvgl.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) > we have `count-matches' in replace.el, which returns the > number of matches of a regexp. Why not to have an standard > function `collect-matches' as well? > > I know `xref-collect-matches' but it uses grep program: some users might > not have grep installed, or they may prefer to use Emacs regexps. > > I've being using for a while something similar than the patch below. > Probably it doesn't need to be a command, just a normal function. > > What do you think? But there is already the occur-collect feature implemented in occur-1 and occur-read-primary-args. Why would we need a separate command? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 23:58:56 2017 Received: (at 26338) by debbugs.gnu.org; 3 Apr 2017 03:58:56 +0000 Received: from localhost ([127.0.0.1]:58039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cut8p-00013o-Rv for submit@debbugs.gnu.org; Sun, 02 Apr 2017 23:58:56 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:34968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cut8n-00013a-Il for 26338@debbugs.gnu.org; Sun, 02 Apr 2017 23:58:54 -0400 Received: by mail-pg0-f68.google.com with SMTP id g2so26792044pge.2 for <26338@debbugs.gnu.org>; Sun, 02 Apr 2017 20:58:53 -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=7xdEF5m3JbzWMMx8GzNhWNOCOZOG7mI7RdB6gB3Ex8w=; b=kLVS4YzuTwrcGNUb+tieOk3gu6ZJ+byWUPlXIhjTsIv989cUv/38U82fSKfTi1p6Jr qkC5zKy6l1NksXoZN0JMS+lMvhcEY+X1yCvIGVzCRlNG1wlnuJEt6NREKAtiRtBKdzkS rIoP0CjWd9ipaoOxl9C60GL+cyB33J+PzqktRQk/bn8IexNEUTovkqVnlDxD86uuz0+o CpUszWuxN8wcATuKiVAKqwIj6Lb3ZuC/HhMAYEUWzongEK7hRsg2WQQ5hU1lufbAJSvj 6c1MIScWWTxfI9huVFo/2917KUyGfG+ofqrkW1FdVH0o2P7XfWOwq3NjnhMNioILUR1W p8SA== 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=7xdEF5m3JbzWMMx8GzNhWNOCOZOG7mI7RdB6gB3Ex8w=; b=YBs1gG5xdk4y9SUSgsKbLrtwohZ8BbzRMMuYEnYrx4TgncwCwWdk2Ug6ebaxMscWPq bjHCRubUl7yUSvrJl0nxT/x1FIDRnZkpezhVSa66/mPgzF/PfEcbaic65i6JTYLq/dp7 Qp4xQJ0DiX6WLnSdEP5XREAUyTiQnWGWCOZZbVaK5Kg9WWD4AVN750rvyhHdANHP4ule UZOu3kJ7kQcpoFZQEiObFytn2aTzY8ofMIp4dRpIasTxzpq74s4thGjRqTN6k93PCRGv LZ4Ahc7VfoxGoyRNfFY7Ttsd8+hU8fHanMR8izMVQXR951JV7e7btJyDM3T8nykOyXlA 0vCw== X-Gm-Message-State: AFeK/H3/fjj35eWP8iBW4zLpB8seRrcz9LhuGByXpBxXpynFLt3xfVWoofdUBj3He8sX8Q== X-Received: by 10.84.194.1 with SMTP id g1mr19239774pld.98.1491191927797; Sun, 02 Apr 2017 20:58:47 -0700 (PDT) Received: from calancha-pc (234.204.100.220.dy.bbexcite.jp. [220.100.204.234]) by smtp.gmail.com with ESMTPSA id x21sm22560765pgf.15.2017.04.02.20.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 20:58:47 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Mon, 3 Apr 2017 12:58:44 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Dmitry Gutov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <4723d923-102a-685c-9145-7e08ca3498bb@yandex.ru> Message-ID: References: <8737dr6kxx.fsf@calancha-pc> <4723d923-102a-685c-9145-7e08ca3498bb@yandex.ru> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, juri linkov , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Sun, 2 Apr 2017, Dmitry Gutov wrote: > On 02.04.2017 15:41, Tino Calancha wrote: > >> we have `count-matches' in replace.el, which returns the >> number of matches of a regexp. Why not to have an standard >> function `collect-matches' as well? >> >> I know `xref-collect-matches' but it uses grep program: some users might >> not have grep installed, or they may prefer to use Emacs regexps. >> >> I've being using for a while something similar than the patch below. >> Probably it doesn't need to be a command, just a normal function. >> >> What do you think? > When used interactively, isn't M-x occur doing something like this? > > And for Elisp programs, (while (re-search-forward ...)) is usually > sufficient. That's a three-liner at worst. It might be argue the same for occur. You can just increase a counter inside (while (re-search-forward ...)) > And I've never had a need to limit the number of matches, personally. I did often while implementing Bug#25493. Let's say i am interested in the last 200 commits modifying a file foo.el. M-x: find-library foo RET C-x v l M-: (setq hashes (collect-matches "^commit \\([[:xdigit:]]+\\)" nil 1 200)) In this case, there is no need to go beyond 200 that's why the limit argument might be useful. Another example, let's say i want to know the two first defun's in subr.el M-x: find-library subr RET M-: (collect-matches "^(defun \\([^[:blank:]]+\\)" nil 1 2) RET Of course you could do: M-: (seq-take (collect-matches "^(defun \\([^[:blank:]]+\\)" nil 1) 2) RET ;; But if you just want the 2 leading defun's this is a waste. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 03 00:02:00 2017 Received: (at 26338) by debbugs.gnu.org; 3 Apr 2017 04:02:00 +0000 Received: from localhost ([127.0.0.1]:58045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cutBo-0001Ax-AD for submit@debbugs.gnu.org; Mon, 03 Apr 2017 00:02:00 -0400 Received: from mail-pg0-f68.google.com ([74.125.83.68]:35406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cutBm-0001Ak-Uu for 26338@debbugs.gnu.org; Mon, 03 Apr 2017 00:01:59 -0400 Received: by mail-pg0-f68.google.com with SMTP id g2so26807390pge.2 for <26338@debbugs.gnu.org>; Sun, 02 Apr 2017 21:01:58 -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=/2XIErxYBnEvUOjoN6KhJiibaYI+VWTIeg6gt7+Hj/M=; b=aWa0MsnaFl2FmB3pFSF5aRvyhWZxw3iqz0XToPgqQwYEbY8THzltVVm7iw5UnxK6pS hP5rAgnMG7F3s5/3HcJdmecW2eDG+n9oJDkfLJCTUADYhM+WJCsdkmTVMvuOboimOsnv SK3d2XNJnfgr9wnOfBijVDW5lwxBYUmfHxgNULUid0DO7MtgWJnMUrTjjLGLF9BfM3MV dQgsrVSfZJqowaVxMLqXcUN2ICyi/4K0mRy9L7uM/SdOfqz3ebcmQSGkmOpJcKFi4NoP yyFoMSNtNV7wo31zp1u4YsekD8TBRlRu8DOY1kwHtw7HIdFY6LQSaFPKF9nAhTEYfggR uOhg== 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=/2XIErxYBnEvUOjoN6KhJiibaYI+VWTIeg6gt7+Hj/M=; b=QikjbxtsDGNtsd4ccLtWWu6YfvJMlXM/84phlucvTNqZGCheG6a/zgc7fD5gA7B6VQ v7AnRBX9Wz/gfKithwEsyyPXv6x9nuN7FrNpFFhaLzJgGzc8DcALjds/OLf+wZK5nyQP KQHM9n3QvV75jZz6/eS+xfRz0vS3QpHm+we7QRNEtBogvO5eeVLwWVcwKpP80ekwKrCx XAsaUCoHj2b9JGTNVfffLV7NpWwWlpaSaIDmFpadcKz1PieZSZv79nc7gq+VDvsVCWLH ssHNf7rxWV+BmGWCXZCfOcuYXkUh0aWmuv2kNs243oYSU7UWmdrLviRMoPJw3tpFX8Pu zFPw== X-Gm-Message-State: AFeK/H1ASZT8Xme58VQuQk9phHV4hQ/VPLTqE+lewREdjUD0n45ktpm4XU+hKuJKD+iwWA== X-Received: by 10.84.179.193 with SMTP id b59mr19252701plc.56.1491192113439; Sun, 02 Apr 2017 21:01:53 -0700 (PDT) Received: from calancha-pc (234.204.100.220.dy.bbexcite.jp. [220.100.204.234]) by smtp.gmail.com with ESMTPSA id n24sm22535256pgc.43.2017.04.02.21.01.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Apr 2017 21:01:52 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Mon, 3 Apr 2017 13:01:50 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Juri Linkov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <87h926cvgl.fsf@localhost> Message-ID: References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Mon, 3 Apr 2017, Juri Linkov wrote: >> we have `count-matches' in replace.el, which returns the >> number of matches of a regexp. Why not to have an standard >> function `collect-matches' as well? >> >> I know `xref-collect-matches' but it uses grep program: some users might >> not have grep installed, or they may prefer to use Emacs regexps. >> >> I've being using for a while something similar than the patch below. >> Probably it doesn't need to be a command, just a normal function. >> >> What do you think? > > But there is already the occur-collect feature implemented in occur-1 > and occur-read-primary-args. Why would we need a separate command? Sorry, i don't know about `occur-collect', i can not find its definition. It doesn't seem to be a defun in replace.el. See my previous e-mail and let me know if `occur-collect' can serve for that purpose. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 03 02:13:19 2017 Received: (at 26338) by debbugs.gnu.org; 3 Apr 2017 06:13:19 +0000 Received: from localhost ([127.0.0.1]:58070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuvEt-0004LG-Kf for submit@debbugs.gnu.org; Mon, 03 Apr 2017 02:13:19 -0400 Received: from mail-pg0-f54.google.com ([74.125.83.54]:32993) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cuvEs-0004Kz-5V for 26338@debbugs.gnu.org; Mon, 03 Apr 2017 02:13:18 -0400 Received: by mail-pg0-f54.google.com with SMTP id x125so110120187pgb.0 for <26338@debbugs.gnu.org>; Sun, 02 Apr 2017 23:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=EHR4BaC/sPZ4/gCGjGxDEWp07qZ5Q+39vPVWodQwGuw=; b=qWxF4R4eSq5GMbzDD6PvAWqaj+6GV4xhIzJwfKuftNbmd9Gs4WnqK2kNL3TX6hoZQM TDhOpcZRT8TG2sWbDjpxArgLY6L7dKO1pVnx+7ep1Z8dc3rzUT5Clprcedr3YU+UFvmc /rppscLL/OZgXD1AxdZVtiXgHd6JhRYmlShuhfZumPbXBwHPPChCToeubYCRJ6ejUNzt dxRzQ4spW+F8hv3km5TBbEhLpMjQ364vMcllXkQUvfPgLsVDTBONQi81HoTPen9CYw13 KCwyuisqFEScFJ7veEPcOLF77FddxE7DZ0NMOuh38johb8Aymz+SsB1QjdnhFDeBnHMg vUIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=EHR4BaC/sPZ4/gCGjGxDEWp07qZ5Q+39vPVWodQwGuw=; b=Huqw4j2O2xQgjRAehm56JF0Q+KApue3KG+3r3zpnRkbbVlOK0UaoZiTyrq+nxCr1vV JRA6Qraf0RwIx/isexB2j9cjFczL3V7CSQVoKowk5C0PZ+A1lmuD9aRQaLOeAW5SH4XJ nP8y5AxFrW/RqrQlj+GHU3ufV+lffNnLefNP3iLwTRy7Mrf6Tc2n6U62ibj7clk92UaJ x0y0mmY4iH7COPnv/+T6eAAHnTfbo1wRhH+b4Irpe3Gt1bT22rhoCAvNm6jrrCgvK3SD cPtZ4rzfW4a7P8bRltzvxSM0G++LXQ4lJwnn+iBn+kt/a8vcxt/me4fllmwOTHW2i/vo vLzg== X-Gm-Message-State: AFeK/H3mvUNIsOZRCkFVexIDh8u2empsEzJiCzu0Y8Ilv3YruL2ymrE23S/NKaKShZQkEw== X-Received: by 10.99.99.135 with SMTP id x129mr16065676pgb.121.1491199992556; Sun, 02 Apr 2017 23:13:12 -0700 (PDT) Received: from calancha-pc (MAR89-178.kek.jp. [130.87.89.178]) by smtp.gmail.com with ESMTPSA id g5sm23228009pfe.12.2017.04.02.23.13.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 02 Apr 2017 23:13:11 -0700 (PDT) From: Tino Calancha To: Juri Linkov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> Date: Mon, 03 Apr 2017 15:13:07 +0900 In-Reply-To: <87h926cvgl.fsf@localhost> (Juri Linkov's message of "Mon, 03 Apr 2017 01:10:02 +0300") Message-ID: <87k272ow7g.fsf@calancha-pc> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Juri Linkov writes: >> we have `count-matches' in replace.el, which returns the >> number of matches of a regexp. Why not to have an standard >> function `collect-matches' as well? >> >> I know `xref-collect-matches' but it uses grep program: some users might >> not have grep installed, or they may prefer to use Emacs regexps. >> >> I've being using for a while something similar than the patch below. >> Probably it doesn't need to be a command, just a normal function. >> >> What do you think? > > But there is already the occur-collect feature implemented in occur-1 > and occur-read-primary-args. Why would we need a separate command? Indeed i don't think we need a new command for this. I am thinking more in an standard function. Following: (occur "defun\\s +\\(\\S +\\)" "\\1") doesn't return the collected things. It writes the matches in *Occur* buffer. Then, if you want a list with the matches you must loop again inside *Occur* which is sub-optimal. For me, it has sense to have a `occur-collect' which just returns the list of matches. Then, we might use such function in the implementation of occur-1 which could bring a cleaner implementation. We might get also the LIMIT argument for occur which might come in handy for multi-occur with lot of input buffers (just an idea). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 03 19:36:57 2017 Received: (at 26338) by debbugs.gnu.org; 3 Apr 2017 23:36:57 +0000 Received: from localhost ([127.0.0.1]:59610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvBWr-0005p6-8R for submit@debbugs.gnu.org; Mon, 03 Apr 2017 19:36:57 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:50699 helo=homiemail-a19.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvBWp-0005os-MY for 26338@debbugs.gnu.org; Mon, 03 Apr 2017 19:36:56 -0400 Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 87DD4604090; Mon, 3 Apr 2017 16:36:54 -0700 (PDT) Received: from localhost.linkov.net (m83-179-201-25.cust.tele2.ee [83.179.201.25]) (Authenticated sender: jurta@jurta.org) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id A3363604088; Mon, 3 Apr 2017 16:36:53 -0700 (PDT) From: Juri Linkov To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Organization: LINKOV.NET References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> Date: Tue, 04 Apr 2017 02:35:29 +0300 In-Reply-To: <87k272ow7g.fsf@calancha-pc> (Tino Calancha's message of "Mon, 03 Apr 2017 15:13:07 +0900") Message-ID: <87fuhpcbem.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) >>> What do you think? >> >> But there is already the occur-collect feature implemented in occur-1 >> and occur-read-primary-args. Why would we need a separate command? > Indeed i don't think we need a new command for this. I am thinking mor= e > in an standard function. > Following: > (occur "defun\\s +\\(\\S +\\)" "\\1") > > doesn't return the collected things. It writes the matches in *Occur* > buffer. Then, if you want a list with the matches you must loop > again inside *Occur* which is sub-optimal. > For me, it has sense to have a `occur-collect' which just returns the > list of matches. > Then, we might use such function in the implementation of occur-1 > which could bring a cleaner implementation. > We might get also the LIMIT argument for occur which might come > in handy for multi-occur with lot of input buffers (just an idea). occur-collect is intended for interactive use. As for programmatic use, Dmitry is right: a universal idiom is (while (re-search-forward ...)). This is why e.g. the docstring of =E2=80=98replace-regexp=E2=80=99 recomm= ends to use an explicit loop like (while (re-search-forward ...) (replace-match ...)) From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 03 21:38:02 2017 Received: (at 26338) by debbugs.gnu.org; 4 Apr 2017 01:38:02 +0000 Received: from localhost ([127.0.0.1]:59682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvDQ1-0000TK-TD for submit@debbugs.gnu.org; Mon, 03 Apr 2017 21:38:02 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:34670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvDPy-0000SU-KG for 26338@debbugs.gnu.org; Mon, 03 Apr 2017 21:38:00 -0400 Received: by mail-pg0-f41.google.com with SMTP id 21so137040967pgg.1 for <26338@debbugs.gnu.org>; Mon, 03 Apr 2017 18:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=bzGvWZ4OtyTdrCUtwnUlSTI8PwTyKKtptHXLvD1+ngo=; b=W0u3pbtO30d0SHNwBXt5TNBUbqoAD8gs8xMQA0zh305ZBHFEtWtqsxur/XcTbf8hbY 9DnJYQFoH/zS0QwjHNA0PuIrB08uReodQaEjSYkubAu/wTMnMHCi2GbYwFl7IDco5beQ PsjluViGlt0JOL94SMvKhh7bH6dy+Yex3bZ+CLIdY+1B/usx3MsS0ipPhWoXBw0tNOCY oaoXdbDEBDPhFBNL9IBAbiZQljAw7PV92Fg4SxTeaqQBhYV1wLwRrK2TIQvokeU3cvMm W8/4XOKKaSwzggXqg1tUzJOjb0AbwxtkquCCXHPb562oOhKP4Bwi0uML4R01AlWKNg9o 4h6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=bzGvWZ4OtyTdrCUtwnUlSTI8PwTyKKtptHXLvD1+ngo=; b=DOIvyYpQPEg73svzqRYiFirs4c7V7B4E7eZ6m+bvuA+jqrRftn8gJiwj/Frf5TLwYa 10dcUOomr/9Zc1IuGF5xrBcTBeGgobo5SJHfWScIhqwEq2ojHJjWWu6y8zV5cbJGYL04 xM/YmuSKKwioveU5ZtPeZEa50ig7VDRo+wq0Qv+1/a8f/+C1dnD/PP/91bJqFm8tUE+1 OYn0h0IytY+GvodD0BEHm3O9j2biRp+3xxg66PFfdNdXI89DqO8LEIQr/JrUZKEGEHvy YyyUhQmW/JWnspjnDcko/4OK6o7AWJWc4XesGzPa2Ubv/6B4eccAStDRlC1RzXvXtJ8T I5kw== X-Gm-Message-State: AFeK/H3BdZHiDSdRiUZ4kx9ob5VtwdubG45xr5VC2Yp/IiVhXumJIIZJ1OLxkYEMLwwYnA== X-Received: by 10.84.229.13 with SMTP id b13mr25291851plk.72.1491269872711; Mon, 03 Apr 2017 18:37:52 -0700 (PDT) Received: from calancha-pc (234.204.100.220.dy.bbexcite.jp. [220.100.204.234]) by smtp.gmail.com with ESMTPSA id s11sm28101238pgc.61.2017.04.03.18.37.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Apr 2017 18:37:52 -0700 (PDT) From: Tino Calancha To: Juri Linkov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> Date: Tue, 04 Apr 2017 10:37:48 +0900 In-Reply-To: <87fuhpcbem.fsf@localhost> (Juri Linkov's message of "Tue, 04 Apr 2017 02:35:29 +0300") Message-ID: <87lgrheyvn.fsf@calancha-pc> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Juri Linkov writes: >>>> What do you think? >>> >>> But there is already the occur-collect feature implemented in occur-1 >>> and occur-read-primary-args. Why would we need a separate command? >> Indeed i don't think we need a new command for this. I am thinking more >> in an standard function. >> Following: >> (occur "defun\\s +\\(\\S +\\)" "\\1") >> >> doesn't return the collected things. It writes the matches in *Occur* >> buffer. Then, if you want a list with the matches you must loop >> again inside *Occur* which is sub-optimal. >> For me, it has sense to have a `occur-collect' which just returns the >> list of matches. >> Then, we might use such function in the implementation of occur-1 >> which could bring a cleaner implementation. >> We might get also the LIMIT argument for occur which might come >> in handy for multi-occur with lot of input buffers (just an idea). > > occur-collect is intended for interactive use. As for programmatic use, > Dmitry is right: a universal idiom is (while (re-search-forward ...)). > This is why e.g. the docstring of =E2=80=98replace-regexp=E2=80=99 recomm= ends to use > an explicit loop like (while (re-search-forward ...) (replace-match ...)) OK thanks. Let me ask you my last proposal before come back to my dark cave and start painting animals in the walls. Any interest in something like this?: (defmacro with-collect-matches (regexp &optional group &rest body) "Collect matches for REGEXP and eval BODY for each match. BODY is evaluated with `it' bound to the match. Optional GROUP if non-nil, then is the regexp group to save. Otherwise, save the whole match." From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 03 22:20:33 2017 Received: (at 26338) by debbugs.gnu.org; 4 Apr 2017 02:20:33 +0000 Received: from localhost ([127.0.0.1]:59697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvE59-0003Ds-Fn for submit@debbugs.gnu.org; Mon, 03 Apr 2017 22:20:33 -0400 Received: from mail-pg0-f43.google.com ([74.125.83.43]:33294) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvE56-0003Df-Tw for 26338@debbugs.gnu.org; Mon, 03 Apr 2017 22:20:29 -0400 Received: by mail-pg0-f43.google.com with SMTP id x125so137644179pgb.0 for <26338@debbugs.gnu.org>; Mon, 03 Apr 2017 19:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=MgLmTOSvzjjgimUbgM+J5I3gVIYUj/DUVTun6D8wz1M=; b=WYSEdx8svZOncP8q6eEIcUi0BvvEDfxfB9HU0IkDcMb6hJpoaxMa318qtQhuBEQvaW wedamJse44d3MLiARRW29XpmiWqN1jYuuGobT7M7Yfps95UtSfByq9DlKhZxjvXPIdBv mSAbcbgqnIMJyz4ujwxFl8tyPJnet56K/sbP0hWc1No5YrXzqGHQRVpjJo5i9pugeiAm 6TNBOGZNFbE1Z8xVnXDs8uZ1B0UjsAp6Wage9JR9UGDIX+le+WkpyfIUrnkNzlVjfYtH qawmZkEbbuYhfaqX8b/1MdhnfTFg1cOGQyvt5KHi/BkFySy1g1pgU0ucQpjW/RDYBbft MAog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=MgLmTOSvzjjgimUbgM+J5I3gVIYUj/DUVTun6D8wz1M=; b=FMOlcwOWW5aW/8/nWv8fAehFJo/sAhqfnDjKtkQ1Yu3Y5e8ykw4aIqIUwZdZeHjoVk Ebo2PUrKUhNPOSuKBMfg/bFOZZByf2o5F62T6PXFYzgLPT9YuCPVh4wdqJnkpAVmRlmG FS4HpVz0N+Hf6b82tCCLg5tJNGg752ZBAFlaqdQI11wYOTf1ftT8y+OORwXhNPC12cVD KROJ4+hKcjkXDWAd7tJRRKU2rYMlfnS28LepXrfPPGRsDrJcqLisaDR2z5cmVtVBJRs8 i5CPLmMRwsi7fW6fDWqw1tSoFyKMe8z9nD9t9pPJ21cTeBMz0ZNWcX1/JPbmgoi+lByq p4Fw== X-Gm-Message-State: AFeK/H27IP5Mx3aRjvqyP/IwLS5vVR2JHvVQoPMkdfbEo5L+YWlRfz0wvYXucJmCwo5yYA== X-Received: by 10.99.155.17 with SMTP id r17mr20979215pgd.193.1491272423170; Mon, 03 Apr 2017 19:20:23 -0700 (PDT) Received: from calancha-pc (MAR89-178.kek.jp. [130.87.89.178]) by smtp.gmail.com with ESMTPSA id i3sm28135012pfk.47.2017.04.03.19.20.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Apr 2017 19:20:22 -0700 (PDT) From: Tino Calancha To: Juri Linkov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <87lgrheyvn.fsf@calancha-pc> (Tino Calancha's message of "Tue, 04 Apr 2017 10:37:48 +0900") References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Date: Tue, 04 Apr 2017 11:20:18 +0900 Message-ID: <878tng9an1.fsf@calancha-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, tino.calancha@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) Tino Calancha writes: > Juri Linkov writes: >> occur-collect is intended for interactive use. As for programmatic use, >> Dmitry is right: a universal idiom is (while (re-search-forward ...)). >> This is why e.g. the docstring of =E2=80=98replace-regexp=E2=80=99 recom= mends to use >> an explicit loop like (while (re-search-forward ...) (replace-match ...)) > OK thanks. Let me ask you my last proposal before come back to my dark > cave and start painting animals in the walls. > > Any interest in something like this?: > > (defmacro with-collect-matches (regexp &optional group &rest body) > "Collect matches for REGEXP and eval BODY for each match. > BODY is evaluated with `it' bound to the match. > Optional GROUP if non-nil, then is the regexp group to save. Otherwise, > save the whole match." Sorry, i was paiting a mammoth and i forgot something in the docstring: --8<-----------------------------cut here---------------start------------->= 8--- (defmacro with-collect-matches (regexp &optional group &rest body) "Collect matches for REGEXP and eval BODY for each match. BODY is evaluated with `it' bound to the match. Optional GROUP if non-nil, then is the regexp group to save. Otherwise, save the whole match. Return a list with the matches." --8<-----------------------------cut here---------------end---------------= >8--- So, for instance: M-x find-library replace RET M-: (length (with-collect-matches "^(defun \\(\\S +\\)" 1)) RET =3D> 52 M-x find-library replace RET M-: (length (with-collect-matches "^(defun \\(\\S +\\)" 1 (with-current-buffer (get-buffer-create "*Matches*") (when (string-match "\\`query-" it) (insert (format "%s\n" it))))) =3D> 52 ;; Same return as before but only write into *Matches* those ;; functions with name starting with "query-". From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 04 10:32:27 2017 Received: (at 26338) by debbugs.gnu.org; 4 Apr 2017 14:32:27 +0000 Received: from localhost ([127.0.0.1]:60783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvPVS-0005zF-QY for submit@debbugs.gnu.org; Tue, 04 Apr 2017 10:32:27 -0400 Received: from mail.mojserwer.eu ([195.110.48.8]:42814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvPVQ-0005z6-57 for 26338@debbugs.gnu.org; Tue, 04 Apr 2017 10:32:24 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.mojserwer.eu (Postfix) with ESMTP id 05AD1E6BAA; Tue, 4 Apr 2017 16:32:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.mojserwer.eu Received: from mail.mojserwer.eu ([127.0.0.1]) by localhost (mail.mojserwer.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LdV1jtsMvKt; Tue, 4 Apr 2017 16:32:19 +0200 (CEST) Received: from localhost (apn-31-0-23-27.dynamic.gprs.plus.pl [31.0.23.27]) by mail.mojserwer.eu (Postfix) with ESMTPSA id 99DFEE6A30; Tue, 4 Apr 2017 16:32:18 +0200 (CEST) References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> User-agent: mu4e 0.9.19; emacs 26.0.50 From: Marcin Borkowski To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-reply-to: <87lgrheyvn.fsf@calancha-pc> Date: Tue, 04 Apr 2017 16:32:12 +0200 Message-ID: <87pogsmefn.fsf@jane> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2017-04-04, at 03:37, Tino Calancha wrote: > Juri Linkov writes: > >>>>> What do you think? >>>> >>>> But there is already the occur-collect feature implemented in occur-1 >>>> and occur-read-primary-args. Why would we need a separate command? >>> Indeed i don't think we need a new command for this. I am thinking more >>> in an standard function. >>> Following: >>> (occur "defun\\s +\\(\\S +\\)" "\\1") >>> >>> doesn't return the collected things. It writes the matches in *Occur* >>> buffer. Then, if you want a list with the matches you must loop >>> again inside *Occur* which is sub-optimal. >>> For me, it has sense to have a `occur-collect' which just returns the >>> list of matches. >>> Then, we might use such function in the implementation of occur-1 >>> which could bring a cleaner implementation. >>> We might get also the LIMIT argument for occur which might come >>> in handy for multi-occur with lot of input buffers (just an idea). >> >> occur-collect is intended for interactive use. As for programmatic use, >> Dmitry is right: a universal idiom is (while (re-search-forward ...)). >> This is why e.g. the docstring of ‘replace-regexp’ recommends to use >> an explicit loop like (while (re-search-forward ...) (replace-match ...)) > OK thanks. Let me ask you my last proposal before come back to my dark > cave and start painting animals in the walls. > > Any interest in something like this?: > > (defmacro with-collect-matches (regexp &optional group &rest body) > "Collect matches for REGEXP and eval BODY for each match. > BODY is evaluated with `it' bound to the match. > Optional GROUP if non-nil, then is the regexp group to save. Otherwise, > save the whole match." Sorry if this was said already, but why a macro and not a map-like function? Best, -- Marcin Borkowski From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 05 07:59:02 2017 Received: (at 26338) by debbugs.gnu.org; 5 Apr 2017 11:59:02 +0000 Received: from localhost ([127.0.0.1]:33271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvjaX-000357-Tr for submit@debbugs.gnu.org; Wed, 05 Apr 2017 07:59:02 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:32961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvjaW-00034p-A7 for 26338@debbugs.gnu.org; Wed, 05 Apr 2017 07:59:00 -0400 Received: by mail-pg0-f67.google.com with SMTP id 79so1754823pgf.0 for <26338@debbugs.gnu.org>; Wed, 05 Apr 2017 04:59:00 -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=fmbO6BXjcRbFbPsblOjTPFWR/Pt7pZjewjEt3cKfNtM=; b=JUEYkRzTPM4qrOi6yhS5UecabA+es/glwLnxzyI9JfMLBthRir74GI0eoG3chXFzgx +2ZU3Tg+98jpjyuALU2t07+O1R78Ig/w1Ijaf7Ksg7u0NinAGNtpmVpQ3ZrUKQRKkZbt jVYyUUffc032t+hDHdBGoZLIQaPpULYcqdHFkexJHYSvYI0ktJfAfgTk2pySb7TjnR00 duv0DaFLp+a2Idj5xKDuwv+RdkppeYFpDirZQOKHBe7hV2MU1ruWGuYIEidF1Bt34388 xRGsY0PKerIEkHe34UrNARRUGRs8RTiUN7shfBRN+IqD0MKriO27sSAeLjFLMw09Z1GF h2oQ== 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=fmbO6BXjcRbFbPsblOjTPFWR/Pt7pZjewjEt3cKfNtM=; b=UGUoAbJz8jwxDfFHhS7lDvBPR65Nti/Cw1RblkuYjtVHaxrpYUAFJgshIuPOFols8B G50pr+EZhv85GG+V7RdpAcAhw0hRpoEfLx1IXKSruWH1lH5kgEXFdboK3apqyuNe+o+6 dVsFow5NxsoihCnT8CaLHAIYNYLmxhc0mJzDMogW36G2RYB0iMZF+1C60wyK1sqpkrYj ql9yeCx8huESM3yC9H2+zg3nrWG10w50yxGTFiTWxuX1KP3FJIzT6JeKbEx6hXvYHXzZ g2sX3cnxgHpSNW1dSY/2sV3pY3J9rxWV4AA01tMciAi65n/YmARsWNxnG5fqbCmgUGZa UHGw== X-Gm-Message-State: AFeK/H2l8KF2IIypGRG7qAcTaNZs7BwZ9Iz88xDvtjd5J1VEVG9lp5AlLQ03xMaZ7lWj+A== X-Received: by 10.98.222.70 with SMTP id h67mr28590492pfg.43.1491393534487; Wed, 05 Apr 2017 04:58:54 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id m194sm37381517pga.62.2017.04.05.04.58.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 04:58:53 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Wed, 5 Apr 2017 20:58:51 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Marcin Borkowski Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <87pogsmefn.fsf@jane> Message-ID: References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Tue, 4 Apr 2017, Marcin Borkowski wrote: >> Any interest in something like this?: >> >> (defmacro with-collect-matches (regexp &optional group &rest body) >> "Collect matches for REGEXP and eval BODY for each match. >> BODY is evaluated with `it' bound to the match. >> Optional GROUP if non-nil, then is the regexp group to save. Otherwise, >> save the whole match." > > Sorry if this was said already, but why a macro and not a map-like > function? No special reason. It's the second idea which came to my mind after my initial proposal was declined. Maybe because is shorter to do: (with-collect-matches regexp) than (foo-collect-matches regexp nil #'identity) if you are just interested in the list of matches. Implementing it as a map function might be also nice. Don't see a big enthusiasm on the proposal, though :-( So far people think that it's easy to write a while loop. I wonder if they think the same about the existence of `dolist': the should never use it and always write a `while' loop instead. Don't think they do that anyway. I will repeat it once more. I find nice, having an operator returning a list with matches for REGEXP. If such operator, in addition, accepts a body of code or a function, then i find this operator very nice and elegant. Regards, Tino From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 05 09:10:14 2017 Received: (at 26338) by debbugs.gnu.org; 5 Apr 2017 13:10:14 +0000 Received: from localhost ([127.0.0.1]:33308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvkhS-0004po-0O for submit@debbugs.gnu.org; Wed, 05 Apr 2017 09:10:14 -0400 Received: from mail-it0-f47.google.com ([209.85.214.47]:32921) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvkhQ-0004pe-PP for 26338@debbugs.gnu.org; Wed, 05 Apr 2017 09:10:13 -0400 Received: by mail-it0-f47.google.com with SMTP id 68so20136675itx.0 for <26338@debbugs.gnu.org>; Wed, 05 Apr 2017 06:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=aBPNhBmr8gbs85FygsG2Jvh0rimstN9oHL9nHyt5qXo=; b=memcPRoDskoGgMdexlyn+xxAuJAQbEKRTm4kzzmDFwuwx1z7xlWGN2w3+brn0Ylr2j ydrXow6k+o6hBNv2zNZZGI23Ut6GZ62JBP/TFRIQme/TJm+glxcvTYPfxgIj+HRfivEA G4VdgqRix1F90mBqcVYmNbqzUCXL2gDXDNgMH7Au+ccOCmmCJ8cfgp8qXZiA3xcD3Xa9 WbYP9I+t9MEOAcTrgtpPD0essQpbkalj+1DuwAvUsABsZ8JaN7PLKIO+AbF/FBlbgaKW RIIkiqCf+YmBSh/uh8wpjnsiMRS3Npls9sgYfS9cshGYhcd+VHiL8fk4xyGBSr0rfK5K Zmow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=aBPNhBmr8gbs85FygsG2Jvh0rimstN9oHL9nHyt5qXo=; b=ieE909h1d4/RQrJp8PpmBerPZKpN+5tTOo0IMLKlJh7Grc56/aOTIevsGxH+HbYqES IbHTORU5mG/t9B0GkfQXMvLbd8Gzvm8iTA2CvGFNAbxop4T7knedlcVKM1mzhBzPMowr Bc6rlvRKfVoLDaNkctSdHcpLjMAGhQTE0Nviqn+NYe6KhSSsV/iDnZn0uLSwEPRy1xZx BiErsentSHySqPelmC0iRSCN8FhFWFa6q01bI2y6hyUrnuhipWbI+tKvvM2AleS9oqP6 i44ZyCJv6LZxJTTeBOQuY/MhIRd2c+A6EOo4xQ7MpzRfJKSDJscX8RTFylZg6UopzV6Y 3TPA== X-Gm-Message-State: AFeK/H2s/YsCN9gSi91Qch/uzigJtbf9ngcMxanPjxlaE2nuFflYjRbs AfI8k8J6pBHdkQ== X-Received: by 10.36.51.212 with SMTP id k203mr20797468itk.6.1491397806961; Wed, 05 Apr 2017 06:10:06 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id c91sm10580865iod.18.2017.04.05.06.10.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 05 Apr 2017 06:10:06 -0700 (PDT) From: npostavs@users.sourceforge.net To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> Date: Wed, 05 Apr 2017 09:11:30 -0400 In-Reply-To: (Tino Calancha's message of "Wed, 5 Apr 2017 20:58:51 +0900 (JST)") Message-ID: <874ly3vw1p.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Marcin Borkowski , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) Tino Calancha writes: > > So far people think that it's easy to write a while loop. I wonder if > they think the same about the existence of `dolist': the should > never use it and always write a `while' loop instead. Don't think they > do that anyway. Perhaps a macro that loops over matches? (defmacro domatches (spec &rest body) "Loop over matches to REGEXP. \(fn (MATCH-VAR [GROUP] REGEXP [BOUND]) BODY...)") 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. > I will repeat it once more. I find nice, having an operator returning > a list with matches for REGEXP. I don't think that's come up for me very much, if at all. It seems easier to just operate on the matches directly rather than collecting and then mapping. > If such operator, in addition, > accepts a body of code or a function, then i find this operator very > nice > and elegant. Forcing collection on the looping operator seems inelegant to me. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 05 18:05:37 2017 Received: (at 26338) by debbugs.gnu.org; 5 Apr 2017 22:05:37 +0000 Received: from localhost ([127.0.0.1]:34151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvt3Z-0003uv-2Z for submit@debbugs.gnu.org; Wed, 05 Apr 2017 18:05:37 -0400 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:33199 helo=homiemail-a23.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvt3X-0003un-F4 for 26338@debbugs.gnu.org; Wed, 05 Apr 2017 18:05:36 -0400 Received: from homiemail-a23.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTP id 92A534B006D; Wed, 5 Apr 2017 15:05:33 -0700 (PDT) Received: from localhost.linkov.net (m91-131-168-2.cust.tele2.ee [91.131.168.2]) (Authenticated sender: jurta@jurta.org) by homiemail-a23.g.dreamhost.com (Postfix) with ESMTPA id 87E334B0063; Wed, 5 Apr 2017 15:05:32 -0700 (PDT) From: Juri Linkov To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer Organization: LINKOV.NET References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> Date: Thu, 06 Apr 2017 01:03:04 +0300 In-Reply-To: (Tino Calancha's message of "Wed, 5 Apr 2017 20:58:51 +0900 (JST)") Message-ID: <871st6342v.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Marcin Borkowski X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) >> Sorry if this was said already, but why a macro and not a map-like >> function? > No special reason. It's the second idea which came to my mind after > my initial proposal was declined. Maybe because is shorter to do: > (with-collect-matches regexp) > than > (foo-collect-matches regexp nil #'identity) > > if you are just interested in the list of matches. Implementing it as > a map function might be also nice. Don't see a big enthusiasm on > the proposal, though :-( > > So far people think that it's easy to write a while loop. I wonder if they > think the same about the existence of `dolist': the should > never use it and always write a `while' loop instead. Don't think they > do that anyway. > > I will repeat it once more. I find nice, having an operator returning > a list with matches for REGEXP. If such operator, in addition, accepts > a body of code or a function, then i find this operator very nice > and elegant. A mapcar-like function presumes a lambda where you can process every match as you need, but going this way you'd have a temptation to implement an analogous API from other programming languages like e.g. https://apidock.com/ruby/String/scan From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 07 06:06:41 2017 Received: (at 26338) by debbugs.gnu.org; 7 Apr 2017 10:06:41 +0000 Received: from localhost ([127.0.0.1]:35756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwQmv-0000cb-B8 for submit@debbugs.gnu.org; Fri, 07 Apr 2017 06:06:41 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:34881) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwQmt-0000cP-PC for 26338@debbugs.gnu.org; Fri, 07 Apr 2017 06:06:40 -0400 Received: by mail-pg0-f42.google.com with SMTP id 81so62525885pgh.2 for <26338@debbugs.gnu.org>; Fri, 07 Apr 2017 03:06:39 -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=YXyovoUuEil1X1I6jY8aKUZK9u85O8E1mosauz8jPEA=; b=gJq52jnSxv7SRpY+wIChnW+FPGnphZVuOoGtoN5QY7O7k+l0zgN9mbGHbUzVGjVwFN JNlydnavfZIlElbgMTKXvmgerkksfvsH3P5C7k4/22Fr1JlOlMuykCXAIw5/pvnIBOPw uCT6vxV8eOJnbGQBwPQQueLQizdkCLyEecHukEfzKaLKZTvzkkrlPJLGxhpeHLZtAxhK oGO4BV58u4xwRA0amDqM3exuDEOJB1FRZFMRgK8fsO13FrHiBgo9K5dKYK+xm0yFOgeh B5KcpdGLznZP5OSTaQaikWWWUBt4wEvC3J3v2kbOw4CJjQjVdgU6G4akWDTjJBLPgMph GZdA== 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=YXyovoUuEil1X1I6jY8aKUZK9u85O8E1mosauz8jPEA=; b=cHI5J5OhPZwEOPtbKiy4+RgYrYST98loJzi4gIbawkTzWSL59g2fpTkgOLv4qxfzr1 AdPNagjMByLRdI5r2IwyRbQlZAOH+QRJw7lJAFHK5JN65hga2wRYMUwAMIzdyHxik+Ws h7b2L8i5VOjg7ID0FZjNLhLlvyFJCM+CCAS27+6X9OJSmR9VQzy2Ax70cwrguxO7t5+m bvDQakJclOTTLO5FzzHvgI0y2SyZKM/nhYrNFM7VlUJ8JFeAu/lyeXYAgAqyOYzpHQsh bE2CVmpSQQvoVyn1m+QFarTj3CJp9fzTBvVdncWxl4KnXPrtBbYh3j4HV0yPWPG0XtzR 0V0g== X-Gm-Message-State: AFeK/H27xCNx7oAGfIh0wtcjwzxryAUtGZMN+p2r3i4hIfed9ZCJFTnE/5e6Odec/uD7gQ== X-Received: by 10.99.8.67 with SMTP id 64mr35813568pgi.220.1491559594031; Fri, 07 Apr 2017 03:06:34 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id q64sm8634943pfi.69.2017.04.07.03.06.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 03:06:33 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Fri, 7 Apr 2017 19:06:30 +0900 (JST) X-X-Sender: calancha@calancha-pc To: npostavs@users.sourceforge.net Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <874ly3vw1p.fsf@users.sourceforge.net> 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Wed, 5 Apr 2017, npostavs@users.sourceforge.net wrote: > Tino Calancha writes: > >> >> So far people think that it's easy to write a while loop. I wonder if >> they think the same about the existence of `dolist': the should >> never use it and always write a `while' loop instead. Don't think they >> do that anyway. > > Perhaps a macro that loops over matches? > > (defmacro domatches (spec &rest body) > "Loop over matches to REGEXP. > > \(fn (MATCH-VAR [GROUP] REGEXP [BOUND]) BODY...)") > > 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 ;-) > >> I will repeat it once more. I find nice, having an operator returning >> a list with matches for REGEXP. > > I don't think that's come up for me very much, if at all. It seems > easier to just operate on the matches directly rather than collecting > and then mapping. Sometimes i want to collect matches for different purposes; feed them into another functions accepting a list. That's why i miss a standard operator collecting matches. Sure, it can be done with a `while' loop, and 3-5 lines. With the operator would be just one function call. >> If such operator, in addition, >> accepts a body of code or a function, then i find this operator very >> nice >> and elegant. > > Forcing collection on the looping operator seems inelegant to me. You know, the beauty is in the eyes watching. The elegance too. Maybe you don't like the blue jersey i am wearing now; my mum made it for me and i love it ;-) Suppose depend on the name of the operator. Not a sorprise if `collect-matches' collect matches; a bit of sorprise if `domatches' does such thing. Thank you for your opinion :-) From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 07 10:40:42 2017 Received: (at 26338) by debbugs.gnu.org; 7 Apr 2017 14:40:42 +0000 Received: from localhost ([127.0.0.1]:36657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwV46-0000dS-0l for submit@debbugs.gnu.org; Fri, 07 Apr 2017 10:40:42 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:27818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwV44-0000dF-HS for 26338@debbugs.gnu.org; Fri, 07 Apr 2017 10:40:40 -0400 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 v37EeXf0029872 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Apr 2017 14:40:33 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v37EeXma004982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Apr 2017 14:40:33 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v37EeVE6011999; Fri, 7 Apr 2017 14:40:31 GMT MIME-Version: 1.0 Message-ID: <943bd0fd-c4ad-48f4-a803-f832b5bf0edf@default> Date: Fri, 7 Apr 2017 07:40:28 -0700 (PDT) From: Drew Adams To: Tino Calancha , npostavs@users.sourceforge.net Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer 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> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Marcin Borkowski , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.6 (----) > > 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 wan= t > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 07 10:47:30 2017 Received: (at 26338) by debbugs.gnu.org; 7 Apr 2017 14:47:30 +0000 Received: from localhost ([127.0.0.1]:36665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwVAg-0000nt-0c for submit@debbugs.gnu.org; Fri, 07 Apr 2017 10:47:30 -0400 Received: from mail-pg0-f49.google.com ([74.125.83.49]:35635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwVAe-0000ne-7K for 26338@debbugs.gnu.org; Fri, 07 Apr 2017 10:47:28 -0400 Received: by mail-pg0-f49.google.com with SMTP id 81so68819803pgh.2 for <26338@debbugs.gnu.org>; Fri, 07 Apr 2017 07:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=oYXF1aZrMgfbb3GIZUwjbC5raKbKyq7vukaC16miGdY=; b=GsbhXPKSwy6BGWb+ojdJURw/I05FB8A9UFBKtr1cnMjGPlqYt+bM5qIrxWU7r3T6nV WKFToTiGA1q+iIts5XSD7Z3J4S6cyQta0R+vYF3fl3y81wrZC0k/8Nlmhoxx10Zf2yEh p3N+4zoK0ExahkeoN5vqmBZJnJjjQKyOaYLncvC+7lYS6Q7SJ3UnjSMaiMdQXEiAY+NN 8tPpve4sIce3s2jzCPJW4oDgsJUgvyxYBILDWff+AmoBdgGOBoWHTI0bBpSbED6nXMra PZpxdw/BdcPc9VlprRFdxt1KSgET17NDYM9stBVfSgD3HjcEfFMU0D729Pq0Pjy6rrdQ xchg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=oYXF1aZrMgfbb3GIZUwjbC5raKbKyq7vukaC16miGdY=; b=LBVn7PrnzToURPZslApcV7BIZ0IO8D/oYPnq4S8SSy33rK65KNMYGY+Uiu91ZXZcPm +5GaXeTIURZHBmqA8/DSz9J62ey6PL3/6gCtrJCXPxYa272yMarQreUIP0CjWfYPcn2e 7A6vw7ETvqSbN118ZoBr/K47bzF9AiYJIPQ6WhlCeiJeSTIlbydUiw33xfKa8LH4raBr JIFLBeY433VFzlUIefTFh4B/XYO+YIdS9IDOM1kKhNXeit8lOgDW76JBPfbqZPTJn1sh Cq5NJhPPYsAB5MQ3FKHcGVFRbj24qWV8WaQgXCboLxpt46wYsl9AkYipmMVslmtZLiDY 0xAw== X-Gm-Message-State: AFeK/H0C3/plP4Iz6Q3N/Tq1OwGf0UkrhC9Qhfvszd7tII2OPsen9Sb5YxelPrsREYo7wg== X-Received: by 10.84.231.9 with SMTP id f9mr49370546plk.191.1491576442205; Fri, 07 Apr 2017 07:47:22 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id g5sm10212435pfe.12.2017.04.07.07.47.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 07 Apr 2017 07:47:21 -0700 (PDT) From: Tino Calancha To: Juri Linkov Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> <871st6342v.fsf@localhost> Date: Fri, 07 Apr 2017 23:47:16 +0900 In-Reply-To: <871st6342v.fsf@localhost> (Juri Linkov's message of "Thu, 06 Apr 2017 01:03:04 +0300") Message-ID: <87a87sqnpn.fsf@calancha-pc> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Dmitry Gutov , Marcin Borkowski , tino.calancha@gmail.com, npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Juri Linkov writes: >>> Sorry if this was said already, but why a macro and not a map-like >>> function? >> No special reason. It's the second idea which came to my mind after >> my initial proposal was declined. Maybe because is shorter to do: >> (with-collect-matches regexp) >> than >> (foo-collect-matches regexp nil #'identity) >> >> if you are just interested in the list of matches. Implementing it as >> a map function might be also nice. Don't see a big enthusiasm on >> the proposal, though :-( >> >> So far people think that it's easy to write a while loop. I wonder if they >> think the same about the existence of `dolist': the should >> never use it and always write a `while' loop instead. Don't think they >> do that anyway. >> >> I will repeat it once more. I find nice, having an operator returning >> a list with matches for REGEXP. If such operator, in addition, accepts >> a body of code or a function, then i find this operator very nice >> and elegant. > > A mapcar-like function presumes a lambda where you can process every > match as you need, but going this way you'd have a temptation to > implement an analogous API from other programming languages like e.g. > https://apidock.com/ruby/String/scan I am not crazy with the mapcar-like implemention either. Actually, I have changed my mind after nice Noah suggestion. He mentioned the possibility of extend `cl-loop' with a new clause to iterate on matches for a regexp. I think this clause fits well in cl-loop; this way we don't need to introduce a new function/macro name. --8<-----------------------------cut here---------------start------------->8--- commit 59e66771d13fce73ff5220ce3df677b9247c9c52 Author: Tino Calancha Date: Fri Apr 7 23:31:08 2017 +0900 New clause in cl-loop to iterate in the matches of a regexp Add new clause in cl-loop facility to loop over the matches for REGEXP in the current buffer (Bug#26338). * lisp/emacs-lisp/cl-macs.el (cl--parse-loop-clause): Add new clause. (cl-loop): update docstring. * doc/misc/cl.texi (For Clauses): Document the new clause. * etc/NEWS: Mention this change. diff --git a/doc/misc/cl.texi b/doc/misc/cl.texi index 2339d57631..6c5c43ad09 100644 --- a/doc/misc/cl.texi +++ b/doc/misc/cl.texi @@ -2030,6 +2030,21 @@ For Clauses This clause iterates over a sequence, with @var{var} a @code{setf}-able reference onto the elements; see @code{in-ref} above. +@item for @var{var} being the matches of @var{regexp} +This clause iterates over the matches for @var{regexp} in the current buffer. +By default, @var{var} is bound to the full match. Optionally, @var{var} +might be bound to a subpart of the match. It's also possible to restrict +the loop to a given number of matches. For example, + +@example +(cl-loop for x being the matches of "^(defun \\(\\S +\\)" + using '(group 1 limit 10) + collect x) +@end example + +@noindent +collects the next 10 function names after point. + @item for @var{var} being the symbols [of @var{obarray}] This clause iterates over symbols, either over all interned symbols or over all symbols in @var{obarray}. The loop is executed with diff --git a/etc/NEWS b/etc/NEWS index aaca229d5c..03f6ecb88b 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -862,6 +862,10 @@ instead of its first. * Lisp Changes in Emacs 26.1 +++ +** New clause in cl-loop to iterate in the matches for a regexp +in the current buffer. + ++++ ** Emacs now supports records for user-defined types, via the new functions 'copy-record', 'make-record', 'record', and 'recordp'. Records are now used internally to represent cl-defstruct and defclass diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el index 25c9f99992..50596c066e 100644 --- a/lisp/emacs-lisp/cl-macs.el +++ b/lisp/emacs-lisp/cl-macs.el @@ -892,6 +892,7 @@ cl-loop the overlays/intervals [of BUFFER] [from POS1] [to POS2] the frames/buffers the windows [of FRAME] + the matches of/for REGEXP [using (group GROUP [limit LIMIT])] Iteration clauses: repeat INTEGER while/until/always/never/thereis CONDITION @@ -1339,6 +1340,33 @@ cl--parse-loop-clause (push (list temp-idx `(1+ ,temp-idx)) loop-for-steps))) + ((memq word '(match matches)) + (let* ((_ (or (and (not (memq (car cl--loop-args) '(of for))) + (error "Expected `of'")))) + (regexp (cl--pop2 cl--loop-args)) + (group-limit + (and (eq (car cl--loop-args) 'using) + (consp (cadr cl--loop-args)) + (>= (length (cadr cl--loop-args)) 2) + (cadr (cl--pop2 cl--loop-args)))) + (group + (or (and group-limit + (cl-find 'group group-limit) + (nth (1+ (cl-position 'group group-limit)) group-limit)) + 0)) + (limit + (and group-limit + (cl-find 'limit group-limit) + (nth (1+ (cl-position 'limit group-limit)) group-limit))) + (count (make-symbol "--cl-count"))) + (push (list count 0) loop-for-bindings) + (push (list var nil) loop-for-bindings) + (push `(re-search-forward ,regexp nil t) cl--loop-body) + (push `(or (null ,limit) (and (natnump ,limit) (< ,count ,limit))) cl--loop-body) + (push (list count `(1+ ,count)) loop-for-sets) + (push (list var `(match-string-no-properties ,group)) + loop-for-sets))) + ((memq word hash-types) (or (memq (car cl--loop-args) '(in of)) (error "Expected `of'")) --8<-----------------------------cut here---------------end--------------->8--- In GNU Emacs 26.0.50 (build 7, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-04-07 Repository revision: 67aeaa74af8504f950f653136d749c6dd03a60de From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 07 11:28:57 2017 Received: (at 26338) by debbugs.gnu.org; 7 Apr 2017 15:28:57 +0000 Received: from localhost ([127.0.0.1]:36705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwVon-0001pk-LD for submit@debbugs.gnu.org; Fri, 07 Apr 2017 11:28:57 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:32971) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwVol-0001pU-8D for 26338@debbugs.gnu.org; Fri, 07 Apr 2017 11:28:55 -0400 Received: by mail-oi0-f43.google.com with SMTP id b187so89968610oif.0 for <26338@debbugs.gnu.org>; Fri, 07 Apr 2017 08:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3D5aoE2QXxu6KctnxBQD3VDpwXP2RmeivRxbQ84Wrh8=; b=vaY0RhtcdUAmdqLwNIMZxHD4sn0489eNnZlJs3zugMSxbzW5DETUrEafMnylMGwKcH F0VYn/5dHW4u245+uLtn3ifX/Lb0MrBVPO/DnxQTylUKJopvcskl1hSxtJb5UZCHfl1t cADkNZHRRMcDuFwnJsD3OrPTnUrYTfdSkcDZrOFBlZjkXMBB86pD8hn+v7Mhkbyht2BH zHXmepa53Ob2t7czIMpfplvVCK2HuxtADQYPUuz8okVXBvpHGU87Xlz5PpmsWOdmk560 R71f7Gm6zu/iTH4vOkSiXu/0K8eMhUAphJkf4Uhn4+awgqYjzRbDJEbQw9V+zACKUMO0 ToWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3D5aoE2QXxu6KctnxBQD3VDpwXP2RmeivRxbQ84Wrh8=; b=rVDBqiuLv/kGby5xAd0g6c7m+6F845jGQEcpN09cPpPpMqj8hfH1zdIg5qPoCJ0EZV S1vjo2i4OBpwDd6f/rsFtNCMPZL3knw6W6nDrIaxii1Ltn/2fO+8ftX3v3tKnwN9Cze8 jk9fFaWi4OLWOLKxIMd7WbUc40vd5+obFtaUEK3tu7u/I5GVcse3RnlrsOSHvfuGVQzt pZIV651mIK4SG+68d/eXMH0OXGQl6BYJ88rxufcHMPBKq7bnBVXJyBo97uK+rvqOdbBk oLz1snWM2oIcK+E+C5pSm33QCy4kOoY1sgrRY4IZzH7Kx5HJaIisK6WVFc/DvM8T5eg+ M0Ow== X-Gm-Message-State: AFeK/H25zVwXjwrsNWgsQE1KHcFWEalY+tcSggx+FKsHPPvOnU/iiWXmDgXhgVCkjDAKVxONAIucsr91Ro3DoA== X-Received: by 10.157.38.42 with SMTP id a39mr23170311otb.267.1491578927394; Fri, 07 Apr 2017 08:28:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.80.133 with HTTP; Fri, 7 Apr 2017 08:28:46 -0700 (PDT) In-Reply-To: <87a87sqnpn.fsf@calancha-pc> References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> <871st6342v.fsf@localhost> <87a87sqnpn.fsf@calancha-pc> From: Noam Postavsky Date: Fri, 7 Apr 2017 11:28:46 -0400 X-Google-Sender-Auth: fRNeOK0QcXO5rXvQ5tz2aaNASqI Message-ID: Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: Tino Calancha Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Dmitry Gutov , Marcin Borkowski , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On Fri, Apr 7, 2017 at 10:47 AM, Tino Calancha wrote: > + > +@example > +(cl-loop for x being the matches of "^(defun \\(\\S +\\)" > + using '(group 1 limit 10) > + collect x) > +@end example You can reuse the existing 'repeat N' clause instead of 'using (limit N)'. (cl-loop for x being the matches of "^(defun \\(\\S +\\)" using (group 1) repeat 10 collect x) Regarding Drew's concerns about extending cl-loop with more non-Common Lisp things, I just don't see that as a problem. I suppose it would be nice to have a more easily extensible looping macro, like iterate [1]. That would be quite a bit of work though. [1]: https://common-lisp.net/project/iterate/ From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 07 11:54:59 2017 Received: (at 26338) by debbugs.gnu.org; 7 Apr 2017 15:54:59 +0000 Received: from localhost ([127.0.0.1]:36710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwWDy-0002Pw-Qo for submit@debbugs.gnu.org; Fri, 07 Apr 2017 11:54:59 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:42483) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwWDw-0002Pj-Ll for 26338@debbugs.gnu.org; Fri, 07 Apr 2017 11:54:57 -0400 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 v37FsnmR005266 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Apr 2017 15:54:50 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v37FsmYK027267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Apr 2017 15:54:48 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v37FskYM028985; Fri, 7 Apr 2017 15:54:47 GMT MIME-Version: 1.0 Message-ID: <1258a7b8-6c73-4cef-ab23-bc324a2c6f12@default> Date: Fri, 7 Apr 2017 08:54:44 -0700 (PDT) From: Drew Adams To: Noam Postavsky , Tino Calancha Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> <871st6342v.fsf@localhost> <87a87sqnpn.fsf@calancha-pc> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Dmitry Gutov , Marcin Borkowski , Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.6 (----) > Regarding Drew's concerns about extending cl-loop with more non-Common > Lisp things, I just don't see that as a problem. It depends on what one considers "a problem". I think it is a problem for `cl-', which was intended for Common Lisp emulation, to become a dumping ground for anyone's idea of a cool thing to add to Emacs. That's not what it's for. We've already had a couple of things unrelated to CL that were misguidedly added to `cl-'. We should not continue that practice (and we really should remove those from the `cl-' namespace). There is nothing preventing Emacs from adding any constructs it wants. There just is no reason why the `cl-' namespace (and the `cl*.el' files) should be polluted with stuff that is not Common Lisp emulation. A user of `cl-loop' should be able to expect Common Lisp `loop', or as close to it as we can get. > I suppose it would be nice to have a more easily extensible > looping macro, like iterate [1]. That would be quite a bit > of work though. As for `iterate': If this is what you mean: https://common-lisp.net/project/iterate/ then I'm all in favor of it. I much prefer it to `loop'. But I don't see anyone stepping forward to add it to Emacs. Even then, I would probably prefer that we add it to the `cl-' namespace and stay as close as possible to emulating the Common Lisp `iterate' (no, it is not part of the CL language, but yes, it is something developed for/with CL). There are lots of users of CL, and lots of CL code. Both should find a simple, straightforward path to Emacs. We should minimize any differences between Emacs emulations and the things being emulated. But again, nothing prevents Emacs adding a different construct that does exactly what you want, with all the bells and whistles you think are improvements over `loop' or `iterate' or whatever. That should not be in the `cl-' namespace, and we should not confuse users by passing it off as (even a partial) emulation of a Common Lisp construct. That's all. Just one opinion. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 00:46:01 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 04:46:01 +0000 Received: from localhost ([127.0.0.1]:36968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwiG9-0000RA-Ay for submit@debbugs.gnu.org; Sat, 08 Apr 2017 00:46:01 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwiG7-0000Qy-U4 for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 00:46:00 -0400 Received: by mail-pf0-f194.google.com with SMTP id n11so3002424pfg.2 for <26338@debbugs.gnu.org>; Fri, 07 Apr 2017 21:45:59 -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=WwRGZj+MFMDeAmy2/QWhYlDeYAERNLvzk5CoLKFGg1w=; b=lobHSQSKFRxtfQPgGKNLObyAXFgzdtRpvrdXwr2YUmeJIzAwTXJ2eKF8P3l+jMalhp UMpM0V2IidKZBWPjdTnEV2mB2f7s3BWnC57iPQVKuz4qAq6mfdOYFunkj+pLhBskpTGZ QvBPqZtSfgfiK/aKW+8Ueap4O7YEYrSvuCf5Fgah7gMtjgGiIVTJbWS6NF0H371o+FP3 +hv/SQ9N0EbCXsh5MfuhwI/fmSG56Siu6h+5RqKwjOYYAvGEIRiawHdHhxLzXAtyDF3/ RF8NaN9R8B0IgjNSHKgdsx7HmIAl0PsVNjkHWjBoAJGqwKCFJjRxfFhPBtu8PCWHAW5c 6rOg== 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=WwRGZj+MFMDeAmy2/QWhYlDeYAERNLvzk5CoLKFGg1w=; b=YV9nkKB4jMDddYZpXCl7AK8uU+reBzpQMuNKQ6gB+Ec5bjXVolRmCJwMAE2CG/TQKO 0hL6y5VoBm4DLFFx5qNxeq40sxjTXTBjRcnvmtbPL6uUGG6v4N89ZWn+UW4zrQV7cHu2 s+4wtSErIKGL4k91FAKJ3NONuPm+TN1mf7u8YuTSkSPzf4l5GnoI2trWQTZm9vSXCxD0 uL0rU5QY6DUohT4YftYCH5Dx+v6jCo6YD460orN0B6kQEmzhb/8eRx3eMN6ofiaysPwZ nrKGEPx26hCU0wjDBwJ24mvjUW6O6cWIKOmh6zLzDIzVSAIO4QvDI8zBLxXgAR16m0wZ +TgA== X-Gm-Message-State: AFeK/H1/viaGtax7UmW0PSfzZLToZuKyWgNZY9EutRm0UCB3fk+Bvp9tnTPKbi8AByUB4A== X-Received: by 10.98.68.82 with SMTP id r79mr45198886pfa.41.1491626754044; Fri, 07 Apr 2017 21:45:54 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id t187sm12191495pfb.116.2017.04.07.21.45.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 21:45:53 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Sat, 8 Apr 2017 13:45:49 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Drew Adams Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: <943bd0fd-c4ad-48f4-a803-f832b5bf0edf@default> 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , npostavs@users.sourceforge.net, Marcin Borkowski , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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. 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? I find interesting be able to do things like the following: --8<-----------------------------cut here---------------start------------->8--- (require 'find-lisp) (let ((op "defun") (dir (expand-file-name "lisp" source-directory))) (setq funcs (cl-loop for f in (find-lisp-find-files dir "\.el\\'") nconc (with-temp-buffer (insert-file-contents-literally f) (let ((regexp (format "^(%s \\(\\S +\\)" op))) (cl-loop for x the matches of regexp using '(group 1) collect x))))) (length funcs)) => 38898 ; op: defun => 1256 ; op: defmacro => 1542 ; op: defsubst --8<-----------------------------cut here---------------end--------------->8--- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 01:49:42 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 05:49:42 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Fri, 7 Apr 2017 22:49:29 -0700 (PDT) From: Drew Adams To: Tino Calancha Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer 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> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.6 (----) > >>> 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). From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 07:47:09 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 11:47:09 +0000 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 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 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) MIME-Version: 1.0 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> In-Reply-To: From: Philipp Stephani Date: Sat, 08 Apr 2017 11:46:50 +0000 Message-ID: Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: Tino Calancha , Drew Adams Content-Type: multipart/alternative; boundary=001a1147c434d27591054ca64c83 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 09:42:54 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 13:42:54 +0000 Received: from localhost ([127.0.0.1]:37270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwqdh-00078N-Po for submit@debbugs.gnu.org; Sat, 08 Apr 2017 09:42:53 -0400 Received: from mail-pf0-f174.google.com ([209.85.192.174]:33791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwqdf-000783-DF for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 09:42:52 -0400 Received: by mail-pf0-f174.google.com with SMTP id s16so15558316pfs.0 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 06:42:51 -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=C+0oPa1fEOZ/WSGH4ibcPujtSUJV2wex2PKyCKB0aVw=; b=dXWM2UCe8vFBCb6Puo7v9lRwEMsGIGJzt39g2NBbAzS/NHfObskwWisExSb8xRt1+v ORieB5wv0/73t17Kmf7A4WDED3+m5571xgkdIQj6bKcR8FP0x8ezz7pMu9S6YRwanfC/ tQRRPh25HCpJHvq0+VUuobUAK/itBf6Uxxxt5sKY8OqpQ4sKZRpDCwkVCx2uLa30sD+B nBRRyYNNPqdIxYuldT2TXBW+UvX/lh185JLmQ5rFxdgSdji0RH+la/Xn4tQUzINyMq/Q Id0AKYdulmXy9iT/ne2SYPvbhIokSL4sUsFcZHaJLOG50foYK3JRxCg3E8CREP0jRxFm vS4Q== 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=C+0oPa1fEOZ/WSGH4ibcPujtSUJV2wex2PKyCKB0aVw=; b=GiNBLRZe6k5g8BeBhzk1U4BOhee5uRFiMkbf/TrGVo95IVNG4eCvLQNHpOJij9bEZv NEqgEA0yuiNK8xEh0NksMi7x1NRTs1XRmLfpcpxv86GLCGQFVbNUcDWZBDxqfqXmywAV xvNRWR86fz2/Oxnwo+eTcialJlX9+YOx6/9tY+QBrl2Dc/B0dYPe3br/1vfv5W3asbEM LHuPvC4FexWuOXg3WUHXYNFzjTGufBnilyrBoZYYflzxrXoMBhrMXT4z+67hsrzPNCJE SbvdbRFR1oDM/NpxMfrKW3s4EuH0Cz8fLZNlYM+fbWGxHoRsE5EKTGKhlLIWU50WB9fc sz4g== X-Gm-Message-State: AFeK/H3v0YV1WEQDGEi2ObWQekYXk40qa1E1Rb0LuoG7dxIW6+hH9/OoBrZW+8dB6s2OrA== X-Received: by 10.99.209.85 with SMTP id c21mr46944936pgj.147.1491658965665; Sat, 08 Apr 2017 06:42:45 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id 78sm15255608pfm.134.2017.04.08.06.42.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 06:42:45 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Sat, 8 Apr 2017 22:42:41 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Philipp Stephani Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-967213713-1491658964=:16237" X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 26338 Cc: Marcin Borkowski , npostavs@users.sourceforge.net, 26338@debbugs.gnu.org, Tino Calancha , Juri Linkov , Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) --8323329-967213713-1491658964=:16237 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 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. --8323329-967213713-1491658964=:16237-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 09:50:00 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 13:50:00 +0000 Received: from localhost ([127.0.0.1]:37288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwqka-0000di-0i for submit@debbugs.gnu.org; Sat, 08 Apr 2017 09:50:00 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:35804) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwqkZ-0000dT-0O for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 09:49:59 -0400 Received: by mail-pg0-f67.google.com with SMTP id g2so20242555pge.2 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 06:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=JvaWYSZs+6dYyTe13/bs05MH8dG/IG8FJjv7MDTtGzE=; b=NtgllsMUksUsbSsEYBCp27hhNL5hFyQlWtFPAQGPrJ9M8y3wBWTbeAOjBQXcKYRFWc fYH4KgtyGzkeit/V4mpEm+tQ2wy5Ez1oTWQ8X7n56ZAHLidobnckOCzSwN8wqGHGsFLb 7y0muncwzcu/bkniKYtcgUW5nEbIeaFzQb5M6ZN4b5CsxjX7yPiYjgxKx9bp9QcjPz9a 5AxKgwaINjpFOtxazsiKpT43FBMQKzDF5/lkmLQIOOrPvdXzI4nU3e60Fk5fPMGAwBgJ XCkmLZoB/7/1mKmBjUjkpLxKyveEFQlxon2KtebVHNxNE5BgNanQhgroTkshxta3ac1i 41sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=JvaWYSZs+6dYyTe13/bs05MH8dG/IG8FJjv7MDTtGzE=; b=SWoglAP9f/kN+2aYqD2qZFNZKeRPF1KpBnijn8DPhY0Icwx1dMxeJdv4tl7XyxuqpP 50Sd7pwsIJ1SbuALfOBNBD7XIQpWeblpV3KhVE88cwsz64QjYfyezs9Qu880puGviHrc CecU5YImniW/XfglFqmuKtm0XdqIaQAr/xojdz9E2ehxlYsXKp1l9SbWgr0ZGXcRXanc /8hD0jb94aWdcTs5h0Dd6rggYZlXO3Dy0szHnNT3DzF40nsqRh6RtjnBHFFHULeuel8f vQv3Pe6F7qgQfqzmkcjBj5tFRSYqoyl7B8/y/Yb38JacLkx8nWbR4YR48qcA+A4yhEsZ qz+A== X-Gm-Message-State: AFeK/H1AQNgT8TYqzoGk6DBvWIf2Uq3p0Ctmn9IN3U3VJ7W7KX/bktSJdZN0cZ7dS/EAuQ== X-Received: by 10.84.236.1 with SMTP id q1mr56274847plk.135.1491659392885; Sat, 08 Apr 2017 06:49:52 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id c16sm15327410pfl.7.2017.04.08.06.49.50 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 08 Apr 2017 06:49:52 -0700 (PDT) From: Tino Calancha To: Noam Postavsky Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> <87h926cvgl.fsf@localhost> <87k272ow7g.fsf@calancha-pc> <87fuhpcbem.fsf@localhost> <87lgrheyvn.fsf@calancha-pc> <87pogsmefn.fsf@jane> <871st6342v.fsf@localhost> <87a87sqnpn.fsf@calancha-pc> Date: Sat, 08 Apr 2017 22:49:48 +0900 In-Reply-To: (Noam Postavsky's message of "Fri, 7 Apr 2017 11:28:46 -0400") Message-ID: <87k26vqa9v.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Noam Postavsky writes: > On Fri, Apr 7, 2017 at 10:47 AM, Tino Calancha wrote: >> + >> +@example >> +(cl-loop for x being the matches of "^(defun \\(\\S +\\)" >> + using '(group 1 limit 10) >> + collect x) >> +@end example > > You can reuse the existing 'repeat N' clause instead of 'using (limit N)'. > > (cl-loop for x being the matches of "^(defun \\(\\S +\\)" using (group 1) > repeat 10 > collect x) Right! Thank you. I fixed some other parts of the patch as well. --8<-----------------------------cut here---------------start------------->8--- commit fc2eed78e8c5591c3aad358a885b4b5bae6c1041 Author: Tino Calancha Date: Sat Apr 8 22:49:10 2017 +0900 New clause in cl-loop to iterate in the matches of a regexp Add new clause in cl-loop facility to loop over the matches for REGEXP in the current buffer (Bug#26338). * lisp/emacs-lisp/cl-macs.el (cl--parse-loop-clause): Add new clause. (cl-loop): update docstring. * doc/misc/cl.texi (For Clauses): Document the new clause. * etc/NEWS: Mention this change. diff --git a/doc/misc/cl.texi b/doc/misc/cl.texi index 2339d57631..40b90d6003 100644 --- a/doc/misc/cl.texi +++ b/doc/misc/cl.texi @@ -2030,6 +2030,22 @@ For Clauses This clause iterates over a sequence, with @var{var} a @code{setf}-able reference onto the elements; see @code{in-ref} above. +@item for @var{var} being the matches of @var{regexp} +This clause iterates over the matches for @var{regexp} in the current buffer. +By default, @var{var} is bound to the full match. Optionally, @var{var} +might be bound to a subpart of the match. +For example, + +@example +(cl-loop for x being the matches of "^(defun \\(\\S +\\)" using (group 1) + repeat 10 + collect x) +@end example + +@noindent +collects the next 10 function names after point. +This clause is an extension to standard Common Lisp. + @item for @var{var} being the symbols [of @var{obarray}] This clause iterates over symbols, either over all interned symbols or over all symbols in @var{obarray}. The loop is executed with @@ -2487,8 +2503,8 @@ Other Clauses This package's @code{cl-loop} macro is compatible with that of Common Lisp, except that a few features are not implemented: @code{loop-finish} and data-type specifiers. Naturally, the @code{for} clauses that -iterate over keymaps, overlays, intervals, frames, windows, and -buffers are Emacs-specific extensions. +iterate over keymaps, overlays, intervals, frames, windows, buffers, and +matches for a regexp in the current buffer are Emacs-specific extensions. @node Multiple Values @section Multiple Values diff --git a/etc/NEWS b/etc/NEWS index e351abc159..b8298bf180 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -862,6 +862,10 @@ instead of its first. * Lisp Changes in Emacs 26.1 +++ +** New clause in cl-loop to iterate in the matches for a regexp +in the current buffer. + ++++ ** Emacs now supports records for user-defined types, via the new functions 'make-record', 'record', and 'recordp'. Records are now used internally to represent cl-defstruct and defclass instances, for diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el index ecb89fd51d..4710efd0a9 100644 --- a/lisp/emacs-lisp/cl-macs.el +++ b/lisp/emacs-lisp/cl-macs.el @@ -892,6 +892,7 @@ cl-loop the overlays/intervals [of BUFFER] [from POS1] [to POS2] the frames/buffers the windows [of FRAME] + the matches of/for REGEXP [using (group GROUP)] Iteration clauses: repeat INTEGER while/until/always/never/thereis CONDITION @@ -1339,6 +1340,24 @@ cl--parse-loop-clause (push (list temp-idx `(1+ ,temp-idx)) loop-for-steps))) + ((memq word '(match matches)) + (let* ((_ (or (and (not (memq (car cl--loop-args) '(of for))) + (error "Expected `of'")))) + (regexp `(if (stringp ,(cadr cl--loop-args)) + ,(cl--pop2 cl--loop-args) + (error "Regexp must be an string"))) + (group + (if (eq (car cl--loop-args) 'using) + (if (and (= (length (cadr cl--loop-args)) 2) + (eq (cl-caadr cl--loop-args) 'group)) + (cadr (cl--pop2 cl--loop-args)) + (error "Bad `using' clause")) + 0))) + (push (list var nil) loop-for-bindings) + (push `(re-search-forward ,regexp nil t) cl--loop-body) + (push (list var `(match-string-no-properties ,group)) + loop-for-sets))) + ((memq word hash-types) (or (memq (car cl--loop-args) '(in of)) (error "Expected `of'")) --8<-----------------------------cut here---------------end--------------->8--- In GNU Emacs 26.0.50 (build 14, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2017-04-08 Repository revision: 4fbfd7ad53810153371a588a9bd1a69230f60dd5 From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 10:41:48 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 14:41:48 +0000 Received: from localhost ([127.0.0.1]:38231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwrYh-0002CU-Ug for submit@debbugs.gnu.org; Sat, 08 Apr 2017 10:41:48 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwrYg-0002CJ-K9 for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 10:41:47 -0400 Received: by mail-wm0-f41.google.com with SMTP id o81so10523151wmb.1 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 07:41:46 -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=STWFLhf85kgvJgxUJ11w8seBKJHO0fvp+W1RYRafkio=; b=quYP+9naSPojdSul5y1SaTXjI4xvG1jtpDQXoU76p9Q10A4LF1FthdWax8e1FKElkF GnU4NlcADhUIW3Y5VCp/x5YHVv20o8t+ZKeMze6sIyB1BI8wDNk9psyP/qZhVvoA2h/J j0A33lzFeu8MLiFneGUktzJ0L/dy5LzSAF/C1r1NgaicH/YkYr3spZtd9W7iPbb2II5L DgaVOJq8A4yi083cjq5QA9WrcXptwmpjOvvh8Naaqwihhkb8oBUKKk+4fh2CrZk0UNP9 /fCmgwpqD4LZ5WSegxNc71yoiCZE30CnkPbKZ4LS4QsL7oQpGdjIr2oQxIjvwifYDWJW cQiA== 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=STWFLhf85kgvJgxUJ11w8seBKJHO0fvp+W1RYRafkio=; b=ufE2WHfYtfjEaD+I16Mwp4q/mVYTxC4jnZMFefOX/9PGhJSmXg0l8Ct3uIDaAgX2fk mkaFV5KsLM4UlsA5G//o0XqR2AzwTNr01ehEzQwCQAFJGrF9E4eyaZ9+MKS6jOkoWEnd JDYPr+4lRYkrs5vZME1t4RipvI+3dU/7a6RKNo79Q8sf/AIsTpldvV/1QdmajGRZ0/o8 u2bwkryFXFXVAeHYCKAb80ZaNykM3VDqoZDim58DjKr42tDg5OHJL6hs3M73bUlgkVUW Y/V85MA/IAm9WEggaPWz2kamh3FQvcgalzmGs3y6zVaUwM/yXL+xsnX52/NLUrwjnY/v jTEg== X-Gm-Message-State: AN3rC/5ilmgIqxxtncYX65YrCnGNNsM0bBe3R5K/DFVE6Fz1AvvuQxJC A5J+MYk7G5j+l6lKnZ1QMvZq1rVaeQ== X-Received: by 10.28.73.197 with SMTP id w188mr3673043wma.46.1491662500943; Sat, 08 Apr 2017 07:41:40 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Philipp Stephani Date: Sat, 08 Apr 2017 14:41:29 +0000 Message-ID: Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: Tino Calancha Content-Type: multipart/alternative; boundary=001a114b30ec7e5e13054ca8bd19 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Drew Adams , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a114b30ec7e5e13054ca8bd19 Content-Type: text/plain; charset=UTF-8 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. > > 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. > > Your point is about performance. No, I care mostly about clarity, simplicity, and good API design, including 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)) --001a114b30ec7e5e13054ca8bd19 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 15:42=C2=A0Uhr:


On Sat, 8 Apr 2017, Philipp Stephani wrote:

>
>
> Tino Calancha <tino.calancha@gmail.com> schrieb am Sa.= , 8. Apr. 2017 um 06:46=C2=A0Uhr:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Fri, 7 Apr 2017, Drew Adams wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Or an addition to cl-loop that = would allow doing something like
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 (cl-loop for m bei= ng the matches of "foo\\|bar"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0do ...)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Then you could easily 'coll= ect m' to get the list of matches if you want
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>> that.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>> Your proposals looks nice to me ;-)=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (Caveat: I have not been following this= thread.)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> I think that `cl-loop' should be as= close to Common Lisp `loop'
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> as we can reasonably make it.=C2=A0 We = should _not_ be adding other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> features to it or changing its behavior= away from what it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> supposedly emulating.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If you want, create a _different_ macro= that is Emacs-specific,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> with whatever behavior you want.=C2=A0 = Call it whatever you want
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> that will not be confused with Common L= isp emulation.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Please keep `cl-' for Common Lisp e= mulation.=C2=A0 We've already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> seen more than enough tampering with th= is - people adding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> their favorite thing to the `cl-' n= amespace.=C2=A0 Not good.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Drew, i respect your opinion; but so far the= change
>=C2=A0 =C2=A0 =C2=A0 =C2=A0would just extend `cl-loop' which as you= noticed has being already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extended before.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For instance, we have:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cl-loop for x being the overlays/buffers ...=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Don't see a problem to have those things= .=C2=A0
>
>
> I do. They couple the idea of an iterable with a looping construct, an= d 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-d= efun). 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 remo= ved for compatibility reasons, so I'm not arguing about it. I'm arg= uing against adding more such one-off forms.
=C2=A0

but it seems you are fine having iter-by clause in cl-loop, which seems an<= br class=3D"gmail_msg"> Emacs extension (correctme if i am wrong).=C2=A0 So in principle, you are h= appy
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 t= han 'buffers' etc. because it's not a one-off that couples a lo= oping construct with some random semantics.
=C2=A0

Your point is about performance.

No, I care= mostly about clarity, simplicity, and good API design, including separatio= n of concerns.
=C2=A0
=C2=A0 = 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:
=C2=A0(require 'generator)
(iter-defun re-matches (regexp)
=C2=A0 (while (re-search-forward regexp nil t)
=C2=A0 = =C2=A0 (iter-yield (match-string 0))))
(iter-do (m (re-matches (r= x digit)))
=C2=A0 (print m))
(cl-loop for m iter-by (re= -matches (rx digit))
do (print m))

--001a114b30ec7e5e13054ca8bd19-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 11:20:34 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:20:34 +0000 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 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 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) 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) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Sun, 9 Apr 2017 00:20:22 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Philipp Stephani Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-870149736-1491664826=:20978" X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 26338 Cc: Marcin Borkowski , npostavs@users.sourceforge.net, 26338@debbugs.gnu.org, Tino Calancha , Juri Linkov , Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 11:29:48 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:29:48 +0000 Received: from localhost ([127.0.0.1]:38272 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsJA-0003QO-DG for submit@debbugs.gnu.org; Sat, 08 Apr 2017 11:29:48 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:33439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsJ8-0003Q7-JK for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 11:29:46 -0400 Received: by mail-pg0-f42.google.com with SMTP id x125so86198820pgb.0 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 08:29:46 -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=KzjI8OnVn6g8uwkja8dc4y4RfijwmHIlx7lGNzlUggk=; b=b7y6lt8DaaIe+RRGxkxzv9bGIz+tqxIDXNmUxD+0go8sAhmw0Ee4CBC1kZx7GCbgGA bU5lJUOcf/QH3ePrFmqM7KcSnIpMtF2RZuFmaEJiQVjC3MV+2+DtE7dnjEgNtWlBuVdh vLE5gCBmxEGCC0oWj5LKpQwyo6UPFutUCmkFrN/3XbkBvTwsMbbPMKe1C4sCBMIzK/hN UeUH/9hUWtAUtmk3GvlmtkbW313PEtywDFvDN5iqfW4jCNH8d2vwjMAZUVcFyoOf9+sI djFGyOgOTFXwvRLv+W7RJVhhNon9cR0awF09VKLtSrqz+jq4xkJCiRK/WiAy1cBuKpQk UgIQ== 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=KzjI8OnVn6g8uwkja8dc4y4RfijwmHIlx7lGNzlUggk=; b=gdB+iS2KrA9FT+CymfaQ0qVQBXb+t3hRP4FzyGKkOKLqoHe5wPNvrLKYaU2dP4v4rg oWA90a0sj5suWEb2o/WFQVLjcpCVVgH4O72SZW25U8/JthGA61z7eioFb1/WfMm+ITRD Wh/1rh4Z191z41/crCamc02zraCNROVkScp8oPmhuOyARf+onQc6ykZ3DqCrW23F2pay ftG4JputUf5UL2bnk3Gjd5XeSxVBxCy1xMcT12hC+o/sbisPQr0BIMjL6QzGzbeskMDY ToTqGEjFTKvowL8ztYIRkuZBASvOyhDxCTLKvdjT7+gyMU3zsBORwKFmxiGTV4Sz1zSn YRjg== X-Gm-Message-State: AFeK/H3ZjR+7IcpuSnHVQVdIWkuphn84eNGfBHnenFM3ELHBbQAw6viMIx/PgkipPB3Q6A== X-Received: by 10.99.97.77 with SMTP id v74mr47199127pgb.76.1491665380742; Sat, 08 Apr 2017 08:29:40 -0700 (PDT) Received: from calancha-pc (222.139.137.133.dy.bbexcite.jp. [133.137.139.222]) by smtp.gmail.com with ESMTPSA id v86sm15669439pfa.86.2017.04.08.08.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 08:29:40 -0700 (PDT) From: Tino Calancha X-Google-Original-From: Tino Calancha Date: Sun, 9 Apr 2017 00:29:35 +0900 (JST) X-X-Sender: calancha@calancha-pc To: Drew Adams Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer In-Reply-To: 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , npostavs@users.sourceforge.net, Marcin Borkowski , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) On Fri, 7 Apr 2017, Drew Adams wrote: > 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. 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 11:37:12 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:37:12 +0000 Received: from localhost ([127.0.0.1]:38279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsQK-0003ct-5K for submit@debbugs.gnu.org; Sat, 08 Apr 2017 11:37:12 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:33467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwsQH-0003cc-Jt for 26338@debbugs.gnu.org; Sat, 08 Apr 2017 11:37:10 -0400 Received: by mail-io0-f194.google.com with SMTP id b140so5121703iof.0 for <26338@debbugs.gnu.org>; Sat, 08 Apr 2017 08:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=mtEkjZkpYaMcY07hu6RS/Yaaz0S6j93/CtsST9oM5Ik=; b=dDQCVfPWOFxSaVYrg8dIGa0mwcxxzBUiTiMP0LmJSDG16ibthFKl6NR60wT3sfL5Ed iOGwKEQ0mfG8Cg35lUmm4rhbjmwGH9MU6r61HjVyB5R2gDpsCV7vj0DPC3Zf2OaODBAI c7XEE5FBMWls7VNrxUwsXT8Ewg7J3CKsWyDuLQN3hHlcNFLssbNUMUMQNQhtOJSUVvMf sWbS08BoILSeXqeqyGhQMNCGZ/jzkXBHhh++sOBK4AEJ5EAWnBq/YW3QkHHBQ5oo2DxH aq5ppr9r7yAYKHqD67SlgNJuTcm5gI6ae+R6Z8rIif8/xsP+M7nm9guf9gTTg+4BkjbY g2mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=mtEkjZkpYaMcY07hu6RS/Yaaz0S6j93/CtsST9oM5Ik=; b=gSG6zpvUPuBotEQKmez/Vbe4l8FeQMjkmLpzIqFjgN7FzajIW1f/hHeVgEJ1Va0j6z Z9DPiik+mt6ISrN/UrLsT7pCKEVVKlsBgi8nxKhtj9BiaXITgZDGNdpDV7ifZTnmj5BD OOaRpKEXx9UgGmBaeQQUqT+1wGrunf2quBpcbLk0sE14/f61YzBQZIGOaAIcm0/XwHDe a+qpH1YbynJS7P2NW5vmWljNqNzrL3vPE87zjxWwqOsu0PIoVSmcoBlZDFzHKDVDRcKv xJHfiF3Hl4ijhntZDm5BcBtKsBNP41tQGXpXHUBiFJ40+86eEy4CsQmFfLdF5Fzt/qo8 42kg== X-Gm-Message-State: AN3rC/4mJQdVrOPyX3S8NzgWshFjvV0xfc64P0T3CznhbWNEjHHK8pe6xH1yLhzx/nQC8g== X-Received: by 10.107.188.194 with SMTP id m185mr9285776iof.137.1491665824037; Sat, 08 Apr 2017 08:37:04 -0700 (PDT) Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id e124sm1078933itb.24.2017.04.08.08.37.02 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 08 Apr 2017 08:37:03 -0700 (PDT) From: npostavs@users.sourceforge.net To: Philipp Stephani Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer 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> Date: Sat, 08 Apr 2017 11:38:28 -0400 In-Reply-To: (Philipp Stephani's message of "Sat, 08 Apr 2017 14:41:29 +0000") Message-ID: <87vaqeucy3.fsf@users.sourceforge.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Drew Adams , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) Philipp Stephani writes: >>> - Coupling of unrelated entities is always an antipattern. >>> - For N iterables and M looping constructs, you need to implement >>> N*M integrations. > > 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. It's sort of related to Drew's concerns in that Emacs deals with the N*M problem by setting M=1, hence why only cl-loop gets the pressure to add more enhancments. There are some practical problem with iter-defun though: it has several bugs on which there doesn't seem to be any movement[1][2][3], it's reported to be slow[4], and cl-loop's iter-by keyword is not documented at all (that could be easily fixed, at least). I wonder if streams[5] is a better direction. It already has stream-regexp, though it returns match-data rather than a matched string. (package-install 'stream) (require 'stream) (require 'seq) (seq-do (lambda (m) (set-match-data m) (print (match-string 0))) (stream-regexp (current-buffer) (rx digit))) (cl-loop with matches = (stream-regexp (current-buffer) (rx digit)) for m = (stream-pop matches) while m do (set-match-data m) (print (match-string 0))) [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26073 [2]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25965 [3]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26068 [4]: http://lists.gnu.org/archive/html/emacs-devel/2017-03/msg00264.html [5]: https://elpa.gnu.org/packages/stream.html From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 08 11:42:45 2017 Received: (at 26338) by debbugs.gnu.org; 8 Apr 2017 15:42:45 +0000 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 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 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 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 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 MIME-Version: 1.0 Message-ID: <7bb265fb-daa0-4308-a5ac-76952fecfecf@default> Date: Sat, 8 Apr 2017 08:42:32 -0700 (PDT) From: Drew Adams To: Tino Calancha Subject: RE: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer 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> 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)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-Spam-Score: -4.6 (----) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.6 (----) > > 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? From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 22 15:37:16 2017 Received: (at 26338) by debbugs.gnu.org; 22 Apr 2017 19:37:16 +0000 Received: from localhost ([127.0.0.1]:34726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d20qK-0000u0-2U for submit@debbugs.gnu.org; Sat, 22 Apr 2017 15:37:16 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:38098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d20qH-0000tm-Pp for 26338@debbugs.gnu.org; Sat, 22 Apr 2017 15:37:14 -0400 Received: by mail-wm0-f43.google.com with SMTP id r190so39660490wme.1 for <26338@debbugs.gnu.org>; Sat, 22 Apr 2017 12:37:13 -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=kkG5l7imqy9XZa5JKgvWo1voBEC7ZGFkboJJAHtGkqg=; b=m3Ex4fuqVPxLEvBSJ2rHjixXFm8kp0+eCU0m4VrwOpA/31qUjOXr1KLJ89D7jTRNt1 rvlKi+OQrdnqGR3tpBsLzMNvD94hIXqDcW84FmTUYxOqHG62N010cY1YuQZXFMlgKFTz 4mL3hKB5/B6J+KxlKzNvPwoyTjjCmVMqeN6SFjtLvuPaGQbD7XqGzqhNRhq4wft2vCyI aS5/d5ARyxpBmY3jbSTZHRLsrHd75gHstgOvK6I4FCMxHKh72s1SFR+oII0sIKsDojTV HN3cjuXCnoMhVq9RRnELL62eWCJzicFQteici1FNfK1M64NSQHWKFyEzIOgSGRtL8HpL FhEA== 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=kkG5l7imqy9XZa5JKgvWo1voBEC7ZGFkboJJAHtGkqg=; b=po0/PYMn25anKkq0mxstgN2ScZFTQtfjxJJTU7Cc5dUXpZNb3c2dKRXupH8rE9Z+yQ xJkYI+GPoxMeozpTrGISI2GA0KN3E7qPCFxQKZHYKwoz3yora6mgcvG5Xj8j6IDn4jER ZTk6RfPB4HZxf1wZ69NU5+2SzqVxWqaEkyP81v82FRIvGTt83oS0aapdzw9u3e1LBpz8 XLzJxaX3IbuxWNHFi0lLDk5lYsdq8AtbIKivbfw41PHIhuY+acF3fwqBMo3azOkFoxBO IorzZvoCou6LfHpRqnoQi+6Tk9Bc+dFrHdvL83q+XLO1wy+iIZrcqaLjow1XUuazHdFG WQjA== X-Gm-Message-State: AN3rC/6KBGE7ZQy3rUL2vBh5ToRiGz1h5yFkSalFHpNPt55hplKuEVDU cnajeKJ56Iq9zKEVZuxho0NiOZjTQg== X-Received: by 10.28.156.13 with SMTP id f13mr3818357wme.44.1492889828121; Sat, 22 Apr 2017 12:37:08 -0700 (PDT) MIME-Version: 1.0 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> <87vaqeucy3.fsf@users.sourceforge.net> In-Reply-To: <87vaqeucy3.fsf@users.sourceforge.net> From: Philipp Stephani Date: Sat, 22 Apr 2017 19:36:57 +0000 Message-ID: Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: npostavs@users.sourceforge.net Content-Type: multipart/alternative; boundary=001a114b391ae4e268054dc67fb9 X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Drew Adams , Tino Calancha X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a114b391ae4e268054dc67fb9 Content-Type: text/plain; charset=UTF-8 schrieb am Sa., 8. Apr. 2017 um 17:37 Uhr: > Philipp Stephani writes: > > >>> - Coupling of unrelated entities is always an antipattern. > >>> - For N iterables and M looping constructs, you need to implement > >>> N*M integrations. > > > > 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. > > It's sort of related to Drew's concerns in that Emacs deals with the N*M > problem by setting M=1, hence why only cl-loop gets the pressure to add > more enhancments. > > There are some practical problem with iter-defun though: it has several > bugs on which there doesn't seem to be any movement[1][2][3], That's unfortunate, because it's a really well-designed library. Stefan has apparently resumed work on these issues (e.g commit 89898e43c7ceef28bb3c2116b4d8a3ec96d9c8da), so let's hope they will be fixed eventually. > it's > reported to be slow[4], and cl-loop's iter-by keyword is not documented > at all (that could be easily fixed, at least). I wonder if streams[5] > is a better direction. > Maybe, though I'd be hesitant to add yet another library for the same thing to Emacs, and I much prefer generator.el's interface. --001a114b391ae4e268054dc67fb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


<npostavs@users.sourceforge.= net> schrieb am Sa., 8. Apr. 2017 um 17:37=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> writes:

>>> - Coupling of unrelated entities is always an antipattern.
>>> - For N iterables and M looping constructs, you need to implem= ent
>>> N*M integrations.
>
> 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 tha= t couples a
> looping construct with some random semantics.

It's sort of related to Drew's concerns in that Emacs deals with th= e N*M
problem by setting M=3D1, hence why only cl-loop gets the pressure to add more enhancments.

There are some practical problem with iter-defun though: it has several
bugs on which there doesn't seem to be any movement[1][2][3],

That's unfortunate, because it's a really w= ell-designed library. Stefan has apparently resumed work on these issues (e= .g commit 89898e43c7ceef28bb3c2116b4d8a3ec96d9c8da), so let's hope they= will be fixed eventually.
=C2=A0
it's
reported to be slow[4], and cl-loop's iter-by keyword is not documented=
at all (that could be easily fixed, at least).=C2=A0 I wonder if streams[5]=
is a better direction.=C2=A0

Maybe, tho= ugh I'd be hesitant to add yet another library for the same thing to Em= acs, and I much prefer generator.el's interface.
--001a114b391ae4e268054dc67fb9-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 22 15:42:34 2017 Received: (at 26338) by debbugs.gnu.org; 22 Apr 2017 19:42:34 +0000 Received: from localhost ([127.0.0.1]:34731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d20vR-00011D-Mw for submit@debbugs.gnu.org; Sat, 22 Apr 2017 15:42:33 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:34968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d20vQ-000111-29 for 26338@debbugs.gnu.org; Sat, 22 Apr 2017 15:42:32 -0400 Received: by mail-wm0-f48.google.com with SMTP id w64so36733439wma.0 for <26338@debbugs.gnu.org>; Sat, 22 Apr 2017 12:42:31 -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=kdp9SjjLn9mOz23MU6oVnhQt5Y6t82oWrcQFc/ytYEQ=; b=cUO743oxI/wB4B9ogDfZM2lztt3ED3zqkuvoqSssJaREVbZszXYCKoDO3aONW4p8JG ERb7JUb+AX4T++PyCIfOtrrxNI1++5YAOQO6NsUWqsJv+9bFXsUNEbTIL7FfP6ghS8jo gy6SI9XItbFWnqZlqF9+Y7ourTf/ZbtPtZ7xPFSULouCqhKMw/ryQPek26HkvL6A+Qp9 8sRISuNDrWp9WsdBfrzTAvsFaKZJjrWPQeXosFhIJ4NW6wX5RAEz+10537isHU2UQReV QDCzY5MWsLikUm0Q7MHrovp4zykL9pXRKGrFfklLlN58E7gYH+F1LaI7nbQ0SLuZwueE 9nHQ== 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=kdp9SjjLn9mOz23MU6oVnhQt5Y6t82oWrcQFc/ytYEQ=; b=DcKEzQc5MFGwCmsTL6EOUxDCG9XYkgRzyEA3tjOPcElnlrJbnp377bXppA70tdMgq2 9QTqWuFVtfTRqZUwKEY+Ai/Y4od4PUreW//BaSsz8aS4evTP5yW2GFKBtC1Ew0rpnxmq SjE5J4bVp9sUgxlBgmFMxL7mbnuH/qXmgUWUChiFIg6JUs5yX6Nr4DzPIXnU+2fStNEw pVCQxoBEi7cwXKzViVKcOThcnR2WhQy2z0AE+uwBmpkv1oTR1lHehiPHBVFjcGrzL2rO EhCZc7WcgkdRhEwVjWuusLyMGqB58wrWuA6N7V5JpTCUrJJliSjFAHFwx5513UJCXt0f KkMQ== X-Gm-Message-State: AN3rC/5PggZZ2SrY2rb642oS1f+/WxQXiR2BPKmtufGN6HtzhA2n6c/X 9DQWCFFkny4DmqaVdXc42bQnaa1yPA== X-Received: by 10.28.161.66 with SMTP id k63mr3937389wme.46.1492890146390; Sat, 22 Apr 2017 12:42:26 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Philipp Stephani Date: Sat, 22 Apr 2017 19:42:15 +0000 Message-ID: Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer To: Tino Calancha Content-Type: multipart/alternative; boundary=001a114cb0dcdd4cf6054dc6925c X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, Juri Linkov , Marcin Borkowski , Drew Adams , npostavs@users.sourceforge.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --001a114cb0dcdd4cf6054dc6925c Content-Type: text/plain; charset=UTF-8 Tino Calancha schrieb am Sa., 8. Apr. 2017 um 17:20 Uhr: > > > > > 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. > Yes, but it seems we mean different things with these words. "Readability" for me means (among other things) that each logical entity has a single purpose. The single purpose of the (already way too complex) cl-loop macro is iterating over things. It doesn't concern itself with the things it should iterate over and where they come from. > 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. > I disagree. (A) clearly separates the generation of the stream of objects to iterate over from the iteration, (B) doesn't. (A) is extensible to any kind of iteration as long as it can be expressed using generators (or lists, vectors, ...), while for (B) you need a new keyword for every new thing to iterate over. > > 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) --001a114cb0dcdd4cf6054dc6925c 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 17:20=C2=A0Uhr:

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Your point is about performance.
>
>
> No, I care mostly about clarity, simplicity, and good API design, incl= uding separation of concerns.
Expressibity and readability might be some kind of clarity.

Yes, but it seems we mean different things with these = words. "Readability" for me means (among other things) that each = logical entity has a single purpose. The single purpose of the (already way= too complex) cl-loop macro is iterating over things. It doesn't concer= n itself with the things it should iterate over and where they come from.
=C2=A0
I totally agree about API design and separation of concerns.
> =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 I am driven by easy to write code. >=C2=A0 =C2=A0 =C2=A0 =C2=A0Maybe you can provide an example about how t= o write those things using
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the iter-by cl-loop clause.
>
>
> Sure:
> =C2=A0(require 'generator)
> (iter-defun re-matches (regexp)
> =C2=A0 (while (re-search-forward regexp nil t)
> =C2=A0 =C2=A0 (iter-yield (match-string 0))))
> (iter-do (m (re-matches (rx digit)))
> =C2=A0 (print m))
> (cl-loop for m iter-by (re-matches (rx digit))
> do (print m))
Thank you very much for your examples.=C2=A0 They are nice.=C2=A0 I am not<= br> as familiar as you with generators.=C2=A0 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.

<= div>I disagree. (A) clearly separates the generation of the stream of objec= ts to iterate over from the iteration, (B) doesn't. (A) is extensible t= o any kind of iteration as long as it can be expressed using generators (or= lists, vectors, ...), while for (B) you need a new keyword for every new t= hing to iterate over.
=C2=A0

A)
(iter-defun re-matches (regexp)
=C2=A0 =C2=A0(while (re-search-forward regexp nil t)
=C2=A0 =C2=A0 =C2=A0(iter-yield (match-string-no-properties 1))))

(cl-loop for m iter-by (re-matches "^(defun \\(\\S +\\)")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collect m)

B)
(cl-loop for m the matches of "^(defun \\(\\S +\\)"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collect m)
--001a114cb0dcdd4cf6054dc6925c-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 11:41:30 2020 Received: (at 26338) by debbugs.gnu.org; 15 Sep 2020 15:41:30 +0000 Received: from localhost ([127.0.0.1]:60305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kID5F-0003mY-OX for submit@debbugs.gnu.org; Tue, 15 Sep 2020 11:41:29 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kID5D-0003mI-BG for 26338@debbugs.gnu.org; Tue, 15 Sep 2020 11:41:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YaywDt9F5YEpadyv8BZWeZ/P67jgYHQQQa7K6fjZQp4=; b=eLmsEESfw+VBZjI94acWtVxv+m jP2PUTeqmcmzq/PAabEZim7fZzSpXHcihXpyP/H1n1qwRCUbrlwjEzxrd37rH5u7Go/CVKT7X3Dxh Me+RXeI2SOg9BDTDQ9DDTRu2aJJnISYfHqUbzLZgjsb95XQHixuw6pxdpWNF01KWiu10=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kID54-0001tr-0d; Tue, 15 Sep 2020 17:41:20 +0200 From: Lars Ingebrigtsen To: Tino Calancha Subject: Re: bug#26338: 26.0.50; Collect all matches for REGEXP in current buffer References: <8737dr6kxx.fsf@calancha-pc> X-Now-Playing: Saito Koji's _433-1_: "433_054" Date: Tue, 15 Sep 2020 17:41:16 +0200 In-Reply-To: <8737dr6kxx.fsf@calancha-pc> (Tino Calancha's message of "Sun, 02 Apr 2017 21:41:30 +0900") Message-ID: <87d02n6o9v.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Tino Calancha writes: > we have `count-matches' in replace.el, which returns the > number of matches of a regexp. Why not to have an standard > function `collect-matches' as well? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 26338 Cc: 26338@debbugs.gnu.org, juri linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Tino Calancha writes: > we have `count-matches' in replace.el, which returns the > number of matches of a regexp. Why not to have an standard > function `collect-matches' as well? A bunch of discussion then followed, and several patches, but it seemed like many people just thought that this didn't seem generally useful enough... and I agree. Gathering regexp matches from a buffer is a three-liner, and chopping out parts of that is easy enough with seq-take and friends, so adding separate functionality for this just doesn't seem warranted, in my opinion. So I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 15 11:41:37 2020 Received: (at control) by debbugs.gnu.org; 15 Sep 2020 15:41:37 +0000 Received: from localhost ([127.0.0.1]:60308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kID5N-0003mz-0Y for submit@debbugs.gnu.org; Tue, 15 Sep 2020 11:41:37 -0400 Received: from quimby.gnus.org ([95.216.78.240]:46750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kID5L-0003mf-MM for control@debbugs.gnu.org; Tue, 15 Sep 2020 11:41:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=stSFkUhH1pXyUWGtoBTUwyYfa2Vze2QWUsqwyJVH/mM=; b=S6dr6V8kS3xIQDfmJqJxGenMr4 cjuULjvCDM/EMC50vb2gHF/rLpXF2b+wAntPPSjLnzZyQg1UTx18PA2q0AyeOFohL6FOEKAensdbv E0SBy1hDASa7CkGMCBQqGqqgK5q9LFqQzualiOcEq9cp6I+MbV9P0tnNE+6wsjSearfs=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kID5D-0001tz-RR for control@debbugs.gnu.org; Tue, 15 Sep 2020 17:41:30 +0200 Date: Tue, 15 Sep 2020 17:41:26 +0200 Message-Id: <87bli76o9l.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #26338 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 26338 wontfix close 26338 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 26338 wontfix close 26338 quit From unknown Sat Aug 16 18:48:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 14 Oct 2020 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator