26 Space indent

[ghost]

Calling a function that takes a table as an argument, then putting the table contents on a new line indents to 26 spaces which is ridiculous.

minetest.register_node("mod:node", {
                          description = "Node",
                          tiles = {
                             "mod_node.png",
                          },
})

I have

(setq-default indent-tabs-mode nil)
(setq c-basic-offset 4)
(setq-default tab-width 4)
(setq indent-line-function 'insert-tab)
(setq lua-indent-level 4)

set in my config as well.

[meltinglava]

This is emacs that indents. if you make a newline after first ( it indent to what you have set it to.

[marioidival]

[kidd]

I think the busted example @marioidival shows is the most critical because there's no way to reformat it in a way that looks "good".

I've had a quick look at the relevant code and couldn't find a fix for the (trying the solutions recommended in this stackoverflow thread .

Is there any hack that at least we could use for the very concrete cases so that lines like description(...,function() indent 2 spaces from the beginning of the line?

[kidd]

I wrote some elisp to solve my busted use case. Maybe others can adapt it for their use cases.

Alert: huge hack.
http://puntoblogspot.blogspot.com.es/2018/03/fixing-indentation-of-lua-busted-in.html

[codyloyd]

I'm experiencing this issue as well. I guess that aligning the contents of an anonymous function makes a bit of sense in some contexts, but I really dislike it, and especially with highly nested functions like you get when using Busted this creates some super weird looking code.

The above hack posted by @kidd fixes the issue. (so thanks!) But IMO having a way to toggle this behavior would be ideal.

[kidd]

Another advice I added since then is the following one:

(defun rgc-lua-at-most-one-indent (old-function &rest arguments)
  (let ((old-res (apply old-function arguments)))
    (if (> old-res 2) 2 old-res)))

(advice-add #'lua-calculate-indentation-block-modifier
            :around #'rgc-lua-at-most-one-indent)

This keeps indentation at max of 2 spaces when indenting "nested opened blocks". IIRC that's for cases like:

foo({
  this=1,
  that=2
})

[kidd]

Adding a link to some relevant development in a PR #151

[immerrr]

Hey, sorry, this issue flew under the radar for so long.

I think there were similar issues in the past, but just to recap. As you might have discovered this is related to alignment being applied before the indentation:

minetest.register_node("mod:node", {
                          description = "Node",
                          tiles = {
                             "mod_node.png",
                          },
})

The issue here is that lua-mode accumulates all "offset-changing signals", and there are two such signals. One is alignment:

                    -- v-- next line after should be aligned to this column ...
minetest.register_node("mod:node",
                       "foobar")   -- .. like this

and the second one is the indentation:

                                -- v-- next line should be indented by one more offset ...
minetest.register_node("mod:node", {

Of course, there are different approaches to handling these. The one that got implemented in lua-mode way back is to apply both, so first align to the first column of the first argument, and then to indent on top of that. Sometimes it does not look nice, but it is consistent in a sense that the "dedents" for each closer are still nested thus maintaining the structure:

minetest.register_node("mod:node", {
|                      | "foo",
|                      | "bar",
|                      | ..,
|                      }
)

There's a competing and more widely accepted approach : to only take the last "offset-changing signal" per line, and disregard the rest:

                    -- ,-- this can be ignored ...
                    -- |           ,-- this is ignored as well ...
                    -- v           v    v -- only this should affect the offset of the following line
minetest.register_node("mod:node", {foo={
  "foo",
  "bar",
    ..,
}})

Note that if you for some reason need to break the table closing brace from the function-call closing parenthesis, both would dedent to the same level, somewhat losing the structure:

    ..,
}
}
)

The common "fix" for this is to ensure that they are never separated and if you have more arguments to follow, then you put the table on the following line:

minetest.register_node(
  "mod:node",
  {foo={
    "foo",
    "bar",
    ..,
  }},
  "something else"
)

There are of course more approaches, like for example gofmt that does not do alignment at all:

<tab>fmt.Println("Hello, playground",
<tab><tab>"nice to see you",
<tab>)

With this I am not trying to say that one approach is better than the other, but I would also refrain from calling one or the other "busted" :)

I am all for having independent toggles for

a) only applying the last offset-changer per line
b) disabling alignment for nested arguments/elements

provided that

• the default behaviour stays the same
• some tests are added displaying both the old and the new behaviour (here's an example)

Admittedly, I don't have much time or energy to do it myself, but I'm happy to help out with a PR if necessary and ultimately merge it. #151 is a big step in the right direction, it just lacks a couple of tests.

[immerrr]

Thanks to @edam and his PR #151, it should now be possible to tweak auto-indentation behaviour with:

• lua-indent-nested-block-content-align (default t) set to nil to stop aligning the content of nested blocks with the open parenthesis
• lua-indent-close-paren-align (default t) set to t to align close parenthesis with the open parenthesis rather than with the beginning of the line

Setting both to nil would enable auto-indentation like this:

foo('bar', {
    'baz',
    'qux',
})

You still get double indents for the inside table, but there is no more alignment for its contents.

And I'll see if I can adapt the snippet from #132 (comment) to another config parameter.

[mikezackles]

And I'll see if I can adapt the snippet from #132 (comment) to another config parameter.

I ran into this today. The advice-add approach seems to work well enough, but another parameter would be nice.