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

max_line_length is not specified #25

Open
eirnym opened this issue Apr 26, 2021 · 15 comments
Open

max_line_length is not specified #25

eirnym opened this issue Apr 26, 2021 · 15 comments

Comments

@eirnym
Copy link

eirnym commented Apr 26, 2021

max_line_length is used in this repo, in various plugins and core. Is there any reason why this specification doesn't describe it?

@cxw42
Copy link
Member

cxw42 commented May 1, 2021

Thanks for pointing that out! It looks like editorconfig/editorconfig#280 may need to be resolved before we update the specification.

@eirnym
Copy link
Author

eirnym commented May 1, 2021

This attribute as similar attributes in various editors and style checkers generates a warning, nagging users to fix them. Not an error

@eirnym
Copy link
Author

eirnym commented May 1, 2021

I don't see that issue as a blocker. You can take it from PEP-8 if you want a good definition.

@eirnym
Copy link
Author

eirnym commented May 1, 2021

@cxw42 don't see why an implementation is a reason to remove the definition, but not revise it.
I don't see any reason why this question was postponed for all these years and the only solution was to remove this attribute from specification.

@cxw42
Copy link
Member

cxw42 commented May 2, 2021

@eirnym I would like to understand your use case. How is the lack of specification of this property affecting you?

Many things about the project are as they are simply for lack of time to work on them :( .

@eirnym
Copy link
Author

eirnym commented May 2, 2021

I use various editors and tools supporting editor config including but not limited to: IntelliJ idea, vim, kLint, Visual Studio Code, black and others

All these implementations have support of this attribute and links to the specification. I also take this attribute few years ago to my own configuration as well.

And now I see that because of a single rogue implementation, you remove specification entirely instead of changing it to more permissive.

I don't understand the reasoning behind removal as fixing spec or even asking for better words for it is much simpler than remove spec and break all software relies on it.

@xuhdev
Copy link
Member

xuhdev commented May 2, 2021

I agree that we should move forward with this property. Not all editors will interpret it as exactly the same meaning, but so do the others (e.g., editors differ when to apply full indent, half indent, etc.). As long as editors can reasonably interpret max_line_length as some soft wrap limit, I think we should add that to the specification.

@eirnym
Copy link
Author

eirnym commented May 2, 2021

Also kLint adds off value to turn off the check

@cxw42
Copy link
Member

cxw42 commented May 2, 2021

@eirnym I'm sorry you're having a frustrating time.

because of a single rogue implementation, you remove specification entirely

Would you please link to the issue, commit, or PR that did this? I don't know what you're referring to.

In my opinion such decisions or not involving and not asking community could lead that people give up on software

I am sure you meant this constructively. However, it sounded to me like a bit of a threat. Would you please be more careful in the future with this kind of statement? As far as I know, we all have the same goal: to make our computers work the way we want them to :) . Thanks!

@eirnym
Copy link
Author

eirnym commented May 3, 2021

Would you please link to the issue, commit, or PR that did this? I don't know what you're referring to.

Sorry I misread about that. I thought that it was implemented this way.

Any implementation I used threat this parameter as column after which a tool warns a user.

@eirnym
Copy link
Author

eirnym commented May 3, 2021

I am sure you meant this constructively. However, it sounded to me like a bit of a threat. Would you please be more careful in the future with this kind of statement?

Yes, this never meant to be anything like that. Removed this part.

@cxw42
Copy link
Member

cxw42 commented May 4, 2021

@eirnym Thanks very much for the edit :) 👍

I looked back through the repo history --- it looks like it was never documented! :) I think that's why it's missing. This should be a fairly easy fix. You are correct that it has been in use for a long time.

@eirnym
Copy link
Author

eirnym commented May 4, 2021

Ha! I've read about it on the main site as far as I remember… or in plugin for Vim

@anguslees
Copy link

How is the lack of specification of this property affecting you?

I came here looking to create this bug if it didn't exist: It seems perverse that the .editorconfig file in the editorconfig specification uses options that are not part of the editorconfig specification. As someone new to editorconfig, I remain confused about what the possible editorconfig properties actually are.

@florianb
Copy link
Member

Thank you very much for your statements @anguslees!

I will try to enlighten the "perversion" for you: the EditorConfig exists longer than the specification, which is an attempt to make the description of the properties more explicit for implementers.

max_line_length is described in the wiki: https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#max_line_length

As one might guess it is not the easiest thing to make a grown property explicit which was formerly widely interpreted and to consider the resulting work for all these dependent contributors implementing EditorConfig for all those different technologies.

The discussion of the issues with a max_line_length definition is found in the following issue, as commented above:

Thanks for pointing that out! It looks like editorconfig/editorconfig#280 may need to be resolved before we update the specification.

I understand your frustration and while i am happy with deciding stuff this project affects thousands of developers and i really don't want them come after me after a change went unexpected. I experienced that in other projects i maintained before.

But i will try to accelerate that process.

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