Being a ruthless mail-processor, I sometimes archive or delete a message hastily and realize a moment later that I actually want to look at the message again. Of course, if that happens when I''m in a thread-index-mode, then I can just hit ''u'' to undo and all is fine. But if I make the same mistake in thread-view-mode then I''m currently out of luck. Would it be a small change to move the undo keybinding to somewhere more universal? As a first cut, I''d be happy if it just undid the changes to the index, even without undoing any interface changes. That is, if my previous command was archive-thread-and-view-next-thread, it would be OK if it just undid the archiving part. Bonus points if it also undoes the view-next part, but I can imagine that being more work. Again, this is a feature I''d be happy to spend some time investigating myself when I get the chance. I''d just be happy to hear any thoughts on feasibility. And I''m trying to get in the habit of mentioning issues as I run into them rather than waiting until I have the chance to actually work on them, (at which point I may have forgotten the issues). -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/28acedf6/attachment.bin>
Reformatted excerpts from Carl Worth''s message of 2009-09-09:> Would it be a small change to move the undo keybinding to somewhere > more universal?The undo keybinding could definitely be moved from thread-index-mode to the main event loop. That''s a small change. The bigger amount of work is writing undo lambdas for every operation you want to be able to undo, e.g. every command in thread-view-mode. It''s not complicated, just a little tedious, IMO. -- William <wmorgan-sup at masanjin.net>
Excerpts from Carl Worth''s message of Wed Sep 09 19:32:30 +0200 2009:> Being a ruthless mail-processor, I sometimes archive or delete a > message hastily and realize a moment later that I actually want to > look at the message again.What about a "last viewed history" list? Then you could use that to review the threads? Maybe its best to add a property: last-viewed-on: timestamp. Then you can even use the existing search engine to view those threads ? Marc Weber
Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009:> Would it be a small change to move the undo keybinding to somewhere > more universal?No :(> As a first cut, I''d be happy if it just undid the changes to the > index, even without undoing any interface changes. That is, if my > previous command was archive-thread-and-view-next-thread, it would be > OK if it just undid the archiving part. Bonus points if it also undoes > the view-next part, but I can imagine that being more work.I know I sound a bit like a broken record here, but immediate label changes will solve this problem. Then, the undo system would just need to keep a global stack of (msgid, previous_labels). I''m just hoping somebody will volunteer for this - it will be a big patch.
Excerpts from Rich Lane''s message of Fri Sep 11 00:45:20 +0200 2009:> Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009: > > Would it be a small change to move the undo keybinding to somewhere > > more universal? > > No :( > > > As a first cut, I''d be happy if it just undid the changes to the > > index, even without undoing any interface changes. That is, if my > > previous command was archive-thread-and-view-next-thread, it would be > > OK if it just undid the archiving part. Bonus points if it also undoes > > the view-next part, but I can imagine that being more work. > > I know I sound a bit like a broken record here, but immediate > label changes will solve this problem. Then, the undo system would just > need to keep a global stack of (msgid, previous_labels). I''m just hoping > somebody will volunteer for this - it will be a big patch.What prevent us from having a global stack of (msgid, previous_labels) in the actual settings? -- Nicolas Pouillard http://nicolaspouillard.fr
Excerpts from Nicolas Pouillard''s message of Fri Sep 11 05:16:49 -0400 2009:> Excerpts from Rich Lane''s message of Fri Sep 11 00:45:20 +0200 2009: > > Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009: > > > Would it be a small change to move the undo keybinding to somewhere > > > more universal? > > > > No :( > > > > > As a first cut, I''d be happy if it just undid the changes to the > > > index, even without undoing any interface changes. That is, if my > > > previous command was archive-thread-and-view-next-thread, it would be > > > OK if it just undid the archiving part. Bonus points if it also undoes > > > the view-next part, but I can imagine that being more work. > > > > I know I sound a bit like a broken record here, but immediate > > label changes will solve this problem. Then, the undo system would just > > need to keep a global stack of (msgid, previous_labels). I''m just hoping > > somebody will volunteer for this - it will be a big patch. > > What prevent us from having a global stack of (msgid, previous_labels) in > the actual settings?Hmm, you may be right. I was thinking that changes weren''t propagated between buffers except on save, but that''s wrong because UpdateManager is called in the keybinding. In that case, the user sees a mostly* linear series of label changes, so it''s safe to have a global undo stack. * User opens thread-index-mode A containing message M with labels L1 User changes labels on A.M to L2 User opens thread-index-mode B containing message M with labels L1 User changes labels on B.M to L3 UpdateManager changes labels on A.M to L3 User hits ''u'' - now A.M and B.M have labels L1
On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:> Excerpts from Nicolas Pouillard''s message of Fri Sep 11 05:16:49 -0400 2009: >> Excerpts from Rich Lane''s message of Fri Sep 11 00:45:20 +0200 2009: >> > Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009: >> > > Would it be a small change to move the undo keybinding to somewhere >> > > more universal? >> > >> > No :( >> > >> > > As a first cut, I''d be happy if it just undid the changes to the >> > > index, even without undoing any interface changes. That is, if my >> > > previous command was archive-thread-and-view-next-thread, it would be >> > > OK if it just undid the archiving part. Bonus points if it also undoes >> > > the view-next part, but I can imagine that being more work. >> > >> > I know I sound a bit like a broken record here, but immediate >> > label changes will solve this problem. Then, the undo system would just >> > need to keep a global stack of (msgid, previous_labels). I''m just hoping >> > somebody will volunteer for this - it will be a big patch. >> >> What prevent us from having a global stack of (msgid, previous_labels) in >> the actual settings? > > Hmm, you may be right. I was thinking that changes weren''t propagated > between buffers except on save, but that''s wrong because UpdateManager > is called in the keybinding. In that case, the user sees a mostly* > linear series of label changes, so it''s safe to have a global undo > stack.he next question is, what else is needed on this undo stack? Are labels the only interaction we have? Here is what come to my mind: * contacts (I more and more think that contacts should not be handled by sup directly, but that''s another topic) * drafts -- Nicolas Pouillard
Excerpts from Nicolas Pouillard''s message of Fri Sep 11 17:25:06 -0400 2009:> On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote: > > Excerpts from Nicolas Pouillard''s message of Fri Sep 11 05:16:49 -0400 2009: > >> Excerpts from Rich Lane''s message of Fri Sep 11 00:45:20 +0200 2009: > >> > Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009: > >> > > Would it be a small change to move the undo keybinding to somewhere > >> > > more universal? > >> > > >> > No :( > >> > > >> > > As a first cut, I''d be happy if it just undid the changes to the > >> > > index, even without undoing any interface changes. That is, if my > >> > > previous command was archive-thread-and-view-next-thread, it would be > >> > > OK if it just undid the archiving part. Bonus points if it also undoes > >> > > the view-next part, but I can imagine that being more work. > >> > > >> > I know I sound a bit like a broken record here, but immediate > >> > label changes will solve this problem. Then, the undo system would just > >> > need to keep a global stack of (msgid, previous_labels). I''m just hoping > >> > somebody will volunteer for this - it will be a big patch. > >> > >> What prevent us from having a global stack of (msgid, previous_labels) in > >> the actual settings? > > > > Hmm, you may be right. I was thinking that changes weren''t propagated > > between buffers except on save, but that''s wrong because UpdateManager > > is called in the keybinding. In that case, the user sees a mostly* > > linear series of label changes, so it''s safe to have a global undo > > stack. > > he next question is, what else is needed on this undo stack? > > Are labels the only interaction we have? Here is what come to my mind: > > * contacts (I more and more think that contacts should not be handled by > sup directly, but that''s another topic) > * drafts >What actions on drafts are you thinking of making undoable? Could we implement them with reserved labels?
Excerpts from Rich Lane''s message of Sun Sep 13 23:40:05 +0200 2009:> Excerpts from Nicolas Pouillard''s message of Fri Sep 11 17:25:06 -0400 2009: > > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote: > > > Excerpts from Nicolas Pouillard''s message of Fri Sep 11 05:16:49 -0400 2009: > > >> Excerpts from Rich Lane''s message of Fri Sep 11 00:45:20 +0200 2009: > > >> > Excerpts from Carl Worth''s message of Wed Sep 09 13:32:30 -0400 2009: > > >> > > Would it be a small change to move the undo keybinding to somewhere > > >> > > more universal? > > >> > > > >> > No :( > > >> > > > >> > > As a first cut, I''d be happy if it just undid the changes to the > > >> > > index, even without undoing any interface changes. That is, if my > > >> > > previous command was archive-thread-and-view-next-thread, it would be > > >> > > OK if it just undid the archiving part. Bonus points if it also undoes > > >> > > the view-next part, but I can imagine that being more work. > > >> > > > >> > I know I sound a bit like a broken record here, but immediate > > >> > label changes will solve this problem. Then, the undo system would just > > >> > need to keep a global stack of (msgid, previous_labels). I''m just hoping > > >> > somebody will volunteer for this - it will be a big patch. > > >> > > >> What prevent us from having a global stack of (msgid, previous_labels) in > > >> the actual settings? > > > > > > Hmm, you may be right. I was thinking that changes weren''t propagated > > > between buffers except on save, but that''s wrong because UpdateManager > > > is called in the keybinding. In that case, the user sees a mostly* > > > linear series of label changes, so it''s safe to have a global undo > > > stack. > > > > he next question is, what else is needed on this undo stack? > > > > Are labels the only interaction we have? Here is what come to my mind: > > > > * contacts (I more and more think that contacts should not be handled by > > sup directly, but that''s another topic) > > * drafts > > > > What actions on drafts are you thinking of making undoable? Could we > implement them with reserved labels?No I think that''s fine for now to consider, discarding, editing... non-undoable actions. Basically I agree with a global undo stack of labels, I''m just searching for issues ahead. -- Nicolas Pouillard http://nicolaspouillard.fr