This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (6)
- # aleph (3)
- # beginners (38)
- # boot (119)
- # braid-chat (15)
- # braveandtrue (1)
- # clara (4)
- # cljs-dev (56)
- # cljsfiddle (12)
- # cljsjs (15)
- # cljsrn (6)
- # clojars (4)
- # clojure (113)
- # clojure-art (1)
- # clojure-berlin (1)
- # clojure-dusseldorf (3)
- # clojure-india (15)
- # clojure-new-zealand (3)
- # clojure-poland (1)
- # clojure-russia (83)
- # clojure-uk (18)
- # clojurescript (97)
- # community-development (9)
- # cursive (1)
- # data-science (1)
- # datomic (12)
- # emacs (14)
- # hoplon (350)
- # immutant (2)
- # jobs (2)
- # jobs-discuss (23)
- # keechma (74)
- # liberator (1)
- # off-topic (1)
- # om (127)
- # onyx (54)
- # parinfer (74)
- # pedestal (1)
- # proton (5)
- # re-frame (6)
- # reagent (4)
- # remote-jobs (17)
- # ring-swagger (1)
- # slack-help (5)
- # untangled (16)
- # yada (21)
I’m not sure I can. Those modifications are done on the AST, which is built over the text document. So the symbol for the name will be replaced in the AST, which will be synced back to the text document by magic. I don’t think I can intercept that at that point.
Besides, I’d have to ensure that I caught all possible operations which might make non-local edits which would break the code in this way.
IntelliJ in general is not designed around non-local text-based manipulation, which has made getting parinfer in very hard.
So I’m interested what everyone thinks. In noctuid’s article, he argues basically (ignoring all the Emacs stuff) that a combination of auto-indentation and then an action which will indent and rebalance the parens will get most of parinfer’s advantages with none of the disadvantages. What does everyone think about this?
You miss the sort-of automatic paredit, but from shaunlebron's comment above it looks like that may not work as well as hoped due to the issues snoe has raised.
This means that the modifications are local rather than global, but I’m actually starting to think that that is an advantage.
It does not require running paren mode over the whole doc on file open, which has made this a non-starter for several people that I’ve seen.
Assuming the auto-indentation works correctly, I’m actually inclined to agree with him. I’m interested in feedback or counter arguments
In fact, it has one big advantage over parinfer - it doesn’t require mode switching, but provides the main things that users seem to want from both modes (auto-indent from paren mode, and rebalancing based on indentation from indent mode).
it remains true in some cases, obviously, but it’s certainly broken in enough cases that it can’t be advertised like that anymore
Yeah. I’m interested whether people using parinfer a lot actually use that. It always seemed to me like it doesn’t offer enough control - I don’t usually slurp or barf to the end of the line.
From my POV, the hypothetical mode above has another huge advantage - it works much better with IntelliJ’s model.
2. the aggressive-indent + rebalance action based on indentation is another idea that will have tradeoffs that noctuid mentions
in the absence of modes, we must deduce user intention about what is to be preserved by the action the user is taking
But pasting code containing indentation doesn’t work correctly with indent mode either.
it must work in Indent Mode because transformation is based on text not user action
If you’re pasting code after a bunch of spaces, which is pretty common, it won’t work.
sorry, never made this share snippets, but I think it’d be constructive to produce an example here
I’m referring to the fact that the indentation is parsed no matter how it gets there
I’ve just closed the square brace, and I press enter, then I paste:
(when true (do-something))
That code gets broken. I mean, I understand why it happens, but it’s a very common case that will confuse users.
I have the additional problem I discussed above, where non-local changes like renames will currently break things badly.
so in the case of pasting this in this new hypothetical mode, it would be pasted, then aggressively indented
I imagine aggressive indent would stop the cursor at the indentation threshold, similar to paren mode
I guess I’m just starting to get the feeling that indentation is actually more fragile than I had assumed.
And I’m starting to think that perhaps changing parens around based on indentation should be the explicit action, not the automatic one.
If only because the refactoring problem I describe above is probably a deal-breaker for me.
we can hypothesize about new users, but we gotta build both and see how they respond
Ok, I’m going to patch this up for now, and then I think I’m going to try to implement hypothetical mode X for a test release that people can try out.
Even if nothing else comes of it, having provoked people to think about it is really valuable.
Hehe, definitely, although I wouldn’t say we’re at the point of marking off parinfer just yet.
I think the issue I raised about tab stops is part of this too. In indent mode, if you are changing the indentation it means you want to change the structure of the code, that can be done imprecisely with spaces or tabs or rebinding tab to paredit slurp or barf. I needed to highlight cursor column to work in indent mode effectively but even then it's so easy to indent one off in, say, long hiccup forms that the number of mistakes i made was always relatively high in the five months i used it. so I've come around to thinking that the paredit functions really do capture structural edits well.
In vim though, paredit or vimsexp, both have insert mappings that keep parens balanced. Parinfer's behavior when typing open or close parens, or removing them is however far better than vims paredit wrap, or indent mappings and I think slightly better than emacs'