too many windows overflows caption line

Bug #369828 reported by psifertex on 2009-04-30
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
byobu
Wishlist
Unassigned

Bug Description

When more screen windows have been created than will fit in the caption line, the overflow is handled poorly.

In contrast, consider the following caption line:

caption always "%{=}%-Lw%50L>%{r}%n%f %t%{d}%+Lw%?%{g}%-32= %c %l %Y-%m-%d"

It automatically adjusts the focus of the shown windows to include the highlighted window and the extra windows are replaced with elipses. Also, it never runs the stats off the window either (in the above example, time, load, and date)

Related branches

Dustin Kirkland  (kirkland) wrote :

Hi there,

Thank you very much for the bug report.

I can confirm the issue, I see something very similar here. And I did try the screenrc fragment you included. It works as you say:

0$ u1 1$ bash 2$ bash 3$ config 4-$ bash 5$ bash 6$ bash 7$ bash 8$... 23:28 0.47 0.38 0.55 2009-05-13
and
...h 2$ bash 3$ config 4$ bash 5$ bash 6$ bash 7$ bash 8$ bash 9$ bash 23:28 0.75 0.46 0.56 2009-05-13

Note this from screen's manpage:
       = pad the string to the display’s width (like TeX’s hfill). If a number is specified, pad to
              the percentage of the window’s width. A ’0’ qualifier tells screen to treat the number as
              absolute position. You can specify to pad relative to the last absolute pad position by
              adding a ’+’ qualifier or to pad relative to the right margin by using ’-’. The padding trun‐
              cates the string if the specified position lies before the current position. Add the ’L’
              qualifier to change this.

       > mark the current text position for the next truncation. When screen needs to do truncation,
              it tries to do it in a way that the marked position gets moved to the specified percentage of
              the output area. (The area starts from the last absolute pad position and ends with the posi‐
              tion specified by the truncation operator.) The ’L’ qualifier tells screen to mark the trun‐
              cated parts with ’...’.

This won't quite work for us. Note two parts of the configuration:
%-Lw%50L>
and
%-32=

It's the "32" that's a problem here. In the example that you gave, "%c %l %Y-%m-%d" always expands to exactly 32 characters. Unfortunately, we can't be quite so predictable, as your username/hostname/ipaddress are of varying lengths, and you can turn these status items on and off.

Unfortunately, this isn't going to work for us. I'm sorry.

:-Dustin

Changed in byobu:
status: New → Won't Fix
psifertex (launchpad-psifertex) wrote :

What if there were an option that allowed you to choose whether to precompute the length of those strings. After all, the hostname and username aren't likely to change while screen is running. Maybe even have separate selection items in the list, "hostname -- fixed" or some such. I think that the benefit of not having the windows overflow the caption greatly outways the benefit of being able to dynamically update the hostname in the rare event it actually changes.

After all -- it's a wrapper script that computes what to enable/disable anyway, there's no reason it couldn't switch out between a fixed-width pre-computed caption, and a dynamic one. Besides, most of the really dynamic stuff runs in hardstatus, not caption anyway.

Dustin Kirkland  (kirkland) wrote :

I tried a few things last night, but didn't have much success.

Basically, I created a status script that computed that length, and tried to insert it into the caption line. Unfortunately, it didn't work. I'll re-open the bug in case I find a solution.

:-Dustin

Changed in byobu:
status: Won't Fix → Confirmed
Dustin Kirkland  (kirkland) wrote :

I deleted the code already, but here's a snippet from my scrollback...

:-Dustin

psifertex (launchpad-psifertex) wrote :

Thanks for trying. If I can, I'll try to play with it myself some. I worked on the original caption I pasted above a long, long time ago and all I really remember was how much of a pain it was. If I can come up with a good way to automate the fixed-width calculations, I'll give it a whirl. I think it'd definitely be nice to have.

Cheers! Your contribution would be *very* much appreciated.

:-Dustin

Changed in byobu:
importance: Undecided → Wishlist
Dustin Kirkland  (kirkland) wrote :

Okay, I found a neat hack that solves this. Fix committed, will be in 2.20 release.

:-Dustin

Changed in byobu:
status: Confirmed → Fix Committed
psifertex (launchpad-psifertex) wrote :

Cool! Is there a link to the changeset? I'm curious what you did.

Changed in byobu:
status: Fix Committed → Fix Released
Dustin Kirkland  (kirkland) wrote :

On Sun, Jul 12, 2009 at 2:03 PM, psifertex<email address hidden> wrote:
> Cool!  Is there a link to the changeset?  I'm curious what you did.

See lp:byobu

:-Dustin

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments