Terminal.app keeps crashing while using VIM

But users specify the TERM environment variable that tells Vim what terminal features are supported. Plus there are a bunch of Vim settings that can specify terminal escape sequences the user wants Vim to use.

If the user chooses the wrong TERM setting, Vim does not know that.

Of course that doesn't say Vim does not "Color outside the lines" from time to time. A large project such as Vim with multiple contributors can have bugs with respect to the allowed interactions with the terminal.

Sierra Terminal offers the following TERM defaults

Now if Terminal does not play nice with one of these TERM settings, then it is Terminal's fault. If Vim is sending escape sequences not supported by the TERM, it is Vim fault.

But there is one other factor. The host operating system's terminfo (or TERMCAP) files for a given TERM settings. The Mac's terminfo contents may not be the same as the terminfo contents on another platform. There are no rules that says every platform must have identical terminfo files.

So in theory, a Linux platform might have a different terminfo xterm-256color file than what is on the Mac.

If the terminfo data is correct, then then it is still Terminal's fault. But if the Mac's terminfo is different, then the macOS developers were not testing with an accurate environment.

All of this is total speculation.

Another variable would be if Vim is using the host operating system's curses(3) package. Curses translates many requests to actual escape sequences. Vim running on another host will be using a different curses(3) than Vim running on macOS. It is totally possible the non-Mac curses(3) is outputting correct escape sequences, but in a different order than what macOS curses(3) is sending. Again, the macOS developers would not be testing in the same environment and would thus be at a disadvantage.

A bug is a bug, and I'm not suggesting Terminal was correct. What I am saying is that the customer will find "New and Interesting Ways to Use the System". No matter how much something is tested by the developers, they will never, ever think of all the ways a customer will use their software. I speak from experience. Years and years of experience writing Unix based file system software.

With respect to Vim. I doubt Apple will modify Vim code. Vim has a very generous license, so Apple is free to include updated versions of Vim directly from vim.org (which they have been doing, as newer versions of Vim have been appearing with newer versions of macOS). And of course if an Apple employee does find a Vim bug, they are free to report that back to vim.org, or provide vim.org with a proposed fix. From Apple's perspective, it would be much simpler to let vim.org maintain the sources, than to have a Mac specific version that Apple would have to constantly update. I do not think this is any different from Debian, Ubuntu, RedHat, SUSE, etc... They most likely just get their Vim sources from vim.org and the only customization would be how they decide to build it.

I can tell you that Sierra's Applications -> Utilities -> Terminal works just fine using /usr/bin/vim

Try removing (or saving somewhere else)

$HOME/Library/Preferences/com.apple.Terminal.plist

$HOME/Library/Saved\ Application\ State/com.apple.Terminal.savedState

Create a new user account and try vim from there. If that works, it would tend to point to something about your vim initialization scripts or plug-ins, or perhaps shell environment variables.

If that does not work, try booting into Safe mode

<http://support.apple.com/kb/ht1564>

If that works, it may indicate there is a 3rd party addition that is causing problems. 3rd party additions are not loaded when booting into Safe mode. That and more conservative drivers are used.

If that does not work, try using iTerm2

<https://www.iterm2.com/>

This is a different terminal emulator so that if it also fails, there is something common between Terminal an iTerm2. If iTerm2 succeeds, then it something unique to Terminal.

There are other similar threads on this same topic at https://discussions.apple.com/thread/7778906 and others - one of the comments there suggest that the next release of macOS Sierra will fix the problem (see the last page).

And it has exact examples of how to crash vi/vim.

Yes, Safe mode is a diagnostic. It is trying to figure out if a 3rd party addition is the cause of the problem (3rd party additions are very commonly the cause of problems for normal operation on a Mac).

iTerm2 isn't even on the app store and stuff that is is $5 - who's sending EVERY Sierra customer $5 per trial to see what isn't crashing currently ?

That is true. You get it from <https://www.iterm2.com/>, or you can get it via a package manager, such as MacPorts, HomeBrew or Fink.

iTerm2 was a suggestion to get your work done. Not an excuse for Apple. I don't know about you, but I'd rather get paid for doing my job, and not deal with a crashing Terminal app. And I spend hours every day in iTerm2, ssh'ed into other Unix systems running Vim, doing my job.

Where are you getting $5 from. Yes, the iTerm2 project would not mind a donation, but it is not a requirement, especially if you just want to see if iTerm2 works for you.

