headers
Mutt | 1 Apr 01:08

Re: [Mutt] #890: IMAP: mutt does not save to $record if

#890: IMAP: mutt does not save to $record if IMAPconnection timed out during
compose

Changes (by brendan):

  * status:  new => closed
  * resolution:  => fixed

Old description:

> {{{
> Package: mutt
> Version: 1.3.23i
> Severity: normal
>
> -- Please type your report below this line
>
> IMAP: mutt does not save to $record if IMAPconnection timed out during
> compose
>

> I am using IMAP. $record is set to {HOST}inbox.sent-mail
> Sometimes, if it takes quite long to compose a message, mutt complains
> upon sending: "Connection to IMAP server lost".
> and optionally: "Want to create inbox.sent-mail [no]/yes"
>
> The message will not be stored in $record in these cases...
>
> I have not found out how long "quite long" really is...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 1 Apr 01:10

Re: [Mutt] #1016: imap_home_namespace documentation

#1016: imap_home_namespace documentation

Changes (by brendan):

  * owner:  mutt-dev => brendan
  * milestone:  => 1.6

Old description:

> {{{
> Package: mutt
>
> I think a documentation clarification would be appropriate, but I don't
> understand enough IMAP to do it myself.
>
> --
> ciao,
> Marco
> }}}

New description:

 I think a documentation clarification would be appropriate, but I don't
 understand enough IMAP to do it myself.

Comment:

 NAMESPACE should be fixed up before 1.6.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 1 Apr 01:11

Re: [Mutt] #969: Can't clear the 'N' (unseen) flag on read-only

#969: Can't clear the 'N' (unseen) flag on read-only IMAP folders

Changes (by brendan):

  * owner:  mutt-dev => brendan
  * milestone:  => 1.6

Old description:

> {{{
> Package: mutt
> Version: 1.3.25i
> Severity: normal
>
> -- Please type your report below this line
> When reading read-only IMAP folders, I used to be able (1.2.5i) to
> clear the new flag by reading the message.  When updating to 1.3.25i,
> the 'N' flag just stays and is still there the next time around.  Going
> back to 1.2.5i, I notice that the 'toggle-new' function didn't work
> there on read-only imap folders, even though the flag got cleared by
> reading the message.
>
> Looking at RFC 2060, the client is allowed to modify the Seen flag if
> the server returns PERMANENTFLAGS on a SELECT:
>
> Here's a read-write folder:
>
> . select inbox
> * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
> * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 1 Apr 01:15

Re: [Mutt] #1497: mutt: Mail retrieval fails with a certain message

#1497: mutt: Mail retrieval fails with a certain message coming in

Changes (by brendan):

  * keywords:  POP =>
  * component:  mutt => POP

Old description:

> {{{
> Package: mutt
> Version: 1.3.28-2
> Severity: important
>
> [NOTE: this bug report has been submitted to the debian BTS as
> Bug#184918.
> Please Cc all your replies to 184918 <at> bugs.debian.org .]
>
> From: "Chris Tillman" <tillman <at> voicetrak.com>
> Subject: mutt: Mail retrieval fails with a certain message coming in
> Date: Sat, 15 Mar 2003 09:04:32 -0700
>
> This has happened to me a few time in the last month or two, so this
> time I'm submitting a bug hoping it can be tracked down.
>
> The symptoms are that I go to retrieve mail, one message is retrieved,
> and then there is a beep and no further messages are retrieved. If I
> retry, the same message is retrieved again and again.
>
> I ran an strace, which I can send if interested. Here is what I suspect
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 1 Apr 01:16

Re: [Mutt] #1529: new-mail flag appears bust in version 1.4i

#1529: new-mail flag appears bust in version 1.4i

Changes (by brendan):

  * status:  assigned => closed
  * resolution:  => worksforme

Old description:

> {{{
> Package: mutt
> Version: 1.4i
> Severity: normal
>
> -- Please type your report below this line
>
> Here's what happens:
> - mutt tells me there's new mail in mbox "a"
> - I switch to this mbox and read the mail there
> - I switch back to my inbox
> - mutt tells me that there's new mail in mbox "a" again
> - I check, and there isn't any new mail.
>
> First I thought it was a permission problem. I fiddled with permissions
> which
> didn't give me a solution. Then I waded through the news/mailinglist
> archives.
> I did find some related postings, but none of them solved my problem (I
> don't
> have something like 'xbiff' monitoring for new mail). I also tried the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Walker | 1 Apr 01:48
Picon
Picon

Re: [Mutt] #2871: Undelivered Mail Returned to Sender

On Sat, Mar 31, 2007 at 03:59:41AM -0000, Mutt wrote:

> #2871: Undelivered Mail Returned to Sender
> 
>  {{{
>  This is the mail system at host peyresourde.cs.ubc.ca.

Um. Don't suppose there's any way to make bounces disappear...?

(Not vital, but would be nice.)

--

-- 
Paul
Permalink | Reply | 1 comment |
headers
Brendan Cully | 1 Apr 02:01
Gravatar

Re: [Mutt] #2871: Undelivered Mail Returned to Sender

On Sunday, 01 April 2007 at 00:48, Paul Walker wrote:
> On Sat, Mar 31, 2007 at 03:59:41AM -0000, Mutt wrote:
> 
> > #2871: Undelivered Mail Returned to Sender
> > 
> >  {{{
> >  This is the mail system at host peyresourde.cs.ubc.ca.
> 
> Um. Don't suppose there's any way to make bounces disappear...?
> 
> (Not vital, but would be nice.)

Yes, I fixed that after I noticed this message.
Permalink | Reply | 0 comments |
headers
Kyle Wheeler | 1 Apr 08:31

Re: mutt cache sensitivity

On Friday, March 30 at 03:29 PM, quoth Rocco Rutte:
>> So... you're telling me that pointers are no longer stored in the 
>> hcache? Mutt (with hcache) no longer relies on malloc returning 
>> predictable results?
>
> No. Pointers are still stored. We don't really update the hcache so that 
> pointers could be an issue.

... I guess you mean that pointers aren't *restored*?

> The checksum thing is only to ensure that a message was memcpy()'d 
> with the same structure as the mutt instance trying to read the 
> message.

Ah, fair enough.

~Kyle
--

-- 
Arguing with an engineer is like wrestling with a pig in mud, after a 
while you realize the pig is enjoying it.
                                                            -- Unknown
Permalink | Reply | 3 comments |
headers
Brendan Cully | 1 Apr 09:00
Gravatar

mutt: 3 new changesets

3 new changesets in mutt:

http://dev.mutt.org/hg/mutt/rev/f467353f5657
changeset:   5034:f467353f5657
tag:         tip
user:        Brendan Cully <brendan <at> kublai.com>
date:        Sat Mar 31 18:50:39 2007 -0700
summary:     Add tmp flag to bcache_put, create bcache_commit.

http://dev.mutt.org/hg/mutt/rev/bf208df92829
changeset:   5033:bf208df92829
user:        Brendan Cully <brendan <at> kublai.com>
date:        Sat Mar 31 16:07:36 2007 -0700
summary:     Allow IMAP FCC to reconnect if append fails (closes: #890)

http://dev.mutt.org/hg/mutt/rev/ded1b85c289a
changeset:   5032:ded1b85c289a
user:        Brendan Cully <brendan <at> kublai.com>
date:        Sat Mar 31 14:10:35 2007 -0700
summary:     Always set up data pointer in mh_read_dir, not just when allocating context

--

-- 
Repository URL: http://dev.mutt.org/hg/mutt
Permalink | Reply | 0 comments |
headers
Charles Killian | 1 Apr 09:37

Re: [PATCH] new fmtpipe updates

Does status_format get evaluated every time the viewing window changes?  I was
hoping to use it with this pushed fmtpipe patch to get the xtitle functionality
I use to see the number of new messages in the status bar.

But when I set status_format thus:
set status_format="/home/ckillian/hg/mutt/contrib/mutt_xtitle 'Mutt (%n/%m%?b? Inc: %b?): %f
[Summary:%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?l? %l?]' |"

Scrolling the index becomes very slow.  (This is with menu_scroll set and menu_context=5).

Thanks
--Chip

On Wed, Mar 14, 2007 at 02:08:00PM -0700, Brendan Cully wrote:
> On Wednesday, 14 March 2007 at 01:33, David Champion wrote:
> > * On 2007.03.13, in <20070313210222.GB24389 <at> ventoux.cs.ubc.ca>,
> > *	"Brendan Cully" <brendan <at> kublai.com> wrote:
> > > 
> > > On further reflection, I think your fmtpipe.3 patch should work well
> > > enough -- people will just have to get used to putting their string in
> > > extra quoting. But the one you submitted seems to have some garbage in
> > > it ('/tmp/ass', and an #if 0 block), and doesn't really quote things
> > > properly for shell (embedded single quotes would break it). Can you
> > > clean these things up, and maybe add the \| check?
> > 
> > These are fixed in fmtpipe.4, attached.
> 
> I've pushed this version, thanks!
> 
> > I've also added a mutt_xtitle program in mutt_xtitle.c, with hooks into
(Continue reading)

Permalink | Reply | 0 comments |

Gmane