* Sven Guckes <[EMAIL PROTECTED]> [2002-10-14 00:40:18 +0200]: >* Bernard Massot <[EMAIL PROTECTED]> [2002-10-12 23:41]: >> mutt default's behavior is : >> - if the box has no messages matching ~N or ~O, >> go on last message in the bottom of the index (right for me) >> - if there are some messages matching ~N, >> go on the 1st message matching ~N (right for me) >> - if there are some messages matching ~O, >> go on the 1st message matching ~O (right for me) >> - if there are both messages matching ~N and ~O, >> go on the 1st message matching ~N (that's what I don't >> like, I'd like it to go on the 1st message matching ~O) > >i'd limit to "(~N|~O)" and then jump to the first entry - >but this might be either ~N or ~O - depending on the case. >anyway, i suppose this requires a change of the code...
Hmm...not trying to put words in anyone's mouth, here, but I think
what he's really asking for (whether he knows it or not, hehe) is a
function "next-new-or-unread" (in quotes because there is no such
function (yet)). Just saying, because it sounds like he's asking for a
feature I've silently wanted for a long time. :)
Assuming this is true, there are two ways I found to solve this
problem (although one doesn't actually solve the problem per se):
1) Create a recursive macro that, on the first invocation, jumps to
the first unread message in a mailbox, and then reconfigures itself
to jump to the first new message. When invoked the second time, it
jumps to the first new message, then reconfigures itself to jump to
the first unread. Then you execute the macro twice and see which
message is the one you want (in my case, it came down to which one
came first in the index). This doesn't technically answer the
actual question, but it does fake it a lot faster than typing it
all in by hand all the time. :)
2) The other solution, which isn't actually a solution but may work
for you, is to put "unset mark_old" in your .muttrc file. This
will cause mutt to not even differentiate between "new" and
"unread" mail, and thus any call to the next-new function will by
definition also target unread mail.
Which do I use? Hah, well, I can't stand doing #2 and haven't gotten
around to doing #1 yet, so neither. :) However, here's an example of a
recursive macro, so if you (or someone else) decides to put together #1,
you can have a road map on how the concept of self-rewriting macros
happens:
macro index <ESC>J ':my_hdr X-Priority: 5<enter>:my_hdr
X-MSMail-Priority: Low<enter>:macro index y <ESC>K<enter>' "submacro for
y"
macro index <ESC>K ':my_hdr X-Priority: 1<enter>:my_hdr
X-MSMail-Priority: High<enter>:macro index y <ESC>L<enter>' "submacro
for y"
macro index <ESC>L ':my_hdr X-Priority: 3<enter>:my_hdr
X-MSMail-Priority: Normal<enter>:macro index y <ESC>M<enter>' "submacro
for y"
macro index <ESC>M ':unmy_hdr X-Priority<enter>:unmy_hdr
X-MSMail-Priority<enter>:macro index y <ESC>J<enter>' "submacro for y"
macro index y <ESC>J "Toggle Priority"
This is a set of four macros...one "head" macro, where you press y to
cycle through Priority settings, and three "support" macros which
actually change the header and refer to each other in sequence. I used
the sequences <ESC>JKLM for the submacros simply because they were a
pain to type (so I know I won't be wanting them for "real" key
assignments that I'll actually be using directly...you don't ever call
the submacros directly). Let me know if you have any questions.
Actually, this brings out a couple of questions of my own. :)
1) Is there a command to echo text to the "info line" arbitrarily?
You know, the part of the window where it says "PGP signature
successfully verified" or "Committing changes", etc. The bottom
line. I'd really like to edit this set of macros, and some others,
so that they print messages like "Priority set to HIGH" when you
run them.
2) Is it possible to get mutt to put the word wrap character at the
end of the continued line (like Emacs) rather than the beginning of
the continuation? Example:
This is a very long line of text which the user should have wrapped
+before it got to my client, but didn't, so now my mail client has to
+deal with them instead.
(The above is what mutt does now)
This is a very long line of text which the user should have wrapped+
before it got to my client, but didn't, so now my mail client has to+
deal with them instead.
(The above is what I would like it to do)
Yes, I realize we are now entering a level of anal that's extreme
even for this group, but I had to throw it out. :) BTW, note that the
above two examples above are both pre-wrapped, the + signs were put in
manually by me; your word wrap is NOT broken. :)
--
------------------------------------------------------------------------
John Buttery
(Web page temporarily unavailable)
------------------------------------------------------------------------
msg31798/pgp00000.pgp
Description: PGP signature
