Bug 287045 - sysutils/screen50: hardstatus string fix/workaround
Summary: sysutils/screen50: hardstatus string fix/workaround
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Cy Schubert
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-24 12:13 UTC by Xander
Modified: 2025-05-27 19:21 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (cy)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xander 2025-05-24 12:13:52 UTC
I really liked the hardstatusline as defined in the screenrc.sample of screen version 4.x so I've tried to adapt the string definition to get a (almost) similar one for screen50.

Current screen50 version:
> hardstatus string '%{2;0}[%{+b2}%H%{-}][%= %{7}%?%-Lw%?%{+b1}(%{+b7}%n%f%t%?(%u)%?%{-})%{-}%?%+Lw%?%= %{-}]%{+b6}[%m/%d/%y %c]%{-}%{-}'

First try to get the colours (foreground and background) back as in in 4.x:

> hardstatus string '%{2;0}[%{+b10;0}%H%{-}][%= %{7;0}%?%-Lw%?%{+9;0}(%{+15;0}%n%f %t%?(%u)%?%{-})%{-}%?%+Lw%?%= %{-}]%{+b14;0}[%m/%d/%y %c]%{-}%{-}'

This is basically the same but with explicit setting of *both* foreground and background and using numbers from the range 8 to 15 for high(er) intensity ANSI colours. I still used the b (bold) to get the intensity almost the same as in 4.x.

This string however also fails to highlight the current window with red () if and when it is the only/last window. With multiple windows and the last one being the current one, the highlighting appears somewhere in the area before the current window. This suggests some kind of padding/alignment bug.

As a workaround I added a space after the last ')' of the current window. It slightly messes up the layout (too much spacing between current and next window if you have multiple windows) but the highlighting now works as intended. So the following string works for me:

> hardstatus string '%{2;0}[%{+b10;0}%H%{-}][%= %{7;0}%?%-Lw%?%{+9;0}(%{+15;0}%n%f %t%?(%u)%?%{-})%{-} %?%+Lw%?%= %{-}]%{+b14;0}[%m/%d/%y %c]%{-}%{-}'
Comment 1 Xander 2025-05-24 15:37:30 UTC
To get rid of the extra space in the workaround a backspace (^H) works so an ugly but working string is:

> hardstatus string '%{2;0}[%{+b10;0}%H%{-}][%= %{7;0}%?%-Lw%?%{+9;0}(%{+15;0}%n%f %t%?(%u)%?%{-})%{-} ^H%?%+Lw%?%= %{-}]%{+b14;0}[%m/%d/%y %c]%{-}%{-}'
Comment 2 Cy Schubert freebsd_committer freebsd_triage 2025-05-26 14:56:29 UTC
I opened up a ticket with upstream last year and another a month ago. I'm waiting on them to fix the problem.

Your fix seems to work.
Comment 3 commit-hook freebsd_committer freebsd_triage 2025-05-26 15:01:15 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=2faaf242638cb6258789520d77ecae5d82227358

commit 2faaf242638cb6258789520d77ecae5d82227358
Author:     Cy Schubert <cy@FreeBSD.org>
AuthorDate: 2025-05-26 14:58:36 +0000
Commit:     Cy Schubert <cy@FreeBSD.org>
CommitDate: 2025-05-26 15:00:57 +0000

    sysutils/screen*: Work around hardstatus regression

    The workaround provided by the submittor works better than the hardstatus
    line provided by upstream.

    PR:             287045

 sysutils/screen-devel/Makefile              | 1 +
 sysutils/screen-devel/files/screenrc.sample | 2 +-
 sysutils/screen50/Makefile                  | 2 +-
 sysutils/screen50/files/screenrc.sample     | 2 +-
 4 files changed, 4 insertions(+), 3 deletions(-)
Comment 4 Cy Schubert freebsd_committer freebsd_triage 2025-05-26 15:10:12 UTC
Thank you for having the persistence and patience to resolve this issue.
Comment 5 Cy Schubert freebsd_committer freebsd_triage 2025-05-26 22:11:56 UTC
Comments with hardstatus resolution left in upstream bugs 66141 and 67155.
Comment 6 Xander 2025-05-27 18:41:49 UTC
Thanks. Note that the ' ^H' workaround 'fixes' the colours and highlighting for the only/last window title but it will make the status line 2 characters too short (i.e. the status line doesn't take the full width of the actual terminal). 

So there is still a bug somewhere, perhaps not in the string definition but in the parser code.
Comment 7 Cy Schubert freebsd_committer freebsd_triage 2025-05-27 19:21:21 UTC
(In reply to Xander from comment #6)

I suspect there is a bug in the parser somewhere. I don't have the time to dig into this (working on the MIT KRB5 import).

Upstream didn't respond quickly to the first bug I filed. Neither to the second bug.