help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to make `forward-sexp` handle other balanced character-pairs suc


From: Thibaut Verron
Subject: Re: How to make `forward-sexp` handle other balanced character-pairs such as < and > or << and >> in erlang-mode or others?
Date: Mon, 27 Sep 2021 23:14:30 +0200

Hi,

Adding the characters to the syntax table is the canonical answer.
Maybe erlang-mode sets forward-sexp-function? This is typically done
to enhance the sexp movement beyond simple parentheses, for instance
for modes using SMIE.

If you (setq forward-sexp-function nil), does forward-sexp do what you want?

Best wishes,
Thibaut

Le lun. 27 sept. 2021 à 22:54, Pierre Rouleau <prouleau001@gmail.com> a écrit :
>
> Hi,
>
> I am trying to find an easy and efficient way to modify the behaviour of
> `forward-sexp` to handle
> balanced pairs of characters not normally supported by it, such as balanced
> `<` and `>` and
> balanced `<<` and `>>`.
>
> My specific case is to enhance the support of Erlang but I believe it could
> apply to a lot of scenarios.
>
> The implementation of `forward-sexp` allows the use of a
> `forward-sexp-function` which means I
> could implement such a function.
>
> However I was hoping to find a variable that the C-implemented `scan-sexp`
> could use to define
> the matching pair but have not succeeded so far.
> It would seem the easiest and most efficient way of implementing such
> handling of balanced pairs
> would be done there.
>
> I also tried to modify the syntax table the erlang-mode uses but although
> it matches all sorts of
> Unicode character pairs, I can't get forward-sexp to work with ?< and ?>.
>
> Is there a variable one can use to augment or modify the behaviour of
> `scan-sexp`?
>
> Or is forward-sexp meant to be limited to lisp-like syntaxes and I have to
> use another method
> (like SMIE or writing my own forward-sexp-function)?
>
> Thanks!
> --
> /Pierre



reply via email to

[Prev in Thread] Current Thread [Next in Thread]