Re: emacs: are multi-char parentheses possible?

Re: emacs: are multi-char parentheses possible?

[Stefan Monnier]

> Do you know if it is possible for Emacs to handle a pair of multi-char
> parentheses?

Yes, I do.  I also know the answer is not just a plain boolean.

> Take << and >> for example,
>
> (setq-local syntax-propertize-function (syntax-propertize-rules
>                                           ("\\(<\\)<" (1 "(>"))
>                                           (">\\(>\\)" (1 ")<"))))
>
> show-paren-mode can highlight "<<" and ">>" but up-list aren't aware of
> them.

up-list should handle this just as well as show-paren and
for/backward-sexp (and does, in my tests).

Maybe you tried a "forward up-list" where the closing ">>" hadn't yet been
syntax-propertized?

This technique has some downsides, but in the case of << ... >> it might
work well enough.

For things like "begin...end" it's more annoying (e.g. backward word
will stop right between the "b" and the "egin" and forward-word will
stop right between "en" and "d").  For those, SMIE might be a better
option (which uses hooks in show-paren and forward-sexp to try and make
them do The Right Thing, tho the up-list case is only 90% working).


        Stefan

Re: emacs: are multi-char parentheses possible?

[Leo Liu]

On 2014-06-09 11:38 -0400, Stefan Monnier wrote:
> Maybe you tried a "forward up-list" where the closing ">>" hadn't yet been
> syntax-propertized?
>
> This technique has some downsides, but in the case of << ... >> it might
> work well enough.

Thanks for the confirmation. With the syntax-table property the normal
sexp motion commands actually work. But I was in a smie mode which
redefines forward-sexp and the lexer and grammar aren't setup to handle
<< and >> so it appeared forward-sexp failed. I was looking in the wrong
direction for fix.

> For things like "begin...end" it's more annoying (e.g. backward word
> will stop right between the "b" and the "egin" and forward-word will
> stop right between "en" and "d").  For those, SMIE might be a better
> option (which uses hooks in show-paren and forward-sexp to try and make
> them do The Right Thing, tho the up-list case is only 90% working).

I like this feature ;)

Leo

Re: emacs: are multi-char parentheses possible?

[Stefan Monnier]

> Thanks for the confirmation.  With the syntax-table property the normal
> sexp motion commands actually work.  But I was in a smie mode which
> redefines forward-sexp and the lexer and grammar aren't setup to handle
> << and >> so it appeared forward-sexp failed.

Maybe you "did something wrong" there, but SMIE normally tries to obey
the existing syntax tables (and syntax-table properties), so maybe you
saw a bug in SMIE.


        Stefan

Re: emacs: are multi-char parentheses possible?

[Leo Liu]

On 2014-06-09 22:21 -0400, Stefan Monnier wrote:
> Maybe you "did something wrong" there, but SMIE normally tries to obey
> the existing syntax tables (and syntax-table properties), so maybe you
> saw a bug in SMIE.

hmm, I can no longer find a recipe to reproduce the problem I was seeing
where forward-sexp before << moved forward just one char.

BTW, some languages have structured documentation embedded in comments,
for example, texinfo used by octave, or xml-like by misc other
languages. What is the best way to provide in-comment indentation for
them? Is this something SMIE might support in future?

Thanks,
Leo

Re: emacs: are multi-char parentheses possible?

[Stefan Monnier]

> BTW, some languages have structured documentation embedded in comments,
> for example, texinfo used by octave, or xml-like by misc other
> languages.  What is the best way to provide in-comment indentation for
> them?  Is this something SMIE might support in future?

This is currently largely "unchartered territory".  I don't think SMIE
would be incompatible with it, but it would need some new
smie-indent-foo function in smie-indent-functions for that.


        Stefan

Re: emacs: are multi-char parentheses possible?

[Andreas Röhler]

On 10.06.2014 11:22, Leo Liu wrote:
> On 2014-06-09 22:21 -0400, Stefan Monnier wrote:
>> Maybe you "did something wrong" there, but SMIE normally tries to obey
>> the existing syntax tables (and syntax-table properties), so maybe you
>> saw a bug in SMIE.
>
> hmm, I can no longer find a recipe to reproduce the problem I was seeing
> where forward-sexp before << moved forward just one char.
>
> BTW, some languages have structured documentation embedded in comments,
> for example, texinfo used by octave, or xml-like by misc other
> languages. What is the best way to provide in-comment indentation for
> them? Is this something SMIE might support in future?
>
> Thanks,
> Leo
>
>

https://launchpad.net/s-x-emacs-werkstatt/+download

comes with a parser --in beg-end.el--, where in-comment detection of thing-at-point forms might be switched on.
 From there it should be possible to calculate indentation.

HTH,

Andreas

Re: emacs: are multi-char parentheses possible?

[Andreas Röhler]

On 09.06.2014 17:38, Stefan Monnier wrote:
>> Do you know if it is possible for Emacs to handle a pair of multi-char
>> parentheses?
>
> Yes, I do.  I also know the answer is not just a plain boolean.
>
>> Take << and >> for example,
>>
>> (setq-local syntax-propertize-function (syntax-propertize-rules
>>                                            ("\\(<\\)<" (1 "(>"))
>>                                            (">\\(>\\)" (1 ")<"))))
>>
>> show-paren-mode can highlight "<<" and ">>" but up-list aren't aware of
>> them.
>
> up-list should handle this just as well as show-paren and
> for/backward-sexp (and does, in my tests).
>
> Maybe you tried a "forward up-list" where the closing ">>" hadn't yet been
> syntax-propertized?
>
> This technique has some downsides, but in the case of << ... >> it might
> work well enough.
>
> For things like "begin...end" it's more annoying (e.g. backward word
> will stop right between the "b" and the "egin" and forward-word will
> stop right between "en" and "d").  For those, SMIE might be a better
> option (which uses hooks in show-paren and forward-sexp to try and make
> them do The Right Thing, tho the up-list case is only 90% working).
>
>
>          Stefan
>
>

With thingatpt you may specify arbitrary strings as delimiters.
Maybe that's an option in context also.

Andreas