Re: Feature request

[Erik Christiansen]

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

[Walter Alejandro Iglesias]

+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

[Rocco Rutte]

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

Re: [FEATURE REQUEST] ~/.muttrc, ~/.mutt/muttrc and other

[Rado S]

=- 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.

[FEATURE REQUEST] ~/.muttrc, ~/.mutt/muttrc and other directories

[Michelle Konzack]

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

Re: feature request - save_domain

[darren chamberlain]

* 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

feature request - save_domain

[Eric Smith]

.. 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: cross-mbox threading

[Benjamin Pflugmann]

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

[Rocco Rutte]

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

[Benjamin Pflugmann]

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: cross-mbox threading

[Rocco Rutte]

Hi,

* Charles Jie [02-07-02 21:32:56 +0200] wrote:

> 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 ';'.

Well, what would the result be? All contents of the involved
mailboxes are taken and threaded together in a single tree.
Right? I don't really see the difference when using one
instead of many folders.

> 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.

Hmm, same for the 'limit' function (if you use one folder).

> 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.

Sounds kind of interesting. But as usual, more code will
slow operation down. But if such a feature existed, one
would have to turn it off for folders with a few thousand
messages.

>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.

Additionally to the existing information, you would have to
keep in mind where a file is originally stored. If such a
feature existed you could safely allow modifying messages
because you know where they're really stored.

Well, all you described can be done in mutt (of course ;-)
but it is not exactly the same. You could, for example, only
use one folder and make heavy use of the 'limit' function.
Or you could use a wrapper script instead of calling
sendmail directly to store the mail into various folders. I
also think I've read something about a patch allowing one to
use a command for fcc (rather than a filename).

If I had to do what you want, I would:

  * create a backup where all incomming and all outgoing
mail is saved to
  * save all outgoing messages to the same folder from where
they were sent

(this works unless you edit a message in a non-backup folder
but I never do this)

Cheers, Rocco

Feature request: cross-mbox threading

[Charles Jie]

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

Re: [Feature request] mailbox aliases and internal filtering

[Vincent Lefevre]

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:  - 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

[Vineet Kumar]

* 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

[Vincent Lefevre]

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 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:  - 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

[Dave Pearson]

* 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 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

[Feature request] mailbox aliases and internal filtering

[Vincent Lefevre]

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:  - 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

[Sven Guckes]

* 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

[darren chamberlain]

* 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
 after the search.  Here is an example, similar to the above:

  message-hook "~s 'pgp|gpg'" 'push "pgp|gpg"'

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

Re: Feature request: uncolor not only in index

[Gary Johnson]

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]

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

[darren chamberlain]

* 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

[John Buttery]

* 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

[David T-G]

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: uncolor not only in index

[Michael Tatge]

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

[Gary Johnson]

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  "color body [0-9]"
> > % 
> > 
> > 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]

Michael --

...and then Michael Tatge said...
% 
% David T-G ([EMAIL PROTECTED]) muttered:
% > ...and then Michael Tatge said...
% > % macro pager  "color body [0-9]"
% > % 
% > 
% > 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

[Michael Tatge]

David T-G ([EMAIL PROTECTED]) muttered:
> ...and then Michael Tatge said...
> % macro pager  "color body [0-9]"
> % 
> 
> 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

[David T-G]

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  "color body [0-9]"
% 
% 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

Feature request: uncolor not only in index

[Michael Tatge]

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  "color body [0-9]"

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

[Patrick]

* 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 !
> 
> That breaks "? for list" functionality.  It would be better to assign
> it to another key:
> 
> macro index I "!\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
  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

Re: Feature Request

[Shawn McMahon]

begin  quoting what Sven Guckes said on Thu, Apr 04, 2002 at 01:39:43AM +0200:
> 
> feature request denied.
> 
>   macro index c !

That breaks "? for list" functionality.  It would be better to assign
it to another key:

macro index I "!\r"

Then get used to using "I" when you want it.




msg2/pgp0.pgp
Description: PGP signature

