Damn! Experimenting with Talon voice software... sometimes it just comes on for no reason!!! At least it had the good sense to use off-topic 😅

You can try using your favorite file browser with https://github.com/s3fs-fuse/s3fs-fuse or something similar.

Thank you. I am looking for smth like an interactive browser, to be able to list, or look into the contents of a file without downloading it proactively.

I work with 50+ accounts and mounting yet another bucket is not really an option

s3cmd

https://github.com/s3tools/s3cmd

This was just released by amazon. Why not mount the s3 folder locally, then use whatever tool you want locally (like midnight commander or whatnot 🙂 )

For 1. At nubank we are using clojure-lsp as our official lint tool, used on all services, so any user of clojure-lsp (emacs, vim, Vscode) already use the cljfmt and other lint style definitions, for intellij users, they rely on lein lint-fix before opening PR We have a lit CI that runs clojure-lsp format, clean-ns and diagnostics tasks, this way we have a standard for formatting and other standards

difftastic understands Clojure syntax and can provide diffs that take that into account. I use that as one of my git diff tools

https://difftastic.wilfred.me.uk/git.html

I just indent however Emacs decides to indent. If a PR seems to have a bunch of stylistic changes mixed with actual changes, then I request those stylistic changes to be removed. So far this hasn’t caused much friction, even though it seems like all three editors disagree on how to indent clojure syntax unless you integrate cljfmt somehow EDIT: I do sometimes wish macros I write with :style/indent metadata gets respected out of CIDER, but I haven’t ran into issues where coworkers format code inside macros incorrectly, yet.

Am I the only one telling git to ignore white space?

My team uses https://github.com/greglook/cljstyle with a very small number of changes to defaults (the ones everyone agreed on) in a file committed to the repo. It runs in a pre-commit hook, so if you’re not following the format, it fixes them automatically. All the major editors also seem to have plugins for it (I run it on file save from emacs), so mostly no one ever needs the pre-commit hook in practice. I’m a big fan of the https://go.dev/talks/2015/gofmt-en.slide#5 that having some uniform style/formatting is more important than having the particular formatting you like the best. Why waste time arguing about style (except for fun ); we’ve all got more important things to do.

AFAIK, there’s no way to get Cursive and cljfmt to format the same way. This is a major problem in projects where Calva and Cursive are both used. I know that same people disable Calva’s formatting and use something else configured to format in save. I haven’t seen the same non-negotiable situation between cljfmt and clojure-mode, but that’s not a guarantee the situation is not there.

What's important is aligning to one thing and that any commit doesn't change style in unrelated area Commits that reindent an entire file or align bindings make me riot

Wishfull thinking: I think git is ill suited for Clojure specifically, because it doesn't understand the first thing about it: that it's structured. I wish there was a source control tool that actually read s Clojure code. Imagine the possibilities! For example you could then update code via the REPL, possibly automagically. It wouldn't matter how you format it. Everyone gets their own view of things. You could leverage things like spec and other things to talk about how code has changed. Merge conflicts and diffs would have structured semantics too, instead of having to mentally construct them on top of line based diffs.

I have always viewed code style to be the first conversation for a team to tackle when building a shared culture. It is something that can be hidden with a tool, but the underlying people problem will eventual surface somewhere else.

For commercial projects, one of the first things a development team should decide on is format / indenting rules they want to comply with and set up tooling to do so. Most editors follow the Clojure style guide at least in part and can usually be configured to a similar approach. Formatting style should be not be a reason to converge on a single editor choice (unless there are other factors and time given to get people up to speed) Where differences remain between editor configurations, an external tool like cljstyle or zprint can be used as a pre-commit hook or just a manually triggered command line task before final commit and push. I use a make task that runs pre-commit checks to support consistency (and catch anything an editor misses) I also use cljstyle as part of clojure-setup GitHub action so all projects are consistent When committing PRs to projects where I am not a committer, then I'll try follow the format / indentation of that project. Magit for Emacs is a very effective tool for only committing specific lines of a change, avoiding most white-space issues.

> Commits that reindent an entire file or align bindings make me riot That's the advantage of having auto-enforced style IMO -- there may be some whitespace-altering commits initially if you start from a template or something (otherwise not) but then there will never be whitespace-only changes again. > I wish there was a source control tool that actually read s Clojure code. Imagine the possibilities! Usually called 'semantic diff'. I thought I remembered running across one that understood Clojure, but not finding it now. For one that doesn't yet work with Clojure see eg https://semanticdiff.com/.

So my current findings are thus: lsp-format-buffer = cider-foramt-buffer = cljfmt fix cljmt fix != cljstyle fix or zprint with "community style" Of the three zprint looks the most configurable, and it (and apparently at least cljstyle) does more than indentation changes and it's a binary. So, my main confusion and current question is how to make zprint behave like lsp/cider format buffer.

(I have intention to add support for zprint in clojure-lsp as a optional format provider then would be easier to one chose which one to choose easily)