From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Newsgroups: gmane.emacs.devel Subject: Re: Structural regular expressions Date: Thu, 9 Sep 2010 15:51:06 +0000 (UTC) Message-ID: References: <87sk1lt4uf.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1284047621 18492 80.91.229.12 (9 Sep 2010 15:53:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 9 Sep 2010 15:53:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 09 17:53:39 2010 Return-path: 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 ) id 1OtjRP-0002o5-3G for ged-emacs-devel@m.gmane.org; Thu, 09 Sep 2010 17:53:35 +0200 Original-Received: from localhost ([127.0.0.1]:37061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtjRO-0001UJ-Au for ged-emacs-devel@m.gmane.org; Thu, 09 Sep 2010 11:53:34 -0400 Original-Received: from [140.186.70.92] (port=48656 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtjRH-0001SK-MD for emacs-devel@gnu.org; Thu, 09 Sep 2010 11:53:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtjPH-00083t-VU for emacs-devel@gnu.org; Thu, 09 Sep 2010 11:51:28 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:57923) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtjPH-00083d-QQ for emacs-devel@gnu.org; Thu, 09 Sep 2010 11:51:23 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OtjPF-0001Wx-EE for emacs-devel@gnu.org; Thu, 09 Sep 2010 17:51:21 +0200 Original-Received: from 94-21-223-187.pool.digikabel.hu ([94.21.223.187]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 17:51:21 +0200 Original-Received: from levelhalom by 94-21-223-187.pool.digikabel.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Sep 2010 17:51:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 29 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 94.21.223.187 (Opera/9.80 (Windows NT 6.1; U; en) Presto/2.6.30 Version/10.61) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:129820 Archived-At: Eric Schulte gmail.com> writes: > > > > It can be a good start, but the feature in the E editor is more general > > than search and replace. You can perform any operation on the selected > > text. It's sort of like working on the narrowed part of a buffer, only > > the narrowed part in this case consists of several separate ranges of > > the same buffer (like all comments, etc.). > > Would generalizing the narrowing behavior to arbitrarily many ranges in > a buffer instead of a single range have extensive ramifications? The mentioned E feature is sort of like narrowing, but is not the same if I understand it correctly. For example, if I want to replace the word "formatted" to "structured" in all comments then considering the following case (<> indicates comment range boundaries): <.... is the format> the word "format" at the end of the first range and the word "tedious" at the beginning of the next should not be handled as a contiguous text, because in that case the text "formattedious" would match the word to be replaced ("formatted") and it's clearly not correct behavior. So if such "multiple narrowing" is implemented it must maintain the boundaries between the different ranges and shouldn't simply handle it as contiguous text.