> a js library for clojure indent spec? @doglooksgood: if you mean a spec based on the clojure style guide’s indent section, no— because a) there’s some disagreement about indentation length i.e. 2 spaces vs indent to second token b) i want to de-scope indentation preferences from leaking into parinfer’s options for now
plan is to use 1-space indentation to start, but match indentation of the previous or subsequent sibling line if found
much in the same way that Paren Mode will preserve whatever relative indentation you choose, the newline stuff will just use the current established indentation length you chose in the current scope
@shaunlebron I mean the cider-indent-spec, It doesn't care how many spaces will be used for indentation. Instead, it declare a expression syntax to define indentation rule for specific form/macro/function. here's a article for this: https://cider.readthedocs.io/en/latest/indent_spec/
@doglooksgood There are a couple of problems with that: 1) it ties parinfer to Clojure (I believe @shaunlebron wants it to be language agnostic) and 2) it requires parinfer to have access to metadata, which either means some sophisticated parsing, or access to a REPL.
I think that that degree of integration will have to be editor-specific. I could imagine a version which accepts a map of {head symbol -> indentation} which the editor supplies, though.
The problem is knowing ahead of time which symbols you will encounter. Editors could do a pre-pass, I guess, to collect that information.
I'm not sure about other dialects of Lisp, but elisp has the similar solution for indentation. IMO, indent spec can be used for other Lisp as well. And we do not have to access metadata or any thing Clojure specific, just provide a symbol list and let user customize that.
Sure, but the indent spec is currently supplied in metadata. The user could have the {symbol -> spec} map in their .emacs or whatever equivalent, but the point of the indent spec was to try to get away from that.
But right, I think from parinfer’s point of view, it could just receive a map like that. It’s still difficult though - parinfer is currently not aware of which forms represent metadata, and which are “significant” - the indent spec requires knowledge of that to apply it correctly.
None of it is insurmountable, but there are lots of tricky cases.
I think the indent spec can be implemented as a code formatter, separated from parinfer, since currently some editor for Clojure (Lighttable, Atom, VSCode, Nightlight) doesn't support complex indentation. There indent spec can help them a lot.
Yes, definitely.
@doglooksgood BTW I liked your experiments with the hybrid mode, I’ve been planning to try something like that myself.
It’s hard to do in IntelliJ, unfortunately.
hybrid mode?
Or at least, what I would like to do is difficult.
You mean combine Paren and Indent mode in parinfer-mode?
Yes, this bit here: https://github.com/DogLooksGood/parinfer-mode/blob/master/HOW_TO_WRAP_SEXP.org#more-ideas
I use this for weeks and now I turn it off. This may be convenient for some cases, but not as good as I expected.
Interesting. I can imagine a lot of tricky cases around cut and paste
And around selecting a bunch of text including mixed parens, and then deleting it.
What I did for parinfer-mode is 1. before paste, fix parens 2. then, paste in Indent Mode will preserve indentation, paste in Paren Mode will preserve parens.
Are there cases where we care about preserving indentation? I haven't paid to close attention, but it feels like there aren't.
(when pasting)
I'm wondering about cases like these for avi... e.g. should paste always be paren mode? Should inserting characters in the middle of a line always be paren mode?
I'm not even sure how to go about answering them. Collect empiric data? Decide on what would make things work better if users adjusted to them?
@eraserhd: this is something I will have to write a guide on
i can say that there is a progress to make this safer
parinfer 2.0.0 (silent release) makes it safer to paste things in indent mode
pasting wrongly indented code could benefit from preprocessing with paren mode before pasting as doglooksgood said
Oh, the paste buffer itself?
but sometimes there are partial unclosed expressions, which is one of the reasons why I’m considering making Paren Mode work for partial expressions
I think so, not sure yet
Interesting
it might work either way
So yes, some major changes that will dial back parinfer’s aggression and will probably make it safer to copy/paste: 1. unmatched close-parens will suspend indent mode if they are not at the end of the line 2. paren mode should indent expressions even if for partial expressions
will be exploring number 2 after dealing with newline stuff, which protects expressions in Indent Mode when pressing enter