Terminal.app keeps crashing while using VIM

No, no, no.

This is not the MacPorts website. This is the Apple Sierra OS website. I did not log on to hear about GPL wonders. (I know backwards and forwards what they are.) Your continual excuses and mis-directions are not useful. If GPL is so wonderful why do you have an iMac? Because GPL is being attacked and the issues are seriously timely to "setup a full set of servers" - as in several years timely.

I did not buy an iMac to run GPL variant terminals until i "found one that worked and didn't contain malware or spyware" ... which Debian OS warns anyone should be aware is a possibility in such a distribution. I double that down saying: there is far more money and interest in adding malware to linux and freebsd than there is to fix things and remove "further from unix, less secure" hacks - which i estimate there are at least millions of in a GPL distro.

X11 ? X11.app is a misnomer it couldn't do X11 if it tried: and it was designed not to by people who hated the Xerox / MIT licenses - to Xdamage X to take it out of view. But meanwhile they used the code and relabeled it. Smart but we all saw it happen and many said it would long before X.org released a first public version "splitting off X to make it work they said, sure you are, sure you are".

X11.app now no longer supports X11 in any manner at all. X11R6 still does. X.org does NOT, and none of it's apps will work with any other X11 - infact even little tiny X apps of X.org have been thoroughly XCB hacked to work with X.org.

It's on my todo list to "remake X11R6.app" (the only free X, XFree86, that is actually X11 compatible). However it's hard to get to TODO's when the "minimals" aren't working: like a simple Terminal program continually crashing while i'm looking at ports and macports.

LASTLY ON X: Apple removed the label X just after I bought my computer because it had the X. I consider that a breach of contract, re-negging, etc.

If I wanted a non X, non-unix box with no terminal that worked right (ie vt102 and Tektronix graphics support) my best advised choice by anyone would certainly be: Microsoft or hack GPL pc (hacks to beware of). Not including iPhone ties which are nice but "not the rule": they shouldn't be using iPhone as an excuse to kill off everything that had been working. However that's always how "spies" and malware work: continual excuses.

Simply put no ad said "iMac is an iPhone platform that will discontinue all unix and X ties soon and limit users to things iPhone would allow". Rather the opposite they re-inforced the ideas of both unix and X in the ads.

--------------------------------

Let's stay on topic. Imac Terminal.app continually crashes when using vim(1) locally, but not elvis(1) remotely

There is no Apple supported alternative: rather Apple refuses to give macports "license to operate off app store", and to someone who knows all about these things: i'd say there decision is wise. Easily a set of consumers could end up being auto-updated by africa russia germany unexpectedly to ransom computers or government. Infact: it was on the news recently my home State was hit by ransom ware. Macports phones home and they are not liable (ie prison time) for malware - much the opposite i doubt individual code additions can even be traced to persons.

Let's stay on topic. Imac Terminal.app continually crashes when using vim(1) locally, but not elvis(1) remotely

Today I'm using elvis(1) insead of vim(1)

elvis-2.2_0.tar.gz

It hasn't crashed yet, though it's not gotten allot of mileage yet either.

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.

(to get "old but good" elvis-2.2_0 for Sierra, you have to compile it the usual "gnu autoconfigure" way (have Xcode installed), the below script has the ed(1) changes that compile Elvis on modern compilers: script "build" in tarball build-0.1.11.tar.gz)

build-0.1.11.tar.gz

(not yet updated in the above is two changes needed for "Darwin", )

# add these opts when running configure

! [ -f xfree86.done ]&& ! [ -f xorg-server.done ]&& \

opt="$opt --without-x --without-xft --without-gnome "

# sierra's headers don't match elvis's C definition, the new compiler rejects

[ c"$lKERN" = c"darwin"]&&[ ! -f need.c.old ]&& {

cp need.c need.c.old

cat << EOF | ed || true

r need.c

/NEED_MEMMOVE/

-1

.a

#undef NEED_MEMMOVE

.

wq need.c

EOF

}

The bug is unquestionably in the Terminal app. It crashes when using vim via ssh from another (non Mac) server. I am pretty sure it was not Apple's intent to have a magic character sequence which, when sent to Terminal, would crash it. Based on a post in another thread, I was moved to investigate if there was some way I could get an early preview of the 10.12.4 update...😉

