Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request for support on indentation #31

Open
agladysh opened this issue May 12, 2012 · 11 comments
Open

Request for support on indentation #31

agladysh opened this issue May 12, 2012 · 11 comments

Comments

@agladysh
Copy link

Hi,

In our company we have relatively strict guidelines on Lua code formatting and several hundreds KLOC of existing code that follows them (so changing guidelines is not a good idea). I wonder, is lua-mode configurable to match our rules, or is it hard to be made flexible enough to be configurable.

You may find a bunch of code written according to our guidelines, for example, here: https://github.com/lua-nucleo/lua-nucleo/tree/master/lua-nucleo/. I believe that this indentation style is (mostly) not that uncommon.

Indentation rules in short:

  • tabs to spaces;
  • indent 2 spaces;
  • 80 chars max line width;
  • multi-line function arguments to be indented with two indents, closing parenthesis — with one (this, probably, is the uncommon part).

As an illustration, I prepared a naïve set of code (most likely incomplete, but will do as a start; if something more significant will be needed, I'll de-indent, say, a bunch of lua-nucleo files, that should cover most of the rules):

https://gist.github.com/37855303239506a16731

There is input, as typed (pasting it in console emacs works for me), expected output, and actual output with current lua-mode Git HEAD.

Unfortunately, we do not have any elisp gurus in-house, so we can't fix the problem ourselves. So I'm humbly asking for assistance. If this is something that is too large to be handled along the "public support" lines, I'll be happy to discuss sponshorship of one kind or another privately, please poke me via GH message.

Please note that we're not asking for a custom implementation of indentation code, but merely for the possibility to configure lua-mode to match our preferences.

Thank you in advance,
Alexander.

P.S. There was an year-old discussion on SO on that matter:

http://stackoverflow.com/questions/4643206/how-to-configure-indentation-in-emacs-lua-mode

I don't speak elisp, so for me that discussion resulted mostly in cargo-cult programming, with little effect.

@vhallac
Copy link
Contributor

vhallac commented Jun 16, 2012

It would have been great to be able to have an indentation configuration somewhat like the cc-mode, but the current state of affairs is nowhere near that. As you've said yourself, it is the last rule in your list that causes the biggest headache, and unfortunately, even with hacking the code, I don't see an easy way to fix this. I will think about either a quick fix, or a way to make things configurable, but so far, I've got nothing.

One possibility is generating a list of syntax entries instead of simply adding the indentation rules for the modifier in lua-make-indentation-info-pair (the relative and absolute settings), and then converting the entries to the relative and absolute symbols later. I am thinking on this on and off, but it needs to cook a little more in the backburner, I think.

Of course, if someone can get the semantics integration, or maybe even the SMIE indentation support (not sure if this is as good as the semantic mode), that would solve your problems, but I don't see us getting anywhere near that goal soon either.

@agladysh
Copy link
Author

So... any updates on this? :-)

@immerrr
Copy link
Owner

immerrr commented Mar 14, 2013

Hi, unfortunately, no.

But there's good news. I think I'm very close to implementing multiline constructs properly in terms of Emacs24 and the next thing on the list is the indentation engine.

@immerrr
Copy link
Owner

immerrr commented Mar 16, 2013

Hey, actually, todays bugfix for #26 (8d28342) might have fixed some of incompatibilities with your guidelines.

Three things I see now:

  • unindented block-close tokens should be in fact indented by different level
    • easy fix
  • table constructor in return statement is considered a "statement continuation" line and is indented
    • requires some tinkering, but doable
  • lambda-function args block is not unindented properly
    • this might be tough to do without nasty hacks

@immerrr
Copy link
Owner

immerrr commented Mar 16, 2013

unindented block-close tokens should be in fact indented by different level
easy fix

Made unindentation offset customizable in refactor_indentation branch.

@immerrr
Copy link
Owner

immerrr commented Mar 22, 2013

lambda-function args block is not unindented properly
this might be tough to do without nasty hacks

Done in ca39a4a. Two down, one to go.

@agladysh
Copy link
Author

Cool, thanks!

@agladysh
Copy link
Author

So, how is it doing? :-)

@immerrr
Copy link
Owner

immerrr commented Sep 20, 2013

Well, there's good news and there's bad news. :)

The bad news is that the issue remains: indentation engine needs a rewrite and with lua-mode remaining a hobby project it probably won't happen in nearest future. The good news is that I've finally added automatic tests infrastructure to the project and covering indentation corner cases with tests will facilitate the rewrite significantly.

@cigumo
Copy link

cigumo commented Oct 21, 2014

This is a comparison between version 20110428 and 20130419 indentation.
As you can see the anon function is properly indented in the old version, as the second if block and the third.

screen shot 2014-10-21 at 3 03 39 am

@Ambrevar
Copy link

Ambrevar commented Nov 7, 2014

I recently made a pull-request (#80) for a full indentation engine rewrite.
Indenting
https://gist.github.com/agladysh/37855303239506a16731
almost yield the expected result. Two differences:

  • Function parameters have one indent only.
  • The continuing lines.

But the point is not to adapt the engine to the taste of one user, but to make it customizable. My engine rewrite simplifies a great deal the previous version: only 3 functions play 3 distinct roles:

  • indent impact for current line
  • indent impact for next line
  • indentation of current line

It believe this is a saner basis to start from in term of indent customization.
A few variables can easily be added to control the work flow. For instance the continuing line indentation can be easily bo toggled off.

However the function parameters are a different matter as they require some semantic analysis. As far as I know, there is no Lua semantic analyzer for Emacs. Fortunately, Lua is easy to parse, but still, this would be quite some work. Plus semantic analysis is way slower than a 2-lines context indentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants