bug#66159: 30.0.50; lua-ts-mode semantic indentation problems

[Philip Kaludercic]

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.