* [sup-talk] Read only mode for sup @ 2009-04-07 18:26 Nicolas Pouillard 2009-04-07 23:29 ` Ian Smith 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Pouillard @ 2009-04-07 18:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-07 18:26 [sup-talk] Read only mode for sup Nicolas Pouillard @ 2009-04-07 23:29 ` Ian Smith 2009-04-08 8:36 ` Nicolas Pouillard 2009-04-08 19:03 ` Wirt Wolff 0 siblings, 2 replies; 12+ messages in thread From: Ian Smith @ 2009-04-07 23:29 UTC (permalink / raw) Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > What about adding such a read only mode to sup? > * Running a second instance of sup to make searches > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-07 23:29 ` Ian Smith @ 2009-04-08 8:36 ` Nicolas Pouillard 2009-04-08 12:30 ` Ian Smith 2009-04-08 19:03 ` Wirt Wolff 1 sibling, 1 reply; 12+ messages in thread From: Nicolas Pouillard @ 2009-04-08 8:36 UTC (permalink / raw) Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > What about adding such a read only mode to sup? > > * Running a second instance of sup to make searches > > 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. Even when you are editing a mail? -- Nicolas Pouillard ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 8:36 ` Nicolas Pouillard @ 2009-04-08 12:30 ` Ian Smith 2009-04-08 17:01 ` Andrew Pimlott 0 siblings, 1 reply; 12+ messages in thread From: Ian Smith @ 2009-04-08 12:30 UTC (permalink / raw) Excerpts from Nicolas Pouillard's message of Wed Apr 08 04:36:23 -0400 2009: > Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > > What about adding such a read only mode to sup? > > > * Running a second instance of sup to make searches > > > 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. > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 12:30 ` Ian Smith @ 2009-04-08 17:01 ` Andrew Pimlott 2009-04-08 22:18 ` William Morgan 0 siblings, 1 reply; 12+ messages in thread From: Andrew Pimlott @ 2009-04-08 17:01 UTC (permalink / raw) On Wed, Apr 08, 2009 at 08:30:05AM -0400, Ian Smith wrote: > Excerpts from Nicolas Pouillard's message of Wed Apr 08 04:36:23 -0400 2009: > > Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > > > 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. > > > > Even when you are editing a mail? > > Oh, you're right - you have to switch into reply-mode, out of the > editor. Hmm. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 17:01 ` Andrew Pimlott @ 2009-04-08 22:18 ` William Morgan 0 siblings, 0 replies; 12+ messages in thread From: William Morgan @ 2009-04-08 22:18 UTC (permalink / raw) Reformatted excerpts from Andrew Pimlott's message of 2009-04-08: > 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. 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-07 23:29 ` Ian Smith 2009-04-08 8:36 ` Nicolas Pouillard @ 2009-04-08 19:03 ` Wirt Wolff 2009-04-08 21:49 ` William Morgan 1 sibling, 1 reply; 12+ messages in thread From: Wirt Wolff @ 2009-04-08 19:03 UTC (permalink / raw) Excerpts from Ian Smith's message of Tue Apr 07 17:29:04 -0600 2009: > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > What about adding such a read only mode to sup? > > * Running a second instance of sup to make searches > > 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. 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 19:03 ` Wirt Wolff @ 2009-04-08 21:49 ` William Morgan 2009-04-09 11:55 ` Nicolas Pouillard 2009-04-09 17:30 ` William Morgan 0 siblings, 2 replies; 12+ messages in thread From: William Morgan @ 2009-04-08 21:49 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 21:49 ` William Morgan @ 2009-04-09 11:55 ` Nicolas Pouillard 2009-04-09 17:30 ` William Morgan 1 sibling, 0 replies; 12+ messages in thread From: Nicolas Pouillard @ 2009-04-09 11:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-08 21:49 ` William Morgan 2009-04-09 11:55 ` Nicolas Pouillard @ 2009-04-09 17:30 ` William Morgan 2009-04-10 8:36 ` Nicolas Pouillard 1 sibling, 1 reply; 12+ messages in thread From: William Morgan @ 2009-04-09 17:30 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-09 17:30 ` William Morgan @ 2009-04-10 8:36 ` Nicolas Pouillard 2009-04-10 12:24 ` William Morgan 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Pouillard @ 2009-04-10 8:36 UTC (permalink / raw) Excerpts from William Morgan's message of Thu Apr 09 19:30:09 +0200 2009: > 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! :) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] Read only mode for sup 2009-04-10 8:36 ` Nicolas Pouillard @ 2009-04-10 12:24 ` William Morgan 0 siblings, 0 replies; 12+ messages in thread From: William Morgan @ 2009-04-10 12:24 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-04-10 12:24 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-04-07 18:26 [sup-talk] Read only mode for sup 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 2009-04-09 17:30 ` William Morgan 2009-04-10 8:36 ` Nicolas Pouillard 2009-04-10 12:24 ` William Morgan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox