brhfl.com

dvtm and the mouse

This is an old post from an old blog; assets may be missing, links may be broken, and my opinions may differ considerably by this point…

I've gotten quite a few hits from people searching for things like 'dvtm pass mouse.' I don't have much to say on the matter, except that this is the one thing that really bugs me about dvtm. As I have mentioned previously, given the choice between screen, tmux, and dvtm, I like dvtm the best. It is certainly the simplest, and has the smallest footprint. It automatically configures spaces, and makes notions of simultasking as simple as double-clicking. I would say that it brings the best of the GUI experience to terminal multiplexing, while still keeping true to the command line.

But, like many great things, dvtm has problems. First are the bizarre graphical glitches…

toot toot
…which seem to be from dvtm using white instead of 'clear' or 'background' to fill space. This only happens on certain triggers it seems - for instance, clearing the window with the clear command or Ctrl-L renders negative space properly. It's bizzare and irritating, but livable.

But, obviously I want to talk about the mouse here. I actually have two different builds of dvtm installed. One is from MacPorts, the other I either built from source (probably) or installed from Homebrew. The MacPorts version has mouse support compiled in. This makes simultasking very simple, and (as mentioned above) brings some of the best of GUI convenience to the command line. Unfortunately, it prevents mouse reporting inside of windows. So, if I'm running elinks in a dvtm window, I can't click links, etc. The solution would seemingly be to disable mouse control of dvtm using Mod-M (Ctrl-G M), but this leaves me with no mouse control of dvtm, as well as no mouse reporting. That is to say, it's not a solution.

The other build I have, does not have mouse support compiled in (by the omission of CFLAG CONFIG\_MOUSE). On this one, mouse reporting goes through to the windows, with some caveats. First, obviously you'll need to use the keyboard to manage dvtm itself. This defeats part of the purpose, but dvtm's simplicity lends itself to easily learned keyboard support. Changing the modifier to Ctrl-A or something else not in the middle of the keyboard helps too. The other oddity is that since dvtm basically just ignores the mouse input, and it prints the window info at the top of the window, mouse clicks are off by one row. That is to say, if I want to click the 'I'm feeling lucky' button in elinks, I have to click one row above it. Other than that, everything works as it should - left, middle, right clicks and scroll, with one additional caveat.

The notion of a multiplexer is such that scrolling outside of the multiplexer window is not desirable (the multiplexer should fill the terminal, and have its own scrolling mechanism). This leads to one more problem - while I can use the scroll wheel for scrollback in a normal terminal session, hitting the scroll wheel inside a dvtm session produces garbage (unless the program running understands it). Coupled with a touch-sensitive mouse that is easy to accidentally scroll while you're typing, this can become irritating quickly. As is the typical keyboard-based scrollback method common to the big multiplexers - one area where the GUI really has something going for it.

I only really post this here, because I've run through the motions with dvtm, and I do use the mouse on the command line often enough. There's no perfect solution, but the only livable solution right now seems to be just building dvtm without mouse support and getting used to the keybindings and being careful. And the single row offset. Maybe I'll crack open the code some day, and realize I'm in way over my head, and then proceed to not actually fix anything…