Clojurians Log v2

sure!

not crazy about the name

wanted it to be slightly related to parinfer, without creating an impression that it forces everyone to use parinfer if it’s used

@shaunlebron fraction of a second on 40k loc

2.5s on 31k loc

0.77s on the 40k loc.

@shaunlebron changes lgtm. Biggest change on one project was that a bunch of #_-related indents.

Not sure if this is intentional, but:

(let [x 1
      ]
  x)

also multi-line strings don't get indented. E.g.:

(defn foo
"Hello
world")

(defn foo
 "Hello
world")

@dominicm thanks for feedback!

i’ll try adding an option to delete lines that were left empty after linting

multi-line strings cannot be indented, since that would be adding more literal spaces inside the string, thereby breaking code!

i’ll add a note about that 👍

@shaunlebron yeah, I thought that might be the case. There's perhaps an "edge case detection" where you say "This is all aligned already, and it's inside a defn, let's indent it & warn the user". But I'm not sold on that being a good approach.

ah, I see what you mean

for things like docstrings I suppose

where it doesn’t really matter

docstrings are a bit inconsistent in the cljs compiler code—sometimes it’s indented to the first ", other times is it’s indented one space to the right of it

I know. 😞

and sometimes it changes within the same docstring

very hard to detect

I think Clojure's multi-line string support isn't necessarily great tbh. I wish I could do:

<<EOS
If you provide "foo" as a parameter…
EOS

I agree, I notice it a lot. I imagine zprint is the tool for fixing that (I didn't check!)

it doesn't 😞

would you throw a reader error if text inside the heredoc was indented to the left of the << ?

i’ve heard these complaints before, but I’m not sure how people would solve it

@shaunlebron I'm sure there's issues 🙂. I'm not really sure what a heredoc is! I just know it would be nice not to have to worry about string escaping at times, for doing expressive docs.

@dominicm heredoc is the common name for the <<EOS syntax for describing multiline strings

anyway, definitely don’t commit those linted files yet, the trim will have to know about the original code so it doesn’t remove the other empty lines

@shaunlebron ah! I see. I guess the current bash/ruby implementations would be worth comparing against. I don't really feel strongly, I'm just currently thinking about docs. No doubt I'll end up at literate programming.

Oh, I already landed that bomb 😉

I fixed it manually, vim made it easy enough, especially as I checked every change manually so I'd have feedback.

ah, the perils of being a beta tester

cool 👍 appreciate it. good feedback

@dominicm did you have to negotiate at all with your team?

and did you integrate it as a check?

@shaunlebron I ran it as a one-off for now. No negotiating required. The changes were mostly sane. I also manually reverted a change around https://github.com/shaunlebron/parinfer/issues/92

It was easy to use parlinter on the codebase because it's not invasive at all. Nobody is going to fight fixing confusing indentation & moving parens onto the same line.

I’m documenting the cases where people might fight it

you’re saying you reverted the comment change to keep the paren after the comment?

@shaunlebron yes.

I also think using git ls-files -- **/*.{edn,clj{,c,s}} for the list of inputs to parlinter would have been faster, as parlinter probably ran against the compiled files unnecessarily.

uh, you suggest **/*.{edn,clj,cljc,cljs} but same thing

do you think the comment case can be resolved in Indent Mode somehow? that’s a scary thing to me but I’ll try to revisit

@shaunlebron I've no idea. I know you didn't like the edge case of it. It's definitely kind of incompatible with parinfer. But it's definitely the sort of thing I see in codebases quite commonly, and removing it isn't really okay where we have it (usually detailing the reasons for elements in a vector, or documenting why some function unexpectedly appears at the end of the threading macro)

> quite commonly Rather, I see it often in codebases "at least once". So, I don't see it everywhere. But I usually do see it. Not sure how to word that.

I suppose (comment) would work better, but would be inconsistent with the other ;; comments

my concern is that it won’t be integrated as a checker if it fails on an edge case that people want to keep around, and I’ll have to add a ;; parinfer: ignore directive

Well:

(-> 10
    distinct (comment This is like this because reasons of #1 XYZ, #2  DEH))

I agree

maybe as a string

yeah, it’s just bad

(-> 10
    distinct) ;; This is like this because reasons of #1 XYZ, #2  DEH

obviously that’s not an illustrative case for the problem we’re describing though

I think the big benefit you get with

(-> 10
    distinct ;; This is like this because reasons of #1 XYZ, #2  DEH
    )

The trailing paren hurts me though. I agree that it's an annoying edge case.

(-> 10
    distinct
    ;; This is like this because reasons of #1 XYZ, #2  DEH
    (comment))

(-> 10
    distinct
    ;; This is like this because reasons of #1 XYZ, #2  DEH
    #_ignore_me!)

it can be used as a sentinel maybe

The answer is probably to do this:

(-> 10
     ;; This is like this because reasons of #1 XYZ, #2  DEH:
    distinct)

that works, but (+ 1 2 (comment)) is 3, and I think that’s the only way to create a sentinel to allow Parinfer to keep the paren after a comment

oh, and #__ would work too

Not entirely great to be writing code specifically for parinfer though. My team don't use parinfer, so would probably ? over such code

yeah I agree, was just tempted by the technical novelty of the solution i hadn’t realized before

I have another codebase that can have the linter treatment btw, so let me know when trimming all works

@dominicm trimming seems to work if you wanna give it a try

@shaunlebron LGTM!

just for fun, usage from vim: !aFparlinter --trim --stdin

A case where using ;; Foo is like cause X: doesn't work:

{:foo 1
 ;;:bar 10
}

again, uncertain how I feel about it 🙂 totally understand why it is how it is.

@shaunlebron https://github.com/shaunlebron/parinfer/tree/master/lib#api > full text input The whole file? Does it have to be? Or can it be the top level form > cursorLine Relative to the section of text, or whole file?

atom uses it to format top-level forms

where the cursor is relative to the form

Okay, cool. I think the nvim parinfer slow down may be due to it running on whole file. Currently hell on a 1.3k line file. Gonna try optimise the plugin 🙂

@dominicm strange, not sure what the slowdown could be

also, both zprint and cljfmt allow parens after a comment 😕