[EMAIL PROTECTED] 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. _______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
