Closed grahamperrin closed 2 years ago
@grahamperrin This is indicative that termcap for TERM that you used (my guess is xterm-256color) is stale and does not have alternate screen support smcup(te),rmcup(ti). To confirm export TERM=tmux-256color and then start arttime. This time it will close with cleaned up look as arttime ran in alternate screen. You will most likely also see 2 lines saying wrap enable/disable capability smam(SA),rmam(RA) is not found. Both of these are indicative of fact that xterm-256color as well as tmux-256color are suggesting your terminal lacks the capabilities it actually has: alternate screen, enabling/disabling wrap. My observation from forums like for vim is that developers hack their apps by hard coding the escape sequence for such capabilities in their app instead of opening a ticket on someone to update termcap database, as there is no central maintainer across OSes I guess.
@grahamperrin I described the same issue in note of https://github.com/reportaman/arttime/issues/16#issuecomment-1263280574. The reason you didn't see terminal capability errors while testing with my fix for https://github.com/reportaman/arttime/issues/16 is because of missing smcup(te),rmcup(ti) in your xterm-256color termcap. Those error messages got overwritten when arttime was exiting so you missed noticing them, this can never happen if terminal supports alternate screen (which yours does but your termcap says it doesn't). That's because arttime would run in alternate screen, not affecting the contents of main screen. It won't happen with tmux-256color on your system as its termcap mentions that capability... Let's continue the discussion here on what can be done so other developers and users time is not wasted by chasing stale termcaps/terminfo problems. Ideally we would somehow need to report this to FreeBSD developers who maintain that part of OS. Unlike other developers I don't find value in pushing the problem elsewhere by hacking around user's database by embedding some sequences that work for some terminals. The whole idea/contract of having a termcap/info database is that developers should not embed escape special sequences in their applications, and users should keep their termcap/info database up-to-date. Cc: @ThomasDickey
@grahamperrin Update: I was able to fix the termcap database that FreeBSD ships with, and can confirm that everything works smoothly after following these steps to add some missing capabilities to termcap (that are part of their terminfo counterparts). Please let me know if you also see it fixed after following the steps below. Here's are the steps to correct your termcap database on FreeBSD13.1-RELEASE:
/usr/share/misc
termcap
and termcap.db
under that directory.termcap
&& chmod +w termcap.db
.termcap
in editor of choice.xterm-256color
and tmux-256color
to find their respective entries in the file, and replace their entry with updated capabilities:
xterm-256color|xterm alias 3:\
:Co#256:pa#32767:\
:AB=\E[48;5;%dm:AF=\E[38;5;%dm:te=\E[?1049l:ti=\E[?1049h:SA=\E[?7h:RA=\E[?7l:tc=xterm-new:
tmux-256color|tmux with 256 colors:\
:so=\E[7m:se=\E[27m:te=\E[?1049l:ti=\E[?1049h:SA=\E[?7h:RA=\E[?7l:\
:tc=ecma+italics:tc=screen-256color:
$ cap_mkdb termcap
. It will regenerate new termcap.db in the same directory.termcap
&& chmod -w termcap.db
.As an additional step, open a pull request on FreeBSD for most up-to-date termcap. Not sure if there is a reliable way to generate that from @ThomasDickey's latest terminfo database.
… to correct your termcap database on FreeBSD 13.1-RELEASE: …
It's not my everyday system (I have a few virtual machines running RELEASE versions of the OS).
My everyday system is 14.0-CURRENT, will steps be the same?
… a pull request on FreeBSD …
Codeberg, GitHub and GitLab mirrors exist, but not for PR purposes for src
.
Instead, we have Phabricator at https://reviews.freebsd.org/, with associated use of Bugzilla 5.0.4 at https://bugs.freebsd.org/.
I was vaguely aware of various terminfo-related commits last year https://cgit.freebsd.org/src/log/?qt=grep&q=terminfo, generally I'm out of my depth with things such as termcap and terminfo.
@grahamperrin I have a 14.0-CURRENT VM, and I never got any errors on it. AFAIK they already moved to terminfos instead of termcaps, so you might not get any errors out of the box. If you do, please let me know.
Steps for termcap database is the same on 14.0-CURRENT. Though if your system uses terminfo by default then you might not hit such errors in first place. A hack to test if your shell is picking termcap or terminfo is to run this $ tset -S -
command. If the shell is using terminfo, it will return error tset: The -S option is not supported under terminfo.
, and if it is using termcap then it will print the entire termcap entry for your $TERM
.
Steps for terminfo database are not the same. It would be series of commands, particularly $ infocmp
and $ tic
. I can post the steps here if you encounter any problem.
If I get time this week I'll try their bug reporting system. Thanks!
Thanks.
14.0-CURRENT, I seem to get:
Do you really want to quit arttime? [y/n]: y%
– only if run without a desktop environment, e.g. at ttyv4
. I don't imagine people running arttime in this context :-) in other words, not an issue.
With my preferred DE (KDE Plasma), there's no cosmetic issue after quit. I'm back to the command prompt, with no remnant of arttime, for example:
% date ; uname -aKU
Sun 2 Oct 2022 16:56:54 BST
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #21 main-n258027-c9baa974717a: Fri Sep 16 15:41:27 BST 2022 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400067 1400067
% echo $PAGER
PAGER: Undefined variable.
% echo $0
/bin/tcsh
% which arttime
/home/grahamperrin/.local/bin/arttime
% arttime
%
@grahamperrin Thanks for further reports. I installed a fresh 14.0-CURRENT and noticed that terminal that opens after fresh install from grub (in VM window of Parallels at least) is not fully featured:
pkg install terminfo-db
to get the latest terminfos. Then logging in again does point to new terminfos.While this application is intended to be used mostly on one's daily driver DE, it is also intended to work perfectly well in a DE-less tty* (like over ssh). Though the terminal running that tty should support basic features like alternate screen, and terminfos on the system being ssh'ed into should have non-stale terminfo/cap databases. You can test this by SSHing into your FreeBSD 14.0 machine from another machine's DE. You shouldn't see the problem of arttime or vi/vim leaving any characters painted on the ssh tty. If you do, try ssh login again after pkg install terminfo-db
or its equivalent on both machines.
The reason the prompt looks more annoying after arttime exits on such environment is perhaps because vim exits by placing the cursor on the last line, I should do too. That way people will get an equally good experience as exiting from vim on such limited terminals.
I will also try to push a better error reporting mechanism in future so error won't be overwritten on terminals that do not support alternate screen.
* Note: I intend to keep adding more tty-only features like better visual feedback for alarm events.
@grahamperrin Pull and give it a try again (without installing/changing anything else), as explained in above comment arttime will imitate vim's exit strategy on environments with limited term capabilities or inaccurate terminfos. In short you should see a clean prompt each time you exit arttime.
Side note: You just got a mention for your testing support in the new release: v1.9.1 release notes
https://github.com/poetaman/arttime/issues/18#issuecomment-1264675619 no longer reproducible.
Thanks!
With https://github.com/reportaman/arttime/commit/34633fce53c44adbe29bf86c6aa53ac7b73a1112 on branch `oldbsdtput':
Is it possible to have a clear command line prompt after quit?
(I have no idea.)