[Mutt] #2909: Display problems for spams with strange chars

[Mutt]

#2909: Display problems for spams with strange chars

 For many spams, I have display problems for summary line (in index
 window). Columns after subject are shifted and unreadable.

 See attached screenshot and mailbox sample: mail from freshmeat is ok, and
 second is a spam with display problems.

 My index_format:
 set index_format = "%5C %Z  %-70.70s %-27.27L %{%d/%m/%y %H:%M} (%5c)"

 Version tested is 1.5.16

-- 
Ticket URL: 

1.5.16 bug with Reply-To - similar to ticket #2304

[Lars Hecking]

 Since I upgraded to 1.5.16, I'm observing some bizarre behaviour related to
 Reply-To. The situation is similar to the one described by Derek in
 #2304. Actually, I just found this in 1.5.15 as well, so who knows when
 the change actually occurred.

 Basically, I tried to reply to a ticketing system which has the Reply-To:
 set accordingly, but this gets ignored completely, and the reply goes to
 the To:. No setting of reply_to changes anything.

 But: this _only_ happens when hostname is set explicitly in .muttrc!

 Commenting out hostname isn't really an option, as I use it to masquerade
 my From: address. I guess my .muttrc hasn't changed much in years.

help with trying to add format string parsing to "source" directive

[Mike Hunter]

Hey everybody,

I'm floundering a bit in an attempt to add some functionality to the
"source" command and I'm hoping somebody can lend me a hand.

My end-goal is to be able to add some custom header lines based on who
the mail is addressed to.  Unfortunately, this does NOT work:

send-hook '(~t [EMAIL PROTECTED] )' source "/Users/mhunter/bin/my_hdr-gen.pl %T 
|"

I get "source:  too many arguments"

Clever quoting can get one a bit farther, but you end up with the
literal "%T" being passed to the script instead of the expanded value.

I've been trying to come up with a patch to enable this functionality,
but so far I'm not having success:  In init.c, I tried allowing more
tokens in the case of "paths" ending with '|', but when thought I'd get
it to work, I discovered that the function that handles expanding %T
(FWICT) is a static function inside hdrline.c.

I must be going about this wrong, because obviously people use format
strings with "set", but I can't quite follow parse_set to see how it's
doing it.

I've been chatting about this already on usenet:

http://groups.google.com/group/comp.mail.mutt/browse_thread/thread/a5592b5a3e3472e7/3c0a4560597524f3#3c0a4560597524f3

And, for your ridicule, here's my non-working parse_source function that
I'm working on.  It's trying to expand out the string and pass it along
to source_rc (which seems well-prepared to deal with it via eventually
fork/exec'ing).

Any help would be greatly appreciated!

Mike

static int parse_source (BUFFER *tmp, BUFFER *s, unsigned long data, BUFFER 
*err)
{
  char path[_POSIX_PATH_MAX];
  char formatbuf[SHORT_STRING];

  /*we do a first pass with with path expansion for the root */
  if (mutt_extract_token (tmp, s, 0) != 0)
  {
snprintf (err->data, err->dsize, _("source: error at %s"), s->dptr);
return (-1);
  }
  strfcpy (path, tmp->data, sizeof (path));
  mutt_expand_path (path, sizeof (path));

  while (MoreArgs(s))
  {
if (mutt_extract_token (tmp, s, 0) != 0)
{
  snprintf (err->data, err->dsize, _("source: error at %s"), s->dptr);
  return (-1);
}
if (tmp->data[0] == '%')
{
  mutt_FormatString(formatbuf, sizeof(formatbuf), tmp->data, 
hdr_format_str, data, 0);
  safe_strncat(path, sizeof(path), " ", 1);
  safe_strncat(path, sizeof(path), formatbuff, sizeof(formatbuf));
}
else
{
  safe_strncat(path, sizeof(path), " ", 1);
  safe_strncat(path, sizeof(path), tmp->data, tmp->dsize);
}
  } 

  if (path[mutt_strnlen(path, sizeof(path))-2] != '|')
  {
snprintf (err->data, err->dsize,
  _("source: multiple arguments not ending in '|'"), s->dptr);
return (-1);
  }

  return (source_rc (path, err));
}


-- 
"As soon as we started programming, we found to our surprise that it wasn't as
easy to get programs right as we had thoughtI can remember the exact
instant when I realized that a large part of my life from then on was going to
be spent in finding mistakes in my own programs."  --Maurice Wilkes, 1949

[Mutt] #2910: Number of new mails in change-folder view

[Mutt]

#2910: Number of new mails in change-folder view

 If you have new mails in a IMAP mailbox, you can display the count in the
 folder view with the macro %N. Now you read the mails and you would expect
 that this counter is reseted. But since version 1.5.15 this isn't (1.5.14
 have the expected behavior). Even if you save the box the counter shows
 the old number of new emails.

 If you need some kind of more information or a debug log, i can provide
 it. Just let me know.

-- 
Ticket URL: 

Re: [Mutt] #2910: Number of new mails in change-folder view

[Mutt]

#2910: Number of new mails in change-folder view

Changes (by christof):

  * version:  => 1.5.15

-- 
Ticket URL: 

Re: [ANNOUNCE] mutt 1.5.16 released

