[TxMt] Slow writing and FruitMenu

[Alaric Snell-Pym]

On 3 Nov 2006, at 7:36 pm, Peder Axensten wrote:

> I've had a problem with TextMate (and with OmniOutliner), where
> writing in very long lines was extremely slow. Very slow.

I've also found that if I have soft wrapping turned off and write
such a long line that the entire normal 80-column page disappears
quite far off left, then TextMate starts to become very slow to
respond to keypresses.

> I've just updated the utility FruitMenu, since the update claimed
> to fix a problem where writing in OmniOutliner was very slow. Guess
> what, writing speeds in both applications have dramatically improved.

I don't have FruitMenu myself, so it can't be that affecting me :-(

I just did an experiment. Opened a new file, Plain Text mode, and
started typing rubbish. Got to column 480 and all was fine, but I'm
sure it's been slow on much fewer columns than that in source files,
so I copied the line 43 times; and I could see that each paste-and-
hit-Return (I'd only copied the line, not the newline) was taking
longer each time. So I went to the end of line 43 and started typing,
and found I could only add characters at a reduced rate, about five
per second (on my aging G3) - it wasn't just a time lag, the
characters were appearing much slower than I was typing, and building
up in an event queue somewhere.

But hit return to go to the start of line 44 and all is fine. It's
still fine after I go past the right margin, but as soon as the
window scrolls right, it abruptly slows down.

Since it depends on the scroll position, I presume this problem is
with the display code, but it could be an inefficiency in the
underlying text buffer data structure that the display code brings to
light? I dunno.

ABS

--
Alaric Snell-Pym
Work: http://www.snell-systems.co.uk/
Play: http://www.snell-pym.org.uk/alaric/
Blog: http://www.snell-pym.org.uk/?author=4