Add a way to ignore line length

[rob1gat]

First of all, thank you for this formatter !

We are currently studying the possibility of adding it to our project.

After a few tries with different parameters on the codebase, we came to the conclusion that it was better to disable line size forcing, because it would produce less readable code for some cases (for example, some function headers that would be spread over 5 lines instead of one because it was just a bit longer than the max line length).

In order to turn off the line length forcing, we set max_line_length to an absurd amount (1000). But it produced other unintended scenarios, for example a dictionary that was declared on several lines (one line per entry) was now inlined by the formatter.

Is there a way to tell to the formatter to not take care of the line length ? If not, would it be possible to add this as an option (as an additional parameter or by unsetting max_line_length or setting it to 0, for example)?

[NathanLovato]

Could you tell me more about what you're looking for? automatically format some cases but not others? Or something like controlling vertical wrapping manually across your codebase but get some basic inline formatting, like spaces around operators for example? The more concrete you can be, ideally with code examples, the better, I'd need that to assess the amount of work your request would require.

I can't promise anything as this is a free project I'm building in my spare time but I'll at least consider it.

To answer your questions, there's not a way to deactivate working with line length currently; the formatting logic itself is based on respecting the user's desired maximum line length. you can always make a program work in different modes, so everything's technically possible but it depends on how much work it takes and how many people need it (or if someone's willing to contribute and help with maintenance).

[rob1gat]

Thanks for your answer,

something like controlling vertical wrapping manually across your codebase but get some basic inline formatting, like spaces around operators for example

Yes, that is what we would like. To rephrase it, we want to let the formatter handle basic inline formatting, and we don't want the formatter to handle vertical wrapping because we want to handle it ourselves.

Here are some examples of issues we encountered. In these examples, max_line_length parameter is equal to its default value (100) :

Example 1 : function header spread on several lines

This method :

func pick_face_under_pos(x: int, y: int, sensitivity: int = 1, filter: PickFilter = null) -> PickResult:

Will be formatted like this :

func pick_face_under_pos(
    x: int,
    y: int,
    sensitivity: int = 1,
    filter: PickFilter = null,
)

The other function headers in the codebase are not spead this way so we are not used to read multiline fuction headers, so this one is frictionnal to read.

I would prefer to handle this case myself :

• Either I keep it on one line since this does not exceed too much the max line length (105 instead of 100)
• Or I spread it on two lines instead of one (with, for example, one line for x and y and another line for the optional parameters)

Example 2 : function call spread on several lines

This method call :

    var pick_result: PickResult = pick_face_under_pos(pos_x, pos_y, custom_sensitivity, cube_pick_filter)

Will be formatted like this :

    var pick_result: PickResult = pick_face_under_pos(
        pos_x, 
        pos_y, 
        custom_sensitivity, 
        cube_pick_filter
    )

When I scroll the code, I am more concerned about the flow of the code that concerns the scope that I am currently scrutinizing. In this example, I would prefer to have one line that reads like "I get a pick result", and then other lines that use this variable, instead of many lines that reads like "I get a pick result, using pos_x, and pos_y, and custom_sensitivity, and cube_pick_filter".

Example 3 : dictionary inlined

This dictionary :

func to_dict() -> Dictionary :
    return { 
        "id" : id, 
        "title" : title, 
        "creation_date" : creation_date, 
        "last_date" : last_date
    }

Will be formatted as :

func to_dict() -> Dictionary :
    return { "id" : id, "title" : title, "creation_date" : creation_date, "last_date" : last_date }

In this specific example, I would like to keep each value on one line because I have another method set_from_dict() that looks like :

	func set_from_dict(dict: Dictionary) -> void:
		id = dict.id
		title = dict.title 
		creation_date = dict.creation_date
		last_date = dict.last_date

Since the methods are related, it is important that they read the same way.

Example 4 : constant array

If I declare this constant :

const CUBE_EDGE_CORNERS: Array[Vector2i] = [
	Vector2i(0, 1), Vector2i(0, 2), Vector2i(0, 4),
	Vector2i(5, 4), Vector2i(5, 1), Vector2i(5, 7),
	Vector2i(6, 7), Vector2i(6, 4), Vector2i(6, 2),
	Vector2i(3, 2), Vector2i(3, 7), Vector2i(3, 1),
]

It will be reformatted like this :

