Re: newbie configuration questions....
On Fri, Feb 09, 2001 at 09:22:16AM +0900, Joss Winn wrote:
1. Is there any way of flushing deleted mail without having to quit Mutt
or change to a different folder/mailbox? I'd like deleted mail out of
my sight at the press of a button.
yeap .. the command is called "sync-mailbox" and i think the default
key it is bound to is "$"
2. Currently, I open Mutt and it defaults to /spool/joss. Is there any
way to have it default to my mbox when I open Mutt and when new mail
arrives, have that mail automatically moved from the spool to mbox where
I can read/delete, etc. Basically, I want to reduce the amount of
shifting between mail boxes and work mainly in mbox (I have one mail box
where all kept mail resides).
thats a job for procmail or maildrop ...
i guess there's a link to some procmail faq from the mutt faq ..
if you like perl better you may try maildrop.
joss
please cc me at my own address as I'm on the digest and have yet to
recieve one (perhaps there has been no list mail for the last couple of days?)
i've put you on bcc .. so nobody gets confused if more follow-up mails
should arrive. hope thats ok ..
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Re: Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 03:53:44PM +, Dave Pearson wrote: On Mon, Jan 22, 2001 at 04:16:25PM +0100, Heinrich Langos wrote: Dave, you may stop reading. The rest will only bother you and further waste your time. With an attitude like that it's not surprising that you're confused about what I've been saying. Read what I've actually said, look for the reasonable reason this time, then you might find that I've said nothing against the idea of providing the feature you'd like to see. Well, then I'm sorry. I guess I took your repating of "the docs are right" the wrong way. I was not trying to convince you that the docs are wrong and I took your insiting on the thier correctnes as conviction that there is nothing to improve. That really upset me. Sorry, once again. ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... But we can't actually make such a guess can we? You also seem to be under the impression that I don't archive older mail. I do. Arguing that "most users" do what you'd like them to do doesn't detract from the point that there can and will be large mailboxes defined by the mailbox command. When designing new features it makes sense to work to the extreme case, not the average case (especially when you can't really know what the average is). I was just under the impression that incoming mailboxes usually are small. Though my choice of words may have been inappropriate and insulting. I admit that arguing for "most users" in the absents of statistic data is, well, arguable. :-) In order to deal with extremly big mailboxes I proposed that "jump to the previously know end" strategy. But dealing with large amounts of incoming mail could be a problem. Any ideas? I mean other than limiting the amount to scan like "max_growth_to_scan_for_new_mail=200k" If a mailbox had grown more than 200k since the last scan you would only mark the previously known amount of new mail with a "+" and postpone exact scanning and updating of numbers till the user entered that folder and you had to scan it anyway. jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) I don't use fetchmail but the above still isn't true. email does arrive in large batches for me. How comes? Are these large batches usually source initiated (like moderated mailinglists) or are they collected at another MX host before they get transfered to your mail server? In other words: Will they affect all/many of your mailboxes or usually just one ore two? to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) That sounds like a good solution for the problem I highlight above. I hope it is. It would save a lot of trouble. PS: You still appear to have a configuration problem with your copy of mutt: , | Mail-Followup-To: heinrich, [EMAIL PROTECTED] ` yeap .. unfortunatly i don't know how to review the headers before sending an email. could it be a problem with the local sendmail configuration? i've got these in my muttrc but it doesnt realy help. - set edit_hdrs ignore * unignorefrom: subject to cc mail-followup-to \ date x-mailer x-url - furthermore i've got "[EMAIL PROTECTED]" on my "lists". but not on "subscribe" since i like to see the sender instead of the list address in the index. if putting it on "subscribe" will solve the "Mail-Followup-To:"-problem i will do that and change index_format accordingly. TIA -heinrich
Re: Default mailbox display? [partially solved]
first for the important part:
while reading the source to find a place to put Brandon Long's "folder
count" patch. i've found a configure switch named "--enable-buffy-size"
that seems to solve the detection issue. i only browsed through the
source since it was quite late, but it seems to read the end of the
mbox to find out if the last message is a new one. so it partially
scans the mbox file. i guess i can extend that to a full scan to
report real numbers.
but at least it partially solves the detection issue.
On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote:
On Sun, Jan 21, 2001 at 06:44:54PM +0100, Heinrich Langos wrote:
On Sun, Jan 21, 2001 at 03:59:22PM +, Dave Pearson wrote:
[...]
Saving such information won't help you work out how many new mails there
are, or if there is new mail at all. It would let you know if the
mailbox had been modified in some way, which is pretty much what mutt
does right now.
nope ... right now mutt only shows that the mailbox has been accessed. not
if it has been modified.
It would appear that we have different definitions of "accessed" and
"modified". My copy of mutt shows me when an mbox has been modified, not
when it has been accessed.
do me a favor and check your "mutt -v" output. if it says
"+BUFFY_SIZE" than your mutt is not just checking access times but
much more than that. if it says "-BUFFY_SIZE" (like mine did) and
after grep-ing your mailbox still shows an "N", i don't get it.
grep doesn't modify your mbox.
so says strace:
open("/var/spool/mail/heinrich", O_RDONLY|0x8000) = 3
(though i have to admit i didn't find out what the 0x8000 part means
in a quick look at /usr/include/*)
BTW: is your mutt running 24/7 or do you start it anew in the morning
like i do... ( and several times a day whenever i've found a new
feature in mutt that i would like to try out ? :) )
right now a simple grep will screw up new mail detection.
try this:
$ echo blah | mail yourself@localhost
$ grep something /var/spool/mail/yourself
$ mutt -y
and you see no "N" ... pretty sad, isn't it?
No, I don't find it sad, I find it consistent with the documentation.
consistent? yes! i admit it is
consistent with a documentation that says: in some cases new mail
detection is not working as one would expect, because there is evil in
world and "Something is rotten in the state of Denmark" :-)
Obviously you're more than happy to find it an itch worth scratching, feel
free to scratch it. All I've been saying is that it *is* reliable, it does
exactly what it says it does. That it doesn't do what you'd like is a
different matter, I'm not commenting on that.
it's not only me who wants mutt to behave that way, i guess.
if it was not the intention to make mutt detect new mail it would say
"... the main menu status bar displays how any of these folders have
been modified since they where accessed by some programm." ;-)
i'm not saying that mutt should constantly scan the whole mailboxes or
anything like that. i just say it could do so on request. or on startup.
The problem with such a scan is that it could take ages. I've got a lot of
mailboxes, some of which can be huge.
it only scans mailboxes that are marked as incoming mailboxes.
so it would do the same thing it does, when opening that mbox. only to
all of them at once... ok ok .. that would be some overhead.
but it will not scan all your mailboxes. especially not those archive
like things where you keep several years of the kernel developers list
or bugtraq :-)
if you keep your incoming mboxes down to a month back or two, it
shouldn't be such a problem. and the results of scanning can be cached
(just in memory or in a status file) and only refreshed if the file
was modified.
with _you_ chosing your favorite or most reliable way you see fit to
detect modification. be it access/modification time, file size
or md5sum.
any volunteers to go for it? i have to finish a studies project before
i can go for more than a quick'n'dirty hack.
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 01:10:46PM +, Dave Pearson wrote:
On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote:
On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote:
[...]
it's not only me who wants mutt to behave that way, i guess. if it was not
the intention to make mutt detect new mail it would say "... the main menu
status bar displays how any of these folders have been modified since they
where accessed by some programm." ;-)
I agree that this can be viewed as a documentation problem.
In your opinion the documentation is wrong and should be changed to
something like the above? Well, ok then I really misunderstood you
all the time and I misunderstood the documentation. I'm sorry I
wasted your time.
I guess continuing this discussion will not get us anywhere then.
Anyway I will continue this mail since I have some ideas that may
improve the performance in case somebody, maybe me, wants to fix
the non-existing problem :-)
Dave, you may stop reading. The rest will only bother you and further
waste your time.
The problem with such a scan is that it could take ages. I've got a lot of
mailboxes, some of which can be huge.
it only scans mailboxes that are marked as incoming mailboxes.
That's why I said "mailboxes".
ok ok .. just wanted to make sure we talk about the same thing.
i guess most users don't have huge mailboxes since mbox-hooks are a
such a nice way to move older mail out of mailboxes after some time.
anyway...
so it would do the same thing it does, when opening that mbox. only to all
of them at once... ok ok .. that would be some overhead.
That could and would be a *lot* of overhead.
realy? lets see...
and keep in mind that this does not need to be mutts standard way to
detect new mail. just the one it uses when you TAB TAB. or start mutt
with -y.
when you save modification date, filesize, known amount of new mail,
and an md5sum they will only be generated once for each mailbox. so
assuming that you don't add mailboxes on an hourly base I will forget
about that one-time load.
if a change occures (detecting may be done by modification time,
filesize, md5sum (sorted accending by paranoia)) and the filesize
increases you could assume that there is new mail (if it decreased you
could mark that mailbox as "C" for changed or something like that and
stop here).
jump to the previously know end of the file and scan how may new mails
arrived. that shouldn't be too much of a burden for a system. since
mails usually don't arrive in large batches. (i know, fetchmail users
will hate me.)
to prevent errors due to other programms, maliciously changing your
mailboxes and increasing its size, you could check for that.
depending on your level of paranoia you could do anything.
from
A) checking if a new mail starts exactly where it is supposed to start
(at the previously know file-end, which you do anyway by starting
parsingthere)
to
Z) checksumming the mailbox up to the last known
fileend and comparing with the saved checksum.
assuming that increased size usually means that new mail has been
added the overhead would be very small.
if you still think it is too much overhead go for this one:
cache the information that you gathered during those scans to skip the
initial scan that mutt does when you enter a folder.
this will reduce the overhead to almost zero. only if you don't read
the folder that has new mail you will have wasted time. but why do you
get that mail at all if you dont read it ? :-)
for maildir environments the solution seems straightforward.
what about imap? i don't have a clue. could somebody enlighten me?
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Re: Default mailbox display?
On Sun, Jan 21, 2001 at 04:23:53PM +0100, Martin Schweizer wrote: Hello Heinrich On Fri, Jan 19, 2001 at 12:24:40PM +0100 Heinrich Langos wrote: One thing that I think would help not only me, but tons of others is something like this: mailbox 1 3 new messages mailbox 2 12 new messages mailbox 3 8 new messages how about this ? Mail/mutt-users [Msgs:413 New:18 1.1M] Mail/sf/vuln-dev [Msgs:141478K] Mail/nymip [Msgs:54 368K] The above is nice! But how you do you set the 'index_format=' variable for this view? you can't ... thats what this whole thread is about. ;-) i was just making up something to stirr up those who are content with something that is not good enough. something that could be done better but isn't. -heinrich
Re: Default mailbox display?
On Sun, Jan 21, 2001 at 03:59:22PM +, Dave Pearson wrote: On Sat, Jan 20, 2001 at 05:40:03PM +0100, Heinrich Langos wrote: On Fri, Jan 19, 2001 at 12:05:01PM +, Dave Pearson wrote: On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote: the problem with "-y" is that it simply doesn't work reliably. Yes it does. No it doesn't. Been there, tried it. Then your experience is different from mine. I've been using mutt since before the mailboxes feature was added and, apart from the documented issues (which you quoted) it has always worked reliably. That's why I'm saying it does work reliably. The only things I've ever seen that can affect it are those that are documented. [...] The quote is informing you that external processes might change the timestamp behaviour. leading to non-detection of new mail ... i don't want mutt to tell me if i or some programms have accessed the mailbox. i want it to tell me if there is new mail in there. BTW: pointing your finger at evil software that doesn't conform to standards will not solve the problem. if that was enough, nobody at the samba development team would have to care about yet another microsoft-"extention" of standards. So please stop defending mutt's weakness in this area and lets try to think of a way to improve mutt. I love mutt and I want it to suck even less! :-) Please don't suggest that I'm defending a weakness, I'm not. I am pointing out that it does what it says in the documentation. It points out it's own weakness and that other than the documented issues it's reliable. sorry, but the documented issues is what i am ranting about and what i proposed a solution for. documenting an issue may be enough for M$ or IBM. working to resolve the documented issue is what open source is about, isn't it? or is there a _reasonable_ opposition against saving status information that i don't see? Saving such information won't help you work out how many new mails there are, or if there is new mail at all. It would let you know if the mailbox had been modified in some way, which is pretty much what mutt does right now. nope ... right now mutt only shows that the mailbox has been accessed. not if it has been modified. right now a simple grep will screw up new mail detection. try this: $ echo blah | mail yourself@localhost $ grep something /var/spool/mail/yourself $ mutt -y and you see no "N" ... pretty sad, isn't it? if mutt would realy show modification i would instantly shut up. i'm not saying that mutt should constantly scan the whole mailboxes or anything like that. i just say it could do so on request. or on startup. but it seems that i am the only one with that problem. so i guess i'll have to roll my own mutt. i guess the code that is needed is already in there... it just needs some tweaking. -heinrich ps: sorry for my uppish tone ... but i have recently had an overdose of "it's free. quit moaning!"-attitude. :) -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: thread date question
On Sun, Jan 21, 2001 at 02:42:24PM -0500, Ken Weingold wrote: I'm sorry, but I have looked all over my muttrc and the mutt manual, but can't find this anymore. What variable is it that pushed a thead to the top of the index if there is new mail in it? set sort_aux=last-date # date of the last message in thread -heinrich
Re: Default mailbox display?
On Fri, Jan 19, 2001 at 12:05:01PM +, Dave Pearson wrote:
On Fri, Jan 19, 2001 at 12:24:40PM +0100, Heinrich Langos wrote:
On Fri, Jan 19, 2001 at 09:27:53AM +, Dave Pearson wrote:
On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote:
mailbox 1 3 new messages
mailbox 2 12 new messages
mailbox 3 8 new messages
how about this ?
Mail/mutt-users [Msgs:413 New:18 1.1M]
Mail/sf/vuln-dev [Msgs:141478K]
Mail/nymip [Msgs:54 368K]
now wouldn't that be nice ?
Nice, be expensive. Each mailbox would have to be read to get that
information (at least, that's true for mbox style mailboxes).
sure it is expensive. i didn't say it was cheap. but hey somehow we have to
burn those extra MHz :-)
Although it doesn't give you the count you're after it sounds more or less
like you're asking for the screen you'll be presented with if you start mutt
with the "-y" switch ("man mutt" lists all the available switches).
the problem with "-y" is that it simply doesn't work reliably.
Yes it does.
No it doesn't. Been there, tried it.
We talk about multiple incoming mboxes that are fed by procmail, don't we?
I can asure you that I often find new mail in these mailboxes eventhough
"mutt -y" doesn't tell so. That may be because wo do backup our system.
And from time to time I allow myself to grep my mail directory for some
phonenumber or other information.
to quote the docs:
---
Note: new mail is detected by comparing the last modification time to
the last access time. Utilities like biff or frm or any other program
which accesses the mailbox might cause Mutt to never detect new mail
for that mailbox if they do not properly reset the access time. Backup
tools are another common reason for updated access times.
---
That quote is informing you that if you allow other tools to modify the
timestamps. It doesn't say that mutt's detection of mailboxes with new mail
is unreliable.
Yes it does. Or what else does this note say?
1. It states that detection of new mail relies on modification and access time.
2. It further says that there are many utilities that don't handle these times
"right".
3. If you dare to use one of those utilities detection of new mail
will not be reliable.
I didn't say that mutt doesn't detect new mail when it is running.
But it surely doesn't tell you in which mailboxes there is new mail
just by starting mutt -y or doing TAB TAB when changing folders.
There is just to much that could have happend to the timestamps
since it was started last time.
So you have to go and check each mailbox by yourself if you want to be
sure.
same happens when you change to one of those folders and you quit without
saving changes to another folder. if you change into that folder again you
will see mails marked as new though the folder was not marked by "N" in
the folder menue.
The "N" status of a mailbox tells you that it has been updated since you
last read the mailbox.
Using the same flag for "new mail" in the index view and
"updated since you last read" in the folder menu is at least confusing.
from the view point of software ergonomics it is a deadly sin.
and to quote the docs again (this is just a few lines above the Note
that i quoted before)...
---
Usage: mailboxes [!]filename [ filename ... ]
This command specifies folders which can receive mail and which will
be checked for new messages. By default, the main menu status bar
displays how many of these folders have new messages.
---
The "how many have new messages." is the crucial part. This sugessts
that it does check for new mails. Though it only checks for access and
modification times.
Without the Note it would be a lie. With the note it says that it
doesn't achieve it goal (detecting new mail on several mboxes) yet.
But there is room for improvement.
Since it is mutt's only way to have an overview of your incoming
mailboxes i think mutt is actually quite weak here.
allow for one final quote:
"All mail clients suck. This one just sucks less."
So please stop defending mutt's weakness in this area and lets try to
think of a way to improve mutt. I love mutt and I want it to suck even
less! :-)
how about saving for each of the "mailboxes"
-size
-modification time (not the access time)
-and the last known amount of total and unread mails in it
in a status file that is read on start.
for those who like it to be stronger we could save md5sums instead of
size and modification date. md5sum-ing the folder would still be much
faster than scaning the whole folder for new mail by parsing the file.
on start mutt would check if the saved data matches the one it finds
on the disk. it could mark the folder with that nice &q
Re: Default mailbox display?
On Fri, Jan 19, 2001 at 09:27:53AM +, Dave Pearson wrote:
On Thu, Jan 18, 2001 at 09:01:42PM -0800, Trae McCombs wrote:
One thing that I think would help not only me, but tons of others is
something like this:
mailbox 1 3 new messages
mailbox 2 12 new messages
mailbox 3 8 new messages
how about this ?
Mail/mutt-users [Msgs:413 New:18 1.1M]
Mail/sf/vuln-dev [Msgs:141478K]
Mail/nymip [Msgs:54 368K]
now wouldn't that be nice ?
Where you had the "status bar" that you could move up and down between
mailboxes... and then you would get into the messages of that mailbox.
Although it doesn't give you the count you're after it sounds more or less
like you're asking for the screen you'll be presented with if you start mutt
with the "-y" switch ("man mutt" lists all the available switches).
the problem with "-y" is that it simply doesn't work reliably.
to quote the docs:
---
Note: new mail is detected by comparing the last modification time to
the last access time. Utilities like biff or frm or any other program
which accesses the mailbox might cause Mutt to never detect new mail
for that mailbox if they do not properly reset the access time. Backup
tools are another common reason for updated access times.
---
same happens when you change to one of those folders and you quit
without saving changes to another folder. if you change into that
folder again you will see mails marked as new though the folder was
not marked by "N" in the folder menue.
i'm not sure if saving a mail from your main incoming folder to one of
the other folders will reset its access time as well .. havn't tried
yet.
BTW: unread but old mail is not detected that way at all.
i see the problem but i have not yet seen a correct solution to it.
i guess i could hatch one if somebody told me how mutt recognizes new
and unread mail inside a folder. yes i am to damn lazy to read the
source :-)))
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Re: Searching the outbox.
On Thu, Jan 18, 2001 at 07:24:31AM +0100, Scott A. McIntyre wrote: Hi, What's the magic to being able to search an "outbox" (set record=) for a specific recipient? I can Search by subject just fine, but I can't seem to get mutt to Search based upon recipient. This one has got to be staring me in the face... AFAIK the outbox isn't different from other mailboxes. so you probably want to try "/" or whatever your search key is and enter "~C EXPR" like "~C mutt.org" to search for mails that are To: or CC: to an address that matches "mutt.org". check out the muttrc man page and look for the "Simple Patterns" section. -heinrich
Re: German umlauts and alternates in Mutt.
On Sat, Jan 13, 2001 at 10:15:20PM +0100, Wilhelm Wienemann wrote: Hello Martin! On Sat, 13 Jan 2001, Martin wrote: On Tuesday, December 12, 2000 (CS:2.50.347) 18:29:00 [PM] (+0100) Jens Paulus [[EMAIL PROTECTED]] wrote... 1.) How can I configure Mutt and teach it to display German umlauts? I could not find any instructions in Mutt's manual how to do this. In the default settings, it always replaces these special characters by a question mark in the builtin pager and by a dot (`.') in the normal index and compose inde Try setting your terminal language (LANG=de_DE). Recent mutt versions use that Only export LC_CTYPE="de_DE" in $HOME/.bashrc works for me. yeap .. but it changes the menues to german as well. and it is not very evident why you have to press "u" for "Behalten" :-) i had the same problem on my system. LC_TYPE wasn't set but LANG was set to "C". i've tried "unset LANG" and put it into .bashrc and from that time umlauts are displayed properly in the index as well as in the internal pager and the menues are still in english. -heinrich -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: New mail detection
On Tue, Jan 02, 2001 at 11:23:25PM +0100, Nikolai Prokoschenko wrote: Hi! I'm sad - the detection of new mail is not working anymore :(( The worst thing is - I can't even imagine, what might have gone wrong. Can I somehow see, which mailboxes are being watched by Mutt? I have a typical line "mailboxes `ls /home/nikolai/Mail/Mails/*`" in my .muttrc, but still - new mails are not detected. Can someone help? Ask for further info, if you need it... Best regards, Nikolai. similar problem here... new mails get detected .. but not allways. starting "mutt -y" may or may not show good results. so i've "set sort_browser=reverse-date" in my .muttrc this way i see when a mailbox has been changed last time and recent changes float on top. even if it isn't marked with that nice "N". btw: to see which files are watched start mutt with "-y" or press c (or whatever is your change-folder key) and TAB twice. the first tab will show all files in your "folder" and the second will switch to your "mailboxes". hth -heinrich -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: New mail detection
On Mon, Jan 08, 2001 at 12:49:55PM +0100, Heinrich Langos wrote: On Tue, Jan 02, 2001 at 11:23:25PM +0100, Nikolai Prokoschenko wrote: Hi! I'm sad - the detection of new mail is not working anymore :(( The worst thing is - I can't even imagine, what might have gone wrong. Can I somehow see, which mailboxes are being watched by Mutt? I have a typical line "mailboxes `ls /home/nikolai/Mail/Mails/*`" in my .muttrc, but still - new mails are not detected. Can someone help? Ask for further info, if you need it... Best regards, Nikolai. similar problem here... new mails get detected .. but not allways. starting "mutt -y" may or may not show good results. so i've "set sort_browser=reverse-date" in my .muttrc this way i see when a mailbox has been changed last time and recent changes float on top. even if it isn't marked with that nice "N". found the reason in the manual: -snipp- 3.11 Defining mailboxes which receive mail [...] Note: new mail is detected by comparing the last modification time to the last access time. Utilities like biff or frm or any other program which accesses the mailbox might cause Mutt to never detect new mail for that mailbox if they do not properly reset the access time. Backup tools are another common reason for updated access times. -snipp- another mystery solved ... -heinrich -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: feature-request: delayed resubmission, follow-up
On Tue, Dec 19, 2000 at 03:22:58PM -0500, David T-G wrote:
Heinrich --
...and then Heinrich Langos said...
% hi
%
% often i get mails that i would like to be reminded of later.
% like i get a mail from my girlfriend in the morning that i should
% fetch something on the way home in the evening.
% but in the evening that mail has been scrolled way off the screen
% and is lost between tons of more or less important stuff.
It sounds like you aren't using threading or other particularly
interesting methods of sorting your mail, so you could just do what I do
when pressed by a bunch of junk: go back every once in a while, tag the
messages containing your reminders, and tag-save them to the current
mailbox. If you're looking at the box in unsorted mode, they are dropped
to the bottom and are right under your nose.
well ... i do use threading, i sort out list traffic in seperate mailboxes,
i clean up my inbox every once in a while, i set save_name to keep track
of ongoing threads both ways ... and so on ...
but i get up to a hundred mails a day. and the main point i was trying
to make was that i don't want to be reminded of a mail all the time
because it is so special but i want to get my reminders just in time.
If you're going to do this sort of thing, then a reminder folder would
be a good way to go. You could also use the X-Label: header to write
yourself a note (or even any string like "rem") and then very simply
limit to that string later.
yeap a reminder folder will be the way to go. so that i can get that
mails out of my incoming folder. but still can access it if i need to.
could mutt ask me for input while running a macro ?
like this:
i press my remind-key and mutt askes me for input (e.g. the time i
want to be reminded of that message) and then pipes the mail to an
external programm putting the input that i gave it in the X-Label
header or on the command line for my external programm?
that external programm would do this:
1) save the mail to my reminder folder.
2) extract the subject and time from the header or the commandline and
set up
a) a reminder line for rclock (saying something like "RM: subject")
or an 'at' job that will pop up an xmessage with the same content.
or
b) some 'at' job that will start something that will bounce the
mail to me again at that time so that it pops up in my inbox
again (it is sorted by thread and received time). triggering
rclock, xbiff or whatever i use to monitor the inbox.
or
c) do nothing and leave the reminding and bouncing to a cron job
that scans the reminder folder once every 10 minutes for work
to do.
writing that external programms is no problem .. probably perl ... the
only thing i would have to think about is locking that file so if i
should bounce the mail to myself i can delete it without interfereing
with myself writing another reminder to that folder at the same time. :)
so the question that remains is: how do i prompt a user in mutt
for input and use that input in the macro?
best regards
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
feature-request: delayed resubmission, follow-up
hi often i get mails that i would like to be reminded of later. like i get a mail from my girlfriend in the morning that i should fetch something on the way home in the evening. but in the evening that mail has been scrolled way off the screen and is lost between tons of more or less important stuff. is there a way in mutt to get reminded of that mail later or does anybody know a local mail bouncer daemon that delays delivery for a (by header or subject) configurable time ? dont tell me about mix cascades. i don't want to set up a whole mix just for delaying. and i don't want to send every mail offsite. and an internal mutt solution (like in a special follow-up-folder) would be nicer anyway since you could still access that mails whenever you liked to. i know that this feature would be very usefull in an office environment too. e.g. somebody sends you a mail and you have to call him to clarify something. you try but that sucker isn't in his office. just queue that mail for resubmission in half an hour. would be nice, wouldn't it? -heinrich ps: i'm no on the list so please cc to me. -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: feature-request: delayed resubmission, follow-up
On Mon, Dec 18, 2000 at 01:38:15PM +0100, Thomas Roessler wrote:
One thing you could do is to use the "important" flag and try to get
a habit of looking at the flagged messages from time to time.
that would mean that all falagged messages would show up all the time..
You could even write a little shell script which basically greps for
"X-Status:.*F", and regularly reminds you that you have important
mail sitting in your inbox.
i would have to write back the inbox regularly than. hmm
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Re: feature-request: delayed resubmission, follow-up
On Mon, Dec 18, 2000 at 06:34:45PM +0530, Suresh Ramasubramanian wrote: Wouldn't procmailing mails from your girlfriend, your co-workers etc etc into separate folders help? ;) not realy ... since i wouldn't reread old mail if not reminded. not even mail from my girl :-) What you are suggesting seems to be the job of sendmail + procmail, imho. You _could_ bounce the mail to an alias which calls a script for doing this ... yes .. i am thinking bout that .. but that would put the delayed mails out of my reach for some time. maybe i should save those mails to a special folder and let a cronjob go through it. finding a mail that was due to resubmission it would bounce that mail to me, and delete it from the folder. question is how to embed the time in the saved mail. still a sollution inside mutt would be better for synchronization and other reasons. ps: i'm no on the list so please cc to me. done i'm on the list now. -heinrich -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
