Community

TextPad has two operations that work with brackets: MatchBracket, and MatchBracketExtend. Neither work the way they should.

The way MatchBracket currently works is that it searches forward for the next occurrence of a Bracket. But this does not reflect what a user is typically trying to do when they are matching brackets. The current text selection, or editing point, is typically inside the bracketed text. What MatchBracket should do is search backwards to find the bracket that applies to the current selection.

(Of course, if the current selection is a bracket, then MatchBracket should search forwards for the closing bracket of the pair. TextPad does this now so that's not the issue. It's the initial bracket search that's the issue.)

If TextPad searched backwards for brackets then it would be easier to expand to wider bracketing. Currently the only way to expand (find brackets that enclose brackets) is to do this from end brackets. You have to seach forwards from the end bracket, and then MatchBracket to the beginning bracket. Backwards searching would let users also expand from the start bracket.


OK so what about MatchBracketExtend? It's broken. What it seems to do is select all text between the current editing point (or start of selection), and the next bracket. This really not likely what a user needs. I suggest that MatchBracketExtend should select all the text enclosed by the "closest" brackets. That is, it should select the text between what two "fixed" MatchBracket commands in sequence would find (assuming a bracket wasn't currently selected): the previous start bracket, and its matching end. This is the minimum it should do.

Furthermore it would be very useful if MatchBracketExtend would expand the selection to the next outer bracket pairs if the current selection were already bracketed. In this way you could quickly click somewhere in nested text, do several MatchBracketExtend operations, and know the selection was "matched-up" bracket-wise. It would make indenting, cut/paste, search/replace, etc. much easier for nested text.

I could vote for this if it had a poll

It's not clear (to me at least) that the TextPad people take into account polls to determine what to develop. Doing so is the Microsoft method of product definition.

TextPad is a wonderful product because it is technically strong with a subtle quality to it that's very high. For instance, the other day I had a split window open (actually a two way split) and noticed that my mouse scroll wheel was doing the right thing whenever the cursor was in a particular region. I don't know if it was a concious design to implement that, or whether the underlying development platform gave that to TextPad. But I do know that other editors/other programs don't do this correctly.

Things such as this little feature are throughout TextPad. When you consider the menus it's plain to see that someone has carefully thought about the "right" way to set them up. I could go on... It's a thing of beauty!

Anyway, my point is that I believe TextPad will evolve into what an editor should be, and not necessarily include features because users think it should. My post was pointing out a technical limitation, and proposing a better way of matching brackets. I trust the TextPad people to acknowledge it and do the right thing, whatever that is.