wordragon wrote:

The bug is unquestionably in the Terminal app. It crashes when using vim via ssh from another (non Mac) server. I am pretty sure it was not Apple's intent to have a magic character sequence which, when sent to Terminal, would crash it. Based on a post in another thread, I was moved to investigate if there was some way I could get an early preview of the 10.12.4 update...😉

The Public beta of 10.12.4 is now available

https://9to5mac.com/2017/02/21/macos-10-12-4-public-beta-3/

> 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?

That's completely fair fair to say!

If elvis-2.2_0 ever crashes I'll report it, so far no segfaults and no Terminal.app dumps.

I think I built elvis over vim for linux (x-lfs-2010) due to "issues of it quitting" (possibly even crashing xterm), however I cannot say for sure why i chose elvis. I don't use vim on the remote side either - so I didn't mean to imply "linux vim does not crash".

After exciting the topic I'd like to be a little quieter.

I MOSTLY REPLIED to say that for some curses(1) based programs (they emulate terminals) it's critical to use a "correct" termcap and or terminfo. Those files themselves can support or crash programs (ie, as someone mentioned, for special character sequences).

On my currently non-apple 'nix box I have to do this:

# elvis crashes w/o this

export ELVISGUI=termcap

for an old version of top(1) i had (have) to do this:

export TERM=linux

So it's possible vim(1) is trying to do something Apple Sierra OS doesn't support or is not configured to support.

However we all know *something* is more wrong than that because it should seg fault back to back: not crash the terminal ... well not unless terminal crashing trash was sent?

It's also fair to say "why is apple using vim not nvi - nvi was the elvis based replacement for AT&T vi(1) that BSD was not allowed to ship for free". (elvis is not a new one-off project - it was stable and a cumulus of allot of work by a PhD working at a college, BSD nvi, the vi that freeBSD "always used" was based off it), and "what did apple overlook when choosing vim and it's version?" (note for onlookers: vim probably has better international support than elvis)

Still for me, I'm off to a different todo, as I can actually work for hours without an issue now, it appears

thank you for responding and if I have any updates I'll let you know

let me try to say this quietly as i can.

vim(1) in debian linux crashes too if using xterm and XFree86 (unless fixed by tailoring environment to prevent vim from sending unsupported sequences to terminals that DO NOT SAY they support these sequences - thus it's a vim issue)

whether vim is fixed or Terminal.app is fixed ...

it's still an issue to send ONLY sequences to terminals that support the sequences (ie, VT101 only to detected VT101, linux to linux, see your termcap or terminfo) doesn't matter, or to hack the terminal to support more sequences than it had - where before it never advertised support of all such?

it doesn't matter if Terminal.app supports all sequences if it doesn't say it does. does it support everything xterm-312 does? (multiple windows, Tek graphics, the whole works? i'm unsure but i run 312 on linux and think it's 256. which vim also crashes. so maybe the fix in terminal will just handle a cripple software?) I'm guessing no , but Terminal.app only says "it's got a nice user interface and exceptional international support". Meaning: i doubt Terminal.app says anywhere it fully supports some exact terminal in the terminal database.

they can fix Terminal or Vim - doesn't matter - obviously more supported esc sequences are better IF AND ONLY IF these are not mistakenly interpreted as special whereas other software does not think they are special (which would break other software if so - but i'm unsure how ESC sequences terminate so unsure if they might cause breakage that way).

me? don't break all other software to cater to a (favored) software. fix it so it doesn't impact any older software or just admit the newer software is wrong. (that doesn't mean vim or terminal - could mean either here)

no one listens to me, so whatever, i'll just act like they don't. i'm very used to "big admins" pushing others around happens in all OSes. doesn't matter what one says they have agendas, people they favor, and act on it. for everyone else it's just living with the fact they continually break whatever is working in favor of a favored new project / group.

Concur with Bob, though I continue to use Terminal.app and MacVim 8.0 and /usr/bin/vim 8.0 without incident in both OS X 10.11.6, and macOS Sierra 10.12.3.

I only get this when using the default xterm-256 (or xterm-16, xterm) - changing to ansi or VT100 and it works fine. Not ideal but works as a workaround for now.

The beta OS releases fix this bug. It is not a vim issue, it is an issue with some escape sequence crashing terminal.app.