From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
Subject: [sup-talk] Read only mode for sup
Date: Thu, 09 Apr 2009 13:55:56 +0200 [thread overview]
Message-ID: <1239278036-sup-7327@ausone.inria.fr> (raw)
In-Reply-To: <1239226676-sup-7216@entry>
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
next prev parent reply other threads:[~2009-04-09 11:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-07 18:26 Nicolas Pouillard
2009-04-07 23:29 ` Ian Smith
2009-04-08 8:36 ` Nicolas Pouillard
2009-04-08 12:30 ` Ian Smith
2009-04-08 17:01 ` Andrew Pimlott
2009-04-08 22:18 ` William Morgan
2009-04-08 19:03 ` Wirt Wolff
2009-04-08 21:49 ` William Morgan
2009-04-09 11:55 ` Nicolas Pouillard [this message]
2009-04-09 17:30 ` William Morgan
2009-04-10 8:36 ` Nicolas Pouillard
2009-04-10 12:24 ` William Morgan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1239278036-sup-7327@ausone.inria.fr \
--to=nicolas.pouillard@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox