Variable width formatting? But how would you decide the correct width?

[kkinnear]

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.

[pesterhazy]

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:

• Globally in ~/.zprintrc

• Globally for the project. We could ascend the directory tree until we find a .zprintrc. This would allow you to specify a configuration for a project, which is a common pattern I think. The config file would typically live in the project root, i.e. the directory containing .git. Editorconfig works like that:

  When opening a file, EditorConfig plugins look for a file named .editorconfig in the directory of the opened file and in every parent directory. A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found. https://editorconfig.org/

• Locally for a directory (is that such a useful pattern I wonder?)

• For a whole file using ;!zprint

• For a specific form (using, say, ;!zprint {:format :skip}

I think ideally this configuration should be as editor-agnostic as possible just like Editorconfig, because

• users are often uncomfortable with configuration inside the editor
• the same logic can be reused for other plugins (Atom, IntelliJ)

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?

[kkinnear]

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".
I agree that an editor-agnostic approach sounds best, for the reasons that you discuss.

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 ~/.zprintrc, and if that has {:cwd-zprintrc? true} it will look in the current working directory for a .zprintrc file. Which is nice, but rather limited.

I could imagine adding {:zprintrc :ascend} (and perhaps {:zprintrc :cwd] and deprecate {:cwd-zprintrc? true} over time). Or something like that. Is that kind of what you were thinking?

My tendency would be to make this a configuration option for ~/.zprintrc, so that it wouldn't ascend up the directory tree unless you asked it to do so in your ~/.zprintrc. Mostly so that people wouldn't be surprised by a change if they had a .zprintrc laying around somewhere.

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.

[pesterhazy]

@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:

• easier onboarding for newer developers (zprint will clean up the syntax)
• take complexity out of the editor - all it needs to do is to filter the buffer through an external process
• reduce diff noise due to inevitable editor config disagreements
• less need for "indentation linting" during code review, allowing you to focus on design issues
• style disputes put to rest

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 .zprintrc in all parent directories. I'm asking because

1. it would remove one more piece of configuration that in a team you'd need to instruct new developers to do (i.e. make an entry in $HOME)
2. The very successful prettier-js does search "up the file tree until a config file is (or isn't) found" by default

[pesterhazy]

In fact I think it's interesting to compare how prettier-vscode and prettier-atom work. It looks like both prefer configuring via a .prettierrc in the project root.

[pesterhazy]

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?

[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.

[kkinnear]

In zprint 0.4.15 zprint will search from the current directory up to the root, looking for a configuration file with the name .zprintrc or .zprint.edn. It will take the first one that it finds.

At present, it will only do this if you place :search-config? true in the file $HOME/.zprintrc or $HOME/.zprint.edn. I'm thinking about making this the default in 0.5.0, but I'm not certain about doing that. I know that this isn't quite what you wanted, but it is getting closer.

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 (set-options! {:search-config? true}), it would search for the config file starting at the current working directory. I just thought of that or I would have done it already -- let me know if you would want to do that.