-
Notifications
You must be signed in to change notification settings - Fork 6
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
Variable width formatting? But how would you decide the correct width? #2
Comments
All good points! I guess the gist of the question is, how should we allow users to configure the options map used to zprint a buffer? A few options:
I think ideally this configuration should be as editor-agnostic as possible just like Editorconfig, because
WDYT? Re: the specific case of zprint width, I'm not sure I understand the use case of making the zprint width (which is ultimately an aesthetic choice) depend on the editor window width, which changes and is accidental. Could you explain where that could be useful? |
I think that your list of options makes a pretty good outline for how to configure zprint in an editor. Seems like the "ascend the directory tree" would sort of subsume the "locally for a directory". If I'm understanding what you are thinking, then just about everything in that list is how zprint already works. Except for ascending the directory tree. Right now, zprint looks for I could imagine adding My tendency would be to make this a configuration option for But we can talk about the details once we figure out if that is more or less what you were thinking. Regarding the width. I don't have any particular reason to think that a buffer should define the width that zprint should use. It does seem arbitrary and transient. But I notice that a lot of people don't use 80, and I think it would be important for them to be able to easily specify what they do want. Which the general "how to you configure a zprint plugin" discussion solves nicely. |
@kkinnear yes, exactly that's what I was thinking. To elaborate a bit, I think that code auto-formatting is good when you're the sole developer of a project, but it's great when you're working in a team. Different team members use different editors, but with zprint they can share a single engine to power the project format. This has many benefits:
I think for this "big plan" to work out, we'll need a dead-simple way to configure zprint on a per project basis, something that doesn't require many manual steps. Additionally, a great default config that covers most needs would be fantastic too. I'm wondering what reasons there are (security?) for zprint's not searching for a
|
In fact I think it's interesting to compare how prettier-vscode and prettier-atom work. It looks like both prefer configuring via a |
I wanted to read up on the different configuration options available. Because the docs are comprehensive, I felt a bit overwhelmed and found it hard to get started. So I started a tutorial-style document explaining some of the more common configuration needs. Could you take a look if these tips look accurate @kkinnear? |
I'm delighted you have taken a shot at more user-friendly documentation! I'm really looking forward to reviewing it, and will do so tomorrow. |
In zprint At present, it will only do this if you place If you think it would be useful or important for your use of zprint, I could add a capability so that if your first call to zprint was |
You probably know that zprint has a
:width
key in the top level options-map. You can get it to format to any width. Not everyone uses 80 columns as their preferred width. Now if you don't do anything, it should use ~/.zprintrc to initialize itself, and people can put a:width
value there, which might be the best thing. Also, if you configure{:cwd-zprintrc? true}
in~/.zprintrc
, zprint will also look for a.zprintrc
in its current working directory. The theory is that this allows different projects to have different formatting standards. So if you do nothing special, all of that works and is probably pretty reasonable.On the other hand, you might want to (optionally?) figure out someone's preferred width from a buffer (or something) in emacs and use that? I don't know if that makes sense or not (or would be possible or not on the emacs side). But it seemed worth mentioning it.
The text was updated successfully, but these errors were encountered: