Clojurians Log v2

It's likely emacs parinfer need rewrite for better performance, I'm not sure if it is possible to process whole buffer in a very short time in elisp.

the logic will be quite simple if always process the whole buffer. otherwise I have to find the begin and end for current sexp, that's really difficult.

yeah, I suppose your choices are 1) make parinfer-elisp faster somehow, or 2) use the parent-expression hack that @chrisoakman used in atom-parinfer

https://github.com/oakmac/atom-parinfer#known-limitations

I use some hack for current version, however a sexp can be very large sometimes, for example, config.clj. In that situation, I delay the processing until user stop typing. but I don't think it's a good idea.

just to be clear, why is it bad to process only after user stops typing?

if I have a sexp, 1000 lines. I can feel the pause while parinfer processing text.

I mean, can you clarify this? > I delay the processing until user stop typing. but I don’t think it’s a good idea.

i would think that the pause does not drastically affect typing if it only happens after they’re done typing

anyway, we worked pretty hard to ensure parinfer.js was fast for this reason, do you think parinfer-elisp could be made faster? (I haven’t looked at it)

btw, finally updated the site demo to v3: http://shaunlebron.github.io/parinfer/demo

made the necessary site changes using @rgdelato’s branch of atom-parinfer, and it feels pretty good, so I removed the mode option from the site demo

Actually, I'm still not sure what's happening with that. Should I make a pull request or is @chrisoakman doing work to move Atom to v3?

I want to processing in parallel when user is typing. But don't know how to achieve. also, I'm considering using js version parinfer instead of port it to elisp.

@rgdelato not sure, maybe DM him to coordinate?

@doglooksgood neovim-parinfer has had great success with just using js version, and it works really well.

I think that would save a ton of work if it’s currently possible for emacs plugins to shell out to js

driving back home today. going to try to get forceBalance tests done tonight since atom-parinfer will be using it

how can I try the v3 on atom?

@doglooksgood I have a fork that kinda works, if you already have Atom installed, you can try:

git clone <https://github.com/rgdelato/atom-parinfer.git>
cd atom-parinfer
git checkout cursor-dx-poc
apm install
apm link

I'll try to push out v3 officially this week.

For atom-parinfer.

👍

thx! @rgdelato

I found something not comfortable

(defn foo []
  (println {:a 12
            :b 111}
           bar))

but I enjoy the behavior in v3 when I insert open paren before another open paren.

then I can delete close paren with delete or ^d to do slurp.

@doglooksgood yeah i call this behavior "sibling adoption" with a test case describe in this section https://github.com/shaunlebron/parinfer/blob/master/lib/test/cases/indent-mode.md#changes

@shaunlebron I’d need to try it for real, but I can imagine expecting the same as @doglooksgood

yeah i think i agree

that would be inline with @rgdelato's original idea to apply indent mode above and paren mode below the edit

as always, there are edge cases we have to consider. this would require parinfer to know about sibling alignment

e.g. if bar was indented by only two spaces, would you expect it to stick to the map after deleting and reinserting println? @doglooksgood @cfleming