Re: Windowlist menu customization

[Chris Jones]

On Mon, Jun 25, 2018 at 02:26:12PM EDT, Amadeusz Sławiński wrote:
> On Mon, 25 Jun 2018 12:38:48 -0400
> Chris Jones <address@hidden> wrote:
>
[...]
>
> (I don't think it's possible with current screen, you would need to add
> some kind of tty escape for windows command, so you can get list of
> window ttys.)
> Eh... whatever, I pushed %T escape to git, so if you rebuild you can
> screen -Q windows "%T " and it will give you list of windows ttys ;)
>
> And then write script traversing process tree on this tty and I think
> you still could get some false positives.
>
> This is example of runnning "man man" in one of my shells in screen:
> $ ps ao pid,tty,ppid,comm,args | grep pts/2
>  4696 pts/2     4681 zsh             -/bin/zsh
>  5076 pts/2     4696 man             man man
>  5103 pts/2     5076 less            /usr/bin/less
>
> So if you traversed linearly it would show you /usr/bin/less, while
> running "man man" ;)

Yes, but the one that sits right on top of the shell (here 'man') is the
one we want. Leaves the problem is that if you have typed 3 man commands
in 3 different windows  you want to be able to tell at a glance which
one you want to go back to. So just 'man' by itself is not really good
enough.

> I think better idea is to make sure that applications which can set
> window title actually do set it to something meaningful.

Well... for one thing I do not want to clutter up my hardstatus line
with window TITLES that may be arbitrarily long if you include the
command's flags and argument(s) (e.g. the 'find' command) or lengthy
pipes such as 'command1 | command2 | command3 [| command4...]'... Not to
mention one-liners of this type: "for $(ls ...); do; echo... ' command1;
sleep 2; command2; ...; done... where command2 might for instance be an
awk or sed script for instance...!

In any case, thanks for quickly replying... and confirming that what
I had in mind is not possible with the current GNU/screen setup... and
that it may even not a sensible thing to consider in the first place.

I can (very vaguely so) think only of one option: have GNU/screen
maintain some kind of history of what the user types in each window and
make the last command entered available to user subprocesses (e.g. to
backticks) via an environment variable, which the backtick script could
format to further suit the user's requirements.

One thing I briefly look at was enabling logging to ~/screenlog.n where
n is the window number and reading that file from my backtick... but
it looks as if the backtick specified via 'windowlist string "... %n`"
does not have access to the $WINDOW variable.

Basically, what I am saying is that the 'windowlist' screen should
provide the user with an overview of his GNU/screen session... so that
he could tell what's going on in each window without having to go
through all of them sequentially... pretty much what a user with a ramp
of 12 terminals above his desk can quickly glance at them to remind
himself of what runs where when he comes back from his coffee break...

That's what I have in good old WindowMaker... I just hit CTRL+ALT+' and
I have a list of all my workspaces with the application(s) running in
each one of them in case I need a reminder.

Since it does not provide any additional information that is not already
in a reasonably designed hardstatus/caption line (or the CTRL+a
w list)... as it is currently implemented the windowlist screen could
just as well be removed and nobody would notice. ;)

CJ