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