3 ms·
> getting it wrong means that you don't know which one was supposed to close which opener This is solved by "jump to matching", which every worthwhile editor I
by tomsthumb 9y ago
> getting it wrong means that you don't know which one was supposed to close which opener
This is solved by "jump to matching", which every worthwhile editor I've used has had.
- kazinator 9y agoThat causes the problem of knowing something you don't want to know. That problem, in turn, is solved by not looking at what "jump to matching" is specifically doing, other than watching for it hitting your "target parenthesis". Example. I have this, in the middle of a larger body of code with more open parentheses which are not shown: (foo (((((bar) ... .....)) <- Suppose that the point indicated by the arrow, I want to close (foo, and only (foo. Perhaps I want to start another unit that is on the same level of nesting as foo: (foo (((((bar) ... )) <- must close this ;; (bar ... <-- want to start this; doesn't exist yet So I just type ), or even auto-repeat. The jump-to-matching feature jumps backwards onto various parentheses that I don't care about, getting closer and closer to (foo. That (foo is where my eyes are; I stop when I see the backward jump hit (foo. If I overshoot, then I just backspace. Any good jump-to-matching feature works when you backspace to a parenthesis, not only when you type a new one. So after an overshoot, I can still keep my eyes on the (foo and backspace until the cursor jumps to (foo. It's like keeping your eye on the ball or other target in a sport. There is no value in knowing which of the other parentheses match which openers, and no value in having to interrupt the )))) to deal with other kinds parenthesis, when all I want is to close `(foo is a nuisance. That's just the down-side of whatever notational benefit those other kinds of parentheses bring.