Re: too many messages saturates slow link
great! problem solved. thanks! David Champion [EMAIL PROTECTED] writes: Subject: Re: too many messages saturates slow link On 2001.03.30, in [EMAIL PROTECTED], "Suresh Ramasubramanian" [EMAIL PROTECTED] wrote: Carlos Puchol proclaimed on mutt-users that: Reading /var/spool/mail/me... 1869 (33%) this saturates my modem line for a little while. is there some way to turn it off or just make it show the XX% part (assuming it is not printed at every message)? That's because mutt has to read the contents of your mbox format mailbox. Switch to (say) maildir. Much faster (and better, if you handle large amounts of mail). I get a lot of mail, and don't need to use maildir for performance reasons. Mbox works fine. Changing to maildir won't solve this problem, either, unless for some odd reason maildir switches out the progress report. What you probably want is to set the read_inc variable, or to make it larger than it is already. $read_inc indicates how often to update the status report line whlie reading a mailbox. For example, setting it to 50 makes the status line update every 50 messages, instead of with each message. - -- -D. [EMAIL PROTECTED]NSITUniversity of Chicago
too many messages saturates slow link
hi, when i connect via a slow link to my box, i get this when i type mutt: Reading /var/spool/mail/me... 1869 (33%) this saturates my modem line for a little while. because (it seems) there is a lot of redraws printing the message count (one line per message?). is there some way to turn it off or just make it show the XX% part (assuming it is not printed at every message)? thanks, -c
feature request: delayed delete
i just had an idea for a feature that i think could kick ass. though maybe it is already in place :) i have a mailbox with 3000 messages and the problem is that i keep on leaving stuff there that i think i will need later, but stays there for years. the idea is to delay-delete a message. the idea is to mark a message for deletion, but not delete it for a while. say i set my 'delay-delete' to 14 days. messages i would delete today will actually get removed from my inbox the first time i do an update on my inbox, at or after 14 days from from today (i.e. from the time i deleted them). maybe even being able to set a default delay and a delay per message, possibly allowing to change the delay at a later day would be great. in essence it is like setting an expiration date for messages. when they expire, they get deleted (or perhaps they are sent to some "expired" mailbox. is it feasible at all? herpahs putting some header in the message with delay delete? --carlos
Re: handling text/plain based on extension of the file
Thomas Roessler [EMAIL PROTECTED] wrote: To answer the original question: For mutt, no such thing as a file extension exists when it looks at how to interpret incoming data. well, but attachments have a comment field or something because i can see the name of the file being sent. it also puts it as a default file name when saving it. it would be nice to have the hooks to make viewer decisions based on that info. but i don't know mutt inside to tell how this can be to write, unfortunately. thanks for the response. ++ carlos
handling text/plain based on extension of the file
hi, i was wondering how to do the following (if possible). i reveive ".mgp" files as text/plain attachments, because most people don't know about magicpoint (a little known but awesome presentation software), thus they don't have a mailcap entry of "application/magicpoint; mgp %s" and a mime entry of "application/magicpoint mgp". is it possible for me to instruct mutt to invoke mgp for those attachments that come as text/plan but the extension of the attachment is .mgp? i have dabbled around the manual a bit, but i am not too experienced with muttrc settings. thanks, ++ carlos
Re: handling text/plain based on extension of the file
Suresh Ramasubramanian [EMAIL PROTECTED] wrote: Carlos Puchol proclaimed on mutt-users that: i reveive ".mgp" files as text/plain attachments, because most people don't know about magicpoint (a little known set auto view in .muttrc For example, I use auto_view application/ms-tnef text/x-vcard auto_view application/x-chess application/x-lotus-notes auto_view text/html application/x-gzip application/x-gunzip auto_view application/rtf application/x-rath but i don't think i want to just autoview text/plain attachments, no? i want mgp to handle the text/plain attachments that have an "*.mgp" as file name whe i press "view-attachments" on it. ++ carlos
fix for redhat 1.2i mutt char encodings
i asked last week about a more recent rpm that did not have broken SHAREDIR, etc. like the original redhat 6.2 had. redhat released an update, mutt-1.2i-2, but it needs to have --enable-locales-fix added to the ./prepare line for accented chars to print (the --with-charmaps option does not seem to affect at all). so, instead of 3737 X 000518 D?nis Riedijk ( 32) Re: ... i like to see: 3737 X 000518 Dènis Riedijk ( 32) Re: ... as well as inside messages, this: for me it works with german special characters like ? ? ? without any problems. Thinks like ? ? are also possible. vs this: for me it works with german special characters like ö ä ü without any problems. Thinks like á é are also possible. thanks, ++ carlos
fix for redhat 1.2i mutt char encodings
i asked last week about a more recent rpm that did not have broken SHAREDIR, etc. like the original redhat 6.2 had. redhat released an update, mutt-1.2i-2, but it needs to have --enable-locales-fix added to the ./prepare line for accented chars to print (the --with-charmaps option does not seem to affect at all). so, instead of 3737 X 000518 D?nis Riedijk ( 32) Re: ... i like to see: 3737 X 000518 Dènis Riedijk ( 32) Re: ... as well as inside messages, this: for me it works with german special characters like ? ? ? without any problems. Thinks like ? ? are also possible. vs this: for me it works with german special characters like ö ä ü without any problems. Thinks like á é are also possible. thanks, ++ carlos
No Subject
From: Manoj Kasichainula [EMAIL PROTECTED]
Subject: Re: mime types when attaching files not working
On Wed, May 10, 2000 at 12:35:51PM -0500, Carlos Puchol wrote:
hi, it appears i the setting of proper mime types does not
work when attaching files. i am attaching two files a ps file and
a gif file. you will see that one comes out as text/plain and the
other as applica/octet-stream.
i have tried with all ~/.mutt* files removed . mine is a regular
redhat 6.2 installation. further it seems like all the settings
are ok in the /etc/mime.types file:
I just found this a few days ago helping a friend. Red Hat's mutt
build is broken (because they don't use the BuildRoot functionality
correctly when compiling their RPM).
SHAREDIR="/var/tmp/mutt-root/etc"
SYSCONFDIR="/var/tmp/mutt-root/etc"
This is the evidence of that.
hi, thanks for your tip.
it looks like the problematic part of the rpm spec is this one:
%install
rm -rf $RPM_BUILD_ROOT
make prefix=$RPM_BUILD_ROOT/usr \
sharedir=$RPM_BUILD_ROOT/etc \
sysconfdir=$RPM_BUILD_ROOT/etc \
docdir=$RPM_BUILD_ROOT/usr/doc/mutt-%{version} install
i don't know much about rpms, but
i have tried removing the $RPM_BUILD_ROOT, and what
happens is that when the install time comes,
it tries to overwrite stuff in /etc, naturally, however,
i always compile rpms as a uder, never as root, to
prevent percisely these kinds of security violations.
do you have any suggestions?
alternatively, are there any suggestions of
some place to get some decent
(s)rpms that of mutt 1.2?
thanks for your help,
++ carlos
Re: making mutt packages.
Thomas Roessler [EMAIL PROTECTED] wrote: I'd suggest you use the DESTDIR mechanism. That is, you ./configure mutt with the directories you want on the target system. Then, when it comes to installing things, you type: make DESTDIR=/what/ever/path/you/want install (At least, that's the mechanism Debian uses, and I'm sure Marco would have complained if DESTDIR doesn't work smoothly from the distributed makefiles.) thanks. i did not realize that the archives posted a solution for this (redhat rawhide). i apologize in cuadruple: for sending the original message twice (one apparently went through despite not being subscribed in the list, or per courtesy of the owner), in the second for sending my follow up without a subject (i am running fast on low gas, i guess), third for the several typos and finally for not looking far enough back in the archives. thanks, ++ carlos
