On Mon, Nov 17, 2008 at 03:37:00PM +0100, steve wrote:
> Sometimes people send their message with the following headers:
> From: "email-address"
> which isn't very nice in the index menu.
> I would like to re-write this line as following :
> From: "a chosen name"
> I tried a reply-hook in the con
On Mon, Nov 17, 2008 at 09:32:52PM -0800, Brendan Cully wrote:
> Seems fine. Does anyone object?
I think this makes sense. The user is already requesting that it be displaying
this way in the index, so it should
not be a problem to display it this way when replying.
me
On Tue, Nov 18, 2008 at 03:48:05PM -0500, David Haguenauer wrote:
> I was about to suggest making the To: change conditional on the value
> of a configuration variable, because reverse aliases may be used to
> reply to people who don't know how to spell their own name properly,
> and we may want to
On Mon, Nov 24, 2008 at 04:03:09PM -0500, Don Zickus wrote:
> Basically, I wanted to implement an idea that gmail uses. The one thing I
> liked about gmail is how threads 'bubble' up to the top as the continue to
> be active, leaving dead threads behind. My idea is to hack on to the
> 'sort' comm
On Mon, Nov 24, 2008 at 01:06:16PM -0800, Michael Elkins wrote:
> set sort=threads
> set sort=last-date
Err, that should be:
set sort=threads
set sort_aux=last-date
me
On Fri, Mar 12, 2010 at 05:59:07PM +0100, Louis-David Mitterrand wrote:
> In latest mutt the envelope date (From_) is updated when an attachement
> is deleted.
>
> This completely messes up date-received sorting.
>
> I'm using IMAP.
>
> Bug or feature?
In the IMAP case, Mutt has to upload a ne
On Sat, Mar 13, 2010 at 11:03:25AM +0100, Louis-David Mitterrand wrote:
> On Fri, Mar 12, 2010 at 11:41:29PM -0800, Michael Elkins wrote:
> > On Fri, Mar 12, 2010 at 05:59:07PM +0100, Louis-David Mitterrand wrote:
> > > In latest mutt the envelope date (From_) is updated w
On Sat, Mar 13, 2010 at 04:43:58PM +0100, Louis-David Mitterrand wrote:
> I don't see where a date-time is passed to APPEND.
This feature was added in June of last year, after the 1.5.20 release
(mutt-1-5-20-rel 5888:f399371bb9b0):
changeset: 5949:b2b97c7a2ae6
branch: HEAD
user:Bre
On Wed, Mar 24, 2010 at 12:42:27PM -0400, Paul Greenberg wrote:
> Please help integrate msfetch-send with mutt.
>
> right now I have .muttrc
> set sendmail="/path/to/esmtp -v -X /tmp/esmtp.log"
>
> but I want it to be
> set sendmail="/path/to/msfetch-send"
>
> Can you give me an idea of what ne
On Wed, Mar 24, 2010 at 01:15:15PM -0400, Paul Greenberg wrote:
> What if I want mutt on "y" (send) to send composed e-mail to my application?
Your choices are either to write a sendmail-compatible command line
interface I described in my previous message, or write a gateway daemon
that speaks SMT
[note: please send help requests to mutt-us...@mutt.org rather than the
development mailing list.]
On Mon, Mar 29, 2010 at 12:51:08PM -0400, Aaron Anderson wrote:
> #~t USER messages addressed to USER
>send-hook ~t 'helpd...@widener\.edu' 'my_hdr From: HelpDesk Support
> helpd...@widen
On Thu, Apr 01, 2010 at 05:31:54PM +0200, Simon Ruderich wrote:
> When browsing the manual I wasn't sure at first what editor
> means, so I thought maybe add a little description.
Thanks for the patch. I reworded it slightly and added the sgml
attributes to make it match the style. The wording t
On Thu, Apr 01, 2010 at 05:30:26PM +0200, Simon Ruderich wrote:
> This patch improves the description of $query_format to mention
> that no quotes shouldn't be used around %s.
I reworked that section to be more clear:
This specifies the command Mutt will use to make external address
On Thu, Apr 01, 2010 at 05:28:43PM +0200, Simon Ruderich wrote:
> This fixes some typos I found while browsing the source code.
Thanks for the patch. I applied most of it (comments below).
> /* If Sort is reverse and not threaded, the latest message is first.
> - * If Sort is threaded,
While reading this bug report http://dev.mutt.org/trac/ticket/3400 about
lack of documentation for the mailto: support, and reading the current
security warning about use of mailto:, I came to the conclusion that the
current method is insecure.
This patch adds two new commands:
mailto_all
On Sat, Apr 03, 2010 at 09:56:48PM +0200, Simon Ruderich wrote:
> I think this is a really good idea. You misspelled an end tag,
> this fixes it.
Grr, thanks. I actually did see that error but made the mistake of
fixing it in manual.xml instead of manual.xml.head.
Fixed patch attached.
me
diff
On Sat, Apr 03, 2010 at 09:36:44PM -0400, Thomas Dickey wrote:
> On Sun, 4 Apr 2010, Mutt wrote:
> >The problem is that the ncurses library doesn't have a keycode for
> >ctrl+ or ctrl+. Instead you get a multibyte escape sequence.
>
> That's an extension (mutt could in principle ask ncurses for t
On Sun, Apr 04, 2010 at 06:09:21AM -0400, Thomas Dickey wrote:
> An application can use these by a tigetstr to check existence, e.g.,
>
> char *s;
>
> s = tigetstr("kDC6");
> if (s != 0 && (long)(s) != -1) {
> /* use the value */
> }
>
> ncurses decides that
This patch allows the user to bind to some additional keys if supported
by the terminal. The new sequences take the form of:
where "key" is one of Up, Down, Left, Right, Prev, Next, Home, End.
S=Shift
A=Alt
C=Control
Note that at least
On Tue, Apr 06, 2010 at 06:22:22PM +0200, Moritz Barsnick wrote:
> > to use ":exec what-key" to find out the octal code for a particular
>
> Hey cool.
>
> could someone _please_ tell me and document(!) how to exit the
> "what-key" function? This is probably the first time in years I've had
> to a
[ note: please send requests for help to mutt-us...@mutt.org ]
On Tue, Apr 06, 2010 at 12:45:18PM -0400, J Aaron Anderson wrote:
> I am using Mutt 1.4.2.2i (2006-07-14)
> Im trying to BCC to email addresses when a email is generated by CRON
>
> My structured line to send thru mutt is :
>
> mutt
On Sun, Apr 04, 2010 at 11:47:05AM -0700, Michael Elkins wrote:
> Note that at least under Ubuntu 9.10, the terminfo entry for xterm-new
> doesn't seem to include definition for the Shift-ed versions, so they
> end up showing as some high numbered function key.
Updated patch to fi
Greetings,
After reading more about http://notmuchmail.org I got inspired to figure
out how to use a full text search engine with Mutt. I wrote a patch
which allows the use of a new pattern match, "~q STR" which allows the
user to query external search engines in addition to using the stock
patte
10-03-22) in a gnome-terminal with:
COLORTERM=gnome-terminal
TERM=rxvt
in the environment.
The attached patch fixes the problem. I've committed this to tip.
me
changeset: 6077:77f7300ed3cc
branch: HEAD
tag: tip
user:Michael Elkins
date:Sun Apr 11 18:30:13 2010
On Mon, Apr 12, 2010 at 01:27:42PM +0200, Vincent Lefevre wrote:
In pgp_send_menu() from pgp.c, one has:
case 5: /* (f)orget it */
case 6: /* (c)lear */
msg->security = 0;
break;
Shouldn't (f)orget be removed as it isn't displayed?
This may confuse the user if he types on "f" by mis
On Mon, Apr 12, 2010 at 11:57:38AM -0500, Will Fiveash wrote:
Thanks Michael, that did take care of the problem I described however
while testing that new version of mutt I saw another similar issue.
Here's what I did:
1. type 'm' to start creating a new message.
2. the "Recall postponed message
On Mon, Apr 12, 2010 at 12:19:21PM -0500, David Champion wrote:
By the way, as long as we're discussing cosmetic changes in this area:
ever since this was changed I've been rather thrown off that the PGP
prompt changes to a Security prompt when I forget (clear) it.
Do you have any suggestions f
I have this really strange drawing bug that I can't figure out. This only
happens in gnome-terminal with TERM=xterm or TERM=xterm-new. If I use
TERM=xterm-color the problem goes away. xterm and rxvt-unicode don't exhibit
this problem, either.
Consider the following muttrc:
color normal def
On Mon, Apr 12, 2010 at 04:34:21PM -0700, Michael Elkins wrote:
set index_format='%s%* test'
this index_format always triggers the problem:
set index_format='x%* x'
me
pgpqGijh0R8Ad.pgp
Description: PGP signature
On Mon, Apr 12, 2010 at 03:20:02PM -0500, David Champion wrote:
Improve clarity/uniformity in compose menu's crypto display
I think this looks pretty good. My only concern is that by placing the format
last, it somewhat de-emphasizes PGP/MIME vs S/MIME. But I can't really think
of a present
On Tue, Apr 13, 2010 at 09:48:12AM +0200, Vincent Lefevre wrote:
On 2010-04-12 06:28:17 -0700, Michael Elkins wrote:
On Mon, Apr 12, 2010 at 01:27:42PM +0200, Vincent Lefevre wrote:
The reason for the change was that the original prompt was unclear
to a user. This user thought that 'i&#
pgp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1271193796 25200
# Branch HEAD
# Node ID ae9a02db6ac64c6b2ce1874fa77fa5baed5676c2
# Parent 4d798ee2898ef5b059d05a331c01175c7556e657
remove toggle and replace with format in pgp
Is there a compelling reason not to change the configure script to enable
support for these standard Internet protocols by default?
me
pgpqr52euTbp7.pgp
Description: PGP signature
On Wed, Apr 14, 2010 at 03:55:26PM +0200, Christian Ebert wrote:
* Michael Elkins on Wednesday, April 14, 2010 at 05:56:41 -0700
Is there a compelling reason not to change the configure script to
enable support for these standard Internet protocols by default?
As long as I can still disable
send.c | 141 ++--
1 files changed, 74 insertions(+), 67 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1271256016 25200
# Branch HEAD
# Node ID 407f5ba3f6dd1a3adfe6d2ee2ea86e180e9d2ea6
# Parent
I was just curious how much code there was in Mutt. I broke it into three
parts: core, network (imap/pop/smtp/ssl/sasl), and security
(pgp/smime/remailer), in number of lines according to 'wc -l':
core 65512
network 12798
security 15131
me
pgps7KeAhdVZL.pgp
Description: PGP signature
On Wed, Apr 14, 2010 at 10:27:53AM -0700, Brendan Cully wrote:
On Monday, 12 April 2010 at 15:20, David Champion wrote:
Improve clarity/uniformity in compose menu's crypto display
...
-addstr (_("Clear"));
+addstr (_("None -- press (p)GP or (S)/MIME"));
I like most of this patch, but
On Wed, Apr 14, 2010 at 12:32:31PM -0500, Will Fiveash wrote:
Stability of the configure interfaces. In addition, will changing the
defaults increase the likelihood that either configure or the build will
fail because this introduces new default dependencies on code (libs)
that are external to t
On Wed, Apr 14, 2010 at 12:32:31PM -0500, Will Fiveash wrote:
Stability of the configure interfaces. In addition, will changing the
I forgot to mention that changing defaults in a configure script does not
in any way change the interface to the script. The --enable- and
--disable- options w
On Wed, Apr 14, 2010 at 01:17:03PM -0500, David Champion wrote:
# HG changeset patch
# User David Champion
# Date 1271103184 18000
# Branch HEAD
# Node ID 41a46373ddd9f9178ac9bb18ff42354b8b40b3fb
# Parent 4d798ee2898ef5b059d05a331c01175c7556e657
Improve clarity/uniformity in compose menu's cryp
browser.c | 22 ++
1 files changed, 18 insertions(+), 4 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1271451518 25200
# Branch HEAD
# Node ID 46adbc7b88618dbe909ddb053a02b3abbfd6ae48
# Parent 15b9d6f3284f78139abefe74c2607fa2d338641b
add %D format string
keymap.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1271959872 25200
# Branch HEAD
# Node ID 611ac36d7c18e1fb92723b57b72938f8d9cc694c
# Parent 6ebdfd09abc138766d06b2af0311f5667fb9795c
allow octal codes with
send.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1274197518 25200
# Branch HEAD
# Node ID 9e6f1e443433ab67a458376e240fd031603d2f7f
# Parent 4cd2daafd03bfe9d8af1fa543baf873cd94e144f
The problem was that the smtp code could
recvcmd.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
# HG changeset patch
# User Michael Elkins
# Date 1274807689 25200
# Branch HEAD
# Node ID 4d306b8e4f97738744a1fe6df7193475f7c47dc2
# Parent 29e37994a536a54e75539c5616fe4110198bfed8
fix problem with reply-hook not working
On Tue, Jun 15, 2010 at 02:05:17PM +0200, Christoph Berg wrote:
Debian is piling up quite a bit of bugfixe patches in its 1.5.20
package, and it is increasingly harder to keep track of which bug is
fixed where. A new 1.5.21 release would help to get a consistent code
base.
Is there a chance of a
t, although at least under Ubuntu 8.04.04 it
harmlessly adds -lgpg-error twice.
me
[1] https://bugzilla.redhat.com/show_bug.cgi?id=621626
# HG changeset patch
# User Michael Elkins
# Date 1281038117 25200
# Branch HEAD
# Node ID d9af6aad75aa33329637ef28e1249
On Fri, Aug 06, 2010 at 09:58:41AM +0200, Matthias Andree wrote:
Unbreak X.509 SubjAltName checks,
regression in 6016:dc09812e63a3 that calls strlen on an SSL sk rather than
its string payload.
Thanks, applied. I made a small change to add a (char*) cast to squash the
compiler warning.
me
On Fri, Aug 06, 2010 at 02:34:35PM -0500, Will Fiveash wrote:
browser.c:168: error: `true' undeclared (first use in this function)
browser.c:168: error: (Each undeclared identifier is reported only once
browser.c:168: error: for each function it appears in.)
browser.c:174: error: `false' undeclar
On Fri, Aug 06, 2010 at 09:41:38PM +0200, Matthias Andree wrote:
Drop declaration for unused argv/argc parameters.
Fixes GCC warning with -Wextra.
applied, thanks.
me
pgppjLgnHz46B.pgp
Description: PGP signature
Alternate version of this patch to ensure the cast is safe.
# HG changeset patch
# User Michael Elkins
# Date 1281159058 25200
# Branch HEAD
# Node ID e1aa54051b30b4e733909608fd15aa269ab2c50a
# Parent 5b15d4d9627795c4ff95bf872049bd3be6078e6a
[mq]: mutt_ssl_sign_compare
diff -r 5b15d4d96277 -r
Alternate version with addition check to make sure cast is safe.
# HG changeset patch
# User Matthias Andree
# Date 1281124373 -7200
# Branch HEAD
# Node ID f6590ddfaf4f1317b85345156a62397f1b530213
# Parent 12ffab6683cd85ed8407683ef377f20798d126b4
Fix comparison signedness warnings.
diff -r 12
On Fri, Aug 06, 2010 at 11:49:24PM +0200, Vincent Lefevre wrote:
On 2010-08-06 23:33:29 +0200, Matthias Andree wrote:
-if (chunk >= sizeof (buf))
+if ((size_t)chunk >= sizeof (buf))
I would say that a signedness warning would be here a compiler bug
since with a simple variable range an
applied, thanks.
me
pgp93Fn7nddA5.pgp
Description: PGP signature
applied, thanks.
me
pgpW4uovEOilH.pgp
Description: PGP signature
applied, thanks.
me
pgpCodiGBIuQX.pgp
Description: PGP signature
applied, thanks.
me
pgpYv78Jiy4L6.pgp
Description: PGP signature
applied, thanks.
me
pgpW4Dcm9y897.pgp
Description: PGP signature
applied, thanks.
me
pgpeCkuWOUfyZ.pgp
Description: PGP signature
applied, thanks.
me
pgpiaHEO02Pix.pgp
Description: PGP signature
On Sat, Aug 07, 2010 at 10:04:01AM +0200, Matthias Andree wrote:
Because of the deduction, I cast without adding a check, but you have
a valid point. Note there is a "if (chunk < 0)" check above.
...
So what do we do? Drop this patch? Keep it? Add a comment before line
501? Add an assertion b
On Sat, Aug 07, 2010 at 10:10:16AM +0200, Matthias Andree wrote:
Am 07.08.2010, 07:46 Uhr, schrieb Michael Elkins:
Alternate version with addition check to make sure cast is safe.
-if (!first && pos + strlen (path) >= COLS - 7)
+if (!first && (COLS - 7 >= 0)
On Sat, Aug 07, 2010 at 07:30:49AM -0400, Thomas Dickey wrote:
On Sat, 7 Aug 2010, Matthias Andree wrote:
still mentioning "-2009" for Brendan Cully and Michael Elkins,
among others. These may warrant updating :-)
possibly (was the file changed in 2010?).
As a rule, ex
On Mon, Aug 09, 2010 at 06:09:07PM +0200, Vincent Lefevre wrote:
Now I wonder whether all the headers should be taken into account
(at least by default). This may have security implications. First,
user-defined headers should probably be disabled by changing the 1
into a 0.
yes, see my previous
On Sat, Apr 03, 2010 at 11:39:01AM -0700, Michael Elkins wrote:
While reading this bug report http://dev.mutt.org/trac/ticket/3400 about
lack of documentation for the mailto: support, and reading the current
security warning about use of mailto:, I came to the conclusion that the
current method
* yellow background color which extends to the right margin will contain the
* extra spaces when copying. This is what Mutt is currently doing.
*
* [1] $TERM is screen, xterm-color, or iTerm under OSX are known problems
*
* Author: Michael Elkins
* Date: 2010-08-09
*/
#include
#ifdef
Bumping this message since I was asked about it on IRC.
For the original message, see http://marc.info/?l=mutt-dev&m=127125613617665
me
On Wed, Apr 14, 2010 at 07:41:34AM -0700, Michael Elkins wrote:
Allow setting message security in send2-hook
This patch delays checking the message secu
On Fri, Aug 13, 2010 at 01:12:59AM +0200, Michael Hanselmann wrote:
This patch tries to detect such cases and logs them to the debug log
(similar to a content-length check for mbox files).
+if (h->content->length > 0 &&
+ (h->content->offset + h->content->length) != st.st_size)
+
On Fri, Aug 13, 2010 at 01:49:06AM +0200, Michael Hanselmann wrote:
I think this whole block can be reduced to always setting
h->content->length. All the necessary information is there, and I don't see
any other place where it is adjusted.
You're right. I'll send another patch tomorrow.
I'll
On Thu, Aug 12, 2010 at 04:35:15PM -0700, Michael Elkins wrote:
It is curious how the corruption happened, however. It appears
something damaged the cache itself.
Thinking about this some more after looking at the code, this bug can occur
when the user edits the message after the header has
On Thu, Aug 12, 2010 at 08:36:57PM -0300, Rodrigo Campos wrote:
Well, I'm unsubscribing. If someone has any comments/interest on the patch,
please add me on CC.
Rodrigo,
You may always wish to upload your patch to the bug tracker on dev.mutt.org
and mark it as "enhancement" so that other peop
# HG changeset patch
# User michael.elk...@cobham.com
# Date 1281724591 25200
# Branch HEAD
# Node ID a0d6b775f42a1f4f43b416a7137cb3da6f1f7214
# Parent 6572e8bcd723a34d9457650fe272ff9633033ccf
add support for SSL/TLS-layer compression
diff --git a/init.h b/init.h
--- a/init.h
+++ b/init.h
@@ -29
I noticed that Gmail supports RFC4978, so I took a crack at implementing it.
It seems to work pretty well, as the compressor stats report that both sending
and receiving are compressed to about ~30% of the original size.
Consider this experimental, as it is lightly tested.
To use it, you need
Updated revision of this patch.
me
# HG changeset patch
# User Michael Elkins
# Date 1281743318 25200
# Branch HEAD
# Node ID bb4cc78c5f0e68d92e7bd33772b4893564b5b55b
# Parent 8051fc8b631c2c07e91635907ff488223d677045
add support for SSL/TLS-layer compression
diff --git a/init.h b/init.h
--- a
On Wed, Aug 18, 2010 at 01:33:17PM +0200, Joost Kremers wrote:
I use Mutt to access my mail account with fastmail.fm over IMAP. A few weeks ago
I started getting the message "Mailbox was externally modified. Flags may be
wrong" every time I change to a different mailbox on the server. This messag
On Wed, Aug 18, 2010 at 05:30:07PM +0200, Joost Kremers wrote:
http://wwwuser.gwdg.de/~jkremer/muttdebug.txt
The warning appears twice in the output, searching for "externally modified"
finds it.
The IMAP server is violating RFC3501 for the CLOSE command by sending EXPUNGE
reponses for \Delet
Was there ever any consensus on the trash folder patch. Some mutt-users were
asking about it, and I note that Debian has been including it in their package
for quite some time.
me
pgpPlitShfYvz.pgp
Description: PGP signature
On Thu, Sep 02, 2010 at 07:20:18PM -0400, Ed Blackman wrote:
Does mutt rely on the fact that encoded-text shouldn't have "?" or
SPACE because it makes the implementation easier? Or is it just
following the RFC strictly? Reading the RFC, it's not clear to me
*why* encoded-text can't have "?" o
On Mon, Sep 06, 2010 at 10:27:24PM -0400, Ed Blackman wrote:
I've been running all weekend with this patch. It works for both
unencoded "?" and SPACE characters in RFC2047 header lines. I
searched my mail corpus for RFC2047 encoded headers (both strictly
conformant and non-conformant), and co
On Sun, Sep 12, 2010 at 07:29:17AM +0200, Remco Rijnders wrote:
While trying to resolve my struggle with adding a S/MIME key to my account
(see post on mutt-users) and by manually tinkering with files, I got mutt
to segfault repeatedly.
The attached (tiny) patch should prevent this from happenin
t does not that whatever is on your index_format into account
when limiting the index.
Might there be an other way of doing it?
No, but it was straightforward to add this feature. Try the attached patch.
It adds a ~Z pattern and you can use it with a range.
me
# HG changeset patch
# User Mich
On Tue, Sep 14, 2010 at 07:23:34AM +0200, Oivvio Polite wrote:
Man, that's service and devotion! What version of Mutt do I patch
against? And are you putting this in the mainline so that it will
eventually trickle down to my distribution?
I wrote the patch against hg tip, but my guess is that i
this should be fixed in hg tip, which is why i closed the bug. you want the
behavior that is now default ($mail_check_recent is set).
On Fri, Sep 17, 2010 at 01:46:41AM +0200, Christian Ebert wrote:
I have the new mail_check_recent variable set to yes. It works,
except for my spoolfile which is compiled in:
./configure --with-homespool=Maildir ...
At least I guess it's because of this. It would be nice to have
this working on
On Fri, Sep 17, 2010 at 02:01:17PM +0200, Christian Ebert wrote:
$ mutt -Q spoolfile mbox_type
spoolfile="~/Maildir"
mbox_type=Maildir
$ stat ~/Maildir/new
234881026 1168278 drwx-- 2 chris chris 0 68 "Sep 17 12:02:50 2010" "Sep 17 01:41:20 2010"
"Sep 17 01:41:20 2010" "Nov 17 13:45:43 2008"
On Fri, Sep 17, 2010 at 04:43:38PM +0200, Christian Ebert wrote:
The behaviour for my spoolfile is exactly as if I had the default
setting:
mail_check_recent=no
i.e. new mail is detected once, but not after I visited the spool
and left the message(s) unread.
If you want to be notified about n
On Fri, Sep 17, 2010 at 05:47:16PM -0700, Mun wrote:
I just got 1.5.21 compiled on my Red Hat Enterprise Linux 5.5 system and
noticed that the behavior of auto_view has changed (for me). In my
.mailcap, I have two text/html entries. The first is to launch my
browser (via Gary Johnson's old "bro
On Mon, Sep 20, 2010 at 06:07:59PM -0400, Thomas Dickey wrote:
It's lost by cursor-movement optimization (in ncurses, curses or slang).
xterm sets the line-wrap flag when text is written automatically
wrapping on the right margin. Optimization may notice that it's
faster to jump to the next l
On Fri, Sep 24, 2010 at 08:57:27PM -0400, Thomas Dickey wrote:
no - using addch has no effect. curses collects all of that
information and writes out the changes to the screen when "refresh"
is called (which is also a side-effect of calling getch).
Attached is a test case that prints a long s
Brendan told me I am stepping into a minefield, but I have just pushed some
changes to Mutt's format=flowed handling. A poster on mutt-users noted that
his format=flowed messages were being wrapped at 77 chars despite the width of
his terminal. It seems that previously, when $wrap is 0, Mutt h
On Fri, Sep 24, 2010 at 03:39:13PM +0400, Roman Kagan wrote:
# HG changeset patch
# User Roman Kagan
# Date 1285320318 -14400
# Node ID 01731fb1884ea0e1eaf9008ea9c70804b66f2363
# Parent f467353f5657d9504dc5924fefc804fadc586f57
crypt-gpgme: don't use gpg_* directly
Since mutt uses gpgme, it sho
On Tue, Oct 05, 2010 at 10:34:42PM -0700, Morris, Patrick wrote:
On 10/5/2010 9:54 PM, Ed Blackman wrote:
Ah! I didn't know that. And indeed, they aren't 040 spaces:
000 123 165 172 151 145 054 012 240 012 124 150 151 163 040 145 155
S u z i e , nl sp nl T h i
On Wed, Oct 06, 2010 at 05:18:03PM +0200, Stefan `Sec` Zehl wrote:
I found an annoying bug in mutts attachment handling which took me 2
days to debug.
Whenever you attach a file of content-type "application/pgp", mutt
re-encodes every 0x0a in the file into 0x0d 0x0a before base64-encoding
and se
On Wed, Oct 06, 2010 at 09:28:16AM -0700, Michael Elkins wrote:
On Wed, Oct 06, 2010 at 05:18:03PM +0200, Stefan `Sec` Zehl wrote:
I found an annoying bug in mutts attachment handling which took me 2
days to debug.
Whenever you attach a file of content-type "application/pgp", mutt
On Wed, Oct 06, 2010 at 09:49:28AM -0700, Michael Elkins wrote:
Actually, this is not quite right. Mutt is making the assumption that
all application/pgp parts are ASCII armored, because Mutt doesn't send
binary PGP messages. Thus, Mutt is performing automatic line-ending
canonicaliz
On Mon, Oct 11, 2010 at 06:22:43PM +0200, Ralf Wildenhues wrote:
here's a tiny patch to fix a minor logic error in thread.c, and a dead
code line.
Applied, thank you. Fortunately "a" and "b" are either both NULL or set.
Your patch will at least make Mutt sort wrong instead of crash in case a
Please pardon me for spamming the lists, but if any of you will be in the Los
Angeles area at the end of next month to attend the Southern California Linux
Expo, please drop me an email. Last year I met quite a few diehard Mutt
users, and I think it would be fun to have an informal beer BOF thi
On Fri, Apr 15, 2011 at 03:18:52PM +0200, Honza Horak wrote:
I'm registered in mutt's trac and subscribed to mailing-lists, but not
sure if it's possible or even desired to commit my patches back to
repository.
write access to the repository is limited to a few trusted individuals,
for the obv
On Sun, Jan 29, 2012 at 01:28:33AM -0700, Todd Hoffmann wrote:
It seems like it would be easiest to just put the labels in the x-label
field. I started digging into the mutt code to implement this and
encountered some issues. The patch I've included does make the labels
appear in the message inde
On Fri, Nov 30, 2012 at 07:00:02AM +, Christian Ebert wrote:
* Andras Salamon on Friday, November 30, 2012 at 02:50:16 +
A message consisting of the single line
test
(with one space at the start of the line) will become
test
when postponed.
test
I cannot reproduce this with current H
set from="undisclosed sender:;"
I get:
From: Michael Elkins :
Which is obviously wrong. However, the proposed standard says
user agents SHOULD NOT allow the use of groups except when
"necesary" (presumably in the context of EAI)
[http://tools.ietf.org/html/draft
1 - 100 of 217 matches
Mail list logo