The command line interface is NOT Apple's priority. The fact that there is a Terminal emulator at all is actually strange for the Mac, as its focus is the point and click GUI interface. There was no Terminal in Mac OS 9 and earlier.

As a long time Unix developer, I am grateful that the Mac has a Unix underside, but I also accept that Apple is not selling a system to replace Linux, Solaris, AIX, HP-UX, etc... It just happens to be a happy side-effect for those of us that work in the Unix command line world.

I wouldn't even be surprised if Apple abandons Terminal, like they did for X11.app. If you want X11 now, you have to get XQuartz (also not on the App Store).

If you wish to tell Apple what you think, then there are channels for that. This is a user-to-user technical support forum.

BugReporter (Free ADC (Apple Developer Connection)) account needed for BugReporter

<http://bugreporter.apple.com>

Anyone can get a free ADC account at:

<https://developer.apple.com/register/index.action>

Mac OS X Feedback

<http://www.apple.com/feedback/macosx.html>

They will not reply, but it does get read.

Why is it if I suggest a different terminal emulator (iTerm2), I'm "Off Topic". But if you mention a different editor (elvis), and that is acceptable?

I'm not sure why vim(1) would (more frequently) cause Terminal.app to crash versus any other C program having input/output unless hackers have modified vim to use "libs" and in such a way that causes unusual lib crashes in the core instance (not the vim instance), which Terminal.app would of course trip over. If that is tentatively true: it means it could be vim(1) and lib ncurses together, not Terminal.app, causing the bug.

I would not say anything, except I think you are maligning a group of volunteers that work hard to develop an exceptional programming editor that is used by thousands and thousands of professional, amateur and casual software developers every day.

Vim is 1,578,043 lines of code, syntax files, vim scripts, documentation, etc.... It will have bugs. Terminal is thousands of line of code as well, and it will have bugs. Sometimes the stars align and bug A interacts with bug B. Or, and much more common, a program has a bug (in this example Terminal), but it goes undiscovered because you have to ask it to do things in just the right sequence for the bug to trigger. It is very possible that Vim is using that sequence and elvis is not. And none of these bugs are intentional, nor the result of malicious hacking.

Chances are this thread's problem is a bug in Terminal. If you can reproduce it, you should file a bug with Apple, giving them detailed instructions on how to reproduce it. Then it will have a better chance of being fixed.

BugReporter (Free ADC (Apple Developer Connection)) account needed for BugReporter

<http://bugreporter.apple.com>

Anyone can get a free ADC account at:

<https://developer.apple.com/register/index.action>

If you don't mind being a guinea pig, you can always sign up to get the latest beta: https://beta.apple.com/sp/betaprogram/

Sadly, participation comes with the restriction that you don't comment publicly on what is and isn't in there, etc.

VikingOSX thanks. My MacVim was still 7.4. When I built my Unix based Vim 8.0, MacVim had not yet been updated, and I forgot to go back and look. Your pointer reminded me to get the latest copy. Thanks!

bentor_mac, I tested Terminal with the /usr/bin/vim (VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Dec 6 2016 12:07:41)). and the Unix Vim 8.0 version I built from sources.

I had this problem too, and could trigger it invariably by first joining two (long) lines in ViM, followed by deleting that line from the end of it with the "d0" command.

