Add autocorrections

[bogdan]

Most of haml-lint concerns are too minor to be fixed manually, especially if applied to existing code base.
Please introduces the autocorrect at least for the following easy to fix rules:

• SpaceInsideHashAttributes
• ConsecutiveSilentScripts
• TrailingEmptyLines
• TrailingWhitespace
• LeadingCommentSpace

[MaxLap]

That's a pretty strong case of "do (more) work for me for free". Maybe it's a barrier of language thing, but that phrasing really feels like it.

[bogdan]

Sorry, I didn't mean to offend you. This is how people sometimes frame their requests in my open source repos and I mostly agree because I enjoy helping people by doing things I enjoy to do.
I think "I do more work for you for free" is a principle many open source authors follow. At least I do and met many others who do.

[MaxLap]

I'm not offended, I found it a bit funny. Asking for features can be fine. The way of asking can change the tone dramatically.

"please do X" is a polite tone that a boss uses to essentially give an order to an employee.

"at least for" makes it sound like that's the least the person could do. Like it would be unreasonable not to.

Again, maybe just a barrier of language thing. It's not my repo, i just saw the ticket and felt I had to push back a little.

[wilfison]

@bogdan I don't know if you use VS Code, but I created an extension for HAML that automatically corrects some offenses. Search in the extensions section for "HAML - All in One".

[maddieholtzer]

If I'm not mistaken, while cool, this would be a massssssive amount of work? I remember following the Rubocop autocorrection saga (thank you so much @MaxLap this feature has saved me and my coworkers so much time). This took months of work and a lot of really complex code/a near complete overhaul of a lot of underpinnings of this project.

I'm curious if those who have more insight have a sense of whether this is even really feasible or worthwhile to pursue? Also any sense of how much work this might take and whether the work on the rubocop autocorrect has laid some groundwork that would make this easier?

I've been looking for an excuse to step up and make a large contribution to an open source project that I've benefitted a lot from and would be open to taking this on but want to get a sense of whether I'm wasting my time to even start.

Although I guess this is somewhat rehashed ground from the rubocop autocorrect discussion where there was similar skepticism expressed and ultimately that feature was doable and seems to have been appreciated by the community.

[MaxLap]

@maddieholtzer the Rubocop autocorrect feature did lay some groundwork. The concept of autocorrect just wasn't there before.

However, since there was a single linter to handle, I didn't have to implement logic to handle situations where 2 linters disagree and basically go in an infinite loop.

I don't remember the details exactly, but it won't would be anywhere close to the amount of work for the Rubocop autocorrect system I made. My complexities were about turning Haml to valid Ruby so that RuboCop could process it and then bring the changes back to the original Haml without breaking Haml syntax.

Here, you are editing a text file with little concerns for other things. You can do it one linter at a time. So it probably wouldn't be a big untertaking to try and make one more linter autocorrectable. Learn about the whole code base and see if you want to make another one or stop there.

[maddieholtzer]

@MaxLap thank you for the insight! I'm going to try my hand at figuring out this one first as it's an immediate issue at my company then I'll try this out. A bit busy the next month but pretty free up after that.