Sometimes when typing a right parenthesis, the cursor moves one character to the right instead of actually typing the character.
E.g. if I have this line, with the insertion point directly after the “a”:
(See (a)
… if I type right-parenthesis, the cursor moves to the end of the line instead of inserting “)” as expected.
Sounds like a manifestation of auto-completion. You’re trying to insert more closing brackets? Typing each opening bracket should give you the closing bracket you need, and FT will recognise if you try to add another bracket where it’s already placed one for you. If you tap the closing bracket again, you’ll be able to add as many as you want…
Yes, obviously I could just keep pressing the right-parenthesis key to insert the character I’m trying to type, but that doesn’t make the behavior any less buggy/unpredictable.
Is there a way to disable autocomplete? I use FT for editing and marking up other people’s copy, for posting to the Web. I don’t normally do much actual typing in FT – e.g. in the case above I hadn’t typed either of the opening brackets as the line was part of a block of text I copied and pasted into FT. So, autocomplete only makes my job harder.
I guess if this can’t be changed, I could do all my fixes like this in BBEdit – which does behave predictably – then switch to FT for markup.
Makes more sense that this is an issue for you when working with text that you’re not inputting yourself. I’ll let someone else jump in to answer whether there’s any way of disabling autocompletion (none that I know of…)
Not wishing to split hairs, but I wouldn’t personally say that the behaviour is unpredictable/buggy, rather just not intuitive. I remember having a similar experience when I first experienced autocomplete with FT, but it just makes sense to me now.
That said, one thing I meant to enquire about but completely forgot until this conversation was whether tab could be wired to jump past the closing symbol of an autocompleted phrase, as per Sublime Text (which would make autocomplete more useful IMHO). @mutahhir?
Similar issue… in the text below, what would we expect to happen if the insertion point is placed between the right-parentheses and the delete key is pressed three times, i.e. trying to delete “(a)”?
(See (a))
My intuition/prediction would say:
(See )
But what we actually get is this:
(See
I’d say that behavior is difficult to predict, and unintuitive, and a bug. 
Counterintuitive maybe, but not a bug. Deleting the opening symbol of an autocompleted pair with nothing between the opening and closing symbols deletes the pair. 
Technically it’s not part of an autocompleted pair, though. When the inner-left paren is deleted, its matching right-paren is already gone. The bug is when FT deletes the other paren’s matching pair, which leaves an unmatched left paren.
The only way this sort of autocomplete could possibly be helpful is if it intelligently keeps track of matching pairs. If it can’t even ensure that parentheses are always matched then it should leave them alone and let the writer take care of it. I know what I want to achieve, but when I press the keys to make it happen, something else happens.
Honestly I don’t think this feature was tested with nested parentheses at all.