[Paul McCann]

I'm being driven crazy by slow vim performance in terminal.app. In other terminals (eg Eterm or even xterm via Apple's X11) vim starts up in a second or so, but try the same thing via terminal.app and I'm waiting around 7 or 8 seconds before the screen is redrawn. But the weirdness continues: this occurs even when logged into a solaris machine through terminal.app. That is, the problem persists when simply displaying vim run on another machine. Again, whereas the vim on that machine (when viewed via a well behaved terminal application) starts up in the blink of an eye it's the old 6 to 8 second dance when using terminal.app. In addition, something as simple as deleting a line can cause ye olde lollipop to spin like a mad thing for a couple of seconds.

What I've tried: (1) different fixed width fonts and font sizes; this seemed to help a little (in that courier seemed less hobbled than monaco), but the bad behaviour is still present (2) antialiasing on/off (3) different encodings (4) trashing preferences et al. Even GLTerm is a slug at displaying vim. Carbon vim is fine of course.

This behaviour is consistent on both my macs (733G4 at home and an imac DV 400 at work), and is becoming incredibly annoying. I could try living in X11 for a while, but the terminals have their own lovely "features" (annoying cut/paste behaviour, strange loss of control-a, control-e et al, where you simply get a control character being printed instead of an action being implemented by the interpreting shell, funky focus behaviour under apple's X11.app), so I'd really love to get terminal.app behaving.

So two questions I suppose: does anyone else see the same behaviour with "pure unix" vim in terminal.app (for example)?
And more importantly: any suggestions for how to stamp on this nonsense?

Thanks a lot,
Paul

[OreoCookie]

I have no problems with vim here. iBook 800. You sure that you have one of the later versions (6.1) and *not* the carbonized vim?

[samthecat]

are you using transparency with terminal.app? i have had some performance problems with things as simple as "ls" when transparency was used (nothing as bad a 6-8 seconds, though)

another possibility might be a bizarre termcap entry (caused by some other install). what is your $term (or $TERM)? have you tried to use the "screen" programme to see if the performance is different then?

all i can think of at the moment. good luck

cheers,

samthecat

[macmike42]

You are using the 'vim' package from Fink (or something based on it), correct?

The solution is to remove that and install the 'vim-nox' package. I don't know why it has such a problem with Terminal.app, especially since 'gvim' starts the X version anyway, but if you don't use gvim, this should be a satisfactory fix.

[gorgonzola]

I'm using the vim package and don't have this speed problem. No transparency, but even with heavy transparency it doesn't rainbow when deleting lines and does not take anywhere near 6 seconds to start up. iBook 500/384.

[Paul McCann]

Thanks a lot for the replies.

I've spent far too long trying to track down what's causing this weirdness, and still haven't got to the bottom of it, but here are a couple of symptoms.

Firstly, it's definitely a terminal.app thing, rather than a problem with the version of vim. (For what it's worth, there are about three separate installations of vim involved. The one from darwinports [[installed in /usr/local/bin]], the vim-nox from fink, and vim 6.1 installed on a shiny new solaris machine and viewed either through terminal.app or Eterm etc.)

TERM is set to xterm-color, but ansi, ansi-color and vt100 all display the same funky behaviour.

The one smoking gun that I can point at after all this experimentation is *Monaco*. If my font is set to Monaco (rather than Courier, for example) the slow slow slow startup and spinning lollipop are very much in evidence. Anti-aliasing doesn't seem to influence things at all. Given that I prefer to use Monaco it's a bit of a pain, but Courier it is for now (even Courier bold stuffs things up). Yep, it's looking more and more strongly correlated to the choice of font. Unfortunately there's something else in the mix as well, but for now that'll have to do. I can hack the slow startup time, but can't hack the slow updates to the screen.

Just out of interest: what fonts do you prefer to use in terminal.app?

Thanks again,
Paul

[Paul McCann]

OK, I think I've knocked the other piece of the puzzle on the head. macmike42 was on the money here, but the font issue was blunting my appreciation.

Seems that if you have DISPLAY set and use a simple "vim" with the bells-and-whistles version of vim (ie that including gvim etc etc), the startup will be delayed while something X-ish takes place. This was hitting me while using the solaris machine. The system-wide login on that machine makes a guess at what a user's DISPLAY variable should be set to. Calling plain old vim without an X-server set up but with that environment variable set brings the delay. Unset it and vim is happy again.

Hopefully this thread helps someone else somewhere sometime! The font question remains: anyone confirm/deny the horrific behaviour I've been seeing with Monaco as the terminal font?

Cheers,
Paul

[iCode]

Originally posted by Paul McCann:
... The font question remains: anyone confirm/deny the horrific behaviour I've been seeing with Monaco as the terminal font?

Now that you mention it, I have found that I too developed a performance problem with Terminal. I also use Monaco and when I SSH into my Linux box and 'ls' a directory that results in bold text the terminal becomes very sluggish as I try to scroll it back and forth over the bold area. Where the text is plain the performance is acceptable.

Incidentally, I noticed this after I have upgraded my video card in my Cube to a card that supports Quartz Extreme. Prior to this the scolling behavior was not an issue since bold text did not appear in my terminal (at least I don't remember it now).

In any case, I use an alternate terminal app (GLterm) which is very snappy, so Terminal.app performance is no longer an issue.

[Paul McCann]

Yep, the "enhanced" ls output always throws a spanner in the works here too. Truly tragic.

(Anyone using tcsh should be able to see the slow Monaco behaviour by issuing

% ls-F
% ls

Until all the colour has gone away I'm guessing you'll see pretty sluggish output to the terminal window.

Cheers,
Paul

ps Just tried GLterm again; works a treat now that I've slapped my forehead (ie, unset DISPLAY). I'll hunt around a bit more today and see if there's an alternative workaround. No obvious startup option that I can see. Mmmm, OK, here's a hacky attempt: throwing the following shell script --called "vim"-- into my ~/bin directory on the solaris box (which is checked before /usr/local/bin):

#!/bin/sh
unset DISPLAY
exec /local/bin/vim "$@"

Bingo: even if the DISPLAY environment variable is set everyone's happy, regardless of whether or not the X server is running on the "foreign" machine. Very much *UBE*.

[Gary Kerbaugh]

   This is probably unrelated except that it's a performance issue. Has anyone checked their system.log and notice that every time a Fink installed application is invoked, /usr/libexec/fix_prebinding goes through a lengthy ordeal trying to prebind it. The process takes several seconds to cycle but I doubt it's using too much processor during that time. However, I think the performance hit is noticeable.
   I would naturally like to know if this is unavoidable or if it can be turned off. I would also like to know if this is the norm for Fink installed apps or if something anomalous is happening on my machine.
   If you get a chance to grep your system.log, I'm curious to know how wide-spread this issue is.

grep "fix_prebinding" /var/log/system.log