From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom <levelhalom@gmail.com> Newsgroups: gmane.emacs.devel Subject: Re: Structural regular expressions Date: Fri, 10 Sep 2010 20:29:45 +0000 (UTC) Message-ID: <loom.20100910T221237-941@post.gmane.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> <46875.130.55.118.19.1284065220.squirrel@webmail.lanl.gov> <AANLkTimUS7zL77TGiWoEdS+=nuww=TSABKMZuSiYPaCc@mail.gmail.com> <E1Ou5lY-0006Jj-MB@fencepost.gnu.org> <AANLkTi=dv8n40x-rTtz@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1284150617 24912 80.91.229.12 (10 Sep 2010 20:30:17 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Sep 2010 20:30:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 10 22:30:16 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 1OuAEe-00036D-Jm for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 22:30:13 +0200 Original-Received: from localhost ([127.0.0.1]:37075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OuAEW-0006pV-0i for ged-emacs-devel@m.gmane.org; Fri, 10 Sep 2010 16:30:04 -0400 Original-Received: from [140.186.70.92] (port=48197 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OuAEP-0006nt-Ed for emacs-devel@gnu.org; Fri, 10 Sep 2010 16:29:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from <ged-emacs-devel@m.gmane.org>) id 1OuAEN-0005fl-WE for emacs-devel@gnu.org; Fri, 10 Sep 2010 16:29:57 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:53910) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <ged-emacs-devel@m.gmane.org>) id 1OuAEN-0005fY-MC for emacs-devel@gnu.org; Fri, 10 Sep 2010 16:29:55 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from <ged-emacs-devel@m.gmane.org>) id 1OuAEK-0002zE-Gf for emacs-devel@gnu.org; Fri, 10 Sep 2010 22:29:52 +0200 Original-Received: from 94-21-154-120.pool.digikabel.hu ([94.21.154.120]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <emacs-devel@gnu.org>; Fri, 10 Sep 2010 22:29:52 +0200 Original-Received: from levelhalom by 94-21-154-120.pool.digikabel.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <emacs-devel@gnu.org>; Fri, 10 Sep 2010 22:29:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 69 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.154.120 (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." <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:129929 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/129929> David House <dmhouse <at> gmail.com> writes: > > On 10 September 2010 16:43, Richard Stallman <rms <at> gnu.org> wrote: > > Could someone please explain what a "structural regular expression" > > means? The message that started the thread did not say. > > It is not a property of the regexps themselves, but pertains to > functions that use regexps: namely that they only apply to a subset of > your buffer. For example, you might do a query-replace-regexp on only > the comments of a C file, or an isearch-regexp on only the strings. So > note that the subsets they apply to are non-contiguous in general. > It is the property of the regexps, because the main point of the feature is there are enhanced regexps which are aware of the syntax of the buffer contents, so you can select comments, strings, scopes, etc. Examples for the mentioned blog post: V/pattern select all matches V|pattern select all lines with match V{scope select all matching scopes Vatype select all objects (inclusive) Vttype select all objects (exclusive) Y/pattern select everything but matches Y|pattern select all lines without match Y{scope select everything but scope Yatype select everything but objects (inclusive) Yttype select everything but objects (exclusive) And you can perform further selections after the first selection recursively, so you can select comments in scopes, etc. The document that inspired the above feature of the E editor: "The current UNIX® text processing tools are weakened by the built-in concept of a line. There is a simple notation that can describe the `shape' of files when the typical array-of-lines picture is inadequate. That notation is regular expressions. Using regular expressions to describe the structure in addition to the contents of files has interesting applications, and yields elegant methods for dealing with some problems the current tools handle clumsily. When operations using these expressions are composed, the result is reminiscent of shell pipelines." http://doc.cat-v.org/bell_labs/structural_regexps/se.pdf > It has been proposed to support this by generalizing the concept of > the region to actually be a list of (contiguous) regions. Another idea > further up was to use special text properties. I wonder if there is a simpler solution. For example, during the selection process a separate buffer could display interactively the current selection made by the user and this buffer could be set up with text properties and such, so that it is known where the individual ranges start and end. After the user done his work in this temporary buffer the resulting ranges could be copied back to the appropriate sections of the original buffer thereby committing the changes. This way nothing has to be changed in Emacs core.