Totally broken in Mate/Gnome terminal. When started, immediately asks if I want to abort the operation. Without any response to this continues operation when focus switched from that terminal window. Left arrow key not operational -- either doesn't react to it at all or shows "Save configuration before continuing?" and doesn't exit newsgroup or rtin when initial list of groups is shown. Returns to where it was when focus switched from the terminal window it runs in. Impossible to exit other than killing the process or by 'Q' (capital) command that doesn't save state and sometimes kills the subscribed groups, even unsubscribing them on the server. Also displays "Bad command. Type 'h' for help." when focus switched on and off the terminal window. Almost works in "konsole" terminal -- everything works as expected, left arrow works, almost OK but also show that "Do you want to abort current operation?" when focus is switched off that konsole window. However, in konsole it is just an annoyance -- that message disappears when focus is switched back to that window and everything continues to work as expected. In Gnome (gnome-terminal) or Mate (mate-terminal) it is totally unusable. Worked OK in Gnome/Mate in Fedora 27 to 38 (maybe even earlier, don't remember) although showing that "Bad command" on focus changes. That was not even an annoyance -- I simply used to ignore that message. It was there for as long I started using Gnome even before Mate fork. Reproducible: Always Steps to Reproduce: 1. Open Gnome/Mate terminal 2. Type e.g. "rtin -g some_nntp_server". 3. Get that "Do you want to abort" message right away. Happens in Mate and Gnome desktop. Machines are fully loaded Dell T5500 -- Dual Xeon X5675 @ 3.07GHz (12 physical cores total), 72 GiB of RAM.
Thanks for the report. I'm able to reproduce the issue.
Ok, so with the latest updates (as of today), it's a bit better. Not unusable any more, but still annoying. It's as if the arrow keys and 'q' key send some extra codes not recognized by tin or its keyboard input library. The issues I can reproduce are: 1. "Bad command. Type 'h' for help." is displayed almost all the time. 2. Using the left or right arrow key to enter/leave groups brings up "Do you want to abort this operation? (y/N)" message, but only if you pressed some other key earlier. Entering/leaving the same group works. 3. Trying to quit using 'q' key doesn't work. Repeated pressing of 'q' brings up "Save configuration before continuing? (Y/n)" message. I'll take a closer look as soon as I have more time. Ideas: 1. One of the updated dependencies is breaking keyboard input. 2. Miscompilation (compare configure.log from F38 and F39). F38 build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2133945 F39 build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2257456
I found some issues related to custom autoconf macros. Scratch build to test here: https://koji.fedoraproject.org/koji/taskinfo?taskID=112173847 , please test.
Never mind, I was able to test that build and it's not fixing the bug.
I've reported this upstream and we're trying to figure it out together. Upstream asked for `stty -a` output from different terminal emulators. Please provide yours, if they're different.
Here it is: Gnome (Mate) terminal: [ksi@maverick ~]$ stty -a speed 38400 baud; rows 30; columns 100; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc Konsole terminal: [ksi@maverick ~]$ stty -a speed 38400 baud; rows 30; columns 100; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon ixoff -iuclc -ixany -imaxbel iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
Thanks. It looks like the only difference is ixoff, but flipping the setting doesn't change behaviour in gnome-terminal. Since tin works correctly in xterm, I agree with upstream that this is not a bug in tin. Reassigning to vte291 for now as this is a common dependency of gnome-terminal and mate-terminal.
For those without access to a Usenet server, here's the public tin one to test and reproduce the issue: $ NNTPSERVER=news.tin.org rtin
Bad news, I'm able to reproduce this on F38 as well. While the 'q' key is working correctly, 'L' (capital ell) is not. In xterm, it invokes the "Enter Message-ID to go to:" correctly, but under gnome-terminal it only shows "Bad command. Type 'h' to help.". And I started getting the "Do you want to abort this operation? (y/N) N" prompt when entering a newsgroup using right arrow key, too. I'll try to identify which package update caused this.
OK, it _IS_ a bug in tin. There might be some changes in GNOME and wherever else but it is ONLY tin that was affected. Absolutely everything else wors as it used to work before. Just look at e.g. alpine -- no problems whatsoever, everything works including right/left arrow functionality to enter/exit message/folder/attachments and whatever else. Everything else also works as it used to -- mc, joe, various text mode utilities, ALL of them. It is ONLY tin that is affected so it is 100% tin's problem. It MIGHT be that some changes affected tin but that ONLY means it was buggy from the very beginning, just that bug was not triggered before. I don't think it is a very good idea to put blame elsewhere for something that made ONLY ONE program to misbehave. And I think it would be justifiable if those guys who are being blamed just reply with "Scrap tin, junk it". It is definitely something with signal handling or termcap/terminfo or something related in tin. The proper way to fix it would be to find out WHAT causes it to output that "Do you want to abort this operation? (y/N) N" message. Should be not all that difficult after all. I would've fixed it myself but simply don't have time to dig into it and trying to understand how that terminal code works in tin. It is mostly working in konsole so I can live with it for a time being. Awkward and inconvenient but not totally screwed as it is in gnome/mate.
Indeed. Apparently, recent change in terminfo exposed this bug, reassigning back to tin. I'll go back to tin upstream and try to figure it out. It is reproducible in xterm. For now, a good work-around is to set: use_mouse=OFF in ~/.tin/tinrc
Upstream supposes this to be the issue reported in October here: https://github.com/vim/vim/pull/13440 and resolved here: https://lists.gnu.org/archive/html/bug-ncurses/2023-10/msg00117.html (Fedora package maintainers might want to apply a small change to terminfo)
I can confirm this is fixed in Fedora 40 with ncurses 6.4-12.20240127.fc40, so a backport to Fedora 38 and 39 would be appreciated. Reassigning to ncurses.
Updating misc/terminfo.src to 20231028 would be the simplest change. https://github.com/ThomasDickey/ncurses-snapshots/commit/0daa37c5fb53ac883424599b93fa152f23643398 https://github.com/ThomasDickey/ncurses-snapshots/commit/0daa37c5fb53ac883424599b93fa152f23643398#diff-01544c577762d3308a1d232aa7afc79acf64b9a5057f88a004df82fda89549b7 diffs to terminfo.src may look "large", but that's mostly due to formatting.
Thanks for the suggestion. I'll prepare updates for F38 and F39.
FEDORA-2024-399b399916 (ncurses-6.4-7.20230520.fc39.1) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-399b399916
FEDORA-2024-9e02bc2225 (ncurses-6.4-7.20230520.fc38.1) has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9e02bc2225
FEDORA-2024-399b399916 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-399b399916` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-399b399916 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-9e02bc2225 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9e02bc2225` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9e02bc2225 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-399b399916 (ncurses-6.4-7.20230520.fc39.1) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-9e02bc2225 (ncurses-6.4-7.20230520.fc38.1) has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.