dtach and dvtm, Modern Tools Ancient Interface

Been pretty interesting in the past few weeks from a technology stand point,

Have been working on writing a custom Linux device driver, while this in it by itself should be interesting what was even more interesting is getting to know the tools and adjust them to my (one would think) particular taste.

Been wanting for a while to get to know a powerful text editor, I wasn’t looking for a cult in particular but accepted that it is more than likely be part of the deal.

well back when I was playing with the very first versions of MythTV (it must have been 2003) I got to know the advantages of remote accessing my Linux box which must have been Mandrake (recently I  learned a whole lot about the plant while wikipedia surfing, but this is another story all together) , I use to access my personal little hacked projects every chance I had and pretty quickly became a fan of ssh (by all means more useful than sliced bread) combined with ‘GNU screen’

(incidentally the reason I prefix screen with GNU is not because I subscribe to the idea where if something was compiled with GCC it should be prefixed with GNU rather that ‘screen’ is such a common word in the technology context that writing ‘GNU screens’ clarifies that one discusses the software rather than the hardware but this is most definitely for yet another discussion.)

to go with GNU I had to work with one of them text mode editors and for reasons I can not remember I started to work with Emacs more frequently, this was the very basic of all text editing, hack a perl script here and there to acquire xmltv or fix some issues with QT display widget nothing big, by all means not an extensive use.

Having started my new job in the last two years have had the chance to dive for the first time in my professional life in a mostly Linux environment, and I was pretty excited and decided to take the opportunity and finally deepen my knowledge of Emacs.

Religions aside I’m loving it,  the bloatware doesn’t bother me as disk space is never an issue now days and when learning new-trick-from-old-dogs most of the dependencies are already built in.  for the most part the learning curve is well worth it as I pick new uses to Emacs they tend to use a consistent key binding and design philosophy. but by all means the killer feature for me is the fact that it’s a full featured text editor (the running joke is that Emacs is a good operating system lacking a good text editor)  that runs completely in text mode, now I can get whatever runs under over and with Emacs accessible anywhere ssh and screen are available and this is just great for me.

Having learned that I quickly started to have a separate Emacs session each running inside a screen per project, picked up a few tricks from Emacs Fu and googled the rest. I’m fairly happy with my system going.

Got to the tweaking level where I like the 256 zenburn emacs color scheme going on after struggling a bit with putty, Ubuntu and Emacs to convince them all they do support them 256 colors. I’m also using the same .emacs both on my Ubuntu and my OSX after learning enough emacs-lisp to survive.

The thing I love the most about this setup is that I would leave work say in a middle of debugging an issue, drive home eat dinner or whatever and ssh to work type

screen -R session.drivers

and I’m right there were I left everything and it takes me a few seconds of recap in my head to continue from where I’ve left, this is just great.

however the quest for convenience and productivity never ends.

see at home I have this 24 inch dell 2408wfp, which by the way is a great non-GNU screen which I bought the second it was available on the  market,  actually I think I may have even pre-ordered. This means that at home I have way more non-GNU screen real estate and my ssh screen sessions could just be laid out side by side, or tiled if you will. but if they’re tiled anyhow why won’t I just let a tiled-windows-manager do the job for me? plus it would save me all these keyboard taps that I can later spend on say communicating all these very-particular thoughts.

looking around a bit I found dvtm which is tile-text-mode-window-manager: exactly what I was looking for.

so the plan is to have 4 windows tiled, each connected to a pre existing (and different)  gnu not unix screen  session,

so to give you an idea I’d like to have:

quarter of my screen dedicated to an Emacs session with my driver source code, toolchain etc.

quarter dedicated to my test application source code, compilation window, shell to run it etc.

another quarter for a serial port with log of the target etc.

and the last (and yes least) quarter to I don’t know something else (right now I have my dvtm cheat sheet there, but it is way too much real-estate for it going forward)

so I do that by creating four dvtm windows (this is by the way C-g c in the default binding which is not Emacs friendly *sigh*)

I then in the shell prompt I get in every dvtm ‘windows’ issue: ‘screen -x 1235.drivers’ to ” “Attach to a not detached screen. (Multi display mode)”, this is great as it allows me to have two ‘views’ to the same screen session, and then after repeating all this three times I have all my Emacs sessions tiled across my entire 24″ screen and if I put Putty to full screen mode it looks like I do rocket science in my spare time (I don’t, I’m just enough of a sucker be working on my spare time).

it’s true that screen is holding my Emacs sessions alive and dvtm is tiling them all nice for me but It’s awfully a lot of work to reconnect and C-g j between the windows and look for the right screen session to connect, I’d like to be able to do all that in one tap, well I’ll be willing to settle for typing one line of text to the command line ideally with just searching the shell’s history.

well why won’t we permanently run dvtm inside GNU not unix screen such that all I need to do is reconnect to a screen session that will run dvtm that will run 4 windows each running a screen session connected to an older screen session in sharing mode.

why won’t we indeed. having tried that I’ll tell you why not: because it’s messing up the background color in emacs, more specifically when I run emacs inside dvtm that runs inside screen I get only the text with the zenburn brown background all the blank space around it is as black as Unix can make it, this is no good(tm) after spending all these late night hours getting colors to work to my liking. see I would debug this if I had the slightest clue where to start, it’s quite weird because screen on it’s own runs Emacs and doesn’t screw up the background color, same goes for dvtm I can run Emacs inside dvtm and it shows the background color just fine. it gets even weirder: I can run Emacs inside screen inside dvtm and it will be OK, it’s just the combination of screen->dvtm->emacs that is no good. to iterate:

dvtm->screen->emacs OK

dvtm->emacs OK

screen->emacs OK

screen->dvtm->screen->emacs NOT OK.

(insert apology for making people dizzy)

so I figured I’ll try running dvtm inside tmux,: no go, exactly the same problem, down this thread they seems to experience the same problem (just with dvtm and man), looks like an issue with way the background color is refreshed or something.

then I found to solution dtach: running dvtm inside dtach and then running screen and Emacs inside the screen session did not screw up the background color in emacs.

Just do one thing well.

so who’s writing this M-x podcatcher-mode ?

This entry was posted in remote, Technology and tagged , , , , , , , , , . Bookmark the permalink.

4 Responses to dtach and dvtm, Modern Tools Ancient Interface

  1. anon says:

    why dvtm at all??? screen can do all that on its own too, plus it’s scriptable so you can very well get what you want at the push of a button with a few lines in your conf

    i see people recurrently getting trapped in this pitfall due to dtach and dvtm now being fashionable or something, i guess no one reads the documentation anymore, gnu screen is a brilliant, flexible and powerful tool, it’s sad it’s so often underestimated

    • mousecradle says:

      gnu screen is great, I remember that I was impressed when I first discovered it and I have been using it for many years, actually I did start to look into solving my problem using only screen and while researching I came across tmux, dvtm and finally dtach, you’re probably right that I could solve my problem using only screen, but as both dvtm and dtach are carried by the distribution I use (Ubuntu) and are easy to install and configure what’s the harm of using them to go along with good old gnu screen?

  2. MichaelWH says:

    One reason I don’t like using screen in place of dvtm is that screen only splits the screen horizontally. I like having tiles, not slices.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s