New changeset in mutt:
http://dev.mutt.org/hg/mutt/rev/55cd4cb611d9
changeset: 5178:55cd4cb611d9
branch: HEAD
tag: tip
user:Serta? ?. Y?ld?z
date:Thu Jun 14 18:17:41 2007 -0700
summary: flowed: consider a single space as a hard line break. Closes #2906
--
Repos
#2912: decrypt gnupg message fails with "Could not copy message"
This is what the .muttdebug0 looks like:
{{{
mutt_pgp_command: gpg --passphrase-fd 0 --no-verbose --batch --output -
/tmp/mutt-valinor-1000-32324-5
pgp_copy_checksig: "gpg: encrypted with 2048-bit ELG-E key, ID 8F9380D6,
create
#2912: decrypt gnupg message fails with "Could not copy message"
Comment (by kait):
Maybe i should tell you that i am using version 1.5.13 with these compile
options:
{{{
-DOMAIN
+DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
+USE_FCNTL -USE_FLOCK +USE_INODESORT
+USE_POP
On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> If your vi regards something like a failed pattern search as an error,
> you have to accept that.
Nonsense. If Mutt behaves badly dealing with a common application
that people use in conjunction with Mutt, especially one Mutt
spe
On Wed, Jun 13, 2007 at 04:31:22PM -0600, Kyle Wheeler wrote:
> On Wednesday, June 13 at 06:03 PM, quoth Jean-Pierre Radley:
> >Under Posix 2004 rules, I'm not sure what exit status vi will
> >present, but the vi on all variants of Unix from SCO, as well as the
> >vi on Solaris 10, adhere to the
#2909: Display problems for spams with strange chars
Comment (by Alain Bench):
{{{
Bonjour, et merci pour ce rapport de problème.
On Wednesday, June 13, 2007 at 10:43:36 -, Mutt wrote:
> For many spams, I have display problems for summary line (in index
> window). Columns after subjec
On 2007-06-15 08:19:15 -0400, Derek Martin wrote:
> On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> > If your vi regards something like a failed pattern search as an error,
> > you have to accept that.
>
> Nonsense. If Mutt behaves badly dealing with a common application
> tha
Hi, I found bug in SS11 which is triggered by mutt source. It makes
function crc_matches return false even if the crc is correct. This
virtually disables header cache.
Workaround I found is to change the definition
unsigned int mycrc = 0;
to
static unsigned int mycrc = 0;
I don't want to file
On Fri, Jun 15, 2007 at 08:19:15AM -0400, Derek Martin wrote:
> On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
> > If your vi regards something like a failed pattern search as an error,
> > you have to accept that.
>
> Nonsense. If Mutt behaves badly dealing with a common appli
In the last episode (Jun 15), Vladimr Marek said: Hi, I found bug in
> SS11 which is triggered by mutt source. It makes function crc_matches
> return false even if the crc is correct. This virtually disables
> header cache.
>
> Workaround I found is to change the definition
>
> unsigned int mycrc
> > SS11 which is triggered by mutt source. It makes function crc_matches
> > return false even if the crc is correct. This virtually disables
> > header cache.
> >
> > Workaround I found is to change the definition
> >
> > unsigned int mycrc = 0;
> >
> > to
> >
> > static unsigned int mycrc =
On Fri, Jun 15, 2007 at 06:17:53PM +0200, Oswald Buddenhagen wrote:
> > Nonsense. If Mutt behaves badly dealing with a common application
> > that people use in conjunction with Mutt, especially one Mutt
> > specifically intends to be compatible with (like vi), then Mutt is
> > broken.
> >
> that
On Friday, 15 June 2007 at 18:06, Vladimír Marek wrote:
> Hi, I found bug in SS11 which is triggered by mutt source. It makes
> function crc_matches return false even if the crc is correct. This
> virtually disables header cache.
>
> Workaround I found is to change the definition
>
> unsigned int
On Friday, June 15 at 02:25 PM, quoth Derek Martin:
It's not broken. The application developer has the right to use any
exit status he wants. Mutt CAN NOT make assumptions about what the
exit status means.
Now wait a minute, you're mixing standards here. Just as the
application developer ha
> > Hi, I found bug in SS11 which is triggered by mutt source. It makes
> > function crc_matches return false even if the crc is correct. This
> > virtually disables header cache.
> > unsigned int mycrc = 0;
> > to
> > static unsigned int mycrc = 0;
[...]
> Wow, that's voodoo. I don't see any ha
As per Subject. I attached a hacky patch to 2910, and expected trac
to mail that fact to the list - nothing.
--
Daniel Jacobowitz
CodeSourcery
Vincent Lefevre typed (on Fri, Jun 15, 2007 at 04:42:18PM +0200):
| On 2007-06-15 08:19:15 -0400, Derek Martin wrote:
| > On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote:
| > > If your vi regards something like a failed pattern search as an error,
| > > you have to accept that.
| >
On Fri, Jun 15, 2007 at 02:06:10PM -0600, Kyle Wheeler wrote:
> Now wait a minute, you're mixing standards here.
No I'm not. The OP's version is technically compliant to the
standard. It is exiting with a non-zero status when an error has
occured. I should be able to stop here, as that is proo
On Friday, 15 June 2007 at 22:08, Vladimír Marek wrote:
> > > Hi, I found bug in SS11 which is triggered by mutt source. It makes
> > > function crc_matches return false even if the crc is correct. This
> > > virtually disables header cache.
>
> > > unsigned int mycrc = 0;
> > > to
> > > static un
On Friday, June 15 at 05:51 PM, quoth Derek Martin:
On Fri, Jun 15, 2007 at 02:06:10PM -0600, Kyle Wheeler wrote:
Now wait a minute, you're mixing standards here.
No I'm not. The OP's version is technically compliant to the
standard.
I didn't mean "standards" as in "you're mixing the X sta
On Friday, June 15 at 02:59 PM, quoth Brendan Cully:
On Friday, 15 June 2007 at 22:08, Vladim'ir Marek wrote:
Hi, I found bug in SS11 which is triggered by mutt source. It makes
function crc_matches return false even if the crc is correct. This
virtually disables header cache.
unsigned int my
When entering an mbox from a folder, and then exiting back to the folder,
presently the cursor returns to the top of the folder. It would be nice if
the cursor remained opposite the mbox exited from, in the same way that
when browsing an mbox and exiting an email/thread does.
It would save an awfu
#2910: Number of new mails in change-folder view
Comment (by brendan):
This patch appears to remove the ability to distinguish between "new" and
"old" unread messages over IMAP (which was finally fixed in 1.5.14 IIRC).
You're not supposed to be prompted to open mailboxes that only have old
me
On Friday, 15 June 2007 at 17:02, Kyle Wheeler wrote:
> On Friday, June 15 at 02:59 PM, quoth Brendan Cully:
>> On Friday, 15 June 2007 at 22:08, Vladim'ir Marek wrote:
> Hi, I found bug in SS11 which is triggered by mutt source. It makes
> function crc_matches return false even if the crc
> >>>Wow, that's voodoo. I don't see any harm in making the change though.
> >>
> >>Making the variable static makes compiler to store the value to physical
> >>memory and not just to register. I can confirm that on SS12 the problem
> >
> >you'd think &mycrc would have the same effect :)
>
> It *
25 matches
Mail list logo
