From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: Design of commands operating on rectangular regions Date: Mon, 23 Nov 2015 01:57:59 +0200 Organization: LINKOV.NET Message-ID: <874mgda8oo.fsf@mail.linkov.net> References: <86zizdczhp.fsf@stephe-leake.org> <871tc315y3.fsf@lifelogs.com> <83k2pvqg0l.fsf@gnu.org> <837fluqkd1.fsf@gnu.org> <87oaf1s82r.fsf@mail.linkov.net> <876116ucdm.fsf_-_@mail.linkov.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448238457 24160 80.91.229.3 (23 Nov 2015 00:27:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2015 00:27:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 01:27:37 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a0eym-0008C9-NB for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2015 01:27:36 +0100 Original-Received: from localhost ([::1]:58024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0eym-0001HY-OC for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 19:27:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0eyT-0001G5-3N for emacs-devel@gnu.org; Sun, 22 Nov 2015 19:27:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0eyP-0005lx-UB for emacs-devel@gnu.org; Sun, 22 Nov 2015 19:27:17 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:52385 helo=homiemail-a13.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0eyP-0005lm-MU for emacs-devel@gnu.org; Sun, 22 Nov 2015 19:27:13 -0500 Original-Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id 1AB1733406F for ; Sun, 22 Nov 2015 16:27:12 -0800 (PST) Original-Received: from localhost.linkov.net (m91-131-172-22.cust.tele2.ee [91.131.172.22]) (Authenticated sender: jurta@jurta.org) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id 701A433406C for ; Sun, 22 Nov 2015 16:27:11 -0800 (PST) In-Reply-To: (John Wiegley's message of "Fri, 20 Nov 2015 11:10:49 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 69.163.253.7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195081 Archived-At: > Can you tell me more about the meaning of `region-noncontiguous-p' here? > How does the caller know when this option is required? To be able to process a non-contiguous region differently than the ordinary region, a command needs to know either whether it's operating on the special region (so the command itself can acquire all additional information about the region and its shape), or receive all this information through its arg. I provided the patches for both variants in bug#19829, and it seems that you prefer the latter, if I'm not mistaken. Please confirm do you think that it would be better to add a 'region' arg such that when used programmatically it's required to be in this form, or when used interactively it takes a form with fine-grained boundaries: (region (shape . rectangle) (positions . (1 . 2) (3 . 4) (5 . 6) ...) ... to accompany coarse-grained boundaries in START and END args. > My takeaway is that this patch conflates user-level indications (selected > regions) too closely with the programmatically provided entities (the region > specified by START END). Perhaps it points to the need for an `interactive' > specifier to request "the current region, though if multiple sub-regions > exist, the set of spans indicated by those sub-regions". A function like > `shell-command-on-region' should be determined by its arguments. This patch > introduces a much tighter coupling with its context of use than what we had > previously. > > To make that last statement clearer: Right now, `shell-command-on-region' acts > on a buffer, and a region of text within that buffer. This region is provided > to the command through its arguments by (interactive "r"). The only thing that > `shell-command-on-region' needs to do beyond that is to query the current > buffer, in order to feed text to the executed process. So, our "context" is > the current buffer, while everything else is provided by its arguments. > > Your patch introduces a more hybridized behavior: (interactive "r") provides > the total extent of the region, but now there's an additional parameter, > `region-noncontiguous-p', that alters the behavior of shell-command-on-region > so that it pays attention not only to the current buffer, but also to > user-specified regions when drawing text from the buffer. And these regions > are only somewhat related to the region provided by "interactive 'r'". > > I feel that the semantic "level" of these three arguments -- START, END and > REGION-NONCONTIGUOUS-P -- are now different, which I find confusing. > `region-noncontiguous-p' doesn't relate to the `interactive' form at all, but > rather solely to this new behavior, internal to shell-command-on-region.