Screen does not seem to "automatically redraw" after edits on macOS 13/14 (Homebrew-built binary)

Question

Screen does not seem to "automatically redraw" after edits on macOS 13/14 (Homebrew-built binary)

kajukenbo opened this issue 8 months ago · comments

Since macOS Ventura 13.x, OpenVI in a terminal session does not seem to "automatically redraw" after edits.

I would presume this is actually due to however (they) changed n/curses or whatever on macOS.

Obviously there is no :set redraw or the like to test - not that I'd expect that to do much on an "intelligent terminal."
Behavior is the same in the default Terminal and iTerm2; full-screen and windowed mode.

Any suggestions on what to check or how to troubleshoot?

OpenVI installed via Homebrew, FWIW.

Jeffrey H. Johnson · Answer 1 · Wed Oct 11 2023 03:45:11 GMT+0800 (China Standard Time)

@kajukenbo

Thanks for the report.

Can you describe the behavior a bit more, or maybe what it was doing before that it isn't doing now? I have a virtual machine here running Sonoma I can try to replicate it with, but everything seems OK to me at a quick glance. In any case, if something isn't displayed right, does ^L (Control-L) correctly redraw the screen?

Could you also show me the output from the command -v ovi, echo "${TERM:-}", sw_vers, uname -a, and otool -L "$(command -v ovi)" commands run in the Terminal?

Maybe I'm getting a bit ahead of things, however, if you don't mind compiling OpenVi yourself, you could try to do so, but building against Homebrew's ncurses, which may work better (or differently).

If you have either Xcode or the Xcode CLT (command-line tools) installed, you should be able to do this easily with the following commands:

$ brew install ncurses make
$ git clone "https://github.com/johnsonjh/OpenVi.git" && cd OpenVi
$ env CFLAGS="-I$(brew --prefix ncurses)/include" LDFLAGS="-L$(brew --prefix ncurses)/lib" LTO=1 gmake CURSESLIB="-lncurses"

You should verify the newly compiled binary (./bin/vi) is really linked against the Homebrew ncurses package by using otool -L ./bin/vi. If that does help, you could (temporarily) replace your existing ovi binary with this one - i.e. cp -f ./bin/vi "$(command -v ovi)" - and I'll update the Homebrew formula to build against Homebrew's ncurses.

Dave Jones · Answer 2 · Wed Oct 11 2023 03:56:25 GMT+0800 (China Standard Time)

@johnsonjh

Hello sir.

I will do some testing in the next few days, per your recommendations and post back.

But as I state, I do not believe this to be an "OpenVI problem" per se, because "Version 4.0 (gritter)" and "nvi-1.81.6" via Homebrew also fail to "redraw" as of macOS Ventura 13.x so please do keep that in mind.

^r does redraw "manually" as intended.

Jeffrey H. Johnson · Answer 3 · Wed Oct 11 2023 04:01:22 GMT+0800 (China Standard Time)

Hopefully something I can at least work around.

Something else to try too - install tmux with brew, start a new session with "env TERM=xterm-256color tmux -2 -u new", explicitly set your TERM variable with "export TERM=screen-256color", and then run ovi (or another vi) and see if your redraw behavior has improved.

If so, you probably have something somewhere doing something weird with your terminal settings and/or TERM variable.

Dave Jones · Answer 4 · Fri Oct 27 2023 03:54:55 GMT+0800 (China Standard Time)

Something else to try too - install tmux with brew, start a new session with "env TERM=xterm-256color tmux -2 -u new", explicitly set your TERM variable with "export TERM=screen-256color", and then run ovi (or another vi) and see if your redraw behavior has improved.

I just tried all this (before manual compile), no change.

Testing the previous recommendations now.

Dave Jones · Answer 5 · Fri Oct 27 2023 03:59:58 GMT+0800 (China Standard Time)

$ command -v ovi
/opt/homebrew/bin/ovi
$ echo "${TERM:-}"
xterm
$ sw_vers
ProductName: macOS
ProductVersion: 13.6
BuildVersion: 22G120
$ uname -a
Darwin {Apple M1 Pro} 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28 PDT 2023; root:xnu-8796.141.3.700.8~1/RELE
ASE_ARM64_T6000 arm64
$ otool -L "$(command -v ovi)"
/opt/homebrew/bin/ovi:
/usr/lib/libutil.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)

Dave Jones · Answer 6 · Fri Oct 27 2023 04:00:27 GMT+0800 (China Standard Time)

$ echo $0 ; echo $SHELL ; ksh --version ; set -o
/bin/ksh
/bin/ksh
version sh (AT&T Research) 93u+ 2012-08-01
Current option settings
allexport off
bgnice on
braceexpand on
clobber on
emacs off
errexit off
exec on
glob on
globstar off
gmacs off
histexpand off
ignoreeof off
interactive on
keyword off
letoctal off
log on
login_shell off
markdirs off
monitor on
multiline on
notify off
pipefail off
privileged off
rc on
restricted off
showme off
trackall off
unset on
verbose off
vi on
viraw on
xtrace off

I will try a compile ASAP.

Dave Jones · Answer 7 · Fri Oct 27 2023 04:09:31 GMT+0800 (China Standard Time)

BTW, yes ^l and ^L both seem to redraw "manually" as with ^r

In short any sort of page jump in Command mode has a high probability of simply moving to the location without refreshing the display. The data shown in the terminal emulator sort of "overlaps" the old and new data, almost like it did not scroll at all.

Forgive me, I realize that may not make much sense.

I could perhaps add a screen shot if that helps, but I will try the compile momentarily.

Dave Jones · Answer 8 · Fri Oct 27 2023 04:19:31 GMT+0800 (China Standard Time)

YES!

The compiled version with ncurses from homebrew seems to behave as expected.

I will play with it a bit an let you know if I spot any irregularities.

In the meantime, I am going to "copy it over temporarily" as you suggested.

My apologies for not getting back to this sooner.
Sometimes life gets in the way.

Jeffrey H. Johnson · Answer 9 · Fri Oct 27 2023 04:44:38 GMT+0800 (China Standard Time)

No problem, thanks for checking.

I still can't replicate the problem here, however, so once you are sure that the version linked against Homebrew's ncurses solves all the problems, let me know and I'll submit a patch so future Homebrew binaries are built that way (and also add a note in the OpenVi documentation).

Jeffrey H. Johnson · Answer 10 · Fri Oct 27 2023 16:18:53 GMT+0800 (China Standard Time)

I've gotten an independent report of this via email. And also of the same solution working. (User also has the same problems with nvi and nvi2.)

Jeffrey H. Johnson · Answer 11 · Fri Oct 27 2023 19:49:14 GMT+0800 (China Standard Time)

Fixed in Homebrew/homebrew-core#152557

Dave Jones · Answer 12 · Mon Apr 29 2024 22:47:39 GMT+0800 (China Standard Time)

Quick update, homebrew updated ncurses.

==> Upgrading ncurses
  6.4 -> 6.5
==> Pouring ncurses--6.5.arm64_sonoma.bottle.tar.gz

This might fix other implementations, like nvi

$ brew info ncurses
==> ncurses: stable 6.5 (bottled) [keg-only]
Text-based UI library
https://invisible-island.net/ncurses/announce.html
Installed
/opt/homebrew/Cellar/ncurses/6.5 (4,051 files, 9.9MB)
  Poured from bottle using the formulae.brew.sh API on 2024-04-29 at 09:40:26
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/n/ncurses.rb
License: MIT
==> Dependencies
Build: pkg-config ‚úî
==> Caveats
ncurses is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have ncurses first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/ncurses/bin:$PATH"' >> ~/.profile

For compilers to find ncurses you may need to set:



For pkg-config to find ncurses you may need to set:

==> Analytics
install: 70,609 (30 days), 189,476 (90 days), 724,226 (365 days)
install-on-request: 2,382 (30 days), 4,252 (90 days), 11,952 (365 days)
build-error: 13 (30 days)