too many windows overflows caption line

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

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.

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

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

:-Dustin

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

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

:-Dustin

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

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