Off the top of my head, point motion (e.g. forward-word should skip the
entire word, not stop where the syntax class changes from "(" to "w") and
font locking (show-paren-mode should highlight the entire matching words).

Since the matching keyword lengths can be different (begin vs end), my
understanding is I can't just turn them into ((((( and ))) because it
doesn't balance.

Currently I have some hacks for Ruby mode that makes the first characters
of the block keywords have "(" or ")" syntax class. It works fine, aside
from point motion and font locking.



On Fri, Apr 26, 2013 at 2:53 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:

> Erik Charlebois <erikcharlebois@gmail.com> writes:
>
> > 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).
> >
> > A mode would use a syntax-propertize-function to tag keywords with
> > appropriate text properties. So something like Ruby:
> >
> > class Foo
> > def Bar
> > if condition
> > ...
> > end
> > end
> > end
>
> ruby-mode code could definitely benefit from something like this.
>
> > would have syntax classes like:
> >
> > (**** www
> > (** www
> > (* wwwwwwwww
> > ...
> > )**
> > )**
> > )**
>
> I don't think using syntax-propertize-function is something the person
> who wrote that TODO entry had in mind, but if we'll use it for that
> purpose, at least in ruby-mode implementing something like a "generic
> parenthesis" class should suffice (which would work similarly to generic
> string and generic comment delimiters), since all non-curly blocks in
> Ruby end the same way.
>
> So, what's the rationale for your, more complex proposal? In what
> context would treating e, g, i and n in "begin" as parenthesis openers
> will be useful?
>