GNU bug report logs - #73404
30.0.50; [forward/kill/etc]-sexp commands do not behave as expected in tree-sitter modes

Previous Next

Full log

Message #217 received at 73404 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: Eli Zaretskii <eliz <at> gnu.org>, mickey <at> masteringemacs.org, casouri <at> gmail.com,
 monnier <at> iro.umontreal.ca, 73404 <at> debbugs.gnu.org
Subject: Re: bug#73404: 30.0.50; [forward/kill/etc]-sexp commands do not
 behave as expected in tree-sitter modes
Date: Mon, 06 Jan 2025 09:54:49 +0200

> However, deciding on what makes sense is hard, which is why I'm
> suggesting we try to define a "spec". It needn't really be much more
> than reference suggestions for mode implementors at first, then maybe
> some intersection of features crystallize across all modes.

I don't think it's possible to find a spec better than Stefan already
defined as an AST node delimited by an opening and a closing "keyword":
(...), [...], if...fi, begin...end, ...

>> Indeed, sentences and paragraphs are even more fuzzy concepts when applied
>> to programming languages.  But some modes make sense of these things
>> nevertheless.  For example, in both c-mode and c-ts-mode 'M-e'
>> moves to the end of statement that usually end with a semicolon;
>> so your intuition about these things looks correct.
>
> Yes, but imo more importantly, disregarding any confusing naming we have
> a very rich set of operations available to us that I think should be as
> distinct as possible:
>
> - C-M-f
> - M-f
> - M-a
> - M-e
> - C-f
> - C-a
> - C-e
> - more

Or when looking at the commands with the 'forward-' prefix:

  forward-list (C-M-n)
  forward-page (C-x ])
  forward-paragraph (M-})
  forward-sentence (M-e)
  forward-sexp (C-M-f)
  forward-symbol
  forward-word (M-f)

Interesting that a potentially useful 'forward-symbol' has no binding.

> If we'll aim to get the absolute most out of the parse tree
> possibilities we should strive to make these distinct, at least down the
> line. Some of these are simpler to categorize than others, such as a
> sentence meaning "some expression that ends that isn't a function or a
> class definition".

In languages with statements a sentence corresponds to a statement.
Then a paragraph is a less useful concept since a group of statements
compose a block that corresponds to a list, not a paragraph.  Then
probably the definition of a paragraph should remain as a group of lines
separated by empty lines.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.