Subject: [sup-talk] Read only mode for sup

From: [email-masked] (Nicolas Pouillard)
Date: Tue, 07 Apr 2009 20:26:58 +0200

Hi all,

What about adding such a read only mode to sup?

I see to important usages:

* Running sup in an environment that we don't want
  to change, like a backup or synchronized index.

* Running a second instance of sup to make searches
  while we are editing a mail.

Best regards,

-- 
Nicolas Pouillard

---

From: [email-masked] (Ian Smith)
Date: Tue, 07 Apr 2009 19:29:04 -0400

>   while we are editing a mail.

This use case already works using buffers - you can switch between them
fairly easily.  I need to rewrite my reflexes still, but I run sup in
screen, so it can't be that hard.

Ian
-- 
Ian Smith
ismith at mit.edu
ismith at bostonaccess.org

---

From: [email-masked] (Nicolas Pouillard)
Date: Wed, 08 Apr 2009 10:36:23 +0200

> screen, so it can't be that hard.

Even when you are editing a mail?

-- 
Nicolas Pouillard

---

From: [email-masked] (Ian Smith)
Date: Wed, 08 Apr 2009 08:30:05 -0400

> Even when you are editing a mail?

Oh, you're right - you have to switch into reply-mode, out of the
editor.  Hmm.
-- 
Ian Smith
ismith at mit.edu
ismith at bostonaccess.org

---

From: [email-masked] (Andrew Pimlott)
Date: Wed, 8 Apr 2009 10:01:08 -0700

> Oh, you're right - you have to switch into reply-mode, out of the

I've always wondered, could a mailer use job control, like a shell, to
allow it to have multiple sub-processes and switch among them?  Then,
you could suspend your editor and get back to sup, and later resume your
editor.

Andrew

---

From: [email-masked] (Wirt Wolff)
Date: Wed, 08 Apr 2009 13:03:07 -0600

> screen, so it can't be that hard.

In my situation buffers aren't enough sometimes. Aside from having to
exit the editor, unless I'm mistaken there's no way to view more than
one buffer at once. Mostly I've appreciated relaxing into that way of
working, and even found it helpful to concentration and productivity.

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.

There are surely other solutions, hopefully simpler ones, but I've not
gotten motivated enough to work them out yet. 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.

-- 
regards,
wmw

---

From: [email-masked] (William Morgan)
Date: Wed, 08 Apr 2009 14:49:47 -0700

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 <wmorgan-sup at masanjin.net>

---

From: [email-masked] (William Morgan)
Date: Wed, 08 Apr 2009 15:18:14 -0700

Reformatted excerpts from Andrew Pimlott's message of 2009-04-08:
> you could suspend your editor and get back to sup, and later resume
> your editor.

The problem is that when the editor is in the foreground, it has
control. So I don't think Sup would be able to suspend it. But it might
be possible to do something like catch SIGTSTP signals when the editor
is running, and file those process ids away for later resumption. You'd
have to suspend from within the editor, but the rest of the behavior
might be close to what you want. Interesting idea.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Nicolas Pouillard)
Date: Thu, 09 Apr 2009 13:55:56 +0200

> 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.

> merge, there's only overwrite. 

Simultaneous read/write Sups would be great too!

-- 
Nicolas Pouillard

---

From: [email-masked] (William Morgan)
Date: Thu, 09 Apr 2009 10:30:09 -0700

Reformatted excerpts from William Morgan's message of 2009-04-08:
> 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.

Ok, I've done this on branch 'better-buffer-list', which I've merged
into next. Pull and see how you guys like it. Summary:

1. 'b' rolls the buffer forward as usual.
2. 'B' now rolls the buffer backwards like in the olden days.
3. ';' pulls up the buffer list, which is now sorted by access time,
   colorized to show "system" vs non-"system" buffers, and has little
   stars for buffers with unsaved content.
4. '+' is now the apply-to-tagged command.

Sorry for changing so many keymappings, but I really wanted ';' so that,
with 'j' and 'k', you can swap buffers really quickly with just one
hand. Since that freed up B, I figured I'd reenable the old behavior,
and '+' kinda makes sense for apply-to-tagged anyways.

Nicolas, I had to revert your "Buffer switching, 'bn' for the next one
and 'bp' for the previous" change in next. I hope you're not offended! :)
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Nicolas Pouillard)
Date: Fri, 10 Apr 2009 10:36:16 +0200

> and 'bp' for the previous" change in next. I hope you're not offended! :)

I'm not offended, I just wanted to tend to more scalable bindings, where
a meaningful letter is kept to be the leading one for more advanced bindings
on a particular topic.

Moreover optimizing bindings for QUERTY keymap does not make sense for other
people... Personally I use and prefer DVORAK.

-- 
Nicolas Pouillard

---

From: [email-masked] (William Morgan)
Date: Fri, 10 Apr 2009 05:24:15 -0700

Reformatted excerpts from Nicolas Pouillard's message of 2009-04-10:
> Moreover optimizing bindings for QUERTY keymap does not make sense for
> other people... Personally I use and prefer DVORAK.

Uh oh. Well, time to get working on that configurable keymap patch...
-- 
William <wmorgan-sup at masanjin.net>