From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Erik Charlebois Newsgroups: gmane.emacs.devel Subject: Re: multi-character syntactic entities in syntax tables Date: Fri, 26 Apr 2013 17:37:47 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd6ab98991cb904db4a581c X-Trace: ger.gmane.org 1367012269 8504 80.91.229.3 (26 Apr 2013 21:37:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Apr 2013 21:37:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 26 23:37:53 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UVqL3-0005pB-1D for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2013 23:37:53 +0200 Original-Received: from localhost ([::1]:46365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVqL2-0003e3-MB for ged-emacs-devel@m.gmane.org; Fri, 26 Apr 2013 17:37:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVqKz-0003by-Es for emacs-devel@gnu.org; Fri, 26 Apr 2013 17:37:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UVqKy-0001ax-8F for emacs-devel@gnu.org; Fri, 26 Apr 2013 17:37:49 -0400 Original-Received: from mail-ia0-x22a.google.com ([2607:f8b0:4001:c02::22a]:50942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UVqKy-0001am-1x for emacs-devel@gnu.org; Fri, 26 Apr 2013 17:37:48 -0400 Original-Received: by mail-ia0-f170.google.com with SMTP id k20so1029476iak.15 for ; Fri, 26 Apr 2013 14:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y+5W80LEO8Ak4GS3FHEO1aXv09aHFwVTD/nJ5fRvbWU=; b=lLdXW1JINUO9X9focdZVxST+BzuV6KbtmlkLAe9s0HFIrx82BwcxhS0jb1VzeQutJw yYrN/a5Rl0r7nCQjHbJcwiBZH5wYPXmPmCkKiryDxjJQYdhAZy8wjqEda8K3RvEGp6mM qgSSuZmgKIzsRZxoagG5aAVk0wzr/6zniV90Hx5e4sgMABtAHZ79uDmdEQHrgA7iSZej H8Ayb43FlhfVwLGQ7LRuvbe4wCKyOKmH7sx9Apo3uqdIEPlfv1Vyt9hlzcVjQUHkVsIK X/nM86mcgwPessk7KQCu0XchJDg65R8fWvU93mrxHLe7VAItz6cggT6QD/39lIK5gDn/ kI1g== X-Received: by 10.50.1.103 with SMTP id 7mr2965285igl.69.1367012267332; Fri, 26 Apr 2013 14:37:47 -0700 (PDT) Original-Received: by 10.64.59.193 with HTTP; Fri, 26 Apr 2013 14:37:47 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::22a X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159174 Archived-At: --047d7bd6ab98991cb904db4a581c Content-Type: text/plain; charset=UTF-8 ruby-forward-sexp works fine. It's more for things like % (under vim emulation, I'm not sure what the Emacs-equivalent is) to jump to the matching brace and show-paren-mode. On Fri, Apr 26, 2013 at 3:26 PM, Stefan Monnier wrote: > > One of the items in etc/TODO is: > > ** Beefed-up syntax-tables. > > *** recognize multi-character syntactic entities like `begin' and `end'. > > > Lately I'm using languages where this would be quite useful and would be > > interested in adding support. Before I dive in, are there any strong > > opinions about how this should be implemented? > > > The approach I was thinking of taking is defining a new syntax character > > class (let's say, *) which inherits from the previous character > > (recursively if the previous character is *). The important distinction > is > > that they would not be treated as a new instance of that syntax class, so > > point movement by syntax class or paren matching would work (e.g. begin > > would be (****, and would only add 1 level of paren nesting). > > I see. So you'd rely on syntax-propertize-function to recognize those > multi-char entities and label them with one of the current syntaxes for > the first char and "*" for the other ones, thus labelling the symbol as > forming a single entity. > > That's interesting. The main drawback I see with it is the heavy > reliance on syntax-propertize, which can imply a significant performance > cost when jumping to the end of a largish buffer (forcing the whole > buffer to be lexed). > > But it sounds like an attractive "easy" way to extend syntax tables to > support multi-char entities. > > BTW: have you tried to set forward-sexp-function to something like > ruby-forward-sexp? > > > Stefan > --047d7bd6ab98991cb904db4a581c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ruby-forward-sexp works fine. It's more for things lik= e % (under vim emulation, I'm not sure what the Emacs-equivalent is) to= jump to the matching brace and show-paren-mode.


On Fri, Apr 26, 2013 at 3:26 PM, Stefan = Monnier <monnier@iro.umontreal.ca> wrote:
> One of the items in etc/TODO is:
> ** Beefed-up syntax-tables.
> *** recognize multi-character syntactic entities like `begin' and = `end'.

> Lately I'm using languages where this would be quite useful and wo= uld be
> interested in adding support. Before I dive in, are there any strong > opinions about how this should be implemented?

> The approach I was thinking of taking is defining a new syntax charact= er
> class (let's say, *) which inherits from the previous character > (recursively if the previous character is *). The important distinctio= n is
> that they would not be treated as a new instance of that syntax class,= so
> point movement by syntax class or paren matching would work (e.g. begi= n
> would be (****, and would only add 1 level of paren nesting).

I see. =C2=A0So you'd rely on syntax-propertize-function to recog= nize those
multi-char entities and label them with one of the current syntaxes for
the first char and "*" for the other ones, thus labelling the sym= bol as
forming a single entity.

That's interesting. =C2=A0The main drawback I see with it is the heavy<= br> reliance on syntax-propertize, which can imply a significant performance cost when jumping to the end of a largish buffer (forcing the whole
buffer to be lexed).

But it sounds like an attractive "easy" way to extend syntax tabl= es to
support multi-char entities.

BTW: have you tried to set forward-sexp-function to something like
ruby-forward-sexp?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--047d7bd6ab98991cb904db4a581c--