-
Notifications
You must be signed in to change notification settings - Fork 8
Use atom-linter helpers for dealing with temp files #13
Comments
The temp method is there in the latest release. |
After reviewing the @steelbrain thoughts? |
@jschroeder9000 why would you want to write multiple files to a single dir? |
It's a workaround for a limitation of |
That is horrible, You should open an upstream bug demanding for stdin support. |
I'll try to avoid making any demands. Our work is possible because of theirs. :) I did open an upstream bug (sds/haml-lint#66) which brought about the idea of setting an environment variable with the necessary config location, but it lost steam. We could try to revisit that. OTOH, I agree it would be ideal if Initially that seemed like a boon for adding STDIN support to haml-lint, but after investigating further I don't believe that is the case. Since both are written in ruby, haml-lint calls rubocop code directly; it does not create a new process where rubocop could read from STDIN. Rubocop could theoretically add support for being passed a string, but all that would do is make haml-lint more performant by eliminating disk writes of its own. Neither rubocop accepting input from STDIN nor from a string has any real bearing on haml-lint's ability to accept input from STDIN. I make disk writes to satisfy haml-lint. Haml-lint makes disk writes to satisfy rubocop. And in spite of that this package performs well for me (granted I've only used it on machines with SSDs). Each project is making use of edge cases in its dependency that are difficult to justify supporting. In order to eliminate disk writes here, rubocop would have to support being passed a string. But I bet that would get laughed down. That's what I would probably do. Who passes file contents as a string to a CLI program? Nobody. Except haml-lint. But that's what would it would take to eliminate disk writes because haml-lint uses rubocop's CLI class. And that makes sense because it's a stable public API. In the mean time I intend to support After all this rambling I intended to close this since it seems that helpers are not as good a fit as originally thought. But now I see that haml-lint actually has implemented support for the environment variable proposed a few months ago (sds/haml-lint@f222bfa). Ugh. For now I think the best way to move forward is to make use of haml-lint's support for setting an environment variable for the rubocop config location. It requires no additional changes to dependencies and would eliminate the need to copy the rubocop.yml file to the temp dir, which in turn eliminates the need to support multiple files in the same temp dir, which means it is, in fact, possible to go ahead with this proposed change. It may also be possible to further cut back on disk accesses by remembering the location of the rubocop config file. That could break things if people add/move/remove it, though. Something to think about. I've also toyed with the idea of a setting that would enable/disable lintOnFly for only this package (while respecting the setting of the main linter package) for people who may not appreciate the IO overhead. It hasn't gone anywhere yet, though. /ramble |
John, I respect you and I respect your opinions. but IMO, it's a false argument that we should not demand new features just because we're using someone's project. I know a lot of linters that support stdin and some linters like I am not in the favor of disabling The best way of solving this would be to demand support for stdin in haml linter, if they don't agree with you, argument with them and show them the benefits. Not everyone has SSD and even when they have SSD we shouldn't do something that's unnecessary. |
I'm removing the current temporary file setup in #113. It isn't complete enough to cover all the edge cases, and the entire idea just doesn't really work with linters that require several external files. The I'll leave that open for a few days for comments or ideas to a potential solution. |
The
atom-linter
package intends to implement functionality for dealing with temp files. When that happens,linter-haml
should use that instead of custom code.Depends on: steelbrain/atom-linter#30.
See also: #11.
The text was updated successfully, but these errors were encountered: