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

{[()
   ]}
   ^ 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 )

@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.