const CUBE_EDGE_CORNERS: Array[Vector2i] = [
    Vector2i(0, 1), 
    Vector2i(0, 2), 
    Vector2i(0, 4),
	Vector2i(5, 4), 
    Vector2i(5, 1), 
    Vector2i(5, 7),
	Vector2i(6, 7), 
    Vector2i(6, 4), 
    Vector2i(6, 2),
	Vector2i(3, 2), 
    Vector2i(3, 7), 
    Vector2i(3, 1),
]

Sometimes we need to adjust the number of items per line to enhance readability. In this example, it is more readable for us to have one line for each x component value.

Conclusion

• Keep in mind that these examples are inspired by our codebase but they are crafted to illustrate our issues. I know that in these specific examples, some alternative solutions could be applied (for example : reduce name sizes to keep line length under 100)
• In the 4th example, it is completely ok to add # fmt comments, but in the other ones this would alter the reading flow
• In the 3rd example, it is better to spread the dictionary on several lines, but sometimes it is better to keep it on one line, it depends on the context
• Each of these cases should be handled with the solution that offers the most readability. This is not systematically the same solution each time. Since godot editor offers easy way to keep an eye on the line length, we stated that this was more appropriate to handle line length ourselves than giving this responsability to the formatter

[NathanLovato]

Thank you. I see. I see, actually the previous the implementation of the formatter may have been closer to what you were looking for, although it had some limitations with the quality of the formatting it could produce.

It would take hints from the input: if you kept everything on one line it would keep everything on one line and if you added a line return anywhere in an expression or statement that could wrap over multiple lines, it would then lay them vertically.

E.g. if you had this in the input:

return { "id" : id, "title" : title, "creation_date" : creation_date, "last_date" : last_date }

It would stay this way but if you had this in the input (or any line return anywhere in the dictionary):

return {
    "id" : id, "title" : title, "creation_date" : creation_date, "last_date" : last_date }

It would format the dictionary like this:

return { 
    "id" : id, 
    "title" : title, 
    "creation_date" : creation_date, 
    "last_date" : last_date
}

And keep it that way unless you decided to remove all the line returns. What do you think of a solution like this? It still gives you manual control but also some automation.

Note: For one of the cases, arranging data structures in a certain way, this is something I'd like to implement at some point no matter what because this is a definitive case where easy control over the output layout would be helpful to everyone.

For example, in this case, the formator would count how many values you want on the first line (3):

const CUBE_EDGE_CORNERS: Array[Vector2i] = [
	Vector2i(0, 1), Vector2i(0, 2), Vector2i(0, 4),
	Vector2i(5, 4),
Vector2i(5, 1),
Vector2i(5, 7),
Vector2i(6, 7),
Vector2i(6, 4),
Vector2i(6, 2),
Vector2i(3, 2),
Vector2i(3, 7),
Vector2i(3, 1),
]

And format as you had it in your example:

const CUBE_EDGE_CORNERS: Array[Vector2i] = [
	Vector2i(0, 1), Vector2i(0, 2), Vector2i(0, 4),
	Vector2i(5, 4), Vector2i(5, 1), Vector2i(5, 7),
	Vector2i(6, 7), Vector2i(6, 4), Vector2i(6, 2),
	Vector2i(3, 2), Vector2i(3, 7), Vector2i(3, 1),
]

That is something I'd really like to have in a future update.

For the rest I have to see how much work it would take to provide and maintain this different formatting mode, and how many people would use or at least want it.

One thing I can say is this is not something that will be immediately available as this is a project I build and maintain in my spare time so it probably won't work for you for your current project, unless you find a line length setting that works well enough for you, like allowing up to 120 or 140 characters.

---

Note for self on what it would take: we could record as part of the intermediate representation special line breaks that indicate the group or structure had newlines. We could introduce a formatting mode that would optionally ignore all the soft lines, but rather use these special line breaks as formatting hints or preserve them as is.

[rob1gat]

Hello, thanks for your detailed answer and sorry for the delay.

What do you think of a solution like this? It still gives you manual control but also some automation.

We discussed about it with the team and the consensus is that we would prefer an option to deactivate line length handling. If you take the example 1 in my previous post, sometimes we would prefer to split the function header in 2 lines.

Note: For one of the cases, arranging data structures in a certain way, this is something I'd like to implement at some point no matter what because this is a definitive case where easy control over the output layout would be helpful to everyone.

This looks like a good solution, I don't see any such case where the number of items per line can vary.