This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # atlanta-clojurians (1)
- # beginners (198)
- # calva (4)
- # cider (16)
- # clara (8)
- # cljs-dev (14)
- # cljsrn (4)
- # clojure (204)
- # clojure-europe (3)
- # clojure-gamedev (2)
- # clojure-italy (8)
- # clojure-nl (17)
- # clojure-poland (3)
- # clojure-russia (20)
- # clojure-spec (32)
- # clojure-uk (45)
- # clojurescript (59)
- # community-development (1)
- # core-async (25)
- # cursive (20)
- # datomic (47)
- # emacs (7)
- # fulcro (8)
- # iot (1)
- # iotivity (2)
- # jobs (1)
- # jobs-discuss (8)
- # juxt (11)
- # luminus (5)
- # nrepl (4)
- # off-topic (136)
- # onyx (24)
- # other-lisps (1)
- # parinfer (74)
- # pedestal (1)
- # planck (3)
- # portkey (67)
- # random (1)
- # re-frame (28)
- # reagent (11)
- # reitit (9)
- # remote-jobs (3)
- # ring-swagger (2)
- # rum (3)
- # shadow-cljs (96)
- # slack-help (3)
- # spacemacs (6)
- # tools-deps (3)
- # unrepl (1)
- # vim (4)
@cfleming interesting, smart mode should handle that well, but again it’s probably the editor integration that isn’t notifying parinfer of the nature of the change to help it do the right thing
I don’t think it’s that, it’s that IntelliJ sometimes produces very complex lists of overlapping changes.
i’ll have to talk about state of parinfer on sunday for the repl podcast, maybe we can catch up on how it’s been working in cursive before then?
We’ve talked about this before, and IIRC the conclusion at the time was “it can’t be expected to handle all the potential edge cases for changes like that”, which I think is reasonable.
i caught up with chris (atom) and jason (vim/kakoune) and they said the exact same thing about the editor integrations they’re maintaining
So what really made the difference was the change I made which doesn’t run paren mode on file open, but marks the problems instead and lets the user fix them.
Then it doesn’t matter if parinfer breaks something in a really crazy change list because the user can then fix it to what they meant.
other problems are related to unexpected changes to code with previously correct indentation
Currently I don’t run it anywhere, so if the file is broken it’s broken, and there’s no parinfer until it’s fixed. I was planning to make a change to have that apply per top-level form, but I never got around to it and no-one has complained that it’s a problem.
It’s actually not on by default, I meant to turn it on by default once it stabilised but never did. When I first brought it out a lot of people said they were using it and liking it, and I see occasional comments along those lines.
Copy/paste is still a little painful sometimes. I have plans to make it better, but haven’t had time.
Which happens before parinfer gets to run. That occasionally leads to things you wouldn’t expect, but they’re generally easy issues to fix.
yeah, i had weird things happen when doing some cljs work in atom, like it would dedent entire expressions after my cursor that i had to manually fix
never isolated the cause, but the root of this is that it is very delicate to the wrong change information from the editor
I don’t think that’s always the cause, sometimes it makes sense if you think about it, but to a user who doesn’t understand the algorithm it’s going to be weird.
The user will have expected it to be inserted in the defn form, because their caret was indented when pasting. But IntelliJ pastes, then indents, and then at the end parinfer is run. The indent sees that the new block is outside the top-level form so it dedents it, and then parinfer doesn’t put it in because it’s no longer where the user thought they put it.
Right, but there’s no step there which is obviously wrong, but the end result is confusing.
btw, Kakoune apparently has almost exactly the change log we want, but it wasn't exposed. It wasn't the undo tree, but a monotonic change log that even records switches between branches of the undo tree.
Monotonic is probably the wrong word. Append-only. I will attempt to use it this week.
Well, there's two things to account for. The first is that this change log has only positional changes, not text. Internally, parinfer only needs positional changes, but it parses that out of text. So I'll need to change that somehow.
The second is that parinfer wants changes as though they all happened simultaneously, and Kakoune's log has them stacked sequentially.
e.g. the log might say "insert 10 characters at position 2, then delete 3 at position 7"
@shaunlebron About the state of integration. For Calva I have so far fallen back on only doing parinfer (smart mode) on the user’s command. Main reason being that vscode is a bit lacking in its API:s. But we have started a change in the whole formatting approach in Calva that might open up for on-the-fly parinfer.
Yes, Calva has a command Infer parens. (Since it has an on-the-fly formatter, things are most often correctly indented, so running smart mode means infer parens.)
if that’s the case, that smart mode = indent mode. the only thing that would make their effects different is the presence of the “changes” option
Yes, one-off, not a toggle. And no
changes passed. But there there are two other commands that use that option (also on-offs).
right, this sequential problem is seen in atom when we’re batching change events that can’t be fetched synchronously
(But so far the users who have talked to me about it are happy with doing smart mode at will.)
just to be precise with the language here, your integration is just using “indent mode” if no
changes object is being passed to “smart mode”