From mboxrd@z Thu Jan 1 00:00:00 1970 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 08 Apr 2009 14:49:47 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239217190-sup-5981@chigamba> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> Message-ID: <1239226676-sup-7216@entry> 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. > 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. -- William