I frequently have trouble using Emacs under screen because sometimes erase and backspace get switched, resulting in emacs believing every backspace is a Control-h for help. For some reason I always forget the command to fix this. For now and future reference, the fix is:
I highly recommend upgrading to Emacs CVS-HEAD as it now includes multi-tty emacs. Multi-tty allows console or graphical frames to attach to an existing emacs server on the system, regardless of the graphics mode. What this means is that I can start a server using
(server-start) in an emacs session under my screen session. I can then connect to this instance of emacs using
emacsclient from both another console, or from a graphical frame. Since all of the buffers are shared between instances I no longer need to worry if I remembered to save changes to a buffer of another instance running on the same computer.
It does have a few bugs that remain to be fixed. If I forget and invoke
screen -DAr from another console that forceably disconnects both the screen on the other terminal, as well as the other terminal. If that terminal is also hosting the graphical emacsclient it seems to kill both the emacs client and the hosting emacs server. I’m sure this issue will be corrected prior to the next official release.
Given that RMS has just stepped down as the maintainer for GNU Emacs1, perhaps a new release is forthcoming sooner rather then the more usual later. Moving away from CVS to a more distributed SCM may also assist in this venture.
I have returned to using
Ctrl-z as the prefix code for screen commands. Despite it’s obvious shortcomings by overriding normal process suspension, it does not impair
XON/XOFF terminal status in the way
Ctrl-q did. As a side effect this would also break creation of new screen-shells in screen, as they would not forward key events back to the main screen session. This prevents screen switching until the newly created screen-shell is terminated. The
Ctrl-a code despite being the default screen prefix is not suitable as it overrides emacs/bash keybindings for beginning of line. Finally,
Ctrl-z still allows for process suspend using
Ctrl-z is a bit cramped, but as a bonus it does make it easier to eat or drink and monitor several screen-shells at the same time.
Following in my adventures in discovering the total uselessness of fedora core [3,4] I have discovered a whole new set of issues to complain about. I discovered the best way
to fix both the weird iso image sizing/md5sum problem and the unreliability of the cd install medium to successfully install every package is to do a network install. Which works great for me since wuarchive is accessable as a nice reasonable speed of about 8 megs a second. Somehow I don’t think it works well for most people though.
I fail to see why distributions like Fedora core are immensly popular. Fedora core and any corresponding system based on rpm and dependent on the anaconda installer all suffer from the same fatal flaw. If any single rpm fails to install, the entire install process is halted and must be restarted. It doesn’t pause and ask you for a different source for the rpm, in this day and age it could probaby even download the specified rpm online, let alone just wait for you to clean the install disk.
The problem is exacerbated by the fact that as near as I can tell Fedora Core install disks are the most finicky disk images I have ever encountered. The only possible way I can even get a system installed is to install bare GUI desktop install.
Yet once the base system is installed the problems still continue. Apparently it’s only possible to manually select all the packages you didn’t get to install with yum. There is a gui for selecting additional packages but it suffers from the same problem the original install gui suffered from, ie a single failure kills the whole process. I don’t know if this is better here or worse, on the one hand at least you can try several different combinations without needing to walk back through the entire disk formatting procedure, but on the other it would definitely seem logical to allow the tool to download packages from a remote location if the cd fails.