From: Philip Kaludercic <philipk@posteo.net>
To: john muhl <jm@pub.pink>
Cc: Andrey Listopadov <andreyorst@gmail.com>,
66159@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#66159: 30.0.50; lua-ts-mode semantic indentation problems
Date: Sat, 30 Sep 2023 07:52:34 +0000 [thread overview]
Message-ID: <8734ywkshp.fsf@posteo.net> (raw)
In-Reply-To: <87il7z5g3g.fsf@pub.pink> (john muhl's message of "Sun, 24 Sep 2023 13:20:23 -0500")
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.
>
> Andrey Listopadov <andreyorst@gmail.com> writes:
>
>> Thanks! The patch seems to work as I would expect for most cases.
>>
>>> 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.
>>
>> 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.
>
>>> Sure. It's a new mode so nothing is really set in stone. Let me know if
>>> you have other suggestions.
>>
>> I also noticed that `lua-ts-inferior-lua` for some reason starts itself
>> in a new frame instead of just a new window. I haven't seen this
>> behavior with other inferior-*-modes, and the `lua-start-process'
>> function from `lua-mode' doesn't spawn a new frame either.
>>
>> Looking at the code, it seems that it was a deliberate choice, as I see
>> the use of `display-buffer-pop-up-frame' in the `display-buffer' ACTION
>> arg.
>
> It did use a window originally but I was asked to change it:
>
>>> + (pop-to-buffer buffer)))
>>
>> I believe that `display-buffer-pop-up-frame' is the preferred alternative
>> to `pop-to-buffer' these days.
>
> Maybe I misunderstood and it was only about not using ‘pop-to-buffer’
> and should have been ‘display-buffer-pop-up-window’. CC’d Philip for
> clarification.
Yes, you are right, I meant `display-buffer-pop-up-window'.
> If you customize where you want it with ‘display-buffer-alist’ that
> should be respected.
next prev parent reply other threads:[~2023-09-30 7:52 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
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 [this message]
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=8734ywkshp.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=66159@debbugs.gnu.org \
--cc=andreyorst@gmail.com \
--cc=eliz@gnu.org \
--cc=jm@pub.pink \
/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).