finally solved this. the logic still have some difference with the official version, but going to add tests to make current version usable and stable before going any further.
@doglooksgood sorry, I meant to send you this yesterday: https://github.com/shaunlebron/parinfer/blob/master/lib/test/cases/smart-mode.md#leading-close-parens
those are all the test cases I use to describe leading closers in smart mode
@doglooksgood in answer to your last question, the cursor holds the parens in position
whenever a close-paren is detected at the beginning of the line without a cursor to its left, paren-mode is run
actually, that’s wrong
https://github.com/shaunlebron/parinfer/blob/3.12.0/lib/parinfer.js#L1274-L1304
when a leading close-paren is found, it exits to paren-mode
so paren-mode does all the handling of those cases
and that logic is just a single call to isCursorLeftOf
to determine whether to keep the close-paren where it is, or to append it to the previous line
@shaunlebron i'm curious why smart mode not allow delete anymore in this case
(
|)
when i have multiple close paren here, i move cursor right, one cursor will go to the trail position. but how can i get it back? i think this is kind of inconvenient.
there are two questions there
first question: why can’t you press delete at that position? paren-mode handles all cases with leading close-parens because I don’t know how else to fix all the edge cases related to them
this in turn constrains the indentation to keep the leading close-paren valid
it’s not great
but I don’t know if producing this is any better:
()
|)
^ error: imbalanced
second question: with multiple leading close-parens being held by the cursor, then moving cursor to the right, how do you move the displaced close-paren back to where it was before moving the cursor?
example, here:
{[(
)]}
^ cursor before this character
then after moving cursor to right:
{[()
]}
^ cursor before this character
answer: I really want to communicate that the cursor is responsible for holding these parens in place. this is part of the language that is consistent to a few other areas.
I’m not sure what the use-case is for keeping it in place
i only keep the parens in place in this example because the user could be typing something there
but when the cursor leaves, that’s no longer true, so it is a paren whose position has to be normalized
and I can only use the cursor position to denote where the user may be typing
we should be asking these type of detailed questions in this forum so the discussion doesn’t disappear: http://parinfer.trydiscourse.com/
@doglooksgood do you want to ask your future questions there so I can answer in good detail in a more permanent place? you have really good questions
i noticed that our @logbot stopped logging our chats in november of last year 😞 https://clojurians-log.clojureverse.org/parinfer/index.html
reported in #community-development
@logbot is still logging everything. The website that displays the logs is broken.
i’m moving the discourse channel to http://talk.parinfer.io/
it’ll take a while
i decided against putting it in clojureverse since it won’t be clojure-specific in the future (cc: @martinklepsch )
If you did it to not shy away people not looking for Clojure specifically, makes perfect sense 👍 If you did it because you think it would not be appropriate on ClojureVerse long-term we could have talked about it beforehand 🙂
it doesn’t make sense for a racket user to ask questions about parinfer in clojureverse for example
@shaunlebron Hi, i just had a sleep. I'd like to move this stuff to a better place.
just for this question, I noticed parinfer v1 has a option called preview cursor scope, I can't remember it very clearly. but I think it's when i delete the critical indent whitespace, the close paren will move up, and If I insert the whitespace, the close paren will come back. Is that true? If it is, why don't act like that? I've been thinking for a while, because I write parinfer-mode with my understanding instead of port it function by funtion, I wonder if there's some serious rules here, so we can tell users how parinfer work in few semtences.
Yeah, that’s what I meant with the first, sounds sensible 🙂
cool. i do like the idea of all clojure-related projects having discussions there. i’ll try to advocate for that when I see the opportunity