bug#62086: 29.0.60; ruby-ts-mode regressions

[Yuan Fu]

> On Apr 12, 2023, at 1:13 PM, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
> On 12/04/2023 18:31, Dmitry Gutov wrote:
>> On 12/04/2023 10:05, Yuan Fu wrote:
>>> Actually, would it make sense to define sexp as “anything but some very 
>>> small punctuation and delimiters”?
>> Pretty much. If I understood you correctly.
>> E.g. in ruby-ts-mode identifiers and numbers are also sexps.
> 
> Allow me to update that.
> 
> From the previous threads, for ruby-ts-mode at least, we seem to have 
> concluded that it's best to treat those nodes as sexps which have visible 
> boundaries that are visible and don't overlay exactly the boundaries of the 
> contained nodes.
> 
> For example, we now exclude statement nodes and binary expression nodes 
> because both make forward/backward-sexp less obvious and predictable: you 
> move point to the beginning of 'a + b', press C-M-f, and if the jump happens 
> over the whole expression, this is just as likely to mismatch the user's 
> intention (which might have wanted to only jump over 'a'). So these are the 
> node we rule out.

User might as well want to move over the whole expression, since they can use 
forward-word if they want to move over smaller elements. But I guess that’s 
just personal preferences.

> The easiest choice would be to go back to treating only 
> braces/brackets/parens are sexp delimiters, but in Ruby, at least, we have 
> lots of constructs that are delimited with keywords (such as 'if', 'def', 
> 'end'), so that doesn't work. Maybe it'll work better in C/C++, where you 
> mostly need to be able to differentiate between different types of angle 
> brackets.

To clarify, my point is to define sexp by exclusion rather than inclusion, ie, 
defining a set of nodes that are not sexp, rather than defining a set of nodes 
that are sexp. I mentioned delimiters because they are excluded from sexp, not 
because they delimit sexp.

Yuan