* Thu Nov 20 2008 Fabian Groffen <[EMAIL PROTECTED]>
> On 20-11-2008 16:24:04 +0900, TAKAHASHI Tamotsu wrote:
> > * Wed Nov 19 2008 Fabian Groffen <[EMAIL PROTECTED]>
> > > On 18-11-2008 12:39:31 +0100, Jukka Salmi wrote:
> > > > > Hmm, is anybody else
/dev/null -f imap://localhost/INBOX.second.third"
with my patch.
Do you want mutt to translate "imap://localhost/second.third"
to "imap://localhost/INBOX.second.third" ? But older versions
didn't do it IIRC.
> > A patch (which is attached) I received off-list from TAKAHA
* Wed Nov 19 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> I have no idea what ks_c_5601-1987 means, but I
> suspect NetBSD (Citrus?) iconv. I think I'm using
> GNU iconv.
Blame me! See http://dev.mutt.org/trac/ticket/3134 and
http://mail-index.netbsd.org/current-users/2008/
* Tue Nov 18 2008 Jukka Salmi <[EMAIL PROTECTED]>
> Is anybody able to reproduce this? Or is anybody able to read [1]this
> message with the latest Mutt? (I just want to make sure it's not a OS
> problem before sending a bug report. This is NetBSD/i386 5.99.01, BTW.)
I can read it from both local
* Mon Nov 17 2008 Brendan Cully <[EMAIL PROTECTED]>
> On Sunday, 19 October 2008 at 14:47, TAKAHASHI Tamotsu wrote:
> > Version 3.
> >
> > * Sat Oct 18 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> > > +static STACK_OF(X509) *SslSessionCerts = NULL;
&g
* Mon Nov 17 2008 Michael Elkins <[EMAIL PROTECTED]>
> What does mutt-dev think about making $reverse_alias apply to replies?
It looks easy.
I don't set $reverse_alias though.
--
tamo
diff -r 8199185fa595 send.c
--- a/send.cSun Nov 16 21:01:41 2008 -0800
+++ b/send.cTue Nov 18 01:53:21 2
* Thu Nov 6 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> If your $spoolfile points to a Maildir, you cannot
> tab-complete "!" correctly.
>
> :set spoolfile=/somewhere/Maildir
> c!
>
> will give you "!///".
>
> This is caused by a co
* Wed Nov 12 2008 Gary Johnson <[EMAIL PROTECTED]>
> worked fine until I added a particular term to the 'reply_regex'
> expression. That term contained some non-ASCII characters that have
> appeared in place of "Re" in replies I've received from Outlook
> users in Beijing. Apparently my Solari
* Mon Nov 10 2008 Gary Johnson <[EMAIL PROTECTED]>
> but when I try to pipe a message to mutt's stdin, I get a
> segmentation fault, e.g.,
>
>$ echo test | mutt -s test garyjohn
(snip)
>Program received signal SIGSEGV, Segmentation fault.
>0x080b1f1b in mutt_smtp_send (from=0x0, to=0x
If your $spoolfile points to a Maildir, you cannot
tab-complete "!" correctly.
:set spoolfile=/somewhere/Maildir
c!
will give you "!///".
This is caused by a conflict between mutt_complete()
and mutt_expand_path().
"+" and "=" always point to a directory, not a file.
So "+foo" may/should expa
* Mon Nov 3 2008 Kyle Wheeler <[EMAIL PROTECTED]>
> On Friday, October 31 at 11:21 PM, quoth TAKAHASHI Tamotsu:
>> So here is another patch.
>> %e is a pretty version of %f in $folder_format.
>
> Hmm... there's a minor problem... in browsing around an IMAP server
* Thu Oct 30 2008 Kyle Wheeler <[EMAIL PROTECTED]>
> On Thursday, October 30 at 04:50 PM, quoth Aron Griffis:
>> Would it be worth making this configurable? I ask because
>> I access three separate accounts from one mutt session, and
>> I might prefer them always to be fully shown in the list
>> r
* Thu Oct 30 2008 Kyle Wheeler <[EMAIL PROTECTED]>
> Is there some reason that the mutt buffy list is all in canonicalized
> full-url form? As a bit of a screen real estate hawk, it seems a bit
> wasteful that when I press 'y', I get a screen full of
> "imaps://[EMAIL PROTECTED]/INBOX/..." -
* Tue Oct 28 2008 Vincent Lefevre <[EMAIL PROTECTED]>
> On 2008-10-28 16:47:17 +0900, TAKAHASHI Tamotsu wrote:
> > Here is another patch, to adjust
> > documentation instead of implementation.
>
> That's not quite correct. The "--" is needed only when t
* Tue Oct 28 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> What about post-detect, instead of pre-detect?
Oh, but my patch didn't allow
"mutt -a first.dat -a second.dat [EMAIL PROTECTED]"
(the second file was treated as an address).
If you need to allow multiple occurence
* Thu Oct 23 2008 Aron Griffis <[EMAIL PROTECTED]>
> Aron Griffis wrote: [Thu Oct 23 2008, 10:07:02AM EDT]
> > What OS is this? There are some patches recently in mutt that
> > affect cmdline processing, but your example works for me.
>
> My mistake, your example doesn't work for me. The reason
The manual has many unsupported variables.
It is really confusing when you are trying to use
an unfamiliar feature.
For example, you can't distinguish OpenSSL variables
from GNUTLS variables without grepping init.h.
I was surprised when the manual told me there was
$ssl_ca_certificates_file, but i
It seems easy and straightforward
to support %ll in snprintf.c.
Now config.h determines OFF_T_FMT,
snprintf should support %ll.
Otherwise, index_format="%c" displays
"dK" for medium-sized messages.
If you decide not to support %ll,
you should avoid %ll in config.h
or mutt_pretty_size.
--
tamo
Version 3.
* Sat Oct 18 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> +static STACK_OF(X509) *SslSessionCerts = NULL;
> +#define CACHE_TRUSTED(c) \
> + if (!SslSessionCerts) \
> + SslSessionCerts = sk_new_null(); \
> + sk_X509_push (SslSessionCerts
Perhaps this is what Rocco meant:
diff -r 10a1f06bc8aa pager.c
--- a/pager.c Tue Oct 07 19:22:53 2008 -0700
+++ b/pager.c Sun Oct 19 13:19:48 2008 +0900
@@ -1511,7 +1511,7 @@
struct q_class_t *QuoteList = NULL;
int i, j, ch = 0, rc = -1, hideQuoted = 0, q_level = 0, force_redraw = 0;
* Mon Oct 13 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> I wrote a patch (attached) to try to
> - check cert_chain and cache trusted certs
> - allow users to save intermediate certs
I'm sure many users have faced this problem because
I found http://wiki.mutt.org/?MuttFaq/Rem
Hi list,
I think mutt's (Open)SSL support is kinda poor.
It only checks a peer's direct signer/issuer.
As SSL has a recursive structure
(selfsigned root -> intermediate certs -> peer),
I hope mutt will check certs a little deeper.
Also, if a peer cert is not signed directly
by any of $certificate
* Sun Sep 21 2008 Kyle Wheeler <[EMAIL PROTECTED]>
> It just came to my attention that, at least when auto-viewing html
> attachments, mutt uses a predictable filename rather than its usual
> secure temporary file creation (e.g. it always uses $TMPDIR/mutt.html to
> view html files).
>
> This
* Thu Jul 17 2008 Derek Martin <[EMAIL PROTECTED]>
> On Thu, Jul 17, 2008 at 12:48:14PM +0900, TAKAHASHI Tamotsu wrote:
> > * Wed Jul 16 2008 Paul Walker <[EMAIL PROTECTED]>
> > > On Wed, Jul 16, 2008 at 02:34:06PM +0900, TAKAHASHI Tamotsu wrote:
> > >
* Wed Jul 16 2008 Paul Walker <[EMAIL PROTECTED]>
> On Wed, Jul 16, 2008 at 02:34:06PM +0900, TAKAHASHI Tamotsu wrote:
>
> > +while (mutt_iconv (cd, &ib, &ibl, &ob, &obl, inrepls, outrepl) ==
> > (size_t)-1)
> [...]
> > + safe_rea
* Sun Jul 13 2008 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> Now mutt depends on UTF-8, so MB_LEN_MAX needs to be
> at least 6. Therefore I suggest mutt.h checks it.
A multibyte guru NOZAKI-san told me that that is not enough.
You must expect errno==E2BIG even if you malloc'ed MB_LE
Hi,
I've just started using mutt-1.5.18 and found that
hcache strings are now converted to UTF-8. (flea#3023)
But it causes a problem on OpenBSD i386 machines
because MB_LEN_MAX==1 there.
(i.e. EUC-JP kanji strings can be truncated.)
Now mutt depends on UTF-8, so MB_LEN_MAX needs to be
at least
* Thu Mar 22 2007 Thomas Roessler <[EMAIL PROTECTED]>
> On 2007-03-22 10:12:08 +0100, Thomas Roessler wrote:
>
> > > + s = strdup (AssumedCharset);
> > > + /* If it begins with ":", make it empty */
> > > + if (s != strtok (s, ":"))
> > > +*s = '\0';
> > > + return s;
>
> This code is act
* Wed Mar 21 2007 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> * Tue Mar 20 2007 Thomas Roessler <[EMAIL PROTECTED]>
> > The way in which this code iterates through AssumedCharset in
> > convert_nonmime_string is clumsy at best. (A better way to go
> > through it wou
* Wed Mar 21 2007 Rocco Rutte <[EMAIL PROTECTED]>
> * TAKAHASHI Tamotsu [07-03-20 00:22:06 +0900] wrote:
> >FYI, I have been using my FormatString for a while.
> >The patch is attached.
> >I hope you can see what I mean with it.
> >But please note this is not r
* Tue Mar 20 2007 Thomas Roessler <[EMAIL PROTECTED]>
> On 2007-03-21 02:42:46 +0900, TAKAHASHI Tamotsu wrote:
>
> > For example, RFC2047 says that
>
> > | Subject: (a
> > | =?ISO-8859-1?Q?b?=)
>
> > | Subject: (a
> > | b)
>
> huh?
* Tue Mar 20 2007 Thomas Roessler <[EMAIL PROTECTED]>
> On 2007-03-20 12:01:49 +0900, TAKAHASHI Tamotsu wrote:
> >strict_mime=yes:
> > unset ignore_linear_white_space
> >strict_mime=no:
> > set ignore_linear_white_space
> Why on earth do we need two
* Mon Mar 19 2007 Adeodato Simó <[EMAIL PROTECTED]>
> Seems like strict_mime never made it? (I can't find it anywhere in the
> source.)
Well, you don't need it any more.
2007-02-27 17:44:09 TAKIZAWA Takashi <[EMAIL PROTECTED]> (brendan)
* mutt.h, parse.c, rfc2047.c, rfc2047.h, rfc2231.
Hi,
* Mon Mar 19 2007 Rocco Rutte <[EMAIL PROTECTED]>
> @@ -1203,9 +1232,10 @@ void mutt_FormatString (char *dest,/*
> output buffer */
> wid = mutt_strwidth (buf);
> if (count > wid)
> {
> + int i;
> count -= wid; /* how many chars to pad */
* Mon Mar 19 2007 TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
> * Mon Mar 19 2007 Elimar Riesebieter <[EMAIL PROTECTED]>
> > >* Sun Mar 18 2007 Elimar Riesebieter <[EMAIL PROTECTED]>
> > >>I've compiled a today's hg clone. Mutt doesn't show s
* Mon Mar 19 2007 Elimar Riesebieter <[EMAIL PROTECTED]>
> >* Sun Mar 18 2007 Elimar Riesebieter <[EMAIL PROTECTED]>
> >>I've compiled a today's hg clone. Mutt doesn't show special chars
> >>like the `German Umlauts' -> ae_?_ ue_?_ oe_?_ sz_?_ anymore. Plain
> >>1.5.14 does. No changes to muttrc.
* Sun Mar 18 2007 Elimar Riesebieter <[EMAIL PROTECTED]>
> I've compiled a today's hg clone. Mutt doesn't show special chars
> like the `German Umlauts' -> ae_?_ ue_?_ oe_?_ sz_?_ anymore. Plain
> 1.5.14 does. No changes to muttrc.
>
> Any hints?
Where did those chars come from? Mail, or mutt it
* Fri Mar 16 2007 Derek Martin <[EMAIL PROTECTED]>
> On Fri, Mar 16, 2007 at 04:18:45PM +0100, Christoph Berg wrote:
> > > I'm curious: does the ssh client binary tend to move around the
> > > filesystem randomly on these peoples' systems?
> >
> > No, but mutt just says "exec error" which is in no
The following reply was made to PR mutt/2841; it has been noted by GNATS.
From: TAKAHASHI Tamotsu <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Subject: Re: mutt/2841: seg fault when selecting folder "=."
Date: Tue, 13 Mar 2007 00:38:53 +0900
* Mon Mar 12 2007 [EMAIL PR
* Thu Mar 8 2007 Christoph Berg <[EMAIL PROTECTED]>
> - Forwarded message from Jö Fahlke <[EMAIL PROTECTED]> -
> Core Securities advisory:
> http://www.coresecurity.com/?action=item&id=1687
>
> Announcement on the GnuPG mailinglist:
> http://lists.gnupg.org/pipermail/gnupg-announce/2007q1
Hi Alain and Takashi,
Thanks for your explanation.
* Thu Mar 8 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> On Tue, Mar 06, 2007 at 08:02:35PM +0100,
> Alain Bench wrote:
>
> > > what/where is (8) multiple_charsets?
> >
> > http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.mutt-j.multi-charset.1
Hi,
* Sun Mar 4 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> On Sun, Mar 04, 2007 at 07:18:14PM +0900,
> TAKAHASHI Tamotsu wrote:
>
> > I'm for it, as MLTerm has "col_size_of_width_a" option
> > and vim has "ambwidth". But I have several q
Hi Alain,
* Sat Mar 3 2007 Alain Bench <[EMAIL PROTECTED]>
> now committed). I'd still recommend inclusion of msyk.iconv-hook and
> M_ICONV_HOOK_sanitize patches (points 3 and 4), and ask reviewers for
> $unknown_charset and multiple_charsets (points 7 and 8). Pointers to the
> patches are in the
* Sun Mar 4 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> I want you to commit the patch concerning wcwidth.
> http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.wcwidth.1
>
> This patch updates wcwidth() to latest Markus Kuhn's one.
> Because this wcwidth() supports CJK, the Japanese localizatio
Hi Brendan,
* Tue Feb 27 2007 Brendan Cully <[EMAIL PROTECTED]>
> For the record, to revert the diff: hg diff -r 4793:4792 | patch -p1.
> There was a minor conflict in UPDATING, easily fixed. hg backout would
> have done about the same thing.
Thanks, I didn't know both reverse-diff and backout.
N
* Tue Feb 27 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> Perhaps the difference is:
> - a bugfix concerning memory allocation
> - "+tamo" part, which is result thing of discussion by Tamotsu and Alain
> - a new patch is safer.
Thanks for your explanation.
I (1) reverted the old patch (rev.
Hi TAKIZAWA-san,
Could you explain the difference between
1.5.6-assumed.1 (Christoph's one) and 1.5.14-assumed.1?
I have a poor memory.
* Mon Feb 26 2007 TAKIZAWA Takashi <[EMAIL PROTECTED]>
> On Fri, Feb 23, 2007 at 11:11:49PM -0800,
> Brendan Cully wrote:
>
> > On Friday, 23 February 2007 at
47 matches
Mail list logo