[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Promote Screen? Include .screenrc!

From: Trent W. Buck
Subject: Re: Promote Screen? Include .screenrc!
Date: Wed, 01 Oct 2008 11:18:40 +1000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

address@hidden writes:

> Some years ago, I tried several Linux distros and found /etc/screenrc
> quite minimalistic.  It took me a long time to adapt the .screenrc to
> my needs.

Screen definitely has a big problem with discoverability.  Very often,
I'll be chatting to someone and they'll say "oh wow, screen can do that?
I never knew!"  And "that" could be anything from auto-naming windows
with :shelltitle to connecting to talking to serial ttys (replacing
minicom) to entering latin-1 characters using :digraph.

(Incidentally Micah, implementing all the digraphs documented in the RFC
would be a neat Unicode-related enhancement.)

> So, my idea was:  Why not use the combined knowledge of the people
> on this mailinglist to compile a user-friendly, yet powerful initial
> .screenrc-configuration and ship it to the individual package-maintainers?

I'm strongly against integrators shipping their favourite customizations
as the default configuration.  Let me give an example: a few months ago,
RMS decided that the colour red was too hard to read on his terminal, so
he changed the DEFAULT emacs configuration so that comments have the
same colour as normal text on the terminal.  To get the old behaviour
back, I have to add about 30 lines to my .emacs -- whereas RMS could
have just added a single line to *his* emacs to turn that color off.

Summary: fixing unwanted changes to distro-specific on-by-default
features is difficult and annoying.  Don't make distro-specific tweaks
unless you have a REALLY good reason.

IMO a better approach would be to have a documentation resource that has
a number of articles that explain how to use Screen features in "real
world" scenarios.  For example, rather than just saying "use ^A^M to
turn monitoring on", you'd start with a problem "how do I know when
people are talking in IRC, using irssi?" and then discuss how to
implement it effectively -- which would include not only discussion of
:monitor, but also how to do things like turning off the clock in irssi,
so you don't get "spurious" activity every minute when it changes.

(I started writing a "Screen Hacks" book along these lines, but got
distracted appallingly quickly.)

If you just dump a bunch of .screenrcs somewhere with the (typically
limited) commentary to explain what each part does, all you'll end up
with is the scenario where people just copy-and-paste other people's
.screenrcs wholesale, with no understanding of what they do.  This tends
to cause regressions -- for example, someone might accidentally copy my
"sorendition = dd" line when they are trying to get my hardstatus
configuration, and then complain that their hardstatus line doesn't have
colour anymore.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]