This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (2)
- # beginners (53)
- # boot (30)
- # cider (27)
- # clara (1)
- # cljs-dev (18)
- # cljsrn (16)
- # clojure (153)
- # clojure-brasil (1)
- # clojure-dusseldorf (5)
- # clojure-italy (20)
- # clojure-losangeles (3)
- # clojure-spec (4)
- # clojure-uk (177)
- # clojurescript (115)
- # component (4)
- # core-logic (1)
- # datomic (29)
- # emacs (9)
- # figwheel (2)
- # gorilla (1)
- # graphql (36)
- # hoplon (4)
- # jobs (1)
- # jobs-discuss (3)
- # juxt (2)
- # keechma (22)
- # lumo (4)
- # off-topic (1)
- # onyx (17)
- # parinfer (96)
- # protorepl (10)
- # re-frame (31)
- # reagent (14)
- # ring-swagger (17)
- # spacemacs (32)
would it be possible for Parinfer to be a standalone executable that other editors can call out to?
I guess you’d pass it a file path to be processed, and it could return the edits as we discussed above?
not particularly, just that it would mean that there wouldn't have to be ports of the code to different langs. write it once in something fast
Or at least, to get a copy of the document efficiently. I guess you could always save + apply it, but that would mean that the user’s doc would be being saved continuously.
Unless you write out a temp file, and then it doesn’t matter how fast your algorithm is 🙂
But I think having the reference impl in something that’s more amenable to either manual or automatic translation might be a good step worth investigating.
So I have a draft of the change to process the whole file and apply edits. Most of the indent mode tests work now, I’m gradually working through the failures. Hopefully I’ll have something to show tomorrow.
There’s still a fair amount of tidying up to do, including things like handling
\r\n correctly and probably revising some of the names (origText -> text etc)
Most of the indent mode tests pass now, I haven’t looked at the paren or smart mode ones yet but a reasonable number of them pass too.
So hopefully the approach is basically sound and there are probably just some bugs lurking there.
I have to head out now, but if you have questions let me know and I’ll try to get to them later this evening.
I’m also planning to revise the edit accumulation and application to the result text, I’m not sure that catches all cases when e.g. edits overlap.
In my initial version I tried to use offset in more places rather than lineStart/x combos, but that made the change larger than it needed to be.
i’ll give it a more thorough look in the morning. i can probably fix the rest quickly. i’m pretty convinced this is the right move btw
There are probably some edge cases to consider around the processing at EOF if the file doesn’t end in
\n too - some of the processing that was at the end of
processLine is now in
onNewline and also in
finalizeResult. If those calls are not idempotent there might need to be some more state there to track that.
current issue is that the edit from correctParenTrail seems to be interfering with previous edits that remove unmatched close-parens on the spot
Ok, can’t really get on now (looking after my daughter) but the issue might be in how the edits are applied in
going to try to keep the same processLine logic to be sure that stuff is happening in the right order
the options screen isn’t showing up for chris, and I’d like to see if it’s working for others
config-key should namespace the config keys to the case of the package I’m guessing
looks like it should be lowercased https://atom.io/packages/parinfer, not sure why I had it capitalized?
in general, it's kinda weird that it's capitalized since it puts Parinfer before all my other packages in alphabetical order
i’m not sure why i ever capitalized it. the readme instructions even give wrong instructions? shouldn’t it be
ln -s <atom-parinfer dir> ~/.atom/packages/parinfer?