From mboxrd@z Thu Jan  1 00:00:00 1970
From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
Date: Thu, 09 Apr 2009 13:55:56 +0200
Subject: [sup-talk] Read only mode for sup
In-Reply-To: <1239226676-sup-7216@entry>
References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad>
	<1239217190-sup-5981@chigamba> <1239226676-sup-7216@entry>
Message-ID: <1239278036-sup-7327@ausone.inria.fr>

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