all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Yuan Fu <casouri@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Theodor Thornhill <theo@thornhill.no>, emacs-devel@gnu.org, eliz@gnu.org
Subject: Re: Plug treesit.el into other emacs constructs
Date: Wed, 14 Dec 2022 00:14:12 -0800	[thread overview]
Message-ID: <4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com> (raw)
In-Reply-To: <jwvk02u99xn.fsf-monnier+emacs@gnu.org>



> On Dec 13, 2022, at 3:19 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>>>> I mean, what construct is each one expected to jump over?
>>> In my book "sexp" movement should jump over subtrees of the AST.
>> It’s pretty hard to judge which subtree to move over at a given point in an
>> AST. For example, when point is at | in the following text:
>> 
>> (|X.y(z), alpha)
>> 
>> Should point move over X, or X.y, or X.y(z)? All three subtrees has their
>> beg=(point).
> 
> Exactly.  It's even a bit worse: I'd also argue that an additional valid
> choice is to move over the whole "X.y(z), alpha".
> 
> The semantics I opted for in SMIE is to choose the smallest/deepest
> subtree.  That's what best matches the previous behavior of
> `forward-sexp`.  If the users want to move over larger units they have
> to place their point elsewhere (e.g. if it's just before ".", then
> moving over "y" wouldn't make sense because "y" is attached to "y(z)"
> and not to ".", only "y(z)" is attached to ".").

I would argue that the purpose of forward-sexp is to move over items in a list. Always going for the smallest subtree doesn’t seem to align with it. Take that example above, going across the smallest subtree means moving over X, then moving over “.”, that doesn’t feel like what forward-sexp should do to me. I think I'm misunderstanding what you mean.

> 
>> Just a thought, but maybe we can let major modes define what’s an “abstract
>> list”, and sexp-forward would move across the immediate children of abstract
>> lists. Eg, abstract lists in C would contain block, argument list,
>> statement, etc. And in the example above forward-sexp would move across
>> X.y(z) because it’s an immediate children of the enclosing abstract list,
>> the argument list.
> 
> Using the semantics I advocate, the user needs to place his point just
> to the left of `;` in order for `forward-sexp` to jump over the next
> instruction (or to the right of the `;` in order to jump over the
> previous instruction with `backward-sexp`).

You mean in the following code

int a = 0[1];
int b = 1;[2]

Forward-sexp would move [1] to [2]? But if we move over the smallest subtree, I’d imagine it only move across the semicolon after [1]. Even if it moves from [1] to [2], needing to adjust point feels very inconvenient to me, at least I wouldn’t want to use something like that. I want to type a single binding and move to where I want, and type that binding multiple times to move multiple steps. Both doesn’t seem to be possible with what you described.

Yuan




  reply	other threads:[~2022-12-14  8:14 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-12 14:33 Plug treesit.el into other emacs constructs Theodor Thornhill
2022-12-12 14:45 ` Eli Zaretskii
2022-12-13 18:17   ` Theodor Thornhill
2022-12-12 15:46 ` Stefan Monnier
2022-12-13 18:27   ` Theodor Thornhill
2022-12-13 19:37     ` Stefan Monnier
2022-12-13 19:53       ` Yuan Fu
2022-12-13 20:06         ` Perry Smith
2022-12-13 23:19         ` Stefan Monnier
2022-12-14  8:14           ` Yuan Fu [this message]
2022-12-14  8:42             ` Theodor Thornhill
2022-12-14 14:01             ` Stefan Monnier
2022-12-14 16:24               ` Theodor Thornhill
2022-12-14 17:46                 ` Stefan Monnier
2022-12-14 18:07                   ` Theodor Thornhill
2022-12-14 19:25                     ` Stefan Monnier
2022-12-14 19:35                       ` Stefan Monnier
2022-12-14 20:04                       ` Theodor Thornhill
2022-12-14 20:50                         ` Stefan Monnier
2022-12-14 21:15                           ` Theodor Thornhill
2022-12-14 21:34                             ` Stefan Monnier
2022-12-15 19:37                               ` Theodor Thornhill
2022-12-15 19:56                                 ` Stefan Monnier
2022-12-15 20:03                                   ` Theodor Thornhill
2022-12-15 20:33                                     ` Theodor Thornhill
2022-12-15 20:57                                       ` Theodor Thornhill
2022-12-24  7:00                                         ` Eli Zaretskii
2022-12-24  8:44                                           ` Yuan Fu
2022-12-24 14:01                                         ` Stefan Monnier
2022-12-24 14:15                                           ` Theodor Thornhill
2022-12-26 19:11                                             ` Theodor Thornhill
2022-12-26 22:46                                               ` Stefan Monnier
2022-12-26 22:51                                                 ` Stefan Monnier
2022-12-27 22:15                                                   ` Theodor Thornhill via Emacs development discussions.
2022-12-28  0:12                                                     ` Stefan Monnier
2022-12-28  9:26                                                       ` Theodor Thornhill via Emacs development discussions.
2022-12-28 18:01                                                         ` Stefan Monnier
2022-12-28 18:27                                                           ` Theodor Thornhill
2022-12-26 22:56                                                 ` Theodor Thornhill
2022-12-27 15:46                                   ` Lynn Winebarger
2022-12-14 23:31               ` Yuan Fu
2022-12-15  0:05                 ` Yuan Fu
2022-12-15  7:09                   ` Eli Zaretskii
2022-12-15  7:14                     ` Theodor Thornhill
2022-12-15  4:37                 ` Stefan Monnier
2022-12-15  5:59                 ` Theodor Thornhill
2022-12-15 21:23                   ` Yuan Fu
2022-12-15 21:28                     ` Theodor Thornhill
2022-12-13 20:02       ` Theodor Thornhill
2022-12-13 23:10         ` Stefan Monnier
2022-12-14 23:32   ` Stephen Leake
2022-12-16 10:02     ` Kévin Le Gouguec
2022-12-16 11:54       ` [SPAM UNSURE] " Stephen Leake
2022-12-17 15:30         ` Kévin Le Gouguec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E3940CA-67A6-45B7-8785-4E60FDECCDFB@gmail.com \
    --to=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.