Re: Feature request
On 04.05.16 15:51, Walter Alejandro Iglesias wrote: > +1 requesting this feature: > > http://unix.stackexchange.com/questions/47773/rebinding-clear-prompt-in-mutt Yes, that would be wonderful. The ^G aberration is a mindbender. > All command line Unix-like system applications should support vi as well > as emacs key bindings. The "map Escape in the terminal" work-around, described at the link, would seem to be a non-starter, since it would completely muck up vim/vi when used as editor in mutt. Erik
Feature request
+1 requesting this feature: http://unix.stackexchange.com/questions/47773/rebinding-clear-prompt-in-mutt All command line Unix-like system applications should support vi as well as emacs key bindings. Walter
Re: [FEATURE REQUEST] ~/.muttrc, ~/.mutt/muttrc and other
=- Michelle Konzack wrote on Sun 18.May'08 at 0:06:56 +0200 -= This would simplify things, because currently if I use mutt -F ~/.mutt_bts/muttrc I have to specify ALL files I source with the FULL PATH which mess up things since some files are only copies from other configs and I have to edit this files all the time I want to change something... Using symlinks and abusing $folder should ease things. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: [FEATURE REQUEST] ~/.muttrc, ~/.mutt/muttrc and other
Hi, * Rado S wrote: =- Michelle Konzack wrote on Sun 18.May'08 at 0:06:56 +0200 -= This would simplify things, because currently if I use mutt -F ~/.mutt_bts/muttrc I have to specify ALL files I source with the FULL PATH which mess up things since some files are only copies from other configs and I have to edit this files all the time I want to change something... Using symlinks and abusing $folder should ease things. Plus shell commands for setup (e.g. 'ls' which can also be useful to generate the appropriate mailboxes command for local mailboxes) and custom my_ variables instead of using $folder (if mutt is recent enough) since that's what they're for, after all... :) Rocco
[FEATURE REQUEST] ~/.muttrc, ~/.mutt/muttrc and other directories
Hello, Since I am developer and my mailinglist/bts subscriptions explode I like to separate the stuff. Unfortunately I have already over 200 config files in my ~/.mutt/ directory. I know I can use mutt -F ~/.mutt/muttrc_std mutt -F ~/.mutt/muttrc_bts mutt -F ~/.mutt/muttrc_ml but this keep all the config files in the same directory which is by default ~/.mutt/. Now I have tried to use mutt -F ~/.mutt_bts/ but this does not work. So I like to see the feature, that if mutt is called with a DIRECTORY as parameter for -F then the default ~/.mutt/ is not more used. This would simplify things, because currently if I use mutt -F ~/.mutt_bts/muttrc I have to specify ALL files I source with the FULL PATH which mess up things since some files are only copies from other configs and I have to edit this files all the time I want to change something... Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
feature request - save_domain
.. like save_name but mutt resolves `bar' from foo.bar.com Some suggested hacks for this but IMHO, this is sufficicently useful (especially for those who deal with many companies / organisations) to be native functionality. -- Eric Smith [hoping]
Re: feature request - save_domain
* Eric Smith [EMAIL PROTECTED] [2002-10-01 10:18]:
Some suggested hacks for this but IMHO, this is sufficicently
useful (especially for those who deal with many companies /
organisations) to be native functionality.
This seems like a good learning excersize, so I was looking into this,
trying to implement save_domain and force_domain that behave identically
to save_name and force_name. However, I cannot figure out how to access
the RHS of the address from within mutt_save_fcc (in hook.c):
/* Within mutt_save_fcc, lines 401 - 427 */
void mutt_select_fcc (char *path, size_t pathlen, HEADER *hdr)
{
ADDRESS *adr;
char buf[_POSIX_PATH_MAX];
ENVELOPE *env = hdr-env;
if (mutt_addr_hook (path, pathlen, M_FCCHOOK, NULL, hdr) != 0)
{
if ((option (OPTSAVENAME) || option (OPTFORCENAME))
(env-to || env-cc || env-bcc))
{
adr = env-to ? env-to : (env-cc ? env-cc : env-bcc);
mutt_safe_path (buf, sizeof (buf), adr);
snprintf (path, pathlen, %s/%s, NONULL (Maildir), buf);
if (!option (OPTFORCENAME) mx_access (path, W_OK) != 0)
strfcpy (path, NONULL (Outbox), pathlen);
}
else if ((option (OPTSAVEDOMAIN) || option (OPTFORCEDOMAIN))
(env-to || env-cc || env-bcc))
{
/* XXX how to access domain portion of address? */
}
else
strfcpy (path, NONULL (Outbox), pathlen);
}
mutt_pretty_mailbox (path);
}
I've already defined OPTSAVEDOMAIN and OPTFORCEDOMAIN in init.h and
mutt.h; if I duplicate the code for OPTSAVENAME and OPTFORCENAME in the
XXX'ed area, I get the correct results. I'm a little stumped, and I'm
sure I'm missing something simple. Any pointers?
(darren)
--
Morality works best when chosen, not when mandated.
-- Larry Wall
Re: Feature request: cross-mbox threading
Hi. Just minor addition, else, I think this has been discussed quite thourougly now. On Sat 2002-07-06 at 11:07:53 +0200, Rocco Rutte wrote: * Benjamin Pflugmann [02-07-05 23:56:08 +0200] wrote: On Fri 2002-07-05 at 01:36:52 +0200, Rocco Rutte wrote: I misunderstood him (completely) but one may specify a limit pattern to show only the mails of one correspondence. How? Hmm, is that a trick question? You limit to mails from you to A and to mails from A to you. Or did I miss something, again? No, not a trick question. Just a different path of thought. I (mis-)understood correspondence more like thread and not as communication partner. Greetings, Benjamin. -- [EMAIL PROTECTED] msg29430/pgp0.pgp Description: PGP signature
Re: Feature request: cross-mbox threading
Hi,
* Benjamin Pflugmann [02-07-05 23:56:08 +0200] wrote:
On Fri 2002-07-05 at 01:36:52 +0200, Rocco Rutte wrote:
* Benjamin Pflugmann [02-07-05 00:44:50 +0200] wrote:
[...]
I misunderstood him (completely) but one may specify a
limit pattern to show only the mails of one
correspondence.
How?
Hmm, is that a trick question? You limit to mails from you
to A and to mails from A to you. Or did I miss something,
again?
But my point was that your suggestion would have all the
mails in one folder instead. I cannot see loading 3 x 1000
messages being significantly slower/faster than 1 x 3000.
It would be the same.
You can also make mutt save the mail to the folder it
was sent from.
I already have in- and outgoing mails in the same folder.
Don't know if that matters to the original poster.
I think so. The scenario was to have incomming in +inbox and
outgoing mail in +outbox.
You can limit to every mail not from you. If you don't
need the thread anymore, move it to the archive.
Well, that is exactly the point. If I moved it to the
archive and get a new message and have to look it up...
Well, that is a question of how long you keep stuff. For
lists it's unlikely that a response will be send to a mail
which is a few weeks old, for example.
The problem arises (or more precisly: the requested
feature could be of use), when a new mail arrives, which
belongs to an done thread and I have to look it up in
the archive.
In this case you know how important reasonable quoting can
be... ;-) Seriously, you're right allthough I see this as a
question of how long you keep mail. I do have extra-lookups,
too, but not very often. And as my archive is quite big
(because it keeps just everything in one place) it's no
difference to me wether I start a second mutt loading a few
thousand mails or turning this feature on. In the latter
case mutt would have to iterate through the whole big
archive, too.
As I said, that mainly happens only with support mails to
me, so maybe you simply do not encounter this, because you
do no support? This includes two things: Getting mails
after a long period of time (more than a month), which
continues an old thread, and people unable to quote
significant context in such mails.
So, I guess that in your case this feature would be usefull.
Or you just set up a newsserver and use mutt as your
newsreader. ;-)
I don't want to say that such a feature would be useless
at all, I just say it's useless to me since I've
organized my communication to not require such features.
Or because you do not get the kind of mails I get? ;-)
Bcc me and we'll see... ;-)
I just wanted to show that the requested feature would
indeed solve a problem which has no direct solution yet.
And all I tried to say is that there're great features one
may use to achieve the same. I know that a line has to be
drawn somewhere because working around everything would work
like a charm ('telnet localhost pop') but isn't very
convenient.
Cheers, Rocco
Re: Feature request: cross-mbox threading
Hi. On Fri 2002-07-05 at 01:36:52 +0200, Rocco Rutte wrote: * Benjamin Pflugmann [02-07-05 00:44:50 +0200] wrote: [...] I misunderstood him (completely) but one may specify a limit pattern to show only the mails of one correspondence. How? I do not think so. The work to do would not be significantly more than with one folder and threading enabled. Sure, it takes some time, but that it already does with one folder, which you suggested as work-around. Well, the code added would have to read mails from a few additional folders instead of just one. But my point was that your suggestion would have all the mails in one folder instead. I cannot see loading 3 x 1000 messages being significantly slower/faster than 1 x 3000. Or are we talking at cross-issues? I have a problem with the checks involved allthough it may be quite less. I also run mutt on a really old machine where every portion of new code makes working unnecessarily hard. Well, the behaviour would be optional. One if-case doesn't cost much in this case. You can also make mutt save the mail to the folder it was sent from. I already have in- and outgoing mails in the same folder. Don't know if that matters to the original poster. You can limit to every mail not from you. If you don't need the thread anymore, move it to the archive. Well, that is exactly the point. If I moved it to the archive and get a new message and have to look it up... [...] Currently I have a macro defined which files the message in the archive folder as mark that it has been done. I do it completely different without creating the need of such a flag on my own. I also keep a state 'done' which I nicely work around without another flag. My filter creates an archive I usually read only. A mail is considered to be 'done' if I delete it from the folder. I see my folders as a kind of temporary place. Older folders are compressed and can be read using the rr.compressed patch. Outgoing mail is saved to the same archive folder, so I have all I need in one place. If I did not misunderstand you, that is exactly what I have, except that I move the mails only after they are done. But this does not matter in this case. To repeat: New mails are filed in a seperate folder, there is also an archive folder. Outgoing mails go directly to the archive. Mails are deleted from the incoming folder, when done (and for me, also moved to the archive). And additionally, the archive is also compressed. ;-) The problem arises (or more precisly: the requested feature could be of use), when a new mail arrives, which belongs to an done thread and I have to look it up in the archive. As I said, that mainly happens only with support mails to me, so maybe you simply do not encounter this, because you do no support? This includes two things: Getting mails after a long period of time (more than a month), which continues an old thread, and people unable to quote significant context in such mails. On the other hand, I delete/file done mails at once, because I need to be able to see quickly, if there are undone mails pending. And unread would not work, because priorities often demand that I read all e-mails, but do not process the unimportant ones for some days. [...] I don't want to say that such a feature would be useless at all, I just say it's useless to me since I've organized my communication to not require such features. Or because you do not get the kind of mails I get? ;-) [...] If you find this feature that usefull, well, than start coding it... ;-) As I said initially in my first mail, I am not sure whether I agree with the original poster about the solution. I just wanted to show that the requested feature would indeed solve a problem which has no direct solution yet. Greetings, Benjamin. -- [EMAIL PROTECTED] msg29405/pgp0.pgp Description: PGP signature
Re: [Feature request] mailbox aliases and internal filtering
* Vincent Lefevre ([EMAIL PROTECTED]) [020701 08:47]: And using push doesn't work correctly with IMAP folders because the corresponding characters are sent as password characters (for security reasons, I don't store my password on my account, though I could change my mind later). If you're not using SSH or SSL for your IMAP anyway, it's no less safe in your go-r .muttrc than it is on the wire each time you connect. You might as well set it there. good times, Vineet -- http://www.doorstop.net/ -- Computer Science is no more about computers than astronomy is about telescopes. -E.W. Dijkstra msg29341/pgp0.pgp Description: PGP signature
Re: [Feature request] mailbox aliases and internal filtering
On Tue, Jul 02, 2002 at 00:20:17 -0700, Vineet Kumar wrote: If you're not using SSH or SSL for your IMAP anyway, it's no less safe [...] On the internal network, we have the choice between using SSL or not (and it's regarded as safe as it's on the internal network, though I prefer to use SSL even in this case). From external machines, we have to use SSL. -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Feature request: cross-mbox threading
Hi, Situation: I usually have to switch between =mbox and =outbox to check the mails on a specific topic we've gone on for a while. Sometimes, another one, say =work/project-A, needs to get involved, too. The same case happens among =mbox.mutt, =outbox, and =mlist/mutt for my daily life. (=mbox,mutt is the in-coming one, =mlist/mutt is for saving the mail I'd like to keep.) Request: Is it possible to have a cross-mbox-threading function as following: 1. A variable, say ref-mboxes (Type: string, default: =mbox:=outbox), to specify related mboxes to reference. The mailbox in front of ':' is the main (or working) mail box, the right side lists the mailboxes to reference. You can add more reference groups by separating them with ';'. 2. A variable, say cross-reference (Type: boolean, default: no), to turn on or off the cross-reference. It will make the referenced mail appear/disappear on the index. 3. When you work on your coming-in =mbox, you can see the threading also reference to those mails in =outbox. (with some display difference) Not all the mails in =outbox appear in current work session - only those belonging to the threads in =mbox will appear. The mails of ref. mailboxes can be read but are read-only. User can not delete or edit them. (unless another variable 'allow-change-ref-mbox' is turned on) It's to avoid confusing. I found such 3-way cross-reference is quite common in my life, and hope it to come true. Thanks. best regards, charlie
[Feature request] mailbox aliases and internal filtering
I'd like to have aliases for mailboxes. Well, I suppose I could define a spurious address with the wanted alias so that I could use the @alias form. But it would be better if there was a cleaner way. And this alias should be displayed instead of the full name with %f in $status_format. Then, how about being able to do internal filtering? For instance, using mailboxes the_mailbox#pattern1 mailboxes the_mailbox#pattern2 mailboxes the_mailbox#pattern3 mailboxes the_mailbox#pattern4 When opening the corresponding physical mailbox the_mailbox, Mutt would automatically do a limit on the pattern. An alias could be used instead of the full mailbox form the_mailbox#pattern1, and so on. Mutt should be able to recognize when the same physical mailbox is used to detect new mail so that change-folder can work as expected. I don't know what is currently done, but synchronizing/... should not set non-visible new messages to old (possibly through an option if some users don't like this behavior). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: [Feature request] mailbox aliases and internal filtering
* Vincent Lefevre [EMAIL PROTECTED] [2002-07-01 08:32:05 +0200]: Then, how about being able to do internal filtering? For instance, using mailboxes the_mailbox#pattern1 mailboxes the_mailbox#pattern2 mailboxes the_mailbox#pattern3 mailboxes the_mailbox#pattern4 When opening the corresponding physical mailbox the_mailbox, Mutt would automatically do a limit on the pattern. An alias could be used instead of the full mailbox form the_mailbox#pattern1, and so on. I've been doing this sort of thing for a long time using links in the filesystem and mutt's `folder-hook'. See URL:http://www.davep.org/mutt/muttrc/folder-hooks.html and look at the last set of hooks. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: [Feature request] mailbox aliases and internal filtering
On Mon, Jul 01, 2002 at 14:58:03 +0100, Dave Pearson wrote: I've been doing this sort of thing for a long time using links in the filesystem and mutt's `folder-hook'. See URL:http://www.davep.org/mutt/muttrc/folder-hooks.html and look at the last set of hooks. This is not exactly what I want. The problem is that it doesn't work with the mailboxes command to cycle through virtual folders with new mail. Moreover, is there a way to link to an IMAP folder (we don't have access to mailboxes via NFS any longer). And using push doesn't work correctly with IMAP folders because the corresponding characters are sent as password characters (for security reasons, I don't store my password on my account, though I could change my mind later). -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Re: Feature request: uncolor not only in index
* Gary Johnson [EMAIL PROTECTED] [2002-04-10 14:22]: Being able to color and uncolor patterns in the pager would be a good solution. yes - an uncolor command is definitely missing. i keep finding this when testing new color patterns. you'll know once you enter a pattern like ^ or . with a color command. ;-) furthermore, i find that limiting by color is missing, too. the idea being that once all the coloring is done you might want to select all those with the same color. for example, i have lots of color commands for possible spam mails - and once these are done i want to tag them all by color - for deletion. hehe Sven
Re: Feature request: uncolor not only in index
* Michael Tatge [EMAIL PROTECTED] [2002-04-10 14:52:24 +0200]: So far so good. Currently it is impossible to remove that pattern again. uncolor only works in the index. Devellopers, any chance to change that? Once again I'd like to add my voice this feature. I see how you people are...I mention it 4 or 5 times and nobody says anything but now... :p Anyway, I think this would be great. I have a lot of different incoming mailboxes and certain strings have special significance if they come in from a particular source, that the same string doesn't have in other contexts; not being able to remove body/header colors means I wind up with a bunch of highlighted strings after I've been running for a while, which kinda defeats the purpose... By the way, Michael...would you mind asking for a feature where mutt will print the entire comment for the key being used to sign (in the compose screen) instead of just the Key ID? :pp -- [EMAIL PROTECTED] msg27030/pgp0.pgp Description: PGP signature
Re: Feature request: uncolor not only in index
* Gary Johnson [EMAIL PROTECTED] [2002-04-10 10:22]: [-- snip --] That being said, I would really like such an uncolor feature myself. I receive internal newsletters that I find easier to read if I highlight the section headings like this: display-hook '~s blips' 'push /\^[A-Z0-9][A-Z0-9 [:punct:]]*$^M' These highlights disappear, however, whenever I search for something. Being able to color and uncolor patterns in the pager would be a good solution. Where does display-hook come from? I just built 1.3.28 and use 1.3.22.1 regularly and neither has it. I'm assuming it comes from a patch, but which one? (darren) -- I accept chaos. I'm not sure whether it accepts me. I know some people are terrified of the bomb. But then some people are terrified to be seen carrying a modern screen magazine. Experience teaches us that silence terrified people the most. -- Bob Dylan
Re: Feature request: uncolor not only in index
On Thu, Apr 11, 2002 at 11:54:49AM -0400, darren chamberlain wrote: That being said, I would really like such an uncolor feature myself. I receive internal newsletters that I find easier to read if I highlight the section headings like this: display-hook '~s blips' 'push /\^[A-Z0-9][A-Z0-9 [:punct:]]*$^M' These highlights disappear, however, whenever I search for something. Being able to color and uncolor patterns in the pager would be a good solution. Where does display-hook come from? I just built 1.3.28 and use 1.3.22.1 regularly and neither has it. I'm assuming it comes from a patch, but which one? I _think_ it's actually a message-hook? -- Dan Boger [EMAIL PROTECTED] msg27054/pgp0.pgp Description: PGP signature
Re: Feature request: uncolor not only in index
On Thu, Apr 11, 2002 at 11:54:49AM -0400, darren chamberlain wrote: Where does display-hook come from? I just built 1.3.28 and use 1.3.22.1 regularly and neither has it. I'm assuming it comes from a patch, but which one? It was a patch for the 1.2 series. I'm using patch-1.2.bj.display-hook.2. I assumed that it would be applied to the 1.3 series, but I haven't followed the development branch features very closely. I think the name may have changed to message-hook in 1.3, but I don't really know. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Spokane, Washington, USA http://www.spocom.com/users/gjohnson/mutt/ |
Re: Feature request: uncolor not only in index
* Dan Boger [EMAIL PROTECTED] [2002-04-11 12:02]: On Thu, Apr 11, 2002 at 11:54:49AM -0400, darren chamberlain wrote: That being said, I would really like such an uncolor feature myself. I receive internal newsletters that I find easier to read if I highlight the section headings like this: display-hook '~s blips' 'push /\^[A-Z0-9][A-Z0-9 [:punct:]]*$^M' These highlights disappear, however, whenever I search for something. Being able to color and uncolor patterns in the pager would be a good solution. Where does display-hook come from? I just built 1.3.28 and use 1.3.22.1 regularly and neither has it. I'm assuming it comes from a patch, but which one? I _think_ it's actually a message-hook? Yup, got it. Thanks. I was interested in the hook displayed above, which is why I was looking for display-hook in the first place. I noticed, though, that the above command jumps to the first occurance of the match, so my version adds a top after the search. Here is an example, similar to the above: message-hook ~s 'pgp|gpg' 'push searchpgp|gpgReturntop' This highlights pgp and gpg in messages with pgp or gpg in the subject. Thanks to all who helped. (darren) -- A theory is not accepted when it's critics are converted, but when they eventually die. -- Maxwell Plank
Feature request: uncolor not only in index
Hi all, I just played around with my color setup. I found that it's sometimes usefull to hightlight numbers in the body of a message to find a phone number and the like. Now, I want to do that only on demand. macro pager f5 exitenter-commandcolor body [0-9]enterdisplay-message So far so good. Currently it is impossible to remove that pattern again. uncolor only works in the index. Devellopers, any chance to change that? TIA, Michael -- I've run DOOM more in the last few days than I have the last few months. I just love debugging ;-) (Linus Torvalds) PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
Re: Feature request: uncolor not only in index
Michael -- ...and then Michael Tatge said... % % Hi all, Hello! % % I just played around with my color setup. I found that it's sometimes % usefull to hightlight numbers in the body of a message to find a phone Sure; that makes sense. % number and the like. Now, I want to do that only on demand. Of course :-) % % macro pager f5 exitenter-commandcolor body [0-9]enterdisplay-message % % So far so good. Currently it is impossible to remove that pattern % again. uncolor only works in the index. % % Devellopers, any chance to change that? What about a different approach: just search for [0-9\-/\.]* (figuring that that will match most ways to write a phone number; with some magic I'm sure it can include spaces without hitting ALL spaces in the message) while in the pager and let mutt highlight the search results for you. % % TIA, HTH HAND % % Michael % -- % I've run DOOM more in the last few days than I have the last few % months. I just love debugging ;-) % (Linus Torvalds) % % PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26967/pgp0.pgp Description: PGP signature
Re: Feature request: uncolor not only in index
David T-G ([EMAIL PROTECTED]) muttered: ...and then Michael Tatge said... % macro pager f5 exitenter-commandcolor body [0-9]enterdisplay-message % What about a different approach: just search for [0-9\-/\.]* No. This would color each and every -, / and ., too. But ([0-9]+[\.:/-]*)* would do for most numbers, phones, dates and times. Only I cannot turn it off, which sucks. Michael -- Are [Linux users] lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software? (By Matt Welsh) PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
Re: Feature request: uncolor not only in index
Michael -- ...and then Michael Tatge said... % % David T-G ([EMAIL PROTECTED]) muttered: % ...and then Michael Tatge said... % % macro pager f5 exitenter-commandcolor body [0-9]enterdisplay-message % % % % What about a different approach: just search for [0-9\-/\.]* % % No. This would color each and every -, / and ., too. But % ([0-9]+[\.:/-]*)* would do for most numbers, phones, dates and times. Agreed; I said it would need some magic :-) % Only I cannot turn it off, which sucks. What's to turn off? You can either re-search for a non-existent pattern (or something empty like ^$ which won't show up anyway) if you're going to continue reading through that message and somehow don't want to notice the number any more or go back to the index and move on; on my mutt, at least, the next message I enter is not pre-highlighted after a search in another message. % % Michael HTH HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26969/pgp0.pgp Description: PGP signature
Re: Feature request: uncolor not only in index
On Wed, Apr 10, 2002 at 04:06:02PM +0200, Michael Tatge wrote: David T-G ([EMAIL PROTECTED]) muttered: ...and then Michael Tatge said... % macro pager f5 exitenter-commandcolor body [0-9]enterdisplay-message % What about a different approach: just search for [0-9\-/\.]* No. This would color each and every -, / and ., too. But ([0-9]+[\.:/-]*)* would do for most numbers, phones, dates and times. Only I cannot turn it off, which sucks. Sure you can. Since it is a search string, just type something like /lasjdslkddd I just let my fingers jitter on the home row. It won't match anything, thereby turning off the highlighting and leaving the pager otherwise unchanged. That being said, I would really like such an uncolor feature myself. I receive internal newsletters that I find easier to read if I highlight the section headings like this: display-hook '~s blips' 'push /\^[A-Z0-9][A-Z0-9 [:punct:]]*$^M' These highlights disappear, however, whenever I search for something. Being able to color and uncolor patterns in the pager would be a good solution. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Spokane, Washington, USA http://www.spocom.com/users/gjohnson/mutt/ |
Re: Feature request: uncolor not only in index
David T-G ([EMAIL PROTECTED]) muttered: ...and then Michael Tatge said... % % What about a different approach: just search for [0-9\-/\.]* ^^ % ([0-9]+[\.:/-]*)* would do for most numbers, phones, dates and times. % Only I cannot turn it off, which sucks. What's to turn off? Right, you're talking about seraching not coloring, which I missed the first time. Sorry. Michael -- Avoid the Gates of Hell. Use Linux (Unknown source) PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
Re: Feature request: uncolor not only in index
Michael -- ...and then Michael Tatge said... % % David T-G ([EMAIL PROTECTED]) muttered: % ...and then Michael Tatge said... ... % % % Only I cannot turn it off, which sucks. % % What's to turn off? % % Right, you're talking about seraching not coloring, which I missed the Ah. Right. % first time. Sorry. Hey, no problem :-) % % Michael % -- % Avoid the Gates of Hell. Use Linux % (Unknown source) % % PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! msg26974/pgp0.pgp Description: PGP signature
Re: Feature Request
begin quoting what Sven Guckes said on Thu, Apr 04, 2002 at 01:39:43AM +0200: feature request denied. macro index c change-folder! That breaks ? for list functionality. It would be better to assign it to another key: macro index I change-folder!\r Then get used to using I when you want it. msg2/pgp0.pgp Description: PGP signature
Re: Feature Request
* Shawn McMahon [EMAIL PROTECTED] [04-04-02 08:22]: begin quoting what Sven Guckes said on Thu, Apr 04, 2002 at 01:39:43AM +0200: feature request denied. macro index c change-folder! That breaks ? for list functionality. It would be better to assign it to another key: macro index I change-folder!\r Then get used to using I when you want it. The request was: Feature request. It would be nice and timesaving (for me, at least) if change-folder would default to ! when where was not a folder containing New Mail. Neither suggestion satisfies the request... for a default action, a suggested destination when no folder containing New Mail was available. tks, -- Patrick Shanahan Registered Linux User #207535 Registered at: http://counter.li.org
Feature Request
Feature request. It would be nice and timesaving (for me, at least) if change-folder would default to ! when where was not a folder containing New Mail. Perhaps a set feature in muttrc ?? set change-folder some-default-location Just a thought. -- Pat Shanahan Registered Linux User #207535 Registered at: http://counter.li.org
Re: Feature Request
* pat [EMAIL PROTECTED] [2002-04-03 19:48]: Feature request. It would be nice and timesaving (for me, at least) if change-folder would default to ! when where was not a folder containing New Mail. Perhaps a set feature in muttrc ?? set change-folder some-default-location feature request denied. macro index c change-folder! we won't waste extra code for this. ;-) Sven
Re: Feature Request
Sven Guckes wrote: * pat [EMAIL PROTECTED] [2002-04-03 19:48]: Feature request. It would be nice and timesaving (for me, at least) if change-folder would default to ! when where was not a folder containing New Mail. Perhaps a set feature in muttrc ?? set change-folder some-default-location feature request denied. macro index c change-folder! we won't waste extra code for this. ;-) well (s)he requested that it would default to ! when there wasn't already a folder containing new mail. so i don't think this would do quite the same thing... -- Will Yardley input: william @ hq . newdream . net .
Re: Feature Request - change the change-folder default folder
* Sven Guckes [EMAIL PROTECTED] [04-03-02 19:50]: * pat [EMAIL PROTECTED] [2002-04-03 19:48]: Feature request. It would be nice and timesaving (for me, at PS: But, dammit, Pat, put your name into the From: line so an attribution makes sense! Sven Just for you, Sven. aka patrick -- Pat Shanahan Registered Linux User #207535 Registered at: http://counter.li.org
Feature request: auto_view accepts its own handler
I'm not sure I used the correct terminology in the Subject: line, but what I'm looking for is pretty easy to explain (hopefully easy to implement also :p) Basically, this is what we have now: auto_view image/tiff This line tells mutt to consult $mailcap_path and find a mailcap entry that corresponds to the MIME type and display it Well, as you can see from this particular example, you're not going to get anything useful from a TIFF file on a 80x24 terminal (and no, aaview is not an acceptable answer :)) So, what one does is create a mutt-specific mailcap file that has a line for image/tiff which, instead of calling a graphic viewer like qiv/ee/xv/etc, calls something like tiffinfo that displays some properties of the image instead, so at least you can get _something_ useful out of it Well, I like this behaviour by itself, but I think this is only one example of a whole class of cases where the viewer desired for an inline, auto_view environment is a lot different from the viewer one would normally use for a given file type In other words, I think it would be good to have something like this: auto_view image/tiff tiffinfo '%s' In theory, if any more arguments appear after the first argument (the type argument, in this case 'image/tiff') then they are assumed to be a mailcap-format capabilities line Of course, it wouldn't have/want to be a full-featured implementation, since most of the mailcap fields would be irrelevant in an auto_view context (like compose, composetyped, etc), but maybe test and notes could be used somehow *shrug* The point of all this, is that you now have a viewer specifically for auto_view, which is displaying files out of their native environment most of the time So, now when you go to the view attachments menu and select one, you can actually execute it with an image viewer or whatever, instead of having to save it to disk first and then manually run it, or take the time to use the pipe-entry function which may not work if the viewer command doesn't accept stdin By the way, I have read this from Section 53 of the manual: - cut here In addition, you can use this with Autoview to denote two commands for viewing an attachment, one to be viewed automatically, the other to be viewed interactively from the attachment menu In addition, you can then use the test feature to determine which viewer to use interactively depending on your environment text/html; netscape -remote 'openURL(%s)' ; test=RunningX text/html; lynx %s; nametemplate=%shtml text/html; lynx -dump %s; nametemplate=%shtml; copiousoutput - cut here This solution works Most Of The Time(tm), but is a bit inelegant in that it co-opts the copiousoutput flag for mutt use I think adding this extra functionality to the auto_view function would eliminate the need for a lot of the mutt-specific mailcap files that are out there, and should be implementable without a whole lot of coding; in other words, when mutt goes to autoview a particular file as a result of the auto_view command, it sees that there is already an instruction on the command line and just uses that instead of calling the function that searches the mailcap files for a corresponding line Of course, generating a compliant mailcap-style line that views the attachment in the pager without errors would be the user's responsibility; but it already is when generating mailcap files -- John Buttery (Web page temporarily unavailable) msg25035/pgp0.pgp Description: PGP signature
Re: command line folder alias access (feature request)
Alexander, et al -- ...and then Alexander V. Konstantinou said... % % Right now I've achieved this functionality through a wrapper shell % % script that greps for the alias name and invokes mutt with the real % % user name. % % That makes sense, though it sounds somewhat painful. % % It is not really painful, or slow for that matter on my machine ... I'm sure it's easy to use, and I'm glad it's not slow. By painful, though, I meant that it requires an extra step and you have to wrap your mutt invocation. % Here is my quick and dirty script: --8-- snip A nice piece of work. Not so dirty at all :-) % % Have you checked out Hans Bogaard's save_alias patch? That lets you % save your mail to foolong in =foo instead of =foolong, which is perhaps % a backwards way of achieving what you want but adds the advantage that % your aliases are less likely to collide than real world names and so you % shouldn't have any (or should at least have fewer) problems in $folder :-) % % Actually, I like this idea better than mine. I'll try this patch out. Enjoy! You can find a copy at http://mutt.justpickone.org/mutt-build-cocktail/ if nowhere else. % % Thanks, % % Alexander :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
Re: command line folder alias access (feature request)
Alexander -- ...and then Alexander V. Konstantinou said... % As far as I can tell, mutt does not support openning the folder of % a user based on an alias. For example, consider user [EMAIL PROTECTED] % that is aliased as foo. Yep. % % I'd like to be able to open the folder using mutt -f =foo (perhaps % using some other symbol than '='). Nah; that's fine. % % Right now I've achieved this functionality through a wrapper shell % script that greps for the alias name and invokes mutt with the real % user name. That makes sense, though it sounds somewhat painful. % % Have you considered this feature? Would it be something that if I % modified on the source code you would be willing to add to the % main source tree? Have you checked out Hans Bogaard's save_alias patch? That lets you save your mail to foolong in =foo instead of =foolong, which is perhaps a backwards way of achieving what you want but adds the advantage that your aliases are less likely to collide than real world names and so you shouldn't have any (or should at least have fewer) problems in $folder :-) % % Thanks for the great mutt of mailers! % % Alexander :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.justpickone.org/davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
Re: command line folder alias access (feature request)
% Right now I've achieved this functionality through a wrapper shell
% script that greps for the alias name and invokes mutt with the real
% user name.
That makes sense, though it sounds somewhat painful.
It is not really painful, or slow for that matter on my machine ...
Here is my quick and dirty script:
#!/bin/bash
#
# Wrapper script for automatically expanding mutt aliases
#
# Known issues: if an alias conflicts with a real folder name then
# the alias wins!
ALIAS_FILE=$HOME/.mutt/mail_aliases
MUTT=/usr/bin/mutt
COMMAND=
for ARG in $*; do
if [ -n `echo $ARG | grep '^='` ]; then
FOLDER=`echo $ARG | sed 's/=//'`
LINE=`grep ^alias *$FOLDER $ALIAS_FILE`
if [ -n $LINE ]; then
FOLDER=`echo $LINE | awk -F'' '{print $2}' | awk -F'@' '{print $1}'`
ARG==$FOLDER
fi
fi
if [ -n $COMMAND ]; then
COMMAND=$COMMAND $ARG
else
COMMAND=$ARG
fi
done
exec $MUTT $COMMAND
Have you checked out Hans Bogaard's save_alias patch? That lets you
save your mail to foolong in =foo instead of =foolong, which is perhaps
a backwards way of achieving what you want but adds the advantage that
your aliases are less likely to collide than real world names and so you
shouldn't have any (or should at least have fewer) problems in $folder :-)
Actually, I like this idea better than mine. I'll try this patch out.
Thanks,
Alexander
command line folder alias access (feature request)
As far as I can tell, mutt does not support openning the folder of a user based on an alias. For example, consider user [EMAIL PROTECTED] that is aliased as foo. I'd like to be able to open the folder using mutt -f =foo (perhaps using some other symbol than '='). Right now I've achieved this functionality through a wrapper shell script that greps for the alias name and invokes mutt with the real user name. Have you considered this feature? Would it be something that if I modified on the source code you would be willing to add to the main source tree? Thanks for the great mutt of mailers! Alexander
Re: feature request
Thanks! Erwin
feature request
Mutt is great! Two features I'd like to propose: 1. The screen should be cleared at termination. 2. Often I get mail with a lot of adresses in the Cc: field which I'd like to take into my alias list. So: Could the taking alias feature be expanded to other entries and mulpiple entries? Thanks to all developers! Erwin
Re: feature request
Erwin Kaiser writes: Mutt is great! Two features I'd like to propose: 1. The screen should be cleared at termination. This is a feature of the terminal emulator you are running. This is the reason why I replaced the xterm terminfo entry on my Solaris box with the X11R6 xterm definition from ncurses ;)
Re: feature request
On Thu, Jul 12, 2001 at 11:35:43AM +0200, Erwin Kaiser wrote: 2. Often I get mail with a lot of adresses in the Cc: field which I'd like to take into my alias list. So: Could the taking alias feature be expanded to other entries and mulpiple entries? see http://webrum.uni-mannheim.de/jura/moritz/mail2muttalias.shtml for a script that does more-or-less what you want. -- Biju -- - Biju Chacko| [EMAIL PROTECTED] (work) Exocore Consulting | [EMAIL PROTECTED] (play) Bangalore, India | http://www.exocore.com -
Re: Feature Request - don't encrypt when sending to mailing list
David wrote: send-hook ~l 'push f^Uenterpsenter' Okay well that should have been just: send-hook ~l 'push psenter' I have f^U as i dont want to save my messages i send to mailing lists as they get sent back to me anyway. -- Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!! - Fingerprint : 869B 53DD 5E80 E1F0 93F6 9871 0508 0296 5957 F723 David Clarke [EMAIL PROTECTED] || [EMAIL PROTECTED] PGP signature
Re: Feature Request - don't encrypt when sending to mailing list
At 16:00 +0200 08 Apr 2001, Christian Biesinger [EMAIL PROTECTED] wrote: It would be nice if there was an option for mutt to not encrypt mails for mailing lists, even though I've set crypt_autoencrypt to yes (I've installed the S/MIME patch). I know that I could use send-hook for this, but then I'd have to add every mailing list to send-hook as well as to lists/subscribe. You're right, you can use send-hook for this, but you're wrong about needing to specify each mailing list: send-hook ~A 'set crypt_autoencrypt' send-hook ~l 'unset crypt_autoencrypt' The ~l pattern will match if the message is going to a known list. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ If you consistently take an antagonistic approach, however, people are going to start thinking you're from New York. :-) --Larry Wall to Dan Bernstein
Re: Feature Request - don't encrypt when sending to mailing list
Christian Biesinger wrote: I know that I could use send-hook for this, but then I'd have to add every mailing list to send-hook as well as to lists/subscribe. If you have already added the mailing lists to the subscribe list in your muttrc then all you have to do is use a send hook like: send-hook ~l 'push f^Uenterpsenter' This signs all messages to any mailing lists that are listed in subscribe in your muttrc. (~l represents mailing lists) Have a look at "man muttrc" for more ideas on send-hooks -- Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!! - Fingerprint : 869B 53DD 5E80 E1F0 93F6 9871 0508 0296 5957 F723 David Clarke [EMAIL PROTECTED] || [EMAIL PROTECTED]
Re: Feature Request - don't encrypt when sending to mailing list
On Sun, Apr 08, 2001 at 09:37:06PM -0500, Aaron Schrab wrote: send-hook ~l 'unset crypt_autoencrypt' The ~l pattern will match if the message is going to a known list. Hm... This works fine for lists I'm subscribed to. It doesn't work, though, for the lists I'm not subscribed to. Yes, Mutt knows about them - I used the "lists" command for them. Should ~l match them as well? -- Encrypted Emails strongly preferred! Get PGP from: http://www.pgpi.org PGP-Key: 1024D/DFFE21F1 - Get it from http://mmc.sourceforge.net/biesi.asc Key fingerprint = E60D 24FC BBC5 97CE 5421 C0FE 311B 7F82 DFFE 21F1 PGP signature
Re: Feature Request - don't encrypt when sending to mailing list
Christian Biesinger [[EMAIL PROTECTED]] wrote: Currently, I've configured Mutt to always encrypt messages I send. However, sometimes I send mails to mailing lists. Mutt knows about them (I've got entries for them in my ~/.muttrc using lists or subscribe). However, usually mails to mailing lists should not be encrypted. It would be nice if there was an option for mutt to not encrypt mails for mailing lists, even though I've set crypt_autoencrypt to yes (I've installed the S/MIME patch). I know that I could use send-hook for this, but then I'd have to add every mailing list to send-hook as well as to lists/subscribe. No, you should be able to get it working via send-hooks just using the ~l pattern (message is being sent to a known mailing list). Something like: send-hook . "set crypt_autoencrypt" send-hook ~l "unset crypt_autoencrypt" -- Jeremy Blosser | [EMAIL PROTECTED] | http://jblosser.firinn.org/ -+-+-- the crises posed a question / just beneath the skin the virtue in my veins replied / that quitters never win
Feature Request - don't encrypt when sending to mailing list
Hello! Currently, I've configured Mutt to always encrypt messages I send. However, sometimes I send mails to mailing lists. Mutt knows about them (I've got entries for them in my ~/.muttrc using lists or subscribe). However, usually mails to mailing lists should not be encrypted. It would be nice if there was an option for mutt to not encrypt mails for mailing lists, even though I've set crypt_autoencrypt to yes (I've installed the S/MIME patch). I know that I could use send-hook for this, but then I'd have to add every mailing list to send-hook as well as to lists/subscribe. PS: Please CC me on replies, I'm not subscribed to this list. -- Encrypted Emails strongly preferred! Get PGP from: http://www.pgpi.org PGP-Key: 1024D/DFFE21F1 - Get it from http://mmc.sourceforge.net/biesi.asc Key fingerprint = E60D 24FC BBC5 97CE 5421 C0FE 311B 7F82 DFFE 21F1 PGP signature
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| ~
Re: feature-request: delayed resubmission, follow-up
On Wed, Dec 20, 2000 at 12:16:58PM +0100 or so it is rumoured hereabouts, Heinrich Langos thought: so the question that remains is: how do i prompt a user in mutt for input and use that input in the macro? Best I've done is to use xmessage and get the return from the buttons pressed but that only allows pre-defined answers which won't work here. Perhaps a little TCL/TK app to ask for typed input or a set of buttons to create the time from eg. 0h 1h 2h ... 00m 05m 10m 15m ... Pass it on if you do eh? I could use something like that at a later date. -- Conor Daly [EMAIL PROTECTED] Domestic Sysadmin :-) - 12:53pm up 2 days, 41 min, 1 user, load average: 0.00, 0.01, 0.00
Re: feature-request: delayed resubmission, follow-up
On Wed, Dec 20, 2000 at 12:16:58PM +0100, Heinrich Langos wrote: 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? so the question that remains is: how do i prompt a user in mutt for input and use that input in the macro? Here's one way. macro index Escr pipe-messageremind_scriptReturn macro pager Escr pipe-messageremind_scriptReturn where remind_script is something like this: echo "Enter time for reminder:" read time /dev/tty subject=$(sed -n '/^Subject: /s/^[^:]*: //p') echo "mutt -s \"Reminder: $subject\"" your_address | at $time Note that 'mutt' is executed at the time specified and in the environment of 'at' and therefore the message body is no longer available (besides being consumed by 'sed' in this example). I'm sure that's solvable, too, but I'll leave that to you. Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | RF Communications Product Generation Unit | Spokane, Washington, USA
Re: feature-request: delayed resubmission, follow-up
Heinrich -- ...and then Heinrich Langos said... % On Tue, Dec 19, 2000 at 03:22:58PM -0500, David T-G wrote: % ...and then Heinrich Langos said... % % % % often i get mails that i would like to be reminded of later. ... % % and is lost between tons of more or less important stuff. % % It sounds like you aren't using threading or other particularly ... % % 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 ... Good enough. % % 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. Ah; gotcha. % % 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. Sounds like it. % % could mutt ask me for input while running a macro ? mutt's macro language can't, but your external script can. % 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? I'd figure your program would ask for the time (unless it saw it on the command line, of course) and then do the work. % % that external programm would do this: ... % % 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. :) Well, you could always mutt_dotlock to lock it :-) % % so the question that remains is: how do i prompt a user in mutt % for input and use that input in the macro? It seems that the answer is that "you don't" :-) % % 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| % ~ :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
Re: feature-request: delayed resubmission, follow-up
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. 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. HTH HH :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
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
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. 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. -- Thomas Roessler [EMAIL PROTECTED]
Re: feature-request: delayed resubmission, follow-up
Heinrich Langos proclaimed on mutt-users that: 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. Wouldn't procmailing mails from your girlfriend, your co-workers etc etc into separate folders help? ;) 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 ... ps: i'm no on the list so please cc to me. done -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI Turnaucka's Law: The attention span of a computer is only as long as its electrical cord.
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
Hi, On 00-12-18, Heinrich Langos wrote: 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 ? You could tell Procmail to put out an at(1) job. Or make a makro to do this if your so's order are not easy to identify.
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| ~
Re: feature-request: delayed resubmission, follow-up
On Mon, Dec 18, 2000 at 10:46:14AM +0100, Heinrich Langos wrote: 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 use mutt in combination with procmail and xbuffy. If I need to remind myself of a mail, I flag that message as new and save it in a special folder -- done with a macro. Rest is taken care by xbuffy. Further, xbuffy is "omnipresent" in my window manager and a middle click launches mutt. Here are sample mutt macros: # line breaks for clarity macro index "" ":set noresolve\r:set noconfirmcreate\rwN :set resolve\rs\r:set confirmcreate\r" macro pager "" ":set noresolve\r:set noconfirmcreate\rN :set resolve\rs\r:set confirmcreate\r" Here, the mail is saved in $mbox. You can choose yours. resolve is turned off to prevent advancement of cursor when we turn the 'new' flag on. It is turned back on later. I also use nosave_empty. Hence the confirmcreate stuff. Regards Sankar -- Sankaranarayanan K. V. | [EMAIL PROTECTED] Motorola India Electronics Ltd | http://www.mot.com/miel
Re: feature-request: delayed resubmission, follow-up
On Mon, Dec 18, 2000 at 07:29:42PM +0530, Sankaranarayanan K V wrote: I use mutt in combination with procmail and xbuffy. If I need to remind myself of a mail, I flag that message as new and save it in a special folder -- done with a macro. Rest is taken care by xbuffy. Further, xbuffy is "omnipresent" in my window manager and a middle click launches mutt. That special folder should be put in 'mailboxes' also. You can cycle through folders and see your girlfriend's mail whenever you want. BTW, I also use 'set nomark_old'. Regards Sankar -- Sankaranarayanan K. V. | [EMAIL PROTECTED] Motorola India Electronics Ltd | http://www.mot.com/miel
Re: feature-request: delayed resubmission, follow-up
On 2000-12-18 14:25:41 +0100, Heinrich Langos wrote: 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.. Yes. If I got your message right, you belong to those people who have a gigantic inbox where everything piles up. Now, the idea is that you use mutt's limit feature regularly and have a look at what kind of flagged messages you have there. 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 This is, of course, a matter of taste. You could also just pop up an xmessage window telling you that you have so-and-so many flagged messages. -- Thomas Roessler [EMAIL PROTECTED]
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
On Fri, Oct 20, 2000 at 02:14:09PM +0200, Thomas Roessler wrote: Did you try to change the content-type of these octet-streams to application/pgp? With the more recent mutt versions, you can comfortably do this from within mutt. Really? I'm using mutt 1.2i . What version do I need to do this and where do I find information on this? Regards, Daniel.
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
Daniel Kollar [EMAIL PROTECTED] wrote on Mon, 23 Oct 2000: Did you try to change the content-type of these octet-streams to application/pgp? With the more recent mutt versions, you can comfortably do this from within mutt. Really? I'm using mutt 1.2i . What version do I need to do this and where do I find information on this? I think 1.2 is sufficient. Try ^E (edit-type) from either the index, pager or the attachements display view. The change will only last while you're in that folder, it won't get saved into the message (I think). Ooops, I just noticed that this function isn't listed in the manual, time to create a documentation patch again... It is listed in the help screens, though. Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Did you know that the word "gullible" is not in the dictionary?
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
On Mon, Oct 23, 2000 at 10:25:02AM +0200, Daniel Kollar wrote: On Fri, Oct 20, 2000 at 02:14:09PM +0200, Thomas Roessler wrote: Did you try to change the content-type of these octet-streams to application/pgp? With the more recent mutt versions, you can comfortably do this from within mutt. Really? I'm using mutt 1.2i . What version do I need to do this and where do I find information on this? I'm using 1.2i - from the attachments help page: ^E edit-type edit attachment content type Best, Petr
FEATURE-REQUEST: mutt looks for PGPPASS environment variable
Hello mutt-developers, here is a feature request for future versions of mutt: Mutt looks for the PGPPASS environment variable. If this is set, then no passphrase is needed to be send to pgp program, because pgp looks for the PGPPASS variable by itself. Mutt will also not ask the user for the passphrase. This should be easy to implement. The user would then have the option to set the passphrase via a wrapper-script permanently. For example: muttwrap --- #!/usr/bin/sh set $passparam=$* if ( ps -U $LOGNAME | grep mutt | grep -v muttwrap /dev/null ) then echo "WARNING: You are already running Mutt." echo " Starting Mutt in readonly mode." echo echo "Please enter passphrase: " stty -echo read pgppassphrase PGPPASS=$pgppassphrase; export PGPPASS stty echo $PATHTOMUTT/mutt -R $* else echo "Please enter passphrase: " stty -echo read pgppassphrase PGPPASS=$pgppassphrase; export PGPPASS stty echo $PATHTOMUTT/mutt $passparam fi -- Thank you very much! Regards, Daniel.
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
Don't do that. Storing the pgp pass phrase in an environment variable may have been a valid option on MS-DOS computers. It isn't on Unix machines, since the environment is not guaranteed to be confidential. Also, what's the point in using a shell script like the one below? - There is no reason to avoid running two mutts on the same mailbox. Mutt _does_ know how to graciously deal with concurrent access to mail folders. - There is no point in asking for the pass phrase in a shell script, and then storing it in $PGPPASS. Mutt will ask for the pass phrase the first time it's needed, and remember it for the coming $pgp_timeout seconds. The default is 300 seconds; you can easily change that from your .muttrc. Note that the mechanism mutt uses to pass the pass phrase to pgp _is_ safe against eavesdropping by other users on the same system. On 2000-10-20 10:21:20 +0200, Daniel Kollar wrote: Date: Fri, 20 Oct 2000 10:21:20 +0200 From: Daniel Kollar [EMAIL PROTECTED] To: Mutt User List [EMAIL PROTECTED] Subject: FEATURE-REQUEST: mutt looks for PGPPASS environment variable Mail-Followup-To: Mutt User List [EMAIL PROTECTED] User-Agent: Mutt/1.2i Hello mutt-developers, here is a feature request for future versions of mutt: Mutt looks for the PGPPASS environment variable. If this is set, then no passphrase is needed to be send to pgp program, because pgp looks for the PGPPASS variable by itself. Mutt will also not ask the user for the passphrase. This should be easy to implement. The user would then have the option to set the passphrase via a wrapper-script permanently. For example: muttwrap --- #!/usr/bin/sh set $passparam=$* if ( ps -U $LOGNAME | grep mutt | grep -v muttwrap /dev/null ) then echo "WARNING: You are already running Mutt." echo " Starting Mutt in readonly mode." echo echo "Please enter passphrase: " stty -echo read pgppassphrase PGPPASS=$pgppassphrase; export PGPPASS stty echo $PATHTOMUTT/mutt -R $* else echo "Please enter passphrase: " stty -echo read pgppassphrase PGPPASS=$pgppassphrase; export PGPPASS stty echo $PATHTOMUTT/mutt $passparam fi -- Thank you very much! Regards, Daniel. -- Thomas Roessler [EMAIL PROTECTED]
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
Don't do that. Storing the pgp pass phrase in an environment variable may have been a valid option on MS-DOS computers. It isn't on Unix machines, since the environment is not guaranteed to be confidential. I'm working on unix. In the PGP CmdLineGuide you will find a section about this. There you can read that using this feature is safe when you use in in a environment where no one else has access to it. I'm doing that. The environment is only active as long as mutt is open. No one from outside can access it. The wrapper script asks me for entering the passphrase and starts mutt immedeately after this. So, it is safe. The only thing a would agree is that someone can change the wrapper script to send the passphrase via email to outside... Also, what's the point in using a shell script like the one below? - There is no reason to avoid running two mutts on the same mailbox. Mutt _does_ know how to graciously deal with concurrent access to mail folders. - There is no point in asking for the pass phrase in a shell script, and then storing it in $PGPPASS. Mutt will ask for the pass phrase the first time it's needed, and remember it for the coming $pgp_timeout seconds. The default is 300 seconds; you can easily change that from your .muttrc. Maybe you have read my previous email regarding the mutt_octet-filter which can decrypt pgp encrypted octet-streams. The PGPPASS environment variable is the easiest way to remember the passphrase. But now I have to enter the passphrase two times. One for my octet-filter and one for mutt. What solution to you see? Daniel.
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
On Fri, Oct 20, 2000 at 01:51:13PM +0200, Daniel Kollar wrote: In the PGP CmdLineGuide you will find a section about this. There you can read that using this feature is safe when you use in in a environment where no one else has access to it. I'm doing that. The environment is only active as long as mutt is open. No one from outside can access it. The wrapper script asks me for entering the passphrase and starts mutt immedeately after this. So, it is safe. The only thing a would agree is that someone can change the wrapper script to send the passphrase via email to outside... what about people accessing mutt's enviroment through the proc filesystem? or via strace? "an enviroment where no one else has access to it" ususally means a standalone computer, or one where you are the ONLY user (including root)... if it's a multi user machine, your env isn't safe. -- Dan Boger System Administrator [EMAIL PROTECTED] PGP signature
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
On 2000-10-20 13:51:13 +0200, Daniel Kollar wrote: I'm doing that. The environment is only active as long as mutt is open. No one from outside can access it. That's your particular environment. However, mutt is designed in a way which makes it suitable for use on real multi-user systems. You'll understand that we won't encourage practices which are extremely unsafe on such systems - users will get used to these pratices, and run into traps on real multi-user systems. The only thing a would agree is that someone can change the wrapper script to send the passphrase via email to outside... If someone can let you execute Trojan programs or scripts, you have a problem anyways. Maybe you have read my previous email regarding the mutt_octet-filter which can decrypt pgp encrypted octet-streams. The PGPPASS environment variable is the easiest way to remember the passphrase. Did you try to change the content-type of these octet-streams to application/pgp? With the more recent mutt versions, you can comfortably do this from within mutt. -- Thomas Roessler [EMAIL PROTECTED]
Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable
From a bash prompt, try running: COLUMNS= ps ae | grep mutt and see if you don't change your mind about using PGPPASS. -- Bob Bell [EMAIL PROTECTED] - "Just don't create a file called -rf. :-)" -- Larry Wall, creator of the Perl programming language
Re: feature request: delayed delete
On Wed, Jun 28, 2000 at 02:06:02PM +0200, Marius Gedminas wrote: :On Wed, Jun 28, 2000 at 02:14:28AM -0700, Eugene Lee wrote: : : Besides tagging messages by absolute datetimes, this could be extended : to your specific problem by allowing relative datetime patterns. So you : could do things like tag messages that are 14 days old or older. : :So what's wrong with ~d and ~r? Nothing at all. I just need to RTFM more often. My bad. :) -- Eugene Lee [EMAIL PROTECTED]
Re: feature request: delayed delete
On Wed, Jun 28, 2000 at 12:20:29AM -0500, Carlos Puchol wrote: : :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). Actually, I'd like to have add some kind of search pattern to the message-tagging functions. For example, if I knew that I have a bunch of messages from Januaary and February 2000, I'd like to be to be able to tag them, then do with them as I will. AFAIK, this isn't a feature in Mutt. I know I could tag by searching all the "Date:" fields, but those dates aren't quite standard (the same datetime could come in different formats or in different timezones). Besides tagging messages by absolute datetimes, this could be extended to your specific problem by allowing relative datetime patterns. So you could do things like tag messages that are 14 days old or older. What does everyone else think? -- Eugene Lee [EMAIL PROTECTED]
Re: feature request: delayed delete
* Eugene Lee [EMAIL PROTECTED] [000628 09:21]: On Wed, Jun 28, 2000 at 12:20:29AM -0500, Carlos Puchol wrote: :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. .. So you could do things like tag messages that are 14 days old or older. Yes, you "delete by pattern" and use "older than two weeks" as the pattern. You can even bind it to a macro and you can can have mutt execute it on startup. But it may break threads which are about two weeks old. Not a good idea. PS: Please quote with " " - thankyou! Sven
Re: feature request: delayed delete
On Wed, Jun 28, 2000 at 02:14:28AM -0700, Eugene Lee wrote: Actually, I'd like to have add some kind of search pattern to the message-tagging functions. For example, if I knew that I have a bunch of messages from Januaary and February 2000, I'd like to be to be able to tag them, then do with them as I will. AFAIK, this isn't a feature in Mutt. I know I could tag by searching all the "Date:" fields, but those dates aren't quite standard (the same datetime could come in different formats or in different timezones). Besides tagging messages by absolute datetimes, this could be extended to your specific problem by allowing relative datetime patterns. So you could do things like tag messages that are 14 days old or older. So what's wrong with ~d and ~r? Marius Gedminas -- When does summertime come to Minnesota, you ask? Well, last year, I think it was a Tuesday.
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: feature request: graft and prune functions
Hi again! ...and then David @ BigFoot said... % Thomas, et al -- % % ...and then Thomas Roessler said... % % On 2000-04-19 14:57:10 +0300, Mikko Hänninen wrote: % % % % If I remember the thread right, this request came about % % partially because you can't do the "graft" function % % when sending messages. Even if you use edit-headers and % % include a correct References header, Mutt will remove % % it before sending. % % % % Without checking this in the code, I seem to recall that % % adding an In-Reply-To header _plus_ a References header % % will make things work. I just checked this as I was trying to add a References: header to a message, and it disappeared when I closed the editor and then looked in again, even though I-R-T: was there and unchanged. I guess I just have to save - edit - append as I have been... :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: feature request: graft and prune functions
On Wed, Apr 19, 2000 at 09:03:44AM +0200, Thomas Roessler muttered: - On 2000-04-19 00:18:22 -0400, David T-G wrote: - - Thoughts? - - Real men use edit-message for this functionality. But - then again, real men also read their e-mail with dd(1). - - :-) _REAL_ programmers read their email in braille by passing their fingers over the magnetic domains on the hard drive platter. :-) -- -- C^2 No windows were crashed in the making of this email. Looking for fine software and/or web pages? http://w3.trib.com/~ccurley
Re: feature request: graft and prune functions
On 2000-04-19 00:18:22 -0400, David T-G wrote: Thoughts? Real men use edit-message for this functionality. But then again, real men also read their e-mail with dd(1). :-) -- http://www.guug.de/~roessler/
Re: feature request: graft and prune functions
Mikko -- ...and then Mikko Hänninen said... % Thomas Roessler [EMAIL PROTECTED] wrote on Wed, 19 Apr 2000: % Real men use edit-message for this functionality. But % then again, real men also read their e-mail with dd(1). % % If I remember the thread right, this request came about partially % because you can't do the "graft" function when sending messages. % Even if you use edit-headers and include a correct References header, % Mutt will remove it before sending. Exactly the problem I found. The only way I found to graft a message was to save it somewhere and edit it outside of mutt -- and grabbing the Refs is a pain anyway :-) % % (Or maybe I'm thinking of some other message...) Nope; you got it. % % % Mikko % -- % // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ % // The Corrs list maintainer // net.freak // DALnet IRC operator / % // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / % Living on Earth includes an annual free trip around the Sun. :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: feature request: graft and prune functions
Thomas -- ...and then Thomas Roessler said... % On 2000-04-19 00:18:22 -0400, David T-G wrote: % % Thoughts? % % Real men use edit-message for this functionality. But Well, I'd like to, but it doesn't seem to work. I haven't actually tried edit-message to prune, but I certainly have tried and failed to graft -- that is, create a References: header with the reference IDs that I want. % then again, real men also read their e-mail with dd(1). Oh, yeah; I could do that. Did I tell you that I wrote dd with cat(1) one day when I was bored? I had to write cat in morse code first ;-) % % :-) % % -- % http://www.guug.de/~roessler/ :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: feature request: graft and prune functions
On 2000-04-19 14:57:10 +0300, Mikko Hänninen wrote: If I remember the thread right, this request came about partially because you can't do the "graft" function when sending messages. Even if you use edit-headers and include a correct References header, Mutt will remove it before sending. Without checking this in the code, I seem to recall that adding an In-Reply-To header _plus_ a References header will make things work. -- http://www.guug.de/~roessler/
Re: feature request: graft and prune functions
On Wed, Apr 19, 2000 at 05:11:26PM +0200, Thomas Roessler wrote: On 2000-04-19 14:57:10 +0300, Mikko Hänninen wrote: If I remember the thread right, this request came about partially because you can't do the "graft" function when sending messages. Even if you use edit-headers and include a correct References header, Mutt will remove it before sending. Without checking this in the code, I seem to recall that adding an In-Reply-To header _plus_ a References header will make things work. Right, just grab your favrite editor and there you go. Michael -- You can be replaced by this computer. PGP-fingerprint: DECA E9D2 EBDD 0FE0 0A65 40FA 5967 ACA1 0B57 7C13
feature request: graft and prune functions
Hi again! ...and then David @ BigFoot said... % Hi, folks -- % % How can I manually update (or create) the References: header in mutt? I Well, I got absolutely no answers to this one. Clearly I should try again :-) I realized that what I wanted was a compose function that might be called "graft", where you graft a message onto a thread tree (maybe even specifying where by browsing the index, hmmm) and thus create the References: header. Partnered with graft, though probably called from the index instead (though graft might be useful in the index, too) is prune, which lets you disconnect errant subthreads caused by someone 'r'eplying to a message but for a completely different topic, like those people that use old emails as an address book. Thoughts? :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
[Feature Request] ordering of headers
Is there a way to make mutt display headers in the same order for each mail? It seem that mutt is just printing the headers in the order that is inside each email. Like sometimes I get: Date: blah From: foo To:me Subject: Uh huh. Message-ID: string and other times I get: Message-ID: string To: me Date: blah Subject: Uh huh. From: foo I already use the ignore and uninore thingie. I was just hoping to order the headers so that reading email becomes more uniform. --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball [EMAIL PROTECTED] Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD
Re: [Feature Request] ordering of headers
I'm an idiot. hdr_order Guess I need to get sgml-tools eh? --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball [EMAIL PROTECTED] Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD
Re: [Feature Request] ordering of headers
Timothy Ball [EMAIL PROTECTED] wrote on Tue, 07 Dec 1999: Is there a way to make mutt display headers in the same order for each mail? Yes, the hdr_order command. I personally use this in my .muttrc: # Header order hdr_order Date: From: To: Cc: Subject: Resent- Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Have you rebooted your Windows today? Linux! No more reboots.
Re: [Feature Request] ordering of headers
On 07-Dec-1999, Timothy Ball wrote: I already use the ignore and uninore thingie. I was just hoping to order the headers so that reading email becomes more uniform. I've been using hdr_order ever since I used mutt back in 0.9x. I guess you need to dig deeper into the manual. -- Ronny Haryanto
Re: [Feature Request] ordering of headers
From the manual page: hdr_order header1 header2 [ ... ] With this command, you can specify an order in which mutt will attempt to present headers to you when viewing messages. Note that this command is implemented for half an eternity. On 1999-12-07 10:00:19 -0600, Timothy Ball wrote: Date: Tue, 7 Dec 1999 10:00:19 -0600 From: Timothy Ball [EMAIL PROTECTED] To: Mutt Users Mailing List [EMAIL PROTECTED] Subject: [Feature Request] ordering of headers Mail-Followup-To: Mutt Users Mailing List [EMAIL PROTECTED] User-Agent: Mutt/1.1.1i Is there a way to make mutt display headers in the same order for each mail? It seem that mutt is just printing the headers in the order that is inside each email. Like sometimes I get: Date: blah From: foo To: me Subject: Uh huh. Message-ID: string and other times I get: Message-ID: string To: me Date: blah Subject: Uh huh. From: foo I already use the ignore and uninore thingie. I was just hoping to order the headers so that reading email becomes more uniform. --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball [EMAIL PROTECTED] Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD -- http://www.guug.de/~roessler/
Re: [Feature Request] ordering of headers
Hi Timothy! You need to set hdr_order ie: hdr_order From: Subject: To: Cc: Bcc: Sean On Tue, 07 Dec 1999, Timothy Ball wrote: Is there a way to make mutt display headers in the same order for each mail? It seem that mutt is just printing the headers in the order that is inside each email. Like sometimes I get: Date: blah From: foo To: me Subject: Uh huh. Message-ID: string and other times I get: Message-ID: string To: me Date: blah Subject: Uh huh. From: foo I already use the ignore and uninore thingie. I was just hoping to order the headers so that reading email becomes more uniform. --timball -- Send mail with subject "send pgp key" for public key. pub 1024R/CFF85605 1999-06-10 Timothy L. Ball [EMAIL PROTECTED] Key fingerprint = 8A 8E 64 D6 21 C0 90 29 9F D6 1E DC F8 18 CB CD Sean -- GPG ID (DSA) 92B9D0CF PGP2 ID 19592A0D Linux User: #124682 ICQ: 679813 To get my PGP Keys send me an empty email with retrieve as the subject It said "Needs Windows 95 or better". So I installed Linux... PGP signature
Re: A feature request
Yes. www.pgpi.com has a pgp (6.5.x) plugin for outlook express 4/5, pegasus mail, outlook, and eudora -matt - Original Message - From: Mark Weinem [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 04, 1999 11:01 AM Subject: Re: A feature request On Thu, Sep 02, 1999 at 09:39:25AM -0700, Brian D. Winters wrote: [...] but who's going to be sending you PGP/MIME from inside of Outlook Express? ;) Is it possible to configure OE to support PGP/MIME? Regards Mark Weinem
A feature request
Hello, mutt is wonderful. However there is nothing perfect in this world (for me, that is), so I'd like to talk a bit about ignore_list_reply_to variable. We have a couple of local (in geographical sense) mailing lists in which mails come with a huge variance in To: fields, e.g. To: [EMAIL PROTECTED] To: "Programming mailing list" [EMAIL PROTECTED]" To: My Good Friend [EMAIL PROTECTED], [EMAIL PROTECTED] and even To: "Someones Real Name" [EMAIL PROTECTED] (there are three aliases instead of one fixed domain name, so [EMAIL PROTECTED] above is always the same mailing list). It is now being voted if Reply-To should contain just the mailing list address (one of the three), or both mailing list and original sender address. Unfortunately, this renders mutt's `ignore_list_reply_to' completely useless. But wouldn't it be better if mutt just parsed the Reply-To field in this way: if any of the addresses there belongs to a mailing list AND it is also mentioned in the To field, then it is simply ignored as if it wasn't there at all. Also, does anybody know what `Content-Type: text/plain, charset="utf-7"' mean? I do know UTF-8, but I can only guess what UTF-7 is. AFAIK both Netscape and Internet Explorer support it. I recently received a couple of mails in this encoding (mailer: MS Outlook Express 5.00) and the only thing that looked strange was quoting string: `+AD4- '. Unfortunately, mutt does not support it. Still, mutt is wonderful. Any chances of porting it to Win32 so I could comfortably read my mail at work too? :) Best Regards, Marius Gedminas -- Cheap, Fast, Good--pick two.
Re: A feature request
Also, does anybody know what `Content-Type: text/plain, charset="utf-7"' mean? I do know UTF-8, but I can only guess what UTF-7 is. AFAIK both Netscape and Internet Explorer support it. I recently received a couple of mails in this encoding (mailer: MS Outlook Express 5.00) and the only thing that looked strange was quoting string: `+AD4- '. Unfortunately, mutt does not support it. Based on responses (or lack thereof) the last two times I brought up the subject, I am the only other person on mutt-users who has ever seen UTF-7. ;) UTF-7 is a 7-bit clean version of unicode. It is described in rfc1642. UTF-8 is the more standard way of handling unicode. AFAIK, outlook express is the only program which sends UTF-7, and even then it seems that only some installs of outlook express do it. My solution was to find a program called u7tou8 which does conversion from UTF-7 to UTF-8, which is understood by mutt. Then I added the following to my .procmailrc: :0 f * ^Content-Type:.*charset="utf-7" | u7tou8 | formail -i "Content-Type: text/plain; charset=\"utf-8\"" This would of course break things like PGP/MIME signatures, but who's going to be sending you PGP/MIME from inside of Outlook Express? ;) I'm having a bit of trouble finding where you can get this conversion program. Last time I think I found it by searching through the Linux Chinese-HOWTO. Ah, here it is (the HOWTO comes through again): ftp://ftp.ifcss.org/pub/software/unix/convert/utf7.tar.gz Good luck. Brian
Re: Feature request (or yet another brainfart by M$?)
Ralf Hildebrandt [EMAIL PROTECTED] wrote: Have you ever wished you could take back something you said? Well here's some good news: Outlook allows you to recall an email message that you sent to another Outlook user! This is a feature of the underlying Exchange protocol. SMTP has no such feature. But wouldn't that be another nice feature for mutt? Maybe, but once a message enters an SMTP stream, it tends to get delivered permanently. :) -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: Feature request (or yet another brainfart by M$?)
On Wed, Aug 11, 1999, Ralf Hildebrandt wrote: Have you ever wished you could take back something you said? Well here's some good news: Outlook allows you to recall an email message that you sent to another Outlook user! This feature works only if the message you're trying to recall hasn't yet been opened by the receiver. You can choose to simply delete unread copies of the message, or you can replace unread copies of the message with a brand new message. You can also request to be notified whether the message recall was successful. Once you've selected the options you want, click OK, and Outlook attempts to recall the message you selected. Hmm, I wonder how one can abuse this? But wouldn't that be another nice feature for mutt? I believe this is only for within an intranet type network. I don't think it works for the Internet. -Ken -- [EMAIL PROTECTED]AIM: ScopusFest
Re: Feature request (or yet another brainfart by M$?)
On Wed, Aug 11, 1999 at 06:54:25PM +0100, Lars Hecking wrote: Hmm, I wonder how one can abuse this? But wouldn't that be another nice feature for mutt? Ralf, you should lock your screen while away from the computer. I can't believe you actually typed this :) Ok, the eclipse burned my brain, but this is actually the stupidest idea M$ EVER had, and so I thought I'd share my thoughts... -- Ralf Hildebrandt [EMAIL PROTECTED] www.stahl.bau.tu-bs.de/~hildeb If at first you don't succeed, destroy all evidence that you tried. PGP signature
Re: Feature request (or yet another brainfart by M$?)
On Wed, Aug 11, 1999 at 12:56:14PM -0500, David DeSimone wrote: This is a feature of the underlying Exchange protocol. SMTP has no such feature. Hmm, but couldn't mutt support this feature? -- Ralf Hildebrandt [EMAIL PROTECTED] www.stahl.bau.tu-bs.de/~hildeb The secret of flying is simple: Throw yourself at the ground and miss. PGP signature
Re: Feature request (or yet another brainfart by M$?)
On Wed, Aug 11, 1999 at 08:26:40PM +0200, Ralf Hildebrandt wrote: On Wed, Aug 11, 1999 at 12:56:14PM -0500, David DeSimone wrote: This is a feature of the underlying Exchange protocol. SMTP has no such feature. Hmm, but couldn't mutt support this feature? And now, for your amusement, i can inform you that it already does :-) How? Easy, simply send a new mail like this: | From: [EMAIL PROTECTED] | Subject: FOLDER INTERNAL DATA, IGNORE | Supersedes: [EMAIL PROTECTED] | Expires: Wed, 10 Aug 1999 14:00:43 +0100 (CEST) | | This is an folder internal cancel message, please ignore me :-) And have the recipient have the following line in his .muttrc: push D~S|~E\n (not tested :-) CU, Sec -- The UNIX Guru's View of Sex: # unzip ; strip ; touch ; finger ; mount ; fsck ; more ; yes ; umount ; sleep
