Re: Great SWT Program

In article <a6c83212-d35b-4362-85af-0bbbda80d662@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<twerpinator@xxxxxxxxx> wrote:
On Nov 19, 5:53 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
You misunderstand me -- deliberately again, I expect.

When I start up screen, it automatically launches five applications in
different screen windows.

That is odd behavior for this software to have. At least from a
standpoint of user satisfaction.

It does so because I've told it to.

Consider web browsers. Ordinarily people will go to different sites or
do different things each time they run one, so the most logical
starting point is either a blank page or a search engine, particularly
Google.

My FireFox and Opera browsers also tend to launch with 4-10 different
tabs already open. One tends to have the Java APIdoc, one may have
APIdocs for a few other central libraries, one may have the last thing
I was doing so I can just get right back to it, etc.

Likewise it should be possible for you to
reconfigure screen to start up with only a single session open on a
command prompt in your home directory

This is largely the default situation.

Then again, perhaps you do always do the exact same thing, although
then all you would seem to need is one terminal that pops up running
trn (or whatever it is you use to assault cljp with off-topic
posts). :P

I might have one for mail, one for news, one for emacs, one for irc, a
couple shells for general stuff, etc.

"screen vi blah.txt" will launch "vi blah.txt" in a new window.

Eh? Nesting screen instances?

No, a new window in the same instance.

That sounds like an even bigger pain,
even assuming it's fully reentrant. Won't the outer one eat the same
keys that you'd need the inner one to see to operate the inner one?

It would if you /did/ launch one inside another (which isn't what the
above does). You would presumably want to launch the inner one with a
different hotkey.

The excellence of screen in situations of misbehaving networks, as
above, is that it will actually remember all your sessions for you and
restore them when you log back in and and reattach to them.

That's not behavior I recall observing, probably because the
circumstances were different: you're describing the network connection
between your terminal and the remote machine running screen going
kaput; if screen itself hangs or abends, presumably the session state
doesn't get saved.

In this situation, of course, anything could happen. It's not
something I've observed so I can't really say much more than that.

Your killer feature becomes a source of pain when combined with a hang
bug like described, as it just so happens.

There is a "screen -wipe <name>" that can be used to get rid of dead
instances but still, the situation you describe would certainly be
annoying.

Screen only captures C-a. I have remapped this to C-v since I like to
use C-a in emacs. The installation you used may have been configured
to capture C-w of course.

Still got to pick something. If all the apps you ever wanted to use
inside it adhered to CUA, you could pick something relatively useless
like C-x (and use shift-del for cut, or C-c del) that won't be bound
to anything application-specific and it wouldn't impair your use of
any application. Ditto if they all adhered to *some* common set of
bindings, with at least one of those fairly superfluous. But unix text
mode apps are like pre-CUA MS-DOS ones: they all have their own
different and idiosyncratic ones and any choice at all will inevitably
collide with something you want to use in at least one of them. C-v
presumably is the least worst choice given the apps you tend to use,
but ... ouch.

It' s not one I use much, no. And if I need it after all, C-v v causes
screen to forward a C-v to the application.

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.