[Jean-Pierre Radley]

Vincent Lefevre typed (on Mon, Jun 11, 2007 at 03:13:44AM +0200):
| On 2007-06-10 16:27:39 -0400, Jean-Pierre Radley wrote:
| > Brendan Cully typed (on Sat, Jun 09, 2007 at 09:03:59PM -0700):
| > | It's that time again. 
| > 
| > I think line 165 of curs_lib.c, which reads
| > 
| > if (mutt_system (cmd))
| > 
| > should instead be:
| > 
| >  if (mutt_system (cmd) == -1)
| 
| No, it is important that if the editor returns with a nonzero exit
| status, one gets an error.
| 
| > Otherwise, after composing a message and exiting the editor, one
| > gets an error:
| > 
| > Error running "/usr/bin/vi '/usr/tmp/mutt-jpradley-0-23020-1'"!
| 
| This is a problem with your editor.

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 Posix 2001 standard, which includes in the
clause 'consequences of errors' "... or when an error is detected that
is a consequence of data (not) present in the file, ..." and "ex/vi
shall terminate with a nonzero exit status."

So on my Unix, or on Solaris 10, one will increment vi's exit status for
each unsuccessful command, like failed pattern searches, out-of-bound
line-moves, writes to an inexistent directory, etc.

What I suggested is to revert this change:

2007-04-02 17:56 -0700  Brendan Cully  <[EMAIL PROTECTED]>
(15f8a55220a7)
 .
* curs_lib.c: Make mutt_edit_file display error if editor
return is non-zero. (closes #1638)

-- 
JP
==> http://www.frappr.com/cusm <==

Re: [ANNOUNCE] mutt 1.5.16 released

[Kyle Wheeler]

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 Posix 2001 standard, which includes 
in the clause 'consequences of errors' "... or when an error is 
detected that is a consequence of data (not) present in the file, 
..." and "ex/vi shall terminate with a nonzero exit status."


Huh. I guess that's a matter of interpretation. I don't view a failed 
search or an out-of-bound line move as *errors*, but you're right, 
Solaris vi does do that (vim, of course, does not). That's pretty 
strange... I guess that means `vi && make` doesn't work like you'd 
expect on these systems. Then again, what is an error in an 
interactive program?


Now, of course, the idea is to detect whether something went really 
wrong with your editor, such as the editor didn't actually save and 
quit like it was supposed to, or you wrapped your editor in a script 
that bombed out. Perhaps the thing to do is only pause and display a 
warning if there was anything printed to stderr?



What I suggested is to revert this change:

2007-04-02 17:56 -0700  Brendan Cully  <[EMAIL PROTECTED]>
	(15f8a55220a7) 
	 . 
	* curs_lib.c: Make mutt_edit_file display error if editor 
	return is non-zero. (closes #1638)


Do you have any suggested alternative solution for the problem 
reported in that bugreport? http://dev.mutt.org/trac/ticket/1638


~Kyle
--
One of the world's greatest problems is the impossibility of any 
person searching for the truth on any subject when they believe they 
already have it.

-- Dave Wilbur


pgpHeG6zQNKIX.pgp
Description: PGP signature

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-13 18:03:15 -0400, Jean-Pierre Radley wrote:
> Vincent Lefevre typed (on Mon, Jun 11, 2007 at 03:13:44AM +0200):
> | > Otherwise, after composing a message and exiting the editor, one
> | > gets an error:
> | > 
> | > Error running "/usr/bin/vi '/usr/tmp/mutt-jpradley-0-23020-1'"!
> | 
> | This is a problem with your editor.
> 
> 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 Posix 2001 standard, which includes in the
> clause 'consequences of errors' "... or when an error is detected that
> is a consequence of data (not) present in the file, ..." and "ex/vi
> shall terminate with a nonzero exit status."

A non-zero exit status has always meant an error. Now, what is regarded
as an error depends on the application.

> So on my Unix, or on Solaris 10, one will increment vi's exit status for
> each unsuccessful command, like failed pattern searches, out-of-bound
> line-moves, writes to an inexistent directory, etc.

If your vi regards something like a failed pattern search as an error,
you have to accept that. If you don't like it, either use another
editor or use a wrapper to modify the exit status.

Note that vi doesn't have this problem under Linux.

> What I suggested is to revert this change:
> 
>   2007-04-02 17:56 -0700  Brendan Cully  <[EMAIL PROTECTED]>
>   (15f8a55220a7)
>.
>   * curs_lib.c: Make mutt_edit_file display error if editor
>   return is non-zero. (closes #1638)

If this is reverted, this may break the behavior with other editors
(that are conform to the standards).

In particular, the most portable way to terminate a C program
unsuccessfully is to return EXIT_FAILURE, which has the value 1
under Unix. So, if the above is reverted, then this means that
unsuccessful termination of such portable programs will not be
detected!

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: [ANNOUNCE] mutt 1.5.16 released

[Vincent Lefevre]

On 2007-06-13 16:31:22 -0600, Kyle Wheeler wrote:
> Perhaps the thing to do is only pause and display a warning if there
> was anything printed to stderr?

No, a program may terminate unsuccessfully without outputting anything
to stderr. For instance, this is the case when one uses a wrapper sh
script with "set -e" and some command just fails.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)