You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
entering opening parens ends up with an extra space at the end:
then from this state:
attempting tab completion yields a FailedToPerform (doesn't advance caret as before)
then from this state:
pressing down key yields incorrect caret position:
then from this state:
entering "|" somewhat unexpectedly puts the arrow on the next line:
and pressing backspace leaves the whole rule as a ghost:
if I start entering the pattern, the arrow then pops up to the current line:
then from this state:
if I enter space and then "=" the following hole stays put, but if i just enter "=" with no preceeding space, the hole jumps up to the current line:
and then completing the arrow by pressing ">" causes the subsequent rule indentation to change:
and then from here:
inserting a wrapping parens inserts the closing on the next line, causing the "in" to move somewhat distractingly:
and then from here
inserting an opening parens results in the closing ghost ending up outside? which i assume is a bug but am not totally sure:
anyway, most of these aren't egregious but things are going to add up... i feel that about ~20-40% of token boundary actions causes something slightly unexpected to happen.
The text was updated successfully, but these errors were encountered:
entering opening parens ends up with an extra space at the end:
attempting tab completion yields a FailedToPerform (doesn't advance caret as before)
pressing down key yields incorrect caret position:
entering "|" somewhat unexpectedly puts the arrow on the next line:
and pressing backspace leaves the whole rule as a ghost:
if I start entering the pattern, the arrow then pops up to the current line:
if I enter space and then "=" the following hole stays put, but if i just enter "=" with no preceeding space, the hole jumps up to the current line:
inserting a wrapping parens inserts the closing on the next line, causing the "in" to move somewhat distractingly:
inserting an opening parens results in the closing ghost ending up outside? which i assume is a bug but am not totally sure:
anyway, most of these aren't egregious but things are going to add up... i feel that about ~20-40% of token boundary actions causes something slightly unexpected to happen.
The text was updated successfully, but these errors were encountered: