Save external imap emails to a local maildir folder
Dear List, I use Mutt with two external imap accounts. At the moment the only thing I miss by using Mutt is to filter and move emails to local folders. To be honest, I red a lot of howtos but do not understand, how to deal with folders. First of all I like to save emails from external imap accounts to a local maildir folder. But I do not want to use additional software like mbsync or offlineimap. If I press 's'in an imap account to save the email local, what is setup in the config, please? Thank you! Kind regards Piet
Re: Save external imap emails to a local maildir folder
Hello Jean, thank you for your kind answer. I source the email account by macro index,pager 'source ~/.config/mutt/conf/imap1!' and I'm in my imap account. If press key "s" here followed by "?" I have only the choice to save in the for the external imap folders and can't switch to the local maildir. I guess, I have to add something in the imap1 file? Kind regards Piet Am Sat, Feb 19, 2022 at 09:16:04AM +0300 schrieb Jean Louis: > * Piet [2022-02-19 00:17]: > > Dear List, > > > > I use Mutt with two external imap accounts. > > At the moment the only thing I miss by using Mutt is to filter and move > > emails to local folders. > > To be honest, I red a lot of howtos but do not understand, how to > > deal with folders. > > That is exactly what I do all the time, I read IMAP and save to > Maildir. > > I think these are main settings on my side to save it as Maildir: > > set folder=/home/data1/protected/Maildir > set mbox_type=Maildir > > # Save by email address > set save_name=yes > set save_address=yes > > The above makes sure that I save emails by the correspondent's email > addres, if correspondent is per...@example.com then it gets saved in > ~/Maildir/per...@example.com > > and then all conversations sent to per...@example.com and received > from per...@example.com may be easily found in > ~/Maildir/per...@example.com > > I have set one key to open all previous conversations related to the > per...@example.com easily > > > First of all I like to save emails from external imap accounts to a > > local maildir folder. But I do not want to use additional software > > like mbsync or offlineimap. > > One by one or tagged emails, all that can be saved as explained above. > > > -- > Jean > > Take action in Free Software Foundation campaigns: > https://www.fsf.org/campaigns > > In support of Richard M. Stallman > https://stallmansupport.org/
Receive email, filtering
Dear List, before I use email with several devices, I used fetchmail and procmail to receive and filter email. I switched from pop3 to (external) imap and have some question how to deal with mutt and mailfiltering. It seems, that fetchmail receives emails from imap, but only in two ways which can not be combined: 1. 'Fetchall' and delete the messages (option fetchall). Problem: Messages are not avaible for other devices anymore on external imap. Or 2. Fetch only the unread messages (option 'keep') and keep the messages. Problem: Messages which are aleady red will not be fetched. Both ways do not fit to my needs. I'm not 100% sure if I understand how fetchmail is working. Further I try mbsync, but it seems not to work with procmail. Getmail seems to work similar to fetchmail. I don't like to use 'sieve', because not all imap provider offer this. Is there the opportunity to fetch and filter email without deleting it in the external imap account? Thank you for your tipps! Kind regards Piet
Re: Receive email, filtering
Dear Charles, thank you for the hint. I'll try harder to get it work now, because I'm sure if will be possible. But regarding fetchmail, the logs said that both options can't be used together (On a Debian testing system): With fetchmailrc: options keep fetchall ssl mda "/usr/bin/procmail -d %T" Starting with: $fetchmail Message: Both fetchall and keep on in daemon or idle mode is a mistake! I would be prefere to use fetchmail, because I use it for a long time. Kind regards Piet Am Mon, Feb 21, 2022 at 09:00:47AM -0600 schrieb Charles Cazabon: > Piet wrote: > > > > It seems, that fetchmail receives emails from imap, but only in two > > ways which can not be combined: > [...] > > Getmail seems to work similar to fetchmail. > > > Is there the opportunity to fetch and filter email without deleting it in > > the external imap account? > > As the author of getmail, I can assure you that getmail is capable of > retrieving mail and not deleting it from the server afterwards; it's explained > in the docs. > > As much as I detest fetchmail, it virtually certainly can also do this. > > Charles > -- > --- > Charles Cazabon > GPL'ed software available at: http://pyropus.ca/software/ > ---
Saving email, forward to compose
Dear List, I use multiple imap acounts and shift with macros between them: macro index,pager 'source ~/.config/mutt/conf/imap1!' macro index,pager 'source ~/.config/mutt/conf/imap2!' If I save an email to another folder by pressing 's', Mutt asks me if the email should be attached to the target folder. After press y, the related email is marked with a "D". If I switch to the other accout with , the saved messages is openend in the vim editor. I have to close vim by pressing :q! and I'm in the email send dialog (as I would press "m"). The header "to" is containing the text of the macro, something like "ig/mutt/conf/imap2@host. But if I sync manually with key "$" before shifting to the other account, Mutt asks me to delete the message in the actual folder. After press "y" I'm not forwarded to the compose menu. I use a selfcompiled Mutt from git master. What could be wrong? Kind regrds Piet
Re: Saving email, forward to compose
Dear Kevin, thank you, works! Kind regards Piet Am Tue, Feb 22, 2022 at 09:36:20AM -0800 schrieb Kevin J. McCarthy: > On Tue, Feb 22, 2022 at 09:32:50AM -0800, Kevin J. McCarthy wrote: > > On Tue, Feb 22, 2022 at 08:02:03AM +0000, Piet wrote: > > > macro index,pager 'source > > > ~/.config/mutt/conf/imap1!' > > > macro index,pager 'source > > > ~/.config/mutt/conf/imap2!' > > > > > But if I sync manually with key "$" before shifting to the other > > > account, Mutt asks me to delete the message in the actual folder. > > > > The $delete quadoption prompt is happening after . The > > prompt tries to read from input: in this case the contents of your > > macro. Try unsetting $delete, either in your muttrc or at the start of > > the macro. > > Sorry, I meant setting $delete to "yes". > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
Re: Receive email, filtering
Dear Charles and someone else, thank you, works perfectly! Really a big help,because I never got it work before. Kind regards Piet Am Mon, Feb 21, 2022 at 08:53:32PM -0600 schrieb Charles Cazabon: > Piet wrote: > > > > Dear Charles, > > > > thank you for the hint. > > You're most welcome. > > > I'll try harder to get it work now, because I'm sure if will be possible. > > Someone else said I should have given the answer here, even though it is > off-topic. > > For getmail, in the [options] section of your rc file, use: > > read_all = false > delete = false > > It will retrieve all messages the first time they're seen, and will not delete > them from the server. > > Charles > -- > --- > Charles Cazabon > GPL'ed software available at: http://pyropus.ca/software/ > ---
Filtering local Maildir
Dear Mutt users, my emails are synced local to a maildir folder and I read and send emails via Mutt. If I like to 'filter' the email, I tagged them and save into to a special folder. Is there a way to define and use filters, similar to procmail etc? (I guess procmail is only to use when emails are fetched externally, but I like to filter the local emails.) Can I define a lot of filters With Mutt to automate this? Maybe there's an external program or script what can do this job? Thank you very much! Kind regards Piet
Re: Filtering local Maildir
Hello Francsco, yes, I think, mblaze could be my friend! I'll test it! Am 04/08/ schrieb Francesco Ariis: > Hello Piet, > > Il 08 aprile 2022 alle 11:39 Piet ha scritto: > > Is there a way to define and use filters, similar to procmail etc? > > (I guess procmail is only to use when emails are fetched externally, but > > I like to filter the local emails.) > > Depending on how taxing the filtering is you might like > > mblaze - UNIX utilities to deal with Maildir > > Frankly it the tasks are not complex and the maildir is not huge, I would > just set up a `folder-hook` and live with it. E.g. I have this to empty > my trash folder. > > folder-hook trash 'push ~r>1y' > > Would your use-case benefit from one of those two approaches? > —F -- Kind regards Piet
Colours aspell creating messages
Dear Mutt users, I use Mutt with aspell to check my texts. Unfortunately the aspell dedections from potential errors are highlighted so strong, that the spelled text itself is not visible. Could you please tell me, where I can change the related colours? Thank you! -- Kind regards Piet GPG Fingerprint: 1D9D DAD5 BD91 A5E8 C5DB B400 D286 3A10 4969 7909 signature.asc Description: PGP signature
Re: Colours aspell creating messages
Dear Francesco, thank you very much for your answer. The 'magic key' is my editor vim. If I change the vim colorscheme to a fitting other one (in my case 'desert') everything is fine! Kind regards Piet Am 04/20/ schrieb Francesco Ariis: > Hello Piet, > > Il 20 aprile 2022 alle 12:54 Piet ha scritto: > > I use Mutt with aspell to check my texts. > > > > Unfortunately the aspell dedections from potential errors > > are highlighted so strong, that the spelled text itself is not visible. > > Mhhh I use aspell but I see no colours. Relevant ~/.muttrc lines > > set my_it_ispell="aspell -e -d it -c" > macro compose ii 'set ispell=$my_it_ispell' > > How do you invoke it? Maybe you are using it /inside/ your editor of > choice? > —F -- Kind regards Piet GPG Fingerprint: 1D9D DAD5 BD91 A5E8 C5DB B400 D286 3A10 4969 7909 signature.asc Description: PGP signature
Re: Archivation through mutt?
--M9NhX3UHpAaciwkO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, 05 Sep 2001 at 14:39:40 -0400, Matej Cepl wrote:
[...mail archival script...]
>=20
> However, I am really not a programmer and I am still slightly scare of
> Bash. Could you comment, please, on the attached script and tell me
> whether I am to shoot off my foot with this script?
Some quick comments:
- The ${foo} syntax expands to the contents of variable "foo", not to
the output of command "foo". For command substitution, either use
$(foo), or `foo` (note the backticks). The $(foo) form nests easier
than the `foo` form, but the latter is more common between shells.
- In your -e strings for mutt, you must remember to insert the enter
keypress after commands like "", as mutt doesn't do it
for you. "" won't do though, you either need a "\n" or a
literal carriage return (which can be gotten in vi by pressing ^V followed
by ^M, for example).
- You also need to surround push's arguments with quotes of some kind,
otherwise it complains about having too many arguments.
- Unless this is really what you intended, you probably want to add a
"" to the end of each -e string, otherwise mutt will wait
interactively for you to quit each time.
- ... and, a minor quibble, it's a good idea to use "" in
place of ";", in case you ever decide to remap ";".
- For find, you should escape the parentheses to prevent the shell from
interpreting them. Also, it's safer to quote the
-name sent-*
bit as
-name 'sent-*'
just in case your current directory happens to contain a file starting
with "sent-".
Portability issues:
- Declare functions without the leading "function", as the latter is a
bash thing.
- For find, instead of -not, use "!". And, like the parens, it's best
to escape this too.
Then, about the find statement in the script...
Currently, you have:
> find $MAILDIR/ \
> -not ( -name sent-* -o -name trash -o -name draft ) \
> -printf "%P\n" | xargs process
where "process" is a shell function that takes care of archiving all old
mail in the folder named by its first argument ($1).
The find statement will fail to work for two reasons:
1. "xargs foo" takes its input and gives *all of them at once* as
arguments for foo. So "process" would only ever affect the first
folder found, the rest would be ignored.
2. xargs will never even find "process" in the first place, as it's a
shell function. It can only see and call `real' programs.
To get around this, you can do something like the following (sorry for
the long line):
find $MAILDIR/ \
\! \( -name 'sent-*' -o -name trash -o -name draft \) \
-exec mutt -f {} \
-e 'push "~d -'`date --date=3D$ARCHDATE '+%d/%m/%Y'`"=0D=
{}=0D\"" \;
=20
Don't panic. :-) Basically, this does the find, and just directly
executes mutt on each of the matching folders.
I've attached my version of your script with all of the above worked in.
Warning: it's still totally untested. Comments welcome.
[ One minor problem so far is that the FreeBSD date(1) doesn't
understand the --date option, but has a -v option rather, with:
-v -3m
meaning 3 months ago, and
-v +7d
meaning 7 days from now, etc. Does GNU date(1) support the -v option? ]
--=20
Piet Delport <[EMAIL PROTECTED]>
Today's subliminal thought is:
--M9NhX3UHpAaciwkO
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE7mBMYzRUP82sZFCcRAktzAKClfCT7VwcBMjqTY8jprNK3xKoRgQCeOVIx
oBNzxtYl8c0Go51IZExr6rQ=
=5pLQ
-END PGP SIGNATURE-
--M9NhX3UHpAaciwkO--
Re: Archivation through mutt?
--H1spWtNR+x+ondvy
Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6"
Content-Disposition: inline
--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, 06 Sep 2001 at 23:43:41 -0400, Matej Cepl wrote:
> On 7 Sep 2001, at 2:21, Piet Delport wrote:
> > - The ${foo} syntax expands to the contents of variable "foo", not
> > to the output of command "foo". For command substitution, either
> > use $(foo), or `foo` (note the backticks). The $(foo) form nests
> > easier than the `foo` form, but the latter is more common between
> > shells.
>=20
> Thanks, I will use $().
It's mostly a matter of personal taste, i know, but i still think `` is
better, as (AFAIK) it predates $(), and should be supported by more
shells. Not that i can name any examples though. :-)
[snip]
> > I've attached my version of your script with all of the above worked
> > in. Warning: it's still totally untested. Comments welcome.
>=20
> Actually, you haven't.
Gah, my apologies. This is the result of sending long mails in the wee
hours of the morning without proof-reading them.
> However, I have reconstructed the most of your advice and the result
> is attached. The find command you proposed wouldn't work, because the
> purpose of the command is to move messages from the folder in $MAILDIR
> to the one in $ARCHDIR, which cannot be accomplished via mere {}.
Indeed. I was actually planning to tackle this problem with something
like basename, but completely forgot about it before pressing `send'.
> See my proposed solution, which is not optimal either, because it
> doesn't work with mailboxes in the subdirectories of $MAILDIR. Any
> thoughts?
Looks promising, aside from a minor quoting problem (the argument for
mutt -e should be in double-quotes, as 1. single-quoted strings can't
contain single-quotes, not even escaped ones, and 2. no variable or
command substitution takes place at all in single-quoted strings,
meaning the final argument to mutt would be to save the messages in a
folder literally called "$ARCHDIR/$(basename {})" (except that {} would
still replaced by find...)).
There's a biggish problem with this approach that i've overlooked until
now though:
The -exec argument of find passes everything directly to the program
that is its argument, with no shell or expansion performed whatsoever,
aside from replacing a literal '{}' anywhere with the found file's name.
So even after fixing the quotes, the "basename {}" bit will be
interpreted too early, and *find* will be passed the basename of "{}",
which stays "{}". So there's no net effect, mutt will still be
instructed to save the messages to {}.
I thought about this, and came up with a different approach, that (i
think :-) solves the above problem, along with correctly handling files
in sub-directories:
find $MAILDIR/ \
\! -name 'sent-*' \
\! -name trash \
\! -name draft \
-exec /bin/sh -c \
"mutt -f '{}' -e \
\"push '~d -\`date --date=3D$ARCHDATE +%d/%m/%Y\`=0D\
\`echo '{}' | sed -e \"s:^$MAILDIR:$ARCHDIR:\"\`=
=0D\
'\"" \;
(This is beginning to approach some the scariest shell scripting i've
written...)
Explanations (as much for my benefit as anyone else's):
- I'm listing each of the excluded folder names separately as "\! -name
foo"; this is to make it slightly easier to add/remove folder names.
- I'm -execing /bin/sh -c, instead of mutt directly, because a sub-shell
is needed to interpret shell constructs *after* find has replaced {}
with the mail folder name.
- The crucial bit here is:
`echo '{}' | sed -e "s:^$MAILDIR:$ARCHDIR:"`
This will eventually get parsed to (say):
`echo '/my_mail_dir/subdir/myfolder' | sed -e "s:^/my_mail_dir:/my_arch_di=
r:"`
which should result in "/my_arch_dir/subdir/myfolder" being passed to
mutt as the folder to save the expired messages into.
> And I still do not know how to achieve the last command (archiving of
> the sent-* mailboxes).
This isn't going to be too easy, i think. I'm playing around with some
ideas here though, will let you know what turns up.
[snip (Free)BSD date(1) using -v for relative dates, as opposed to GNU
date(1)'s -d and --date...]
This presents a portability problem... either non-GNU systems will have
to install GNU date or the script should have an option to switch
between the two syntaxes, neither of which is particularly fun. Maybe
an equivalent perl one-liner can be used instead of date(1), to sidestep
the problem?
--=20
Piet Delport <[EMAIL PROTECTE
Re: Using PGP signature with mutt ..problem
On Sun, 09 Sep 2001 at 00:25:11 +0200, Cliff Sarginson wrote: > Hello > I am trying to use pgp (and or gpg) signatures with mutt. > I have set up the keys and directories etc. > When I try to sign the message with the option from the > "p" command I get an errno(2) ..no such file or directory. > pgp and gpg are both on the PATH. > Clues ? Have you set the various pgp_*_command options correctly (most likely by sourcing gpg.rc or one of the pgp.rc files (that are included in the mutt distribution) from your .muttrc)? -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is:
Re: easy question... :)
--WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 11 Sep 2001 at 19:13:04 -0700, Denis Perelyubskiy wrote: > * Rino Mardo <[EMAIL PROTECTED]> [09-Tue-01 19:06 -0700]: > > you need procmail for that. in my ~/.procmailrc i have something > > like this: > >=20 > > :0: > > * ^Return-path:.*mutt-user.*@mutt\.org > > $MAILDIR/mutt/ >=20 > actually, does it not make more sense to use ^TO_ expression, in plcae > of ^Return-path? >=20 > why did you choose that? >=20 > (i am not saying ^TO_ is correct, as i only recently started getting > into procmail, but from what i read about ^TO_ it looks at lots of > "To:"-like headers. Return-path may or may not be set by the mailing > list management software, or may actually even be mucked with by MTAs, > i think...at least i saw some message to this effect on some mailing > list. given, it is not a correct configuration, but still a possible > one) I think "Return-to:" is prone to much fewer problems than "^TO_". Consider what happens if someone BCC's the list, or bounces (i.e. redirect/send without modifying the headers) a message to it[1]. They'll fall right through "^TO_", whereas "Return-path:" will still catch them. Personally though, i prefer filtering on this header: ^Delivered-to: mutt-users@ns\.gbnet\.net or even better, the "List-Id:" or "Mailing-List:" headers, but mutt-users has neither. :-/ [1] Sidetrack: I checked now and noticed that TO_ includes "Resent-To:", which should actually catch bounces by some (most?) MUAs. It still isn't bulletproof by far though. :) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --WhfpMioaduB5tiZL Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7nthyzRUP82sZFCcRAjldAKCAy9RWLKABOdoBB+PmMp9wkDqOiQCfUdyN Vm7W+ozkxIEYypWyqqjtIAg= =S0vK -END PGP SIGNATURE- --WhfpMioaduB5tiZL--
Re: mutt & exchange
--aVD9QWMuhilNxW9f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 13 Sep 2001 at 03:01:09 +0200, Magnus Stenman wrote: > if you run cygwin (and since mutt now is in cygwin more people will) > you might not be able to get ssmtp or similar running. Actually, i remember ssmtp running quite well when used mutt on Cygwin (i've since moved to FreeBSD, thank Eris). It can be installed very easily via Cygwin's setup.exe, AFAIR, just like mutt. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --aVD9QWMuhilNxW9f Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7oTXrzRUP82sZFCcRAtVuAKCeLaZQyqVfz8hygRIGlLZ9hvCBkgCgllg0 6AFLPuF2JP84cn6maNemTMs= =qjpd -END PGP SIGNATURE- --aVD9QWMuhilNxW9f--
mutt & Cygwin [was: Re: mutt & exchange]
On Fri, 14 Sep 2001 at 10:48:30 +0530, Suresh Ramasubramanian wrote: > Piet Delport [14/09/01 00:40 +0200]: > > Actually, i remember ssmtp running quite well when used mutt on Cygwin > > (i've since moved to FreeBSD, thank Eris). It can be installed very > > easily via Cygwin's setup.exe, AFAIR, just like mutt. > > Speaking of cygwin, is there any way to spool mail locally on the doze box > using a fetchmail variant? > > c:/mail/ having several mboxes for example. I used to do just that, running both fetchmail and procmail as if on a unix. I compiled both from the stock sources, although there where some gotchas with fetchmail. From memory: 1. I had to ./configure fetchmail with `--with-included-gettext', as it didn't like the gettext headers that came with cygwin. 2. I had to patch fetchmail to make it not complain about the permissions of .fetchmailrc, as the requirement that it isn't world-readable doesn't really apply under Win9x. It's silly that fetchmail doesn't have an override for this behaviour, IMHO. (The patch involved #ifdef'ing out the few lines of code in rcfile_y.y (IIRC) that do the check.) procmail was relatively painless, except that `make install' failed because there was a file in the distribution called `INSTALL', which, because of the case-insensitiveness of Winders, confused make greatly until i moved `INSTALL'. If you're planning to run gpg as well: i had to ./configure it with `--disable-dynload' and `--disable-asm' to get it to compile, and ended up #ifdef'ing out some code that (harmlessly) complains about insecure memory as well. If you want, i can dig up my notes on all of the above, to see exactly what i changed. -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
Re: [1.3.22.1] history bug
On Fri, 14 Sep 2001 at 11:52:50 +0200, Vincent Lefevre wrote: > With Mutt 1.3.22.1, when I type 's' to save a message to a mailbox: > > The up arrow (history-up) seems to behave correctly, going backward > through the history. But when I use the down arrow (history-down), > instead of going forward, it still goes backward. I can confirm that here (see headers for version info). The same seems to happen at the prompt for changing to another mailbox (`c'). -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
OT: Shell scripting [was: Re: Fix for PGP copyright thing...]
--a2FkP9tdjPU2nyhF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, 14 Sep 2001 at 07:03:19 -0400, David T-G wrote:
> % ---BEGIN---
> % #!/bin/sh
> ...
> % pgp $* 2>$PGP_ERR 1>$PGP_OUT
>=20
> BTW, you might want to modify your script to protect any arguments with
> embedded spaces. Change the line above to
>=20
> pgp ${1+"$@"} 2>$PGP_ERR 1>$PGP_OUT
>=20
> and you're golden.
It's much more straightforward to use:
pgp "$@" [...]
actually. :)
> [BTW, I haven't *yet* found this in any shell documentation since I
> saw it in a shell programming tip; can anyone provide me a pointer for
> further research?]
I daresay you haven't been looking hard enough. :)
Quoting FreeBSD's "man sh" [from the listing of special parameters]:
| @ Expands to the positional parameters, starting from one.
| When the expansion occurs within double-quotes, each
| positional parameter expands as a separate argument. If
| there are no positional parameters, the expansion of @
| generates zero arguments, even when @ is double-quoted.
| What this basically means, for example, is if $1 is ``abc''
| and $2 is ``def ghi'', then "$@" expands to the two
| arguments:
| "abc" "def ghi"
As for further research, i generally got by on the sh and bash manpages
up till now. They're generally very concentrated in terms of info, and
take a while to sink in. I find myself realizing new things all the
time when i'm (re-)reading them. :-)
(Prominent example: just now while writing this mail, i saw for the
first time how ${1+"$@"} works. Ingenious approach, even if a bit
redundant. Most probably in the context of the tip you found it in it
was a workaround for a shell that didn't handle a plain "$@" correctly?)
--=20
Piet Delport <[EMAIL PROTECTED]>
Today's subliminal thought is:
--a2FkP9tdjPU2nyhF
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (FreeBSD)
iD8DBQE7pB2mzRUP82sZFCcRAvCVAJ4jzkyFEmALLlEhocnWHQAvXxm4qgCffPxJ
tpv05IQHXabtYMM1jKfdM6c=
=3Ffj
-END PGP SIGNATURE-
--a2FkP9tdjPU2nyhF--
Re: esc t ..why doesn't work when a message is displayed?
--JBi0ZxuS5uaEhkUZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 14 Sep 2001 at 09:26:48 -0400, David T-G wrote: > ...and then Olaf Schulz said... [...] > % But (at least in mutt 12.5i) trying to type ':tag-thread' while in > the pager % has no effect. Maybe it's a problem with the programming > logic behind it that % makes it impossible to have tag-thread > available in the pager? >=20 > I have no answer for that, since I'm no coder by far. But perhaps > that's why it's not bound in the pager by default :-) >=20 > Yes, it seems to me that just about every function should be available > just about everywhere. Go figure. I doubt it's a design limitation... delete-thread and friends are all available in the pager as well as in the index, so why not tag-thread? A temporary workaround is something like this: macro pager \ec "" "tag the current thre= ad" I use a similar macro to do a sync-mailbox from the pager. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --JBi0ZxuS5uaEhkUZ Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7pCDuzRUP82sZFCcRAp2wAJ46DpQVBgBRhxH89We0peQirMEoigCfTOAQ hLhZOuIgFPxkSZWgGHfN6X0= =ERn1 -END PGP SIGNATURE- --JBi0ZxuS5uaEhkUZ--
Re: Macro to tag all messages with a particular flag set
--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 16 Sep 2001 at 15:09:55 +0200, Cliff Sarginson wrote: > Hello > I want to have a macro to tag messages with a particular flag setting > .. in my case the "important" flag. Ultimately what I want is for it > to do an automatic "save" to a particular mail folder (always the same > folder, it has no need to ask me for a name). > I am RTFM as we speak :) Something like: macro x "~F\n+foldername\n" --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7pSQUzRUP82sZFCcRApfWAKChQ6ZCRNGuY5ws7CEN8B1n62JnDACeI2Ju k8JcyVWq2kDhHOoe7dR/XM0= =oRzv -END PGP SIGNATURE- --IJpNTDwzlM2Ie8A6--
Re: OT: Shell scripting [was: Re: Fix for PGP copyright thing...]
--da9oBGf5DLtF9ehv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2001 at 17:19:26 -0400, David T-G wrote: > Will -- >=20 > ...and then Will Yardley said... > % David T-G wrote: > % > > it seems kind of silly to me - i rarely use the bourne shell but i > ... > % >=20 > % > No, it's not silly at all -- /bin/sh is one of the things that can be > ... > % > Doing away with /bin/sh would be a Very Bad Thing. > %=20 > % agreed. i meant it was kind of silly that linux uses bash instead of > % the bourne shell. i was certainly not trying to suggest that we abolish > % the bourne shell! >=20 > Ah :-) Well, you can't use the Bourne shell without proper licensing, > and GNU/Linux is all about free stuff. There's a written-from-scratch > PDksh public domain ksh out there, but bash is the only ready-today free > sh clone (and then some :-) out there. Ahem. This may (or may not) be true of the original Bourne shell, but the *BSD /bin/sh is very real, and is even more free than bash in terms of licensing. :-) And then there's still zsh, sash, and many other variations probably. (This is getting very off-topic for mutt-users, we should probably take it off-list.) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --da9oBGf5DLtF9ehv Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7ppU7zRUP82sZFCcRAqc6AJ4s/rPd1sW8aCMed5UqKUSrmascVACdHdrn 2pcS/2Y6fMG/MULWNCnQT+M= =GMOP -END PGP SIGNATURE- --da9oBGf5DLtF9ehv--
Re: esc t ..why doesn't work when a message is displayed?
--19HmC3QOnaNVzKTI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 16 Sep 2001 at 13:47:32 +0200, Cedric Duval wrote: > * Piet Delport <[EMAIL PROTECTED]> [09/16/01 05:47]: > > A temporary workaround is something like this: > > > > macro pager \ec "" "tag the current = thread" > > > > I use a similar macro to do a sync-mailbox from the pager. >=20 > You no longer need this with 1.3.22.1i, you can now sync from the > pager. Ah, most excellent. Thanks for pointing that out. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --19HmC3QOnaNVzKTI Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7ppcTzRUP82sZFCcRAmW/AJ924TFhZZ0Z8HCi48q/WbQm/5CiyQCfZBjv 95puZ/cAvH/rB4CDhtafJ1Q= =T+GO -END PGP SIGNATURE- --19HmC3QOnaNVzKTI--
Re: Authenticating public keys...
--uQr8t48UFsdbeI+V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2001 at 16:12:25 -0400, Jean-Sebastien Morisset wrote: [...] > What do you guys do? Put up with the warning? Sign the key even if > you're not sure? Use the X-PGP-Fingerprint header as a second > validation? Use fingerprints in signatures? >=20 > We should have a little poll. :-) I put up with the warnings until i can verify a key, as doing otherwise defeats their purpose, and the web of trust. Like other have said, using fingerprints from the email header as validation is a really bad idea, as they're exactly as easy to forge as the signature itself. I'm not of the meeting-in-person-or-over-the-phone-is-the-only-way school though, as even that can be forged with a bit of planning and luck. (Someone's phone can be answered by a malicious person impersonating him, and you won't even know the difference if you haven't heard either party's voice before, or an impersonator could show up at an informal key-signing party without the real person's knowledge, and so on.) It's also in many cases difficult to organise meatspace meetings, with people situated all over the world and all that. So i think the most realistic way to verify keys is to get fingerprints from as many independant sources as possible, and basing your overall trust on the sum of each individual source's trust, if that makes sense. For example, if i can obtain matching fingerprints for many of the FreeBSD core team members' public keys via: - the various online mirrors of the FreeBSD Handbook - a copy of the same handbook from an official release CD - their personal homepages - multiple mailing list postings I'll consider the key trusted, without the slightly inconvenient step of flying abroad and organising a meeting. So the key (no pun intended) to making your public key easily and securely verifiable is to have as many redundant copies of it spread all over the place as you can. The more difficult it is for an imposter to `fake' all the copies at once (or sequentially, while you're checking them), the better. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --uQr8t48UFsdbeI+V Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7pq4EzRUP82sZFCcRAiQHAJ43xR3LC8BGZ5aWJa6PmTafxc3y/gCdFw09 25WU0PO5+uOSpFozgqqwrX4= =4IfA -END PGP SIGNATURE- --uQr8t48UFsdbeI+V--
Re: character enconding question
--mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2001 at 18:18:09 +0200, Enrique de la Torre wrote: > I'm a spanish mutt user. I use emacs as editor: >=20 > > set editor=3Demacs # really simple ;) > >=20 > Everytime I save an email, emacs shows a warning asking me to select > the character coding system, because it finds some non ASCII > characters (iso-8859-1): >=20 > > The target text contains the following non ASCII character(s): > latin-iso8859-1: =F3=ED=E1... > These can't be encoded safely by the coding system undecided-unix. > Select coding system (default iso-8859-1): >=20 > [text/plain, 8bit, iso-8859-1, 0,1K] <=3D=3D USES 8-BIT ENCODING > >=20 > So I just hit enter and works. It uses a 8-bit conding system. If I > use emacs alone, I have no problem with this characters, so I suppose > mutt tells emacs not to use a 8-bit code with iso-8859-1. But I want > mutt/emacs to use it by default, both 8-bit and iso-8859-1, instead of > undecided-unix (i dont really know whats this..) I think this is something to do with emacs alone, and not mutt. As you said emacs doesn't have a problem when editing 8-bit text on its own, maybe this could be because of some email-mode in emacs that's trying to help by complaining about 8-bit text? If you are running an emacs-mode or -plugin (i'm not too familiar with emacs myself, i'm a vim fan) for mail messages, have you tried disabling it? --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7prD1zRUP82sZFCcRAoJzAJ0ePpeX3WX1VJd7vENHpQM/K06i0ACghAcj jBkgfp00hYLWFMRL6V88ITU= =QR1l -END PGP SIGNATURE- --mvpLiMfbWzRoNl4x--
Re: How to *not* include myself in the reply message?
--0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 18 Sep 2001 at 16:26:34 -0700, Jun Sun wrote: > I think it might has to do with my folder setting. I have set up such > that in different folders I have different "From:" address. Perhaps > mutt does not recognize those additional "From:" addresses as "me", > and consequently include them in the group reply. >=20 > Is there anyway to tell mutt what addresses are considered "me" so > that it won't include any of them when I hit "g" group reply? Or is > there way to mutt respect the current "From:" and regard it as "me" ? Are you looking for "alternates"? --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7p+PKzRUP82sZFCcRAhHyAJ9wpaLBZh4hoBEVqtfpy322VCfwBQCeLGjg JjBpEWT0uNPvN6eFq+xby2s= =AncF -END PGP SIGNATURE- --0vzXIDBeUiKkjNJl--
Re: :repeat command
--4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 19 Sep 2001 at 10:57:14 -0400, Miguel Farah F. wrote: > Andy Smith [19/09/2001 10:53] dijo/said: > >On Wed, Sep 19, 2001 at 10:30:49AM -0400, Miguel Farah F. wrote: > > > >> It'd be nice if there was a ":repeat" command that... well... > >> repeats the last command as if it had been just retyped. > > > >Usually you can press the up arrow to scroll back through the > >previous commands? >=20 > The up and down arrows are binded to the previous-undeleted and > next-undeleted commands... Not while in the command-line editor (after pressing `:'), they're not. Unless you mean you've explicitly re-bound them as: bind editor bind editor in which case you're probably much better off reverting to the default bindings. (I can't for the life of me figure out the usefulness of previous- and next-undeleted while in the line editor...) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7qQFtzRUP82sZFCcRAiNVAKCIsWOYZdZ7VOsUkFBaz+5lecO7CQCfdxXZ svyzLm1wE6S/LIQIbg4fVLc= =Af7D -END PGP SIGNATURE- --4Ckj6UjgE2iN1+kY--
Re: rot13 capability?
On Wed, 19 Sep 2001 at 15:09:32 -0400, David T-G wrote: > ...and then David Champion said... [snip] > % Guess someone just can't make up their minds. I wonder whether it's > % Sun or a standards agency. I wish I still had other platforms > > Yeah. Well, FreeBSD has the following to say under tr(1): | COMPATIBILITY | System V has historically implemented character ranges using the | syntax ``[c-c]'' instead of the ``c-c'' used by historic BSD | implementations and standardized by POSIX. System V shell | scripts should work under this implementation as long as the | range is intended to map in another range, i.e. the command ``tr | [a-z] [A-Z]'' will work as it will map the ``['' character in | string1 to the ``['' character in string2. However, if the shell | script is deleting or squeezing characters as in the command ``tr | -d [a-z]'', the characters ``['' and ``]'' will be included in | the deletion or compression list which would not have happened | under an historic System V implementation. [ Online version of the manpage can be found here: http://www.FreeBSD.org/cgi/man.cgi?query=tr&apropos=0&sektion=1&manpath=FreeBSD+4.3-stable&format=html (hope the URL gets through intact) ] So, under the POSIX standard at least (and *BSD, in this case), the One True Way is: tr A-Za-z N-ZA-Mn-za-m Does that work under Solaris? > % Well, the lesson is that tr usage varies wildly among platforms, > % just like expr, but we already knew that. :) That's what POSIX tries to remedy. :) > % So maybe it's best just to have your .mailcap call that rot13 shell > % script, and adapt the script to cope with unames appropriately. Or > % use perl. > > sh is portable (see other drifted-off-topic thread :-) but with this > much garbage rolled in I think I will, indeed, go for perl. Heavens man, have you no concern for efficiency? :-) If the POSIX version doesn't work under Solaris, i'd rather go for: tr ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz \ NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm Much more lightweight, and should work practically anywhere, even if it involves a bit of extra typing. Also, as for getting mutt to actually use the filter, i'm surprised no one has pointed at $display_filter yet. Instead of resorting to hacks involving .mailcap and (horrors :-) editing the message's content type[1], you can just do something like: macro pager ( "set display_filter=\nmacro pager \\ca )\n" macro pager ) "set display_filter=rot13\nmacro pager \\ca (\n" macro pager \ca ) "Toggle ROT13 decoding" (Pity there's no way to force mutt to re-parse the message... i'm using a double to simulate one.) Just replace `rot13' with your chosen filter command and you're set; no extra config required, and no risk of munging actual messages. [1] What happens if the message you're rot'ing is something besides text/plain, like text/html f'rinstance? The given macro will just nuke the content-type from orbit, leaving you looking at HTML source. -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
Re: Binding Shift-keys?
On Wed, 19 Sep 2001 at 10:49:45 -0400, Miguel Farah F. wrote: > I find the key combination for the previous-new command > quite awkward, and I'd rather remap it to Shift-Tab. However, I can't > find a way to define this key combination. What am I missing? I'm not completely sure how you can make shift-tab work[1], but another approach is getting your Alt key recognised as a meta key, which is what the escape-prefixed commands in mutt represent. There are two ways of going about that, corresponding to the two main ways meta keys are generally handled: - Configure your terminal to escape-prefix Alt- (i.e. Meta) modified keypresses, so that results in being sent. - Configure your terminal to send Alt-modified keys with the meta (8th) bit set. In this case, will result in the character with numeric value 0x89 [2] being sent. Mutt won't recognise this out-of- the box though; you'll have to enable the `meta_key' option in your muttrc. Most terminals should be capable of at least one of those possibilities. If yours doesn't, switch. :-) HTH, [1] It likely depends on what your terminal sends when you press shift and tab. If you're determined, you can try and capture it in vi (for example) by entering insert mode and typing . On my computer, that results in: [Z where is a literal escape. You can then macro that sequence from your muttrc. (I had to do this to map to delete-thread on my old Cygwin installation.) [2] Which is the result of 9 (a tab) + 128 (the high bit). -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
Re: macro help (was "Re: rot13 capability?")
--7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 20 Sep 2001 at 08:21:14 -0400, David T-G wrote: [...] > My muttrc has >=20 > macro pager ,@r13on "set display_filter=3D$HOME/local/bi= n/rot13\nmacro pager \\cx ,@r13off\n" > macro pager ,@r13off "set display_filter=3D\nmacro pager\\cx ,@r13on\n" > macro pager \cx ,@r13on "Toggle ROT13 decoding" [...] > And why should the columns differ (example one to examples two and > three) and \cX lose its description? Oops, missed that. The description is lost every time is re-defined from within the other macros. Either add it there, or drop it altogether, i think. (Docs? We don' need no steenkin' docs! :-) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7qkwZzRUP82sZFCcRArMPAJ9/h+xzhC6Tc7uLujWyz8gZmK0SLQCgh6mZ Ldq3zSyhNtGx2Er8eoJ2t5k= =tGpy -END PGP SIGNATURE- --7AUc2qLy4jB3hD7Z--
Re: what makes mutt recognize mbox files?
--xgyAXRrhYN0wYx8y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 20 Sep 2001 at 10:03:53 -0400, darren chamberlain wrote: > Erika Pacholleck <[EMAIL PROTECTED]> said something to this effect on 09/2= 0/2001: > > Now however this does not work, mutts index keeps black (no it is > > not black text on black bg ;) ) although the status lines already > > indicates the correct size, but no messages counted. >=20 > mbox files are separated by "\nFrom " (basically). >=20 > > The headers contain these lines > > >From xxx > > Date: bbb > > From: xx > > Subject: aaa >=20 > Those lines that begin with ">From " should be "From ". I think it's your local MDA that escaped the `From '. :-) They show up naked here. (I'm using Maildir here, which doesn't require `From 's in the message body to be escaped. Erika, those messages should be fine. Any chance of you posting (or mailing privately) some full examples (after stripping any private/sensitive information, of course)? The problem might be subtler that the given example conveys. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --xgyAXRrhYN0wYx8y Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7qk8kzRUP82sZFCcRAh2mAJ0bjomQiOTSE9scSQ9VL+B4x5Or9wCeO54k UiTGK6iTyN9sjyEgcJ2ntNs= =tJNj -END PGP SIGNATURE- --xgyAXRrhYN0wYx8y--
Re: .signature-related blues
--JgQwtEuHJzHdouWu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 20 Sep 2001 at 09:38:39 +0200, Ren=E9 Clerc wrote: > On Wed, Sep 19, 2001 at 10:39:20AM -0400, Miguel Farah F. wrote: > | I think that this should be a mail-client feature, considering it > | does the rest of the preformatting (i.e. inserting quotes and the > | attribution, etcetera) too. >=20 > I think it's handy _not_ to have it in the mail-client, because > sometimes you don't want the sig to be cut off. Probably in the case > one sends you random quotes at the end of his sig, and you want to > reply on a quote ;) If it's an option, you can turn it off temporarily in the rare cases that you want to reply to a sig, and keep it on in the vast majority of cases where you just want the .sig gone. [...] > And the script signature looks like: >=20 > #!/bin/bash >=20 > cat /home/rene/.signature > echo "" > /usr/games/fortune -a -s -n 200 Very OT, but why use "#!/bin/bash" when "#!/bin/sh" will do? Not every Unix comes with bash in /bin like (most incarnations of) Linux. :-) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --JgQwtEuHJzHdouWu Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7qlUNzRUP82sZFCcRAm2XAJ9O8BIHbsOU2NU+wH0mCGK6vfzDJwCfSQZz CwZb/Uk2no9Bpds+y3h4lhM= =1sn0 -END PGP SIGNATURE- --JgQwtEuHJzHdouWu--
Re: what makes mutt recognize mbox files?
--wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 21 Sep 2001 at 00:01:41 +0200, Erika Pacholleck wrote: [snip] > These are the headers in real, anonymized of course: > snip --- this is the very first line --- > From [EMAIL PROTECTED] Sun, 26 Aug 2001 02:46:52 -0500 > Date: Sun, 26 Aug 2001 02:46:52 -0500 > From: x [EMAIL PROTECTED] > Subject: [Newbie] RE: Subject line here >=20 > message here. >=20 > Name of Sender >=20 >=20 >=20 >=20 > From [EMAIL PROTECTED] Tue, 31 Jul 2001 12:16:46 -0400 > Date: Tue, 31 Jul 2001 12:16:46 -0400 > From: First Name [EMAIL PROTECTED] > Subject: [Newbie]Next subject line >=20 > message here. > - snap --- and so on --- >=20 > The only differences between my normal mutt headers are: [...] > 3. the From line has a , after the day and mine is without I think this might be it. I just tried it on one of my archived mboxes; insert the comma and the message vanishes from the index, delete it and the message is recognised. That alone doesn't fix it in your case though... i had to rearrange the ordering of the fields like in this example: | From [EMAIL PROTECTED] Sun Aug 26 02:46:52 2001 -0500 Does doing that work? (Instead of re-arranging every single From_ line, you can prolly just copy an existing one, BTW. I've done this once or twice while recovering Pine mailboxes without any apparent ill effects.) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7q/zXzRUP82sZFCcRAkpdAJ94hYCgd34Vf0iQY6WSCKi7lJ6PDQCggi8E A7HQrvhla72CxIm2/UfsHao= =YrVx -END PGP SIGNATURE- --wq9mPyueHGvFACwf--
Re: macro help (was "Re: rot13 capability?")
On Sat, 22 Sep 2001 at 23:41:18 +0200, Jens Paulus wrote:
> On Thu, Sep 20, 2001 at 09:21:52AM -0400, David T-G wrote:
> > Hey, rot13 is cool. Now for a rot13 filter in vim :-)
>
> From the vim helpfile:
>
> [snip]
> |v_g?| {visual}g? perform rot13 encoding on highlighted text
> |g?| g?{motion} perform rot13 encoding on the text that is moved over
> with {motion}
> [snip]
>
> However, I still don't know what the sense/purpose of rot13 is.
Vg unf znal boshfpngbel hfrf, enatvat sebz gur fvyyl gb gur fbzrjung
frevbhf, fhpu nf cebgrpgvat fcbvyref be cbgragvnyyl bssrafvir grkg sebz
pnfhny ernqvat va choyvp sbehzf. (Vg'f hfrq va arjftebhcf fhpu nf
erp.uhzbe.* sbe aba-cbyvgvpnyyl-pbeerpg wbxrf, sbe rknzcyr, gb cerirag
pbzcynvagf. Vs lbh'er jnearq gung gur wbxr vf cbgragvnyyl bssrafvir,
ohg lbh jrag naq qrpelcgrq vg naljnl, ubj pna lbh pbzcynva?)
Sha snpg bs gur qnl: `iv' EBG13'q orpbzrf `vi'.
> Also, I've never used it.
Lbh unir abj. :-)
--
Piet Delport <[EMAIL PROTECTED]>
Today's subliminal thought is:
PGP signature
Re: macro help (was "Re: rot13 capability?")
--YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, 22 Sep 2001 at 23:15:44 -0400, David T-G wrote: > ...and then Jens Paulus said... > % On Sat, Sep 22, 2001 at 11:41:18PM +0200, Jens Paulus wrote: > % > On Thu, Sep 20, 2001 at 09:21:52AM -0400, David T-G wrote: > % > > Hey, rot13 is cool. Now for a rot13 filter in vim :-) > % >=20 > % > >From the vim helpfile: > % ^ > % Hey, this is bad: what I just experienced is that after the transmission >=20 > Well, yes and no... It's an escape to prevent your mail agent from > thinking that it's the start of a new message. >=20 > % of my mail I see that there is a quotation character just before > % 'From ' (... the vim helpfile). I didn't put it there and it > % doesn't come from David. Obviously the software thinks that there > % should be a distingtion >=20 > That's included by the MTA by design when it's delivered. >=20 > % to the mail separation From_ line in mbox format and inserts the > % quotation character itself automatically. I wonder if there is a way > % to >=20 > Sure; switch to a mail folder format that doesn't require it. I hear > that maildir is good. I switched over to Maildir a few days ago, because i liked the idea of: - Not having to worry with locking. - One message per file, so less chance of catastrophic corruption. Plus, i can go: $ grep foo * | xargs rm and such to process messages using shell commands. Neat. - No From_ quoting or other such hacks involved. In fact, Maildir doesn't seem to use From_ lines to begin with. I can highly recommend Maildir so far. All that was involved in the switch was: 1. Append a `/' to all folder names in my .procmailrc, as in: :0: * ^Delivered-to: mutt-users@ns\.gbnet\.net in.mutt-users/ This tells procmail to use Maildir. 2. Add `mbox_type=3DMaildir' to my muttrc. Not strictly required, as mutt will auto-detect a mailbox's type, but mutt will make all new mailboxes Maildir now. 3. Migrate my old mailboxes by renaming them to `foo.old', then going into them and saving them all back to `foo', creating a Maildir in the process. (Is there a more convenient way to do this?) > % avoid that. I just made an other test with an other sentence and the > % same result. Let's see what happens. > %=20 > % >From heaven to earth. > % >From alpha to omega. >=20 > As expected :-) Those showed up without >'s here in the original message. :-) --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7rk1lzRUP82sZFCcRAl4WAJ0btbWMwEDzZQUGFkET5qlGWffc7ACePEGi QY4l/xMSYj8FY/inYdx3/BM= =k1rX -END PGP SIGNATURE- --YiEDa0DAkWCtVeE4--
Re: Mutt and GPG
--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, 24 Sep 2001 at 18:07:15 -0400, Justin R. Miller wrote:
> Thus spake Ren=E9 Clerc ([EMAIL PROTECTED]):
>=20
> > [... some marvelous Xemacs trick ...]
> >=20
> > Does anybody know if it's possible with vim? I mostly use mutt over
> > ssh...
>=20
> Here's one way:
>=20
> http://groups.yahoo.com/group/mutt-users/message/20095
> http://groups.yahoo.com/group/mutt-users/message/21602
That explains wrapping, but not right-justification, which i think is
what Ren=E9 wants.
Reading `:h right-justify' in vim pointed me to a utility called `par'.
I've only looked at par's options cursorially, but it seems filtering
text through `par 72j' does the trick, including preserving quoting.
This can be done via "!{motion}par 72j", or more conveniently by setting
vim's `equalprg' or `formatprg' options to `par 72j', and then
formatting text with "=3D{motion}" or "gq{motion}", respectively.
--=20
Piet Delport <[EMAIL PROTECTED]>
Today's subliminal thought is:
--RnlQjJ0d97Da+TV1
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (FreeBSD)
iD8DBQE7r77CzRUP82sZFCcRAmbPAKCgLiGQJfG9EOxtiDzvHub08jmxqwCeJX5Y
Kv08GnS7bZ7WG6y9ySEnXwk=
=4tXS
-END PGP SIGNATURE-
--RnlQjJ0d97Da+TV1--
Re: displaying recipient in index
--mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 25 Sep 2001 at 00:58:02 +0200, Eric Smith wrote: > How do I display the recipient name in the index in the form of: > To Email Recipient >=20 > instead of it displaying my name in respect of emails sent by myself? The `alternates' settings is most likely what you're looking for. Basically, it's a regular expression that tells mutt which addresses belong to you, and is used for displaying messages in the above form, stripping yourself from group replies automatically, etc... --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7r8XEzRUP82sZFCcRAlQcAJ9rpD5K/8LA8XmI3y42LAHx42MvGwCdHJPj TrUBH2XgpUggabWFpwaNNYw= =o/pi -END PGP SIGNATURE- --mojUlQ0s9EVzWg2t--
Can't get the vvv-nntp-patch working...
--d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've installed mutt from the ports collection using WITH_MUTT_NNTP (after trying and failing to get the hang of slrn...), and everything seems to have went well, but i'm running into a strange problem when i actually try to read news. I'm running leafnode locally, and mutt connects fine; gives the list of newsgroups when i press `i', lets me subscribe, shows how many are unread, everything. But as soon as i enter a newsgroup, mutt shows me an empty index. No messages whatsoever, even after every obvious way to make mutt display everything it can. Going back to the newsgroup browser shows that all articles seem to have been marked read. Pressing brings back the full message count in the browser, but as soon as i try to re-enter the newsgroup, the articles just dissappear again, just like before. I think the problem is leafnode related, as mutt works perfectly on my ISP's news server. Version info:=20 Mutt 1.3.22.1i (2001-08-30) Leafnode+ NNTP Daemon, version 2.14 Any clues? --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7sAYRzRUP82sZFCcRAo9eAJ0W1MBlQy2iIDRkrcw65t7vbLs8UACeIjJ+ jcuJIpZPdPO24cVmOzGaGCU= =oNbw -END PGP SIGNATURE- --d6Gm4EdcadzBjdND--
Re: send-hook based on what address the message I'm replying to wassent to?
--bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 26 Sep 2001 at 18:06:15 -0700, Taner Halicioglu wrote: > Hmm, maybe this is addressed in a 1.3 mutt, but I dunno... >=20 > I have a few email addresses that forward to this email address, and > I'd like to be consistent and set my From: header based on what a > message was sent TO... >=20 > That is, if someone sends me email to <[EMAIL PROTECTED]>, I'd > like to have a send-hook realise this when I'm replying, and change > my_hdr From: to be <[EMAIL PROTECTED]> instead of > <[EMAIL PROTECTED]>... >=20 > I hope that makes sense? :-) >=20 > Any ideas? I think the `reverse_name' and `reverse_realname' settings are what you're looking for. --=20 Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: --bCsyhTFzCvuiizWE Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) iD8DBQE7spDTzRUP82sZFCcRAqCwAJ9MBHlsWfEdoSTvp45RHybO4waXxwCfaQ1U jQpGEexUo8GFC24l2fS5T4A= =nRTH -END PGP SIGNATURE- --bCsyhTFzCvuiizWE--
Solved somewhat [was: Re: Can't get the vvv-nntp-patch working...]
On Tue, 25 Sep 2001 at 06:20:33 +0200, Piet Delport wrote: [snip mutt and leafnode not working] > I think the problem is leafnode related, as mutt works perfectly on my > ISP's news server. > > Version info: > Mutt 1.3.22.1i (2001-08-30) > Leafnode+ NNTP Daemon, version 2.14 > > Any clues? It seems the problem is a bad interaction between the VVV patch and leafnode 2.14, while they both work fine on their own. Version 1.9.19 of leafnode seems to work though. Has anyone else experienced success/failure with the above combination? Vsevolod, if you're reading this, are you interested in tracking this problem down, if it's on mutt's side? I'll be happy to provide more info and/or a test server, if needed. Thanks, -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
Re: editing headers in vim + clear text signing
On Mon, 01 Oct 2001 at 11:19:43 -0500, David Champion wrote: > On 2001.10.01, in <[EMAIL PROTECTED]>, > "Frederik Vanrenterghem" <[EMAIL PROTECTED]> wrote: > > I'm trying out some ways to clear text sign a message in mutt, using > > :%!gpg -eas > > > > Unfortunately, all headers (including "to") are signed, effectively > > making these headers useless. Is there a way to specify to this > > filter only to sign/encrypt the actual message body? > > I can do it in vi thusly: > > :1[to top of file] > /^$ [find header/body boundary] > j [down 1 line to body proper] > !Ggpg --clearsign [pipe/replace from here to EOF into gpg] > > I suppose that vim ought to work the same way. You can do it a bit more elegantly[1] with this ex one-liner: 1;/^$/+1,$!gpg --clearsign [1] or obscurely, take your pick *grin* -- Piet Delport <[EMAIL PROTECTED]> Today's subliminal thought is: PGP signature
