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: Wed, 08 Sep 2010 10:46:41 +0200 Message-ID: <jwvsk1kaav2.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1283935625 24809 80.91.229.12 (8 Sep 2010 08:47:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Sep 2010 08:47:05 +0000 (UTC) Cc: Tom <levelhalom@gmail.com>, emacs-devel@gnu.org To: "Eric Schulte" <schulte.eric@gmail.com> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 08 10:47:02 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 1OtGJ4-0006qq-4p for ged-emacs-devel@m.gmane.org; Wed, 08 Sep 2010 10:47:02 +0200 Original-Received: from localhost ([127.0.0.1]:48981 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtGJ2-0000qk-FM for ged-emacs-devel@m.gmane.org; Wed, 08 Sep 2010 04:47:00 -0400 Original-Received: from [140.186.70.92] (port=43073 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtGIr-0000ph-IO for emacs-devel@gnu.org; Wed, 08 Sep 2010 04:46:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from <monnier@iro.umontreal.ca>) id 1OtGIn-0004gQ-8c for emacs-devel@gnu.org; Wed, 08 Sep 2010 04:46:49 -0400 Original-Received: from impaqm5.telefonica.net ([213.4.138.5]:45376) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <monnier@iro.umontreal.ca>) id 1OtGIn-0004fk-2C for emacs-devel@gnu.org; Wed, 08 Sep 2010 04:46:45 -0400 Original-Received: from IMPmailhost2.adm.correo ([10.20.102.39]) by IMPaqm5.telefonica.net with bizsmtp id 46q61f00E0r0BT63R8miQX; Wed, 08 Sep 2010 10:46:42 +0200 Original-Received: from ceviche.home ([83.61.36.43]) by IMPmailhost2.adm.correo with BIZ IMP id 48mi1f0010vquEj1i8miAm; Wed, 08 Sep 2010 10:46:42 +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 D1222660D2; Wed, 8 Sep 2010 10:46:41 +0200 (CEST) In-Reply-To: <87sk1lt4uf.fsf@gmail.com> (Eric Schulte's message of "Tue, 07 Sep 2010 19:13:28 -0600") 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:129768 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/129768> > Would generalizing the narrowing behavior to arbitrarily many ranges in > a buffer instead of a single range have extensive ramifications? Would > this be an easy or difficult thing to implement? Since the non-narrowed part is not displayed at all, it wouldn't be quite what we want anyway. We'd need to add something new, tho it could be based on something pre-existing (e.g. it could rely on text properties like to `invisible' and/or `intangible'). > If it's not too difficult then providing behavior like that mentioned in > the article above should be trivial. Nothing's trivial when you have to ensure some amount of backward compatibility with code written many years ago ;-) But of course, it would be OK to start with something that may break pre-existing code, as long as it's only broken when you use the new feature. And I agree with Lennart, that such a new tool, if done right, could be a good basis for better multi-mode support. Stefan