Provide generic framework for calling message-next
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| VM |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
affects vm
importance wishlist
It would be nice to have a generic framework to call "message-next"
after a certain command (e.g. reading, deleting, marking unread, etc.),
similar to the current vm-move-
Presumably this could be configured via an "alist" of some sort, e.g.
(setq vm-post-commands
'((
(
(
(vm-blah . '(vm-cmd1 vm-cmd2 ... vm-cmdN))))
where for each time a command is called (this can presumably be limited
to a reasonable subset like reading, deleting, unreading, marking, etc.
in implementation), its associated "post-commands", if any, are
sequentially called. In the above example, vm-next-message would be
called after deleting and reading a message, but vm-previous-message
would be called after unreading a message.
This would render vm-move-
obsolete, but would be cleaner in my opinion than having to submit a
vm-move-after-XYZ patch for each command I'd like to move after :)
I'm not yet familiar with lisp, but if someone would like to guide me in
implementing this, I'll gladly do the legwork.
--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://
| Uday Reddy (reddyuday) wrote Re: [Bug 1153675] [NEW] Provide generic framework for calling message-next | #1 |
| Changed in vm: | |
| milestone: | none → 8.2.90a |
| Ryan Kavanagh (ryanakca) wrote | #2 |
| Changed in vm: | |
| status: | New → Triaged |
Hi Ryan, What other operations would require auto-movement commands? What
would be the rationale for auto-movement?
In the case of delete, the rationale is clear. Since we are getting rid of
the current message, we presumably want to move to another one. For
vm-flag-
from the "unread messages" pool. So, presumably we want to move to another
unread message (though I discovered that I do not always want this). Why do
you need auto-movement for other commands?