From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier <monnier@iro.umontreal.ca> Newsgroups: gmane.emacs.devel Subject: Re: Structural regular expressions Date: Fri, 10 Sep 2010 15:31:03 +0200 Message-ID: <jwvvd6d7mqf.fsf-monnier+emacs@gnu.org> References: <loom.20100907T212314-566@post.gmane.org> <AANLkTimYvE0aqrG-OQxuY6BTca7ngzrfQUa62mOxyV=+@mail.gmail.com> <loom.20100907T222143-475@post.gmane.org> <87sk1lt4uf.fsf@gmail.com> <jwvsk1kaav2.fsf-monnier+emacs@gnu.org> <pvhphbi0wq0d.fsf@gmx.li> <jwvlj7c9ura.fsf-monnier+emacs@gnu.org> <pvhpd3sow7uc.fsf@gmx.li> <jwvbp8797ox.fsf-monnier+emacs@gnu.org> <87y6bbs8d1.fsf@lola.goethe.zz> <jwvvd6e6e9l.fsf-monnier+emacs@gnu.org> <87iq2drdlx.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1284125482 8937 80.91.229.12 (10 Sep 2010 13:31:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Sep 2010 13:31:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup <dak@gnu.org> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 10 15:31:21 2010 Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org> Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>) id 1Ou3hI-0006Ud-Ax for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 15:31:20 +0200 Original-Received: from localhost ([127.0.0.1]:47307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3hH-0000KO-Lf for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 09:31:19 -0400 Original-Received: from [140.186.70.92] (port=37772 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou3hA-0000JO-Hv for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:31:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from <monnier@iro.umontreal.ca>) id 1Ou3h4-0004Nj-OR for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:31:12 -0400 Original-Received: from impaqm5.telefonica.net ([213.4.138.5]:35823) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <monnier@iro.umontreal.ca>) id 1Ou3h4-0004NV-Hc for emacs-devel@gnu.org; Fri, 10 Sep 2010 09:31:06 -0400 Original-Received: from IMPmailhost2.adm.correo ([10.20.102.39]) by IMPaqm5.telefonica.net with bizsmtp id 4z6H1f00u0r0BT63R1X4Pe; Fri, 10 Sep 2010 15:31:04 +0200 Original-Received: from ceviche.home ([83.61.42.227]) by IMPmailhost2.adm.correo with BIZ IMP id 51X31f0024u4RdP1i1X3nF; Fri, 10 Sep 2010 15:31:04 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id 237C6660D2; Fri, 10 Sep 2010 15:31:03 +0200 (CEST) In-Reply-To: <87iq2drdlx.fsf@lola.goethe.zz> (David Kastrup's message of "Fri, 10 Sep 2010 14:23:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." <emacs-devel.gnu.org> List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=unsubscribe> List-Archive: <http://lists.gnu.org/archive/html/emacs-devel> List-Post: <mailto:emacs-devel@gnu.org> List-Help: <mailto:emacs-devel-request@gnu.org?subject=help> List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=subscribe> Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:129893 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/129893> >>> And what is narrow-to-region supposed to do then? >> Signal an error when the region is not contiguous? > Opens another can of worms because quite a number of commands accepting > a region argument implement it internally using narrow-to-region. What can of worms? Old uses will still work just as well as before. And as explained in earlier threads, some of those commands could be magically made to work by letting an "r" in the interactive spec mean "apply once per contiguous region segment". I haven't experimented with such a change, so it may or may not be an acceptable heuristic, but in any case I don't see it as a problem that commands need to be adjusted in order to work in the case that the region is split into more than 1 chunk. Stefan