From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Oct 2018 15:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 33167@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.154056880422069 (code B ref -1); Fri, 26 Oct 2018 15:47:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Oct 2018 15:46:44 +0000 Received: from localhost ([127.0.0.1]:44259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG4Jw-0005js-0E for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG4Jt-0005jf-M5 for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG4Jn-0003Zx-1q for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:36 -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 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34204) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG4Jm-0003ZV-Pn for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:34 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG4Jj-0004ut-5N for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:46:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG46a-00053F-Dd for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:33:00 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:53586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG46a-0004fV-4b for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:32:56 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9QFSh8C167249 for ; Fri, 26 Oct 2018 15:32:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=LMoAEfHTwuFBnMuaqYdnWDNtXGRz8BMFkiYSwepIbMQ=; b=IjGk/WFEymGQxRAWMxXybOfKHoKswFX8K9TguPRJMhEZ/r4JVmMO8+NM8Mxo6v+jeXkN wi9uVXkVjQqoJO6XsuNZWJVWmZ71JfPNlwVgrwk7OcNddUdZpK9l/VjBnuJAHPz6OxrG x4h2+JTGz6fP9yFbzzlVWQThZWfISVUdujD4vGaxm7L39sv2ZO4q0Ii23fDFs48DwGQM 5kyH4OBygwwLnZKqCvz2qMPJQRM7n3RAMq4B7zae1DgPi5A3gSLHsta3NTBSegPmfjeX o6GtNaODfJWwL9jtI4+86sUSVjh2qCx/fIHCEuaMTMF/QcB/6y39y2qOUh8bFij2SHr9 wQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2n7usuqye1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 26 Oct 2018 15:32:21 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9QFWFM0023122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 26 Oct 2018 15:32:15 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9QFWFfU023703 for ; Fri, 26 Oct 2018 15:32:15 GMT MIME-Version: 1.0 Message-ID: <2e187b74-9999-4090-96b4-bb13d1f27544@default> Date: Fri, 26 Oct 2018 08:32:04 -0700 (PDT) From: Drew Adams X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9057 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810260130 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 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-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: -5.0 (-----) I don't understand these parts of the description: - nil: return the content as a string. What does that mean, for a noncontiguous region? Are the buffer substrings for all of the region segments (zones) concatenated together? If so, say that. - anything else: delete the region and return its content as a string, after filtering it with `filter-buffer-substring', which is called with METHOD as its 3rd argument. So first the region is deleted, and the deleted content (see previous) is filtered via `(filter-buffer-substring BEG END METHOD)' and then returned. Some of what I don't understand: 1. What are the BEG and END args passed to `filter-buffer-substring'? Is BEG the smallest car of any of the zones in the noncontiguous region, and END the largest cdr of any of the zones? 2. `filter-buffer-substring' calls the value of `filter-buffer-substring-function' with the same 3 args. But what can that function do with BEG and END (which are what?)? It's presumably a function that expects to use a single stretch of buffer text from BEG to END. But here we're talking about a noncontiguous=20 3. The 3rd arg to `filter-buffer-substring' just deletes the region from BEG to END if it is non-nil, so it seems like passing that non-nil 3rd arg is useless, as the region gets deleted anyway, by `region-extract-function'. 4. The use of `filter-buffer-substring' is also unclear. It is passed BEG and END (and METHOD, but see #3, above). And it filters the buffer text between BEG and END. But see #1 above - are BEG and END buffer positions that make sense for the whole region text? Just what happens here? This is quite unclear to me. And following the rabbit hole from `region-extract-function' down to `filter-buffer-substring' and then to `filter-buffer-substring-function' does not make things more clear. Or is what happens perhaps that EACH element of the noncontiguous region, that is, each zone (BEG . END) of the list ((BEG1 . END1) ...) gets filtered by `filter-buffer-substring', passing its BEG END and EMTHOD - so that a mapcar is applied? In that case, how are the resulting buffer substrings assembled - are they concatenated to get the return value? In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.16299 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' From unknown Tue Jun 17 01:50:36 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Drew Adams Subject: bug#33167: closed (Re: bug#33167: 26; Doc string of `region-extract-function') Message-ID: References: <831s8bocu3.fsf@gnu.org> <2e187b74-9999-4090-96b4-bb13d1f27544@default> X-Gnu-PR-Message: they-closed 33167 X-Gnu-PR-Package: emacs Reply-To: 33167@debbugs.gnu.org Date: Sat, 27 Oct 2018 11:21:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1540639262-23888-1" This is a multi-part message in MIME format... ------------=_1540639262-23888-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #33167: 26; Doc string of `region-extract-function' which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 33167@debbugs.gnu.org. --=20 33167: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D33167 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1540639262-23888-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 33167-done) by debbugs.gnu.org; 27 Oct 2018 11:20:46 +0000 Received: from localhost ([127.0.0.1]:44655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGMe5-0006CW-IC for submit@debbugs.gnu.org; Sat, 27 Oct 2018 07:20:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGMe3-0006CJ-Pq for 33167-done@debbugs.gnu.org; Sat, 27 Oct 2018 07:20:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGMdt-000842-75 for 33167-done@debbugs.gnu.org; Sat, 27 Oct 2018 07:20:38 -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.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54702) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGMdt-00083w-35; Sat, 27 Oct 2018 07:20:33 -0400 Received: from [176.228.60.248] (port=1311 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gGMds-0001mL-Lu; Sat, 27 Oct 2018 07:20:33 -0400 Date: Sat, 27 Oct 2018 14:20:36 +0300 Message-Id: <831s8bocu3.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <2e187b74-9999-4090-96b4-bb13d1f27544@default> (message from Drew Adams on Fri, 26 Oct 2018 08:32:04 -0700 (PDT)) Subject: Re: bug#33167: 26; Doc string of `region-extract-function' References: <2e187b74-9999-4090-96b4-bb13d1f27544@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 33167-done Cc: 33167-done@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: -6.0 (------) > Date: Fri, 26 Oct 2018 08:32:04 -0700 (PDT) > From: Drew Adams > > - nil: return the content as a string. > > What does that mean, for a noncontiguous region? Are the buffer > substrings for all of the region segments (zones) concatenated together? > If so, say that. No, the value is a list of strings in this case. I fixed the doc string to say that. > 1. What are the BEG and END args passed to `filter-buffer-substring'? > Is BEG the smallest car of any of the zones in the noncontiguous > region, and END the largest cdr of any of the zones? They are the first and the last positions of the region for filter-buffer-substring to act upon. That function is not supposed to process non-contiguous regions. > 2. `filter-buffer-substring' calls the value of > `filter-buffer-substring-function' with the same 3 args. But what > can that function do with BEG and END (which are what?)? It's > presumably a function that expects to use a single stretch of buffer > text from BEG to END. But here we're talking about a noncontiguous No, we are talking about contiguous regions when this function is concerned. > 3. The 3rd arg to `filter-buffer-substring' just deletes the region from > BEG to END if it is non-nil, so it seems like passing that non-nil > 3rd arg is useless, as the region gets deleted anyway, by > `region-extract-function'. Not sure what is the problem here. > 4. The use of `filter-buffer-substring' is also unclear. It is passed > BEG and END (and METHOD, but see #3, above). And it filters the > buffer text between BEG and END. But see #1 above - are BEG and END > buffer positions that make sense for the whole region text? Just > what happens here? See above. It is not the job of filter-buffer-substring to DTRT when the region is non-contiguous, it is the job of its callers. See rect.el for one example. > This is quite unclear to me. And following the rabbit hole from > `region-extract-function' down to `filter-buffer-substring' and then to > `filter-buffer-substring-function' does not make things more clear. It isn't supposed to. If you want to see how non-contiguous regions are used in this context, you need to look in places that do so. > Or is what happens perhaps that EACH element of the noncontiguous > region, that is, each zone (BEG . END) of the list ((BEG1 . END1) > ...) gets filtered by `filter-buffer-substring', passing its BEG END and > METHOD Yes! > - so that a mapcar is applied? Not literally, but the result is a list, yes. > In that case, how are the resulting buffer substrings assembled - > are they concatenated to get the return value? No, you get a list. Again, see rect.el. Bottom line: I fixed the doc string of region-extract-function to say what are the values when the region is non-contiguous, and how filter-buffer-substring is invoked in that case. But I don't think there's anything else that should be done here, because the details of using this facility for non-contiguous regions is entirely up to the Lisp program which implements such a feature. Thanks. ------------=_1540639262-23888-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 26 Oct 2018 15:46:44 +0000 Received: from localhost ([127.0.0.1]:44259 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG4Jw-0005js-0E for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:44 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gG4Jt-0005jf-M5 for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG4Jn-0003Zx-1q for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:36 -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 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34204) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG4Jm-0003ZV-Pn for submit@debbugs.gnu.org; Fri, 26 Oct 2018 11:46:34 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG4Jj-0004ut-5N for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:46:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG46a-00053F-Dd for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:33:00 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:53586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG46a-0004fV-4b for bug-gnu-emacs@gnu.org; Fri, 26 Oct 2018 11:32:56 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9QFSh8C167249 for ; Fri, 26 Oct 2018 15:32:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=LMoAEfHTwuFBnMuaqYdnWDNtXGRz8BMFkiYSwepIbMQ=; b=IjGk/WFEymGQxRAWMxXybOfKHoKswFX8K9TguPRJMhEZ/r4JVmMO8+NM8Mxo6v+jeXkN wi9uVXkVjQqoJO6XsuNZWJVWmZ71JfPNlwVgrwk7OcNddUdZpK9l/VjBnuJAHPz6OxrG x4h2+JTGz6fP9yFbzzlVWQThZWfISVUdujD4vGaxm7L39sv2ZO4q0Ii23fDFs48DwGQM 5kyH4OBygwwLnZKqCvz2qMPJQRM7n3RAMq4B7zae1DgPi5A3gSLHsta3NTBSegPmfjeX o6GtNaODfJWwL9jtI4+86sUSVjh2qCx/fIHCEuaMTMF/QcB/6y39y2qOUh8bFij2SHr9 wQ== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2n7usuqye1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 26 Oct 2018 15:32:21 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9QFWFM0023122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 26 Oct 2018 15:32:15 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9QFWFfU023703 for ; Fri, 26 Oct 2018 15:32:15 GMT MIME-Version: 1.0 Message-ID: <2e187b74-9999-4090-96b4-bb13d1f27544@default> Date: Fri, 26 Oct 2018 08:32:04 -0700 (PDT) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 26; Doc string of `region-extract-function' X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9057 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810260130 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 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: -5.0 (-----) I don't understand these parts of the description: - nil: return the content as a string. What does that mean, for a noncontiguous region? Are the buffer substrings for all of the region segments (zones) concatenated together? If so, say that. - anything else: delete the region and return its content as a string, after filtering it with `filter-buffer-substring', which is called with METHOD as its 3rd argument. So first the region is deleted, and the deleted content (see previous) is filtered via `(filter-buffer-substring BEG END METHOD)' and then returned. Some of what I don't understand: 1. What are the BEG and END args passed to `filter-buffer-substring'? Is BEG the smallest car of any of the zones in the noncontiguous region, and END the largest cdr of any of the zones? 2. `filter-buffer-substring' calls the value of `filter-buffer-substring-function' with the same 3 args. But what can that function do with BEG and END (which are what?)? It's presumably a function that expects to use a single stretch of buffer text from BEG to END. But here we're talking about a noncontiguous=20 3. The 3rd arg to `filter-buffer-substring' just deletes the region from BEG to END if it is non-nil, so it seems like passing that non-nil 3rd arg is useless, as the region gets deleted anyway, by `region-extract-function'. 4. The use of `filter-buffer-substring' is also unclear. It is passed BEG and END (and METHOD, but see #3, above). And it filters the buffer text between BEG and END. But see #1 above - are BEG and END buffer positions that make sense for the whole region text? Just what happens here? This is quite unclear to me. And following the rabbit hole from `region-extract-function' down to `filter-buffer-substring' and then to `filter-buffer-substring-function' does not make things more clear. Or is what happens perhaps that EACH element of the noncontiguous region, that is, each zone (BEG . END) of the list ((BEG1 . END1) ...) gets filtered by `filter-buffer-substring', passing its BEG END and EMTHOD - so that a mapcar is applied? In that case, how are the resulting buffer substrings assembled - are they concatenated to get the return value? In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) of 2018-05-30 Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea Windowing system distributor `Microsoft Corp.', version 10.0.16299 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' ------------=_1540639262-23888-1-- From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 15:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Drew Adams Cc: 33167-done@debbugs.gnu.org Received: via spool by 33167-done@debbugs.gnu.org id=D33167.154065407314403 (code D ref 33167); Sat, 27 Oct 2018 15:28:01 +0000 Received: (at 33167-done) by debbugs.gnu.org; 27 Oct 2018 15:27:53 +0000 Received: from localhost ([127.0.0.1]:45633 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGQVE-0003kE-KU for submit@debbugs.gnu.org; Sat, 27 Oct 2018 11:27:52 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:35522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGQVC-0003k1-5k for 33167-done@debbugs.gnu.org; Sat, 27 Oct 2018 11:27:50 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9RFJQ1F107076; Sat, 27 Oct 2018 15:27:44 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Is8WoQbYpY1X2e8V4J2onGY1ynOzvIrm56VsCgKi1zY=; b=jurnKL8AiE4QRAgCeNh8+DlIEGwkYwmeSX0nD05J5IWjMd/7hLya0BQdR3PIATlqv7/+ FM1muoRuDX71ibhKJX2Mi8qkF8GjYzLJWqEjVKdRghSzVC+LpbAzQcuQSZ8H4kj1OGKa c1tNT7yn1Gr+dcUUdR2/OHSS9Yo06ljTyZ10Xzozw/MiS+UgPA/MJh7cMK5DCF3tMiYI XacU085f4c4sU3CEHdYQRTP/SZAAhCRl62b/dmDzlpwNiRPx7w1iA3yveIleF1gUiQTL H44b8cNtnxGgmQKv0plt9xZfgM/jnzoaM3QRdgVXRkh65DcqmG8keXFE8Xi9ZwogVkYq vA== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2ncfet8ytp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 15:27:43 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w9RFRg7e018833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 15:27:43 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9RFRfq6021526; Sat, 27 Oct 2018 15:27:42 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 27 Oct 2018 08:27:41 -0700 (PDT) From: Drew Adams References: <<2e187b74-9999-4090-96b4-bb13d1f27544@default>> <<831s8bocu3.fsf@gnu.org>> In-Reply-To: <<831s8bocu3.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9059 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810270142 X-Spam-Score: -2.3 (--) 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: -3.3 (---) > > - nil: return the content as a string. > > > > What does that mean, for a noncontiguous region? Are the buffer > > substrings for all of the region segments (zones) concatenated > together? > > If so, say that. >=20 > No, the value is a list of strings in this case. I fixed the doc > string to say that. Good. Thanks. So with nil the value is a list of strings, not a string that is "the content" of the noncontiguous region. > > 1. What are the BEG and END args passed to `filter-buffer-substring'? > > Is BEG the smallest car of any of the zones in the noncontiguous > > region, and END the largest cdr of any of the zones? >=20 > They are the first and the last positions of the region for > filter-buffer-substring to act upon. That function is not supposed to > process non-contiguous regions. Yes, but where do they come from, for that call? How do they relate to, or how are they derived from, the noncontiguous region? Are they point and mark? Something else? That's the question. The only arg to the function that is the value of `region-extract-function` is METHOD. The "region's content" is presumably the content of the noncontiguous region. And presumably it is that that is "the content" that is returned as a string. How is that string derived from the noncontiguous region? That's the question. No connection is made in this doc, AFAICT, between the noncontiguous region and the BEG and END that are passed to `filter-buffer-substring'. > > 2. `filter-buffer-substring' calls the value of > > `filter-buffer-substring-function' with the same 3 args. But what > > can that function do with BEG and END (which are what?)? It's > > presumably a function that expects to use a single stretch of > > buffer text from BEG to END. But here we're talking about a=20 > > noncontiguous >=20 > No, we are talking about contiguous regions when this function is > concerned. Sorry, but I don't understand. What contiguous regions are we talking about? How/where in this doc did you get from a noncontiguous region to contiguous regions? I haven't see your update to the doc string, but so far your description here doesn't give the impression that these questions have been cleared up. > > 3. The 3rd arg to `filter-buffer-substring' just deletes the region > > from BEG to END if it is non-nil, so it seems like passing that > > non-nil 3rd arg is useless, as the region gets deleted anyway, by > > `region-extract-function'. >=20 > Not sure what is the problem here. Not sure what you're saying. Are you saying that I'm wrong that a non-nil 3rd arg just deletes the region? Or are you saying that I'm wrong that that non-nil 3rd arg is useless because the region is deleted anyway? This doc is not clear to me. > > 4. The use of `filter-buffer-substring' is also unclear. It is passed > > BEG and END (and METHOD, but see #3, above). And it filters the > > buffer text between BEG and END. But see #1 above - are BEG and > > END buffer positions that make sense for the whole region text? > > Just what happens here? >=20 > See above. It is not the job of filter-buffer-substring to DTRT when > the region is non-contiguous, it is the job of its callers. See > rect.el for one example. See above. What are BEG and END that get passed to it? The doc should be able to make clear what the behavior is, without someone needing to investigate the code of rect.el. Plus, noncontiguous regions are more general than rectangles. The doc should make clear what happens in the general case. > > This is quite unclear to me. And following the rabbit hole from > > `region-extract-function' down to `filter-buffer-substring' and then > > to `filter-buffer-substring-function' does not make things more clear. >=20 > It isn't supposed to. If you want to see how non-contiguous regions > are used in this context, you need to look in places that do so. The doc should make clear in general terms what extracting a noncontiguous region is about, and just what the value of `region-extract-function' does: what its arguments are and what its return value is (as a function of those arguments). If someone has to look at the (very few, and particular to rectangles, BTW) code where `region-extract-function' is currently used to try to understand it, and the doc doesn't help but at best misleads, then we might as well have no doc for it. I did what you suggest before filing the bug report: checked all of the existing occurrences. I felt that the doc is wrong wrt what really happens, and I feel that there's a need for a general description of this variable which helps. > > Or is what happens perhaps that EACH element of the noncontiguous > > region, that is, each zone (BEG . END) of the list ((BEG1 . > > END1) ...) gets filtered by `filter-buffer-substring', passing > > its BEG END and METHOD >=20 > Yes! Then please say that in the doc. The function iterates over the zones of the noncontiguous region, doing ___. > > - so that a mapcar is applied? >=20 > Not literally, but the result is a list, yes. If you haven't already done so, please say that in the doc. > > In that case, how are the resulting buffer substrings assembled - > > are they concatenated to get the return value? >=20 > No, you get a list. Again, see rect.el. >=20 > Bottom line: I fixed the doc string of region-extract-function to say > what are the values when the region is non-contiguous, and how > filter-buffer-substring is invoked in that case. But I don't think > there's anything else that should be done here, because the details of > using this facility for non-contiguous regions is entirely up to the > Lisp program which implements such a feature. Sounds like you've already corrected some, maybe all, of what was incorrect. See above, in case you were unclear about some of the problems with it and you want to make some of that clearer. Thanks for looking at this. From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 16:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33167@debbugs.gnu.org Received: via spool by 33167-submit@debbugs.gnu.org id=B33167.15406579863876 (code B ref 33167); Sat, 27 Oct 2018 16:34:02 +0000 Received: (at 33167) by debbugs.gnu.org; 27 Oct 2018 16:33:06 +0000 Received: from localhost ([127.0.0.1]:45675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGRWL-00010R-II for submit@debbugs.gnu.org; Sat, 27 Oct 2018 12:33:05 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGRWJ-0000xg-3z for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 12:33:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGRW8-0007cq-PZ for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 12:32:57 -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 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGRW6-0007c9-VS; Sat, 27 Oct 2018 12:32:51 -0400 Received: from [176.228.60.248] (port=4823 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gGRW5-0002Wj-1H; Sat, 27 Oct 2018 12:32:50 -0400 Date: Sat, 27 Oct 2018 19:32:45 +0300 Message-Id: <83o9bfmjte.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Drew Adams on Sat, 27 Oct 2018 08:27:41 -0700 (PDT)) References: <<2e187b74-9999-4090-96b4-bb13d1f27544@default>> <<831s8bocu3.fsf@gnu.org>> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) 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: -6.0 (------) > Date: Sat, 27 Oct 2018 08:27:41 -0700 (PDT) > From: Drew Adams > Cc: 33167-done@debbugs.gnu.org > > > > 1. What are the BEG and END args passed to `filter-buffer-substring'? > > > Is BEG the smallest car of any of the zones in the noncontiguous > > > region, and END the largest cdr of any of the zones? > > > > They are the first and the last positions of the region for > > filter-buffer-substring to act upon. That function is not supposed to > > process non-contiguous regions. > > Yes, but where do they come from, for that call? How do they > relate to, or how are they derived from, the noncontiguous > region? Are they point and mark? Something else? That's the > question. It's entirely up to the region-extract-function that handles such regions. The default one doesn't. So I don't see why these questions need to be answered in the doc string of filter-buffer-substring, they don't belong there and would only confuse. > The only arg to the function that is the value of > `region-extract-function` is METHOD. The "region's content" > is presumably the content of the noncontiguous region. And > presumably it is that that is "the content" that is returned > as a string. How is that string derived from the noncontiguous > region? That's the question. It isn't. The region passed to filter-buffer-substring must always be contiguous. > > > 2. `filter-buffer-substring' calls the value of > > > `filter-buffer-substring-function' with the same 3 args. But what > > > can that function do with BEG and END (which are what?)? It's > > > presumably a function that expects to use a single stretch of > > > buffer text from BEG to END. But here we're talking about a > > > noncontiguous > > > > No, we are talking about contiguous regions when this function is > > concerned. > > Sorry, but I don't understand. What contiguous regions > are we talking about? How/where in this doc did you > get from a noncontiguous region to contiguous regions? That depends on the implementation of region-extract-function that supports non-contiguous regions: it must somehow call filter-buffer-substring-function in a way that this function gets only contiguous regions of text. So this question cannot be answered in the doc string of filter-buffer-substring-function. > I haven't see your update to the doc string, but so far > your description here doesn't give the impression that > these questions have been cleared up. Well, I suggest to read that first: http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=df64da8eb845c9f07ee93bfbf28af41a01a2e83f > > > 3. The 3rd arg to `filter-buffer-substring' just deletes the region > > > from BEG to END if it is non-nil, so it seems like passing that > > > non-nil 3rd arg is useless, as the region gets deleted anyway, by > > > `region-extract-function'. > > > > Not sure what is the problem here. > > Not sure what you're saying. You say that passing the 3rd arg is "useless", and I don't understand why. > Are you saying that I'm wrong that a non-nil 3rd arg just deletes > the region? Or are you saying that I'm wrong that that non-nil 3rd > arg is useless because the region is deleted anyway? I'm saying that I don't understand what you wanted to say here. At all. > > > 4. The use of `filter-buffer-substring' is also unclear. It is passed > > > BEG and END (and METHOD, but see #3, above). And it filters the > > > buffer text between BEG and END. But see #1 above - are BEG and > > > END buffer positions that make sense for the whole region text? > > > Just what happens here? > > > > See above. It is not the job of filter-buffer-substring to DTRT when > > the region is non-contiguous, it is the job of its callers. See > > rect.el for one example. > > See above. See above. > What are BEG and END that get passed to it? The doc string already tells that: the beginning and the end of the region to be filtered. > The doc should be able to make clear what the behavior > is, without someone needing to investigate the code of > rect.el. It does. What it does NOT have to do is tell how one would use this function while implementing a replacement for the default region-extract-function that can handle non-contiguous regions. > Plus, noncontiguous regions are more general than rectangles. Exactly. So each such implementation has to figure out how to call filter-buffer-substring in a way that makes sense and passes only contiguous regions to filter-buffer-substring. > The doc should make clear what happens in the general case. The doc string of filter-buffer-substring needs to tell what that function does. And it does precisely that. > The doc should make clear in general terms what extracting > a noncontiguous region is about, and just what the value of > `region-extract-function' does: what its arguments are and > what its return value is (as a function of those arguments). It does now, please see the new doc string. > I did what you suggest before filing the bug report: > checked all of the existing occurrences. I felt that > the doc is wrong wrt what really happens, and I feel > that there's a need for a general description of this > variable which helps. The doc string was indeed incomplete before my changes; it is IMO complete now. > > > Or is what happens perhaps that EACH element of the noncontiguous > > > region, that is, each zone (BEG . END) of the list ((BEG1 . > > > END1) ...) gets filtered by `filter-buffer-substring', passing > > > its BEG END and METHOD > > > > Yes! > > Then please say that in the doc. NO! Because that's just one possible implementation, for one possible kind of non-contiguous regions. > > > - so that a mapcar is applied? > > > > Not literally, but the result is a list, yes. > > If you haven't already done so, please say that in the doc. If you haven't already done so, please read the new doc string. I think I covered everything that should be covered. From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 19:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 33167@debbugs.gnu.org Received: via spool by 33167-submit@debbugs.gnu.org id=B33167.154066699025190 (code B ref 33167); Sat, 27 Oct 2018 19:04:01 +0000 Received: (at 33167) by debbugs.gnu.org; 27 Oct 2018 19:03:10 +0000 Received: from localhost ([127.0.0.1]:45729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGTrX-0006YC-Q2 for submit@debbugs.gnu.org; Sat, 27 Oct 2018 15:03:09 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:54016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGTrU-0006Xe-Np for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:03:05 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9RIovqa037615; Sat, 27 Oct 2018 19:02:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=SUEGYSMD5XVcJDRjyf79OedUrBbGPaBW9zvChpSiQ6Q=; b=X7LaUH+6aSo8frJrCQW62FYGPYoyh6PVhGAgAO/xXvCPkqVWARa2D+6t4nUzNe19uXx5 X9QWCOK/ambSz06DgseIgCMRsBX1VND7nBojE9k2nU3TCbl1DLSeoSA6hEHggvPYqvG/ glbnyLU7Z3ZSAfjkT0tpTUn3R6kArmviwBDdN2ioIz+8fcmwvaexex+64OnSX+M6XmFO wePeGK7t8qPpHNzx0Ejbn5BYgxweR1LwphD8reRrGIrxQGrVHIIYj2OKuUa8L3SuMsbO Zqp9hCiCryd5TbrdGax6PZzFKdky7PG5zooWy1YSYvSEB1cD7X2mALQW2I2Quyskw55m kw== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2120.oracle.com with ESMTP id 2ncfyph51h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 19:02:58 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9RJ2vx6004926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 19:02:58 GMT Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9RJ2uR1015761; Sat, 27 Oct 2018 19:02:57 GMT MIME-Version: 1.0 Message-ID: <0a008152-d861-4b96-ad2a-b837bd412d98@default> Date: Sat, 27 Oct 2018 12:02:55 -0700 (PDT) From: Drew Adams References: <<2e187b74-9999-4090-96b4-bb13d1f27544@default>> <<831s8bocu3.fsf@gnu.org>> <83o9bfmjte.fsf@gnu.org> In-Reply-To: <83o9bfmjte.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9059 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810270175 X-Spam-Score: -2.3 (--) 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: -3.3 (---) > > > > 1. What are the BEG and END args passed to `filter-buffer- > > > > substring'? > > > > Is BEG the smallest car of any of the zones in the > > > > noncontiguous > > > > region, and END the largest cdr of any of the zones? > > > > > > They are the first and the last positions of the region for > > > filter-buffer-substring to act upon. That function is not supposed > to > > > process non-contiguous regions. > > > > Yes, but where do they come from, for that call? How do they > > relate to, or how are they derived from, the noncontiguous > > region? Are they point and mark? Something else? That's the > > question. >=20 > It's entirely up to the region-extract-function that handles such > regions. The default one doesn't. So I don't see why these questions > need to be answered in the doc string of filter-buffer-substring, they > don't belong there and would only confuse. OK. I guess you're saying that the `region-extract-function' must invoke `filter-buffer-substring' on the content of each piece of the noncontiguous region, but it can pass whatever BEG and END positions it wants, to `filter-buffer-substring'. There is no specified relation between those values it passes and the BEG and END of each piece. That makes little sense to me, so far. I see that in the rectangle case it does decide what BEG and END values to use, and these do not necessarily correspond to the limits of the pieces. In any case, that the use of the var for rectangles might filter each line of the region in the way that it does says nothing about what another value of the variable, in some other context might do. But if the spec of the variable imposes nothing on the BEG and END values passed for filtering, then why does it impose a requirement that `filter-buffer-substring' must be called? The doc string of `region-extract-function' says that it returns the content of the region as a string, after filtering with `filter-buffer-substring' (in the "anything else" case). (You have presumably corrected that to say that it returns a list of such strings - after each is filtered.) If everything were up to the function that is the value of `region-extract-function' then there would be no need, and it would be incorrect, to state that it must filter buffer content by calling `filter-buffer-substring'. If, however, it is a _requirement_ that it calls `filter-buffer-substring' then we need to know what args it passes for BEG and END, in addition to knowing that it needs to pass METHOD as the 3rd arg. Otherwise, the need to use `filter-buffer-substring' is a hollow requirement (no requirement at all). If there is no limit on what it can pass as BEG and END then I do not see why we say that it must call `filter-buffer-substring'. Whether it calls that function or not, it can, it seems, do anything it likes, as long as it returns, for each piece, some subsequence of that piece. Worse: If there is no requirement on what it can pass as BEG and END - not necessarily any relation between those args passed and the limits of the pieces of the noncontiguous region, then it can return any list of subsequences of the buffer - not necessarily related to the noncontiguous region at all. I truly do not understand the intended (specified) behavior of a function that can be the value of this variable. It's not enough to look at the rectangle example - that doesn't specify what, in general, can and cannot be a legitimate value of the variable. My impression, so far, is that the actual requirement for the function (definition of a proper value for the variable),for the "anything else" case, is just that the strings in the returned list must be subsequences of the pieces of the noncontiguous region. > > Not sure what you're saying. >=20 > You say that passing the 3rd arg is "useless", and > I don't understand why. I said: The 3rd arg to `filter-buffer-substring' just deletes the region from BEG to END if it is non-nil, so it seems like passing that non-nil 3rd arg is useless, as the region gets deleted anyway, by `region-extract-function'. In the "anything else" case the `region-extract-function' must delete the region - the whole noncontiguous region. How it does that is its business presumably. Since it deletes the whole noncontig region anyway, why must it also pass METHOD to `filter-buffer-substring'? The only reason to pass a non-nil value as 3rd arg is to delete the text between the first two args passed. But see above. You've now said, IIUC, that it can pass _any_ BEG and END values to `filter-buffer-substring' - those values need not have anything to do with the region or its pieces. So is the point of passing METHOD to `filter-buffer-substring' to be able to delete additional text, which is not in the (noncontiguous) region? What's it about? > > What are BEG and END that get passed to it? >=20 > The doc string already tells that: the beginning and > the end of the region to be filtered. No, the doc string says nothing about the BEG and END values that get passed to `filter-buffer-substring'. And you pointed out that those values passed need not have any relation to the BEG and END limits of the pieces of the noncontiguous region. And it's certainly true, e.g. for rectangles, that they need not be _equal_ to the piece limits. >>>> Or is what happens perhaps that EACH element of >>>> the noncontiguous region, that is, each zone >>>> (BEG . END) of the list ((BEG1 . END1) ...) >>>> gets filtered by `filter-buffer-substring', passing >>>> its BEG END and METHOD > > > > > > Yes! > > > > Then please say that in the doc. >=20 > NO! Because that's just one possible implementation, > for one possible kind of non-contiguous regions. I didn't ask about one possible kind. I asked if that's what happens for any noncontiguous region. You replied "Yes!", so I requested that that info be added to the doc. Now, and above IIUC, you've said that it's not true for all non-contig regions. From what you've said above, it can pass _any_ BEG and END values it wants for any given piece of the noncontig region. But at least the doc can say, and it does now say, that `filter-buffer-substring' is called once for each piece. What it does not say is that it need not be called with the limits of that piece - it can be called with any two buffer positions (apparently). I find it hard to believe that we would both (1) insist that the function (in the "anything else" case) must call `filter-buffer-substring' and (2) not specify some required relation between the limits passed to `filter-buffer-substring' and the limits of the region piece. That's what I've understood now, from your last message. Would you please confirm or correct that understanding of what you've said? I can see that the function should iterate over the pieces of the region. I can see that it might be good to let it remove some bits of those pieces, i.e., filter them a la `filter-buffer-substring'. I guess I can even imagine that it might even be useful for a function to return subsequences of the buffer text that have no relation to the pieces of the noncontiguous region, but that's a stretch. But in that last case, I see no reason to impose the use of `filter-buffer-substring' to accomplish that. And in any case, once the spec says that the function (in the "anything else" case) must delete the noncontiguous region, I see no reason why the function must pass METHOD to `filter-buffer-substring', unless you really want to allow the function to delete not only the noncontiguous region but also any other text in the buffer. I'm trying to understand what the requirement is for a function that is the value of `region-extract-function'. Confirming that it iterates over the pieces of a noncontiguous region cleared up one problem. But the use by `region-extract-function' of `filter-buffer-substring' is less clear than ever, I'm afraid. From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 19:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33167@debbugs.gnu.org Received: via spool by 33167-submit@debbugs.gnu.org id=B33167.154066820227151 (code B ref 33167); Sat, 27 Oct 2018 19:24:02 +0000 Received: (at 33167) by debbugs.gnu.org; 27 Oct 2018 19:23:22 +0000 Received: from localhost ([127.0.0.1]:45743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUB7-00073r-VT for submit@debbugs.gnu.org; Sat, 27 Oct 2018 15:23:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35475) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUB7-00073f-8z for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:23:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGUAw-0007NH-GG for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:23:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGUAw-0007ND-7N; Sat, 27 Oct 2018 15:23:10 -0400 Received: from [176.228.60.248] (port=3521 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gGUAq-00053M-0t; Sat, 27 Oct 2018 15:23:06 -0400 Date: Sat, 27 Oct 2018 22:23:08 +0300 Message-Id: <83h8h7mbxf.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <0a008152-d861-4b96-ad2a-b837bd412d98@default> (message from Drew Adams on Sat, 27 Oct 2018 12:02:55 -0700 (PDT)) References: <<2e187b74-9999-4090-96b4-bb13d1f27544@default>> <<831s8bocu3.fsf@gnu.org>> <83o9bfmjte.fsf@gnu.org> <0a008152-d861-4b96-ad2a-b837bd412d98@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) 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: -6.0 (------) > Date: Sat, 27 Oct 2018 12:02:55 -0700 (PDT) > From: Drew Adams > Cc: 33167@debbugs.gnu.org > > But if the spec of the variable imposes nothing on the BEG > and END values passed for filtering, then why does it impose > a requirement that `filter-buffer-substring' must be called? So that applications could rely on that, and could provide their own filter functions, if they want. From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 19:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Drew Adams Cc: 33167@debbugs.gnu.org Received: via spool by 33167-submit@debbugs.gnu.org id=B33167.154066864327867 (code B ref 33167); Sat, 27 Oct 2018 19:31:01 +0000 Received: (at 33167) by debbugs.gnu.org; 27 Oct 2018 19:30:43 +0000 Received: from localhost ([127.0.0.1]:45752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUID-0007FO-VQ for submit@debbugs.gnu.org; Sat, 27 Oct 2018 15:30:42 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:44642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUIC-0007FB-E2 for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:30:40 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9RJTCom008605; Sat, 27 Oct 2018 19:30:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Lb7K6aKBsHt+GpsE310fDQRs8rBrJuNGcDyDHxGvX8I=; b=IhWFwejfyVKGUW+4QpjLqDvhh2LFv9hcDkXrqV/lDJIY5USmAN/x7M2xxLdYO/U9de0v vLKR4u1WmHYfMoulMYUI0krJf20rkFfRZTOVyZiYRMrPWIgjree3iJSw2r9zFThR83qa 3TB2NlMxyxJn7b1W1kR3or8vYi9HzPhwEWsomJbnTt82x6b/9dHGEnj5oyFij2egLVID 5HaO00PcyppgwDDJiKBed23egL+xRSjN+6vn8z76w5kUzqbL+gLb4hX5pLifUYCYyp5U Q4x+Nrs/DWAJ4gFTZ4mcNZlj1w+jOcGhL2OiUdRVHAZTsAIpSznRXu2OuG52QqMMTbhi 1Q== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2ncgnqh3xu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 19:30:34 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9RJUXi1005851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 27 Oct 2018 19:30:33 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w9RJUWZI020839; Sat, 27 Oct 2018 19:30:32 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 27 Oct 2018 12:30:31 -0700 (PDT) From: Drew Adams References: <<<2e187b74-9999-4090-96b4-bb13d1f27544@default>>> <<<831s8bocu3.fsf@gnu.org>>> <> <<83o9bfmjte.fsf@gnu.org>> <<0a008152-d861-4b96-ad2a-b837bd412d98@default>> <<83h8h7mbxf.fsf@gnu.org>> In-Reply-To: <<83h8h7mbxf.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4756.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9059 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=742 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810270180 X-Spam-Score: -2.3 (--) 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: -3.3 (---) > > But if the spec of the variable imposes nothing on the BEG > > and END values passed for filtering, then why does it impose > > a requirement that `filter-buffer-substring' must be called? >=20 > So that applications could rely on that, and could provide their own > filter functions, if they want. I see. That makes sense. Thx. Is it really the case that the value of `region-extract-function' can pass any limits it wants to `filter-buffer-substring', even limits that have no relation to the pieces of the noncontiguous region? So the only thing specified is that `filter-buffer-substring' gets called once for each each piece? I.e., all that's specified is that if the nc region has N pieces then `filter-buffer-substring' is called N times - nothing more? From unknown Tue Jun 17 01:50:36 2025 X-Loop: help-debbugs@gnu.org Subject: bug#33167: 26; Doc string of `region-extract-function' Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Oct 2018 19:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33167 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Drew Adams Cc: 33167@debbugs.gnu.org Received: via spool by 33167-submit@debbugs.gnu.org id=B33167.154066905128467 (code B ref 33167); Sat, 27 Oct 2018 19:38:01 +0000 Received: (at 33167) by debbugs.gnu.org; 27 Oct 2018 19:37:31 +0000 Received: from localhost ([127.0.0.1]:45761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUOp-0007P4-8f for submit@debbugs.gnu.org; Sat, 27 Oct 2018 15:37:31 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37759) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGUOn-0007Op-JY for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:37:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGUOb-000741-RU for 33167@debbugs.gnu.org; Sat, 27 Oct 2018 15:37:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGUOb-00073u-N2; Sat, 27 Oct 2018 15:37:17 -0400 Received: from [176.228.60.248] (port=4492 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gGUOa-0003Yk-7a; Sat, 27 Oct 2018 15:37:17 -0400 Date: Sat, 27 Oct 2018 22:37:18 +0300 Message-Id: <83efcbmb9t.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Drew Adams on Sat, 27 Oct 2018 12:30:31 -0700 (PDT)) References: <<<2e187b74-9999-4090-96b4-bb13d1f27544@default>>> <<<831s8bocu3.fsf@gnu.org>>> <> <<83o9bfmjte.fsf@gnu.org>> <<0a008152-d861-4b96-ad2a-b837bd412d98@default>> <<83h8h7mbxf.fsf@gnu.org>> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) 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: -6.0 (------) > Date: Sat, 27 Oct 2018 12:30:31 -0700 (PDT) > From: Drew Adams > Cc: 33167@debbugs.gnu.org > > Is it really the case that the value of `region-extract-function' > can pass any limits it wants to `filter-buffer-substring', even > limits that have no relation to the pieces of the noncontiguous > region? I'd say doing so would make no sense to me. > So the only thing specified is that `filter-buffer-substring' > gets called once for each each piece? I.e., all that's specified > is that if the nc region has N pieces then `filter-buffer-substring' > is called N times - nothing more? I think it should be called once on each such piece, yes.