-
-
Notifications
You must be signed in to change notification settings - Fork 336
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
cmd/shfmt: EditorConfig support in stdin doesn't support filenames #577
Comments
Apart from looking up settings, the fake filename can also be used when writing error/warning messages to stderr. This is also useful for editor plugins. |
Naturally, the fake filename should also be used to find the |
Hm. I can see how this could be useful, but I also want to avoid adding more flags unless strictly necessary. It also feels a bit weird that we want to support shell input files with filenames from stdin, but we don't want to do the same for EditorConfig. Why should EditorConfig require being on disk, if we don't require the same of shell files?
Why not just do |
The format-all package for Emacs supports perhaps 40-50 languages depending on how you count. We use stdin->stdout with all formatter programs - no exceptions. For editor plugins like it, the user is typically editing a file but wants to format it before saving it. Piping the editor buffer's contents into the formatter's stdin and then replacing the buffer's contents with the formatter's stdout is much simpler than first ensuring the file is saved and then formatting based on filename. With the latter case, several problems can occur that are difficult to solve reliably. Format-all also supports formatting temp buffers that are not saved to any file, so they have nothing reasonable to use as a filename. In this case, format-all does not pass an |
It has never occurred to me to think about this. I can't think of a practical problem where it makes a difference where the |
Thanks for your reply. I'll need to think about this. The intersection of stdin formatting with EditorConfig is a very awkward one for sure. |
If the user is editing both |
Np, thanks for the prompt reply and consideration! |
Also, this is an appeal to authority but |
While that is true, many formatters out there also have a low filter when it comes to adding more and more flags. Just try to do |
While that's true, I don't see a way to solve this problem without adding a flag. Unix file descriptors do not carry filenames (and even if they did, it might not be the same filename that is used in editor's user interface due to symlinks and the like). One could use an environment variable, but that also adds something and is more brittle than a flag. rufo (for Ruby) is one example of a formatter that has very few flags, but one of them is stdin-filename:
|
First, a question: if this is a smart editor (or rather, a smart editor plugin), should it not be in charge of locating the right EditorConfig file and passing in flags? Granted that the In retrospect, I think fixing #450 might have been a mistake, because it should be the editor doing this work. Otherwise, if the editor runs ten formatting tools, they will all do their own separate work to locate and use EditorConfig files, which at best is wasted effort, and at worst is going to be inconsistent and buggy. -- Now, assuming we want to fix this, my current thinking is as follows:
|
It's not wise to rely on that because the set of available settings and their permitted values can (and probably will) change from one version of the formatter to the next. It's also easy to create subtle inconsistencies between how the editor applies the settings vs how the formatter (with the help of reading its own settings file) does. A It's true that it is also useful to be able to map editor settings (that do not necessarily come from the
Most formatters do not use As far as I can tell, any way you slice it the
Looks good to me. The only thing I would change is that using a zero-length filename |
I agree that
I'm not sure I agree - this already applies to flags, so the editor/plugin integration with shfmt already has to know about shfmt's options anyway. Of course, for any given stable major version like v3, the flags are stable and forwards compatible - and the same applies to how those options map to EditorConfig. I can't change any of those until a potential future v4.
True, but this cuts both ways. The other side of the coin is that, if two tools both have their own logic to use EditorConfig files, they might be inconsistent with each other when used as part of an editor. And, as we said before, duplicate effort that can't be reused between tool invocations either.
It honestly bothers me that so many tools consider themselves special enough to deserve their own "dot-file". This is precisely why I rejected issues like #234 and #358, until someone suggested a format that was standard and could work well enough. I get that, in practice, I can't even name a single other tool or formatter that uses EditorConfig and could fit in an interactive editor. Still, it still feels to me like it's a better design for the editor to be in charge of the EditorConfig from a central and high-level place. Very interesting chat, in any case. I've been thinking about how tools integrate with editors a lot recently, but I hadn't thought about the edge case that EditorConfig introduces with in-memory buffers. I'm still on the fence when it comes to what we should do here. Something we can likely agree on is that, currently, EditorConfig support is almost completely pointless with stdin. |
I appreciate your stamina with this discussion :)
I agree that it would be ideal to keep all formatters' settings in However, we support 40 different formatters and new ones trickle in at a steady pace. There are plugins that support even more. There's no way we can get everyone to agree on where to store their settings.
I believe this is not a wise division of labor:
This is unavoidable. Even if formatters don't parse .editorconfig, every editor needs to parse it separately. One person uses Emacs, another uses Vim; inconsistency can arise. There is no standard editor (except The best solution is to have a standard test suite for editorconfig. Ideally also a standard library for each popular programming language. There could be one and only one command line program to parse
We're talking about milliseconds here. Speed is not an issue; the real issue is arriving at a design simple enough to avoid race conditions, confusing corner cases in pathname lookup, etc. This is one reason why stdin->stdout is such a win.
An editor is not a central place:
As soon as your project has a A formatter needs to be callable from any number of different places and produce behavior as identical as possible from all of them. The more of the style-parsing that's centralized in the formatter itself, the more likely this outcome is.
Emacs keeps track of a a per-buffer working directory, so even in-memory buffers that are not associated with any file have their own idea of their working directory. However, this is not intuitive. In practice, users' mental model of the editor does not associate temp buffers with any particular directory. Since .editorconfig files are associated with particular directories, it's not a good fit. This is different from the In any case, formatting buffers whose current contents do not correspond to a disk file is the norm for editors so stdin->stdout (with or without |
Also, in case the editor's and the formatter's settings diverge (which inevitably happens every now and then), I think it's better to favor the formatter's idea as the ground truth. Automated tools such as a In practice, format-on-save using project settings is so convenient that I rarely even bother to configure Emacs anymore. I just type sloppy code using bad indentation and save frequently to sort out the mess. |
Thanks for the detailed reply. I'm leaning towards giving up the idealism and just adding the flag, for the following reasons:
|
This tells shfmt what the filename was, which allows its parsing of the .editorconfig file to work properly. Refs: mvdan/sh#577
This tells shfmt what the filename was, which allows its parsing of the .editorconfig file to work properly. Refs: mvdan/sh#577
Ref:
shfmt
ignores config file lassik/emacs-format-all-the-code#90Could a command-line flag be added to shfmt to give a fake filename to use when formatting from stdin? I.e. assume that the contents of stdin come from a file with that name.
This would be important when looking up settings for stdin. If
.editorconfig
contains:then
shfmt < foo.sh
will ignore that section of the config since it isn't told the filename offoo.sh
.This would be fixed by
shfmt -assume-filename foo.sh < foo.sh
. Stdin->stdout formatting continues to be important for text editor plugins; it would be more difficult to rely on a simpleshfmt foo.sh
for this use case.Some other code formatters already have an option like this:
clang-format:
prettier:
rufo:
The text was updated successfully, but these errors were encountered: