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

Add option for formatting with spaces between function names and arguments #839

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

alerque
Copy link
Contributor

@alerque alerque commented Dec 23, 2023

Closes #832

So far just some CLI options and tests. Work on implementation pending feedback in issue. All options implemented and tested.

@alerque
Copy link
Contributor Author

alerque commented Jun 28, 2024

I'm using this in production including setting the config option it introduces all over the place. The results are what I want to see. If the implementation here isn't the best way to do it or needs adjusting to be included I'm happy to adapt, but it would be nice if this could get upstreamed so I don't have to push by fork of StyLua on anybody contributing to my Lua projects ;-)

@JohnnyMorganz
Copy link
Owner

I think I'm going to get some movement on #854 this weekend (which I want to merge before next release) so I also hope to review this too. Sorry for the wait!

@alerque
Copy link
Contributor Author

alerque commented Jun 28, 2024

Sure fair enough. From an implementation standpoint there are probably better ways to do this (I was quite unfamiliar with the code base) even with the current parser, and improved full-moon interfaces may open up even better ways. From the perspective of the end user feature introduction the two important parts are the name of the new config option key and values paired with their respective expected test outputs. Everything in between is implementation details that could be refactored at any time.

Personally I'm only interested in the SpaceAfterFunctions:::Definitions option here, but besides Always and Never I also went ahead and implemented the Calls variant because I've seen code bases that use that. The default is of course Never so as not to cause churn in existing users.

Copy link
Owner

@JohnnyMorganz JohnnyMorganz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation itself looks good to me, thank you!

the name of the new config option key and values paired with their respective expected test outputs

I'm trying to think if the key name is complete descriptive of what is actually happening here for someone with no context. The space isn't really after the function, so maybe it should be space_in_functions or space_in_functions_before_parentheses. Not sure though, naming is always hard.

@@ -1158,7 1165,8 @@ pub fn format_function_declaration(
shape
)
.update_leading_trivia(FormatTriviaType::Append(leading_trivia));
let formatted_function_name = format_function_name(ctx, function_declaration.name(), shape);
let formatted_function_name = format_function_name(ctx, function_declaration.name(), shape)
.update_trailing_trivia(FormatTriviaType::Append(function_definition_trivia));

let shape = shape (9 strip_trivia(&formatted_function_name).to_string().len()); // 9 = "function "
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A point worth mentioning is that our "shape" calculation here (and potentially elsewhere) will not take into account the fact that a space was added after the function name (since we explicitly strip the trivia afterwards). Shape is used to store the amount of line budget used so far and how many characters we have left on a line. This opens up a very small edge case where the definition line now hits column_width 1 characters because of the space, but shape only sees column_width and therefore we don't reformat correctly. It's quite a minor edge case though, unsure if it is worth rectifying until someone brings it up

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be happy to fix the edge case if I had any idea where/how, but I wasn't actually that clear on the internals of how that was being done or where extra info should be passed to get it back. Given what you say here I'm guessing the same edge case might exist for some other scenarios unrelated to this PR, no?

README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
@alerque
Copy link
Contributor Author

alerque commented Aug 11, 2024

Implementation itself looks good to me, thank you!

the name of the new config option key and values paired with their respective expected test outputs

I'm trying to think if the key name is complete descriptive of what is actually happening here for someone with no context. The space isn't really after the function, so maybe it should be space_in_functions or space_in_functions_before_parentheses. Not sure though, naming is always hard.

Yes naming is hard. I'm happy to refactor this to another name if you think it best, but I'm not convinced there are better options. Actually instead of space_after_functions the more correct name might be space_after_function_names. It just seems wordy.

I don't like space_in_functions or space_in_function_before_parenthesis because both suggest a different location entirely in my mind.

@alerque
Copy link
Contributor Author

alerque commented Aug 11, 2024

The lint error seems to be unrelated to this PR and more related to a new Rust version. In fact it might even be a false positive for the new lint, I know there was some talk of false positives in new docstring lints. I haven't looked into whether this is one of them, but it seems that should be in a separate PR anywhere.

@alerque
Copy link
Contributor Author

alerque commented Aug 15, 2024

The force-push just now was to add a missed bit to override the configs if CLI arguments were present. The option was working from config (or editor config) and accepted from the CLI but silently ignored.

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

Successfully merging this pull request may close these issues.

Add option to add spaces in function definitions
2 participants