Re: Feature Request - change the change-folder default folder

[Patrick]

* 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

Re: Feature Request - change the change-folder default folder

[Sven Guckes]

* pat <[EMAIL PROTECTED]> [2002-04-03 19:48]:
> Feature request.  It would be nice and timesaving (for me, at
> least) if  would default to ! when where was not a
> folder containing New Mail.  Perhaps a set feature in muttrc ??
> set change-folder 

* Sven Guckes wrote:
> feature request denied.
>   macro index c !
> we won't waste extra code for this. ;-)

* Will Yardley <[EMAIL PROTECTED]> [04-03-02 18:48]:
> 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...

* MuttER aka Pat Shanahan <[EMAIL PROTECTED]> [2002-04-03 23:55]:
> Thanks Will.  You are correct.  I do not want to
> change basic operation, just increase convience,
> which the macro will not accomplish.

ok, got it now.  yes, this would ask for a patch.

by the way - whenever there's new mail in $MAIL
then suddenly cycling does through the list
of "mailboxes" does not work anymore... :-/
what's the logic behind this, anyway?

PS: But, dammit, Pat, put your name into the
 From: line so an attribution makes sense!

Sven

Re: Feature Request

[MuttER]

* Will Yardley <[EMAIL PROTECTED]> [04-03-02 18:48]:
> Sven Guckes wrote:
> > * pat <[EMAIL PROTECTED]> [2002-04-03 19:48]:
> 
> > > Feature request.  It would be nice and timesaving (for me, at
> > > least) if  would default to ! when where was not a
> > > folder containing New Mail.  Perhaps a set feature in muttrc ??
> > > set change-folder 
> > 
> > feature request denied.
> > 
> >   macro index c !
> > 
> > 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...

Thanks Will.  You are correct.  I do not want to change basic
operation, just increase convience, which the macro will not
accomplish.
-- 
Pat Shanahan   Registered Linux User #207535
Registered at: http://counter.li.org

Re: Feature Request

[Will Yardley]

Sven Guckes wrote:
> * pat <[EMAIL PROTECTED]> [2002-04-03 19:48]:

> > Feature request.  It would be nice and timesaving (for me, at least)
> > if  would default to ! when where was not a folder
> > containing New Mail.  Perhaps a set feature in muttrc ??
> > set change-folder 
> 
> feature request denied.
> 
>   macro index c !
> 
> 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

[Sven Guckes]

* pat <[EMAIL PROTECTED]> [2002-04-03 19:48]:
> Feature request.  It would be nice and timesaving (for me, at least)
> if  would default to ! when where was not a folder
> containing New Mail.  Perhaps a set feature in muttrc ??
> set change-folder 

feature request denied.

  macro index c !

we won't waste extra code for this. ;-)

Sven

Feature Request

[pat]

Feature request.  It would be nice and timesaving (for me, at least) if
 would default to ! when where was not a folder
containing New Mail.  Perhaps a set feature in muttrc ??

set change-folder 

Just a thought.
-- 
Pat Shanahan   Registered Linux User #207535
Registered at: http://counter.li.org

Feature request: auto_view accepts its own handler

[John Buttery]

  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 5.3 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=%s.html
text/html;  lynx -dump %s; nametemplate=%s.html; 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)

[David T-G]

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 V. Konstantinou]

> % 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

Re: command line folder alias access (feature request)

[David T-G]

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

command line folder alias access (feature request)

[Alexander V. Konstantinou]

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

[Erwin Kaiser]

Thanks!
Erwin

Re: feature request

[Biju Chacko]

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

[Lars Hecking]

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 ;)

feature request

[Erwin Kaiser]

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 - don't encrypt when sending to mailing list

[David]

David wrote:
> send-hook ~l 'push f^Ups'

Okay well that should have been just:

send-hook ~l 'push ps'

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

[Jeremy Blosser]

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

Re: Feature Request - don't encrypt when sending to mailing list

[Christian Biesinger]

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

[David]

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^Ups'

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

[Aaron Schrab]

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

