[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windowlist menu customization
Re: Windowlist menu customization
Tue, 26 Jun 2018 08:48:53 +0200
On Mon, 25 Jun 2018 17:45:03 -0400
Chris Jones <address@hidden> wrote:
> 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
> > 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...!
That's why I told "something useful", my vim sets window title to:
Also if window title is too long it gets cut off at 20 characters, if
you use %w,%W escapes, %t will show full title.
> 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.
OK, I think I may be bit confused about what you are trying to do here.
If you want to set title based on what you just started in shell it's
possible right now...
or just search for "gnu screen set window title bash" (or some other
> 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. ;)
> screen-users mailing list