unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrey Listopadov <andreyorst@gmail.com>
To: john muhl <jm@pub.pink>
Cc: 66159@debbugs.gnu.org, Philip Kaludercic <philipk@posteo.net>,
	Eli Zaretskii <eliz@gnu.org>
Subject: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Tue, 26 Sep 2023 22:21:35 +0300	[thread overview]
Message-ID: <87lecs4ttm.fsf@gmail.com> (raw)
In-Reply-To: <87il7z5g3g.fsf@pub.pink>


john muhl <jm@pub.pink> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > Another thing that bothers me is that I prefer Gassanenko-style packing
>>> > of `end' keywords so that they vertically align with the scope of the
>>> > opened block, as it saves so much vertical space and is easier for me to
>>> > read, but lua-ts-mode moves it to the latest innermost indentation
>>> > level, as opposed to the outermost depending on the count of ends in the
>>> > line itself:
>>>
>>> I don't see any reason not to support that style but I'm not sure how to
>>> do it. A patch would be welcome but I'll try to figure it out sometime.
>>
>> Maybe introduce indentation styles into lua-ts-mode, like CC Mode and
>> c-ts-mode have?
>
> I’ll have a look at what the c-ts-mode styles do and see what might be
> applicable. In this case the changes can be accommodated by default.

In my opinion, this isn't distinct enough to introduce a new style.
But it's up to you to decide, of course - I'm all for better editing
experience for Lua!

>> A far as I understand it, in the `lua-mode' the overall line indentation
>> is computed via subtracting indentation for every `end' in that line,
>> e.g. `end end end' subtracts `lua-indent-level three times from current
>> indent level.
>
> Thanks for the explanation. The attached patch should make end packing
> work now.

I've tried your latest patch and indeed `end' now pack themselves as in
the lua-mode.  Thank you very much!

>>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>>> you have other suggestions.

I noticed that the `do' keyword is indented similarly to `then' before
the patch when put on the new line:

for i=1,10
    do
    print(i)
end

I'm not sure if that's a proper way to indent it or not though, but `do'
usually signifies start of the scope, so perhaps it shouldn't be
indented in this case.

There are also some weirdness in semantic navigation, but it's more
likely that I'm just not used to new ts-backed navigation yet.

Thanks for your work on lua-ts-mode, it's much more snappy editing
experience now!

If you're willing to dig into some (pretty crazy) involved examples, I
can send here some really convoluted nested anonymous functions that
currently are indented in a weird way in both modes. Neither does it
exactly right in my opiion, but I also don't know if there is the right
way to indent this.  I can send these examples later this week once I
finish an article I'm working on rightnow.

--
Andrey Listopadov





  reply	other threads:[~2023-09-26 19:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-22 19:17 bug#66159: 30.0.50; lua-ts-mode semantic indentation problems Andrey Listopadov
2023-09-22 19:49 ` Eli Zaretskii
2023-09-24 15:06 ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-24 15:44   ` Eli Zaretskii
2023-09-24 16:38   ` Andrey Listopadov
2023-09-24 18:20     ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-26 19:21       ` Andrey Listopadov [this message]
2023-09-27  1:18         ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-30  9:59           ` Andrey Listopadov
2023-09-30 13:57             ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 15:04               ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 19:13                 ` Andrey Listopadov
2023-09-30  7:52       ` Philip Kaludercic
2023-10-06 19:44 ` bug#66159: [PATCH] Various improvements to lua-ts-mode (Bug#66159) john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 10:11   ` Mauro Aranda
2023-10-07 16:15   ` Andrey Listopadov
2023-10-07 18:10     ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-08  9:43       ` Andrey Listopadov
2023-10-09  3:28         ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-17  3:26           ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-20 20:40             ` Stefan Kangas
2023-10-22 20:03               ` john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-23  8:11                 ` Stefan Kangas
2023-10-21  5:15             ` Andrey
2023-10-21 11:37             ` Andrey

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=87lecs4ttm.fsf@gmail.com \
    --to=andreyorst@gmail.com \
    --cc=66159@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jm@pub.pink \
    --cc=philipk@posteo.net \
    /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).