Excerpts from William Morgan's message of Wed Apr 08 23:49:47 +0200 2009: > Reformatted excerpts from Wirt Wolff's message of 2009-04-08: > > However, when for example, composing reviews of unapplied patches, > > each with one or more discussion threads, I often find myself wishing > > I could toggle back and forth between a couple of search buffers and > > their thread views in one frame, while composing in another. > > The curses code was designed to support splitting the screen into > multiple buffers/frames/windows. I, too, found the initial > implementation of one buffer at a time to be surprisingly useful, so I > never took it the rest of the way. I'm certainly open to someone > fighting curses and making this possible. > > As possibly an easier step, I, too, too, find the current buffer- > switching to be pretty onerous, and would love to hear suggestions on > how to improve it. > > One easy thing to comes to mind would be to have buffer-list-mode (which > is what you get when you hit B) sort the buffer list by last access. > Remap that to something like ";" and you have one-handed buffer- > switching with minimal keystrokes.
Or some kind of historic like with "cd -42". It could be "b1" for the last one, "b2" for the previous... I actually use these bindings in my window manager. > > A read-only second sup would get daily usage here. It would be great > > to not have to switch to and from "sup mode" while completing tasks > > referencing multiple threads. > > I think this would be fine and not too hard to implement. > > In fact, I think it might not be too much harder to have multiple > simultaneous read/write Sups, by locking ~/.sup on a per-operation > rather than per-process basis. Of course you'd have to be cognizant of > the fact that they wouldn't be sharing any state except via $ and @. > It would be like editing a wiki page across multiple tabs. There's no > merge, there's only overwrite. Simultaneous read/write Sups would be great too! -- Nicolas Pouillard _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