Feature Request - don't encrypt when sending to mailing list

[Christian Biesinger]

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

[David T-G]

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

[Gary Johnson]

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 r remind_script
macro pager r remind_script

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

[Conor Daly]

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

[Heinrich Langos]

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: ")
  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

[David T-G]

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

Re: feature-request: delayed resubmission, follow-up

[Thomas Roessler]

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: delayed resubmission, follow-up

[Sankaranarayanan K V]

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

[Sankaranarayanan K V]

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

[Heinrich Langos]

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

[Thorsten Haude]

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

[Heinrich Langos]

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

[Suresh Ramasubramanian]

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

[Thomas Roessler]

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]>

feature-request: delayed resubmission, follow-up

[Heinrich Langos]

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: mutt looks for PGPPASS environment variable

[Daniel Kollar]

> > > 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).

Can this be put in an automatic function?

Something like this way:
- check for ".pgp"
- if yes, then change type to "application/pgp"

I was thinking, if this function could be implemented into my
.promailrc. But I don't know how.


Daniel.

Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable

[Petr Hlustik]

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

Re: FEATURE-REQUEST: mutt looks for PGPPASS environment variable

[Mikko Hänninen]

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

[Daniel Kollar]

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

[Bob Bell]

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: mutt looks for PGPPASS environment variable

[Thomas Roessler]

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

[Dan Boger]

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

[Daniel Kollar]

> 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

[Thomas Roessler]

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]>

FEATURE-REQUEST: mutt looks for PGPPASS environment variable

[Daniel Kollar]

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: delayed delete

[Eugene Lee]

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

[Marius Gedminas]

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.

Re: feature request: delayed delete

[Sven Guckes]

* 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

[Eugene Lee]

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]

feature request: delayed delete

[Carlos Puchol]

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

[David T-G]

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

[Charles Curley]

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

[David T-G]

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.

Ahhh...  Hokay, then; you have to have the former in order to have the
latter (though maybe not the other way around, but what do I care).
I still say that it would be convenient to be able to point to a message
and pick up its references :-) but I can live with grabbing them from
other headers and creating the new headers myself.  I guess I just make
IRT: be the ID of the message under which I want the modified message
attached, eh?


Off to play; thanks a bunch! :-)


% 
% -- 
% 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

[Michael Tatge]

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

Re: feature request: graft and prune functions

[Thomas Roessler]

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

[David T-G]

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

[David T-G]

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

[Mikko Hänninen]

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.

(Or maybe I'm thinking of some other message...)


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.

Re: feature request: graft and prune functions

[Thomas Roessler]

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/

feature request: graft and prune functions

[David T-G]

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

Re: [Feature Request] ordering of headers

[Thomas Roessler]

On 1999-12-07 10:07:36 -0600, Timothy Ball wrote:

> I'm an idiot. 
>   hdr_order
> Guess I need to get sgml-tools eh?

The muttrc (5) should do for most configuration commands.

-- 
http://www.guug.de/~roessler/

Re: [Feature Request] ordering of headers

[Sean Rima]

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: 
>  From: 
>  To:  
>  Subject: Uh huh.
>  Message-ID: 
> 
> and other times I get:
>  Message-ID: 
>  To: 
>  Date: 
>  Subject: Uh huh.
>  From: 
> 
> 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: [Feature Request] ordering of headers

[Thomas Roessler]

>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: 
>  From: 
>  To:  
>  Subject: Uh huh.
>  Message-ID: 
> 
> and other times I get:
>  Message-ID: 
>  To: 
>  Date: 
>  Subject: Uh huh.
>  From: 
> 
> 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

[Ronny Haryanto]

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

[Mikko Hänninen]

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

[Timothy Ball]

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

[Feature Request] ordering of headers

[Timothy Ball]

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: 
 From: 
 To:
 Subject: Uh huh.
 Message-ID: 

and other times I get:
 Message-ID: 
 To: 
 Date: 
 Subject: Uh huh.
 From: 

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: A feature request

[Matthew Cordes]

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
>
>