I then systematically disabled settings in .vimrc one-at-a-time to see whether one of those settings (that I've been using for many years) was the problem. It turned out that the "wrapmargin" setting (used in combination "textwidth") was the culprit: the above crash would occur at whatever value I set this (my original setting was "set wm=5"); and the crashes stopped when this setting was removed from .vimrc. Note that I kept "set textwidth=72" throughout.

Thanks Bob Harris for pointing me to checking my settings.

Remains the question why macOS Sierra would trigger the crash where prior OS X versions and all Linux versions would not...

I have been having this happen for a few days now and it's most annoying. I just removed ~/.viminfo and that seems to have fixed the issue -- at least, I'm not able to trigger it at will by vi'ing a file and changing long lines. I hesitate to say "fixed" though since it's obviously a problem with the terminal app itself as no text should be able to crash it like this.

Bob,

I subsequently noticed that the pre-built 8.0+ from the link that I provided, will replace the older operating system /usr/bin/vim with its own updated binary. I haven't seen a negative to that replacement yet.

VikingOSX wrote:

Bob,

I subsequently noticed that the pre-built 8.0+ from the link that I provided, will replace the older operating system /usr/bin/vim with its own updated binary. I haven't seen a negative to that replacement yet.

The MacVim.dmg does not seem to change /usr/bin/vim. I dragged MacVim.app from the .dmg to /Applications, launched, it and /usr/bin/vim is till a 7.4 version on my Sierra system.

Are you talking about building from sources via the above link?

On newer OS versions, I think System Integrity Protection (SIP) prevents modifications to /usr/bin, or are you on a pre-SIP based version of OS X?

NOTE: When I build from sources, I specify my own destination location via

configure --prefix=$HOME/local/arch/${MY_ARCH}/mylocal ...other.args.etc...

Yes, a bit strange, but I build for Mac (at one time both PowerPC and intel, just intel today), AIX, Linux 32-bit, Linux 64-bit, Solaris SPARC and Solaris intel, so depending on what platform I'm on MY_ARCH is set by my .bash_profile. Then I put $HOME/local/arch/${MY_ARCH}/mylocal/bin into my PATH variable via .bash_profile, so that I always find the correct compiled version of Vim for the system I'm currently using (and I used them all during the day; but most editing is on Linux). My $HOME is on an NFS shared home, so the same $HOME is used by AIX, Linux and Solaris. I use the same .bash_profile, .bashrc, .vimrc, etc... on all systems. Either via the NFS shared $HOME, or scripts that copy my essential files and scripts to systems not on the NFS shared $HOME. So much fun being a multi-platform product developer 🙂

Bob Harris

I am running same downloaded installation of MacVim 8 (not locally compiled) on both El Capitan 10.11.6, and macOS Sierra 10.12.3. On the later system, the /usr/bin/vim is 7.4, and on El Capitan, it is 8.0+.

Can't explain the anomaly on El Capitan as I certainly did not manually update /usr/bin/vim.

I use vim almost exclusively via ssh - my lab system is Centos 6, and my client systems are a variety of OS/versions. They all crash terminal, so the issue is the sequences being sent to terminal, not vim. While there may be workarounds in vim configuration, the problem is Terminal (in both senses:-), and Apple needs to fix it.

The problem is repeatable, in the sense that you can create scenarios which always crash it. The ones I have seen all involve wrapped or long lines, however, in my experience, I have seen it crash when moving from one line to the next with the down arrow key (so basically the only things changed are the line counter on the bottom and the cursor position).

I upgraded to Sierra somewhat late. About a week after I did the upgrade, I applied the 12.3 update. The problem did not happen during the first week, so I am pretty sure (since I can't use vim for more than about 20 minutes with it failing) that the problem was delivered in one of the early updates, if not 12.3.

I've tried a couple of suggestions on vim configuration changes (and will try the ones here), but so far, they simply change the frequency of crashes, not eliminate them. I've hit the "report" button easily over 200 times - other than getting to vent some in the comments, it hasn't helped much...

Re: wordragon

Have you tried iTerm2 ???

<http://www.iterm2.com/>

I'm suggesting an alternative terminal emulator so that you can do your work, not to ignore any problems in Terminal.

I also live in Vim at work, and similar to you, I'm ssh'ed into different flavors of Unix systems (Linux mostly, but also AIX and Solaris). But, I rarely edit anything with very long lines, so I cannot tell you that iTerm2 will behave correctly or not.

So just for the purposes of testing, I created a file with 1 very long line (166629 characters long), and iTerm2 seems to be happy.

Again, I'm suggesting an alternative terminal emulator. The same one I'm using professionally every day.

i deleted what i was going to say to be a little "quieter"

I also have vim continually crashing on me SEVERAL TIMES DAILY ... and suspect it's really Terminal.app and not vim

Booting to Safe Mode to use vim is absolutely not an option. The mere suggestion I hope was only for diagnosis. However the problem is already confirmed so that part of diagnosis is immaterial.

iTerm2 isn't even on the app store and stuff that is is $5 - who's sending EVERY Sierra customer $5 per trial to see what isn't crashing currently ?

I think the excuses here for Apple are 0, ZERO. They flagged, it's an F, they need to pay to have it fix immediately and stop covering it up. They need to skip a trip to the Casino and get it done. They keep on spending money on improving garage band instead?

I'm rather forced to use "a big company" computers (due to un-released drivers and auto-updated standards that break past software, ie i need a working web browser it's required to apply for jobs and etc). And that isn't an issue i need to expand on here.