unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Mickey Petersen <mickey@masteringemacs.org>
To: Theodor Thornhill <theo@thornhill.no>
Cc: 60655@debbugs.gnu.org
Subject: bug#60655: 30.0.50; tree-sitter: `treesit-transpose-sexps' is broken.
Date: Mon, 09 Jan 2023 08:48:04 +0000	[thread overview]
Message-ID: <878ricjdee.fsf@masteringemacs.org> (raw)
In-Reply-To: <87sfgkgqlj.fsf@thornhill.no>


Theodor Thornhill <theo@thornhill.no> writes:

> Mickey Petersen <mickey@masteringemacs.org> > The tree-sitter-enabled
> function, `treesit-transpose-sexps', that is called by
> transpose-sexps, is broken.
>>
>> It uses a naive method of sibling adjacency to determine
>> transpositions. But it is unfortunately not correct.
>>
>> Python:
>>
>>
>>   def -!-foo():
>>       pass
>>
>> Turns into this with `C-M-t':
>>
>>   def ()foo:
>>       pass
>>
>> But it ought to be:
>>
>>   foo def():
>>       pass
>>
>>
>> It's swapping two siblings that are indeed adjacent in the tree, but
>> not on screen, which is confusing and a regression from its previous
>> behaviour.
>>
>
> I can try to make transpose-sexps rely on only swapping "allowed"
> node-types?  That would be able to keep the new, better function, yet
> still disallow these syntax-breaking transposes.  What do you think?
>

This is a hard problem. I'm building the self-same in Combobulate, so
when I saw this implementation I saw a well-trodden path by myself.
There's a lot of subtlety to it, and it is not immediately possible to
accurately gauge the right things to swap with simple (or not so
simple) sibling transpositions.

Using a defined list is better, but with the caveat that it requires manual
intervention per mode. This is a really tricky thing to build well.



>> You could make a cogent argument that both approaches are wrong from a
>> syntactic perspective, but I think that misses the broader point that
>> `C-M-t' now does something errant and unexpected.
>
> I don't really see how "foo def():" is any better at all.  We gain some
> great improvements with this "naive" method - namely:
>
> if 5 + 5 == 10 then 10 else 100 + 100.  If point is on the else the 100
> + 100 wil be swapped by 10, but the old behavior will be broken.
>

The old behaviour was consistent. It had a simple *modus operandi*:
swap two things around point. As someone who has used `C-M-t' for
decades, I know what it'll do in pretty much all situations, because I
know what `C-M-k` and `C-M-f/b` do at all times.

Neither approach is great if you holistically approach this task as
"making it correct at all times", and it is easy to confect scenarios
that result in something that is semantically wrong, but syntactically
correct; something that is plain wrong, both semantically and
syntactically; and something that is occasionally correct.

'Like' siblings are an easy way out of this mess with the caveat, as
you'll see, but now you need to carefully pluck the right nodes from
the tree!

Consider the node type `pair' in a dict in Python. They are easily transposable for
that very reason, notwithstanding the anonymous "," node betwixt them.

That is why Combobulate has a list of stuff that it can safely
transpose, and for everything else it defaults to the "classic"
transpose.

>>
>> Worse, it's not possible to revert to the old behaviour (see
>> bug#60654)
>>
>>

Thanks for fixing that!

Kind regards,

Mickey.

>
> Right.
>
> Thanks,
> Theo






  reply	other threads:[~2023-01-09  8:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08 10:53 bug#60655: 30.0.50; tree-sitter: `treesit-transpose-sexps' is broken Mickey Petersen
2023-01-09  6:38 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-09  8:48   ` Mickey Petersen [this message]
2023-01-09 12:29     ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-09 12:30       ` Mickey Petersen
2023-01-09 13:37         ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-12-30 18:22 ` Juri Linkov
2025-01-04 18:30   ` Juri Linkov

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=878ricjdee.fsf@masteringemacs.org \
    --to=mickey@masteringemacs.org \
    --cc=60655@debbugs.gnu.org \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).