Richard Russon [Thu, 18 Aug 2016 16:31:23 +0000 (17:31 +0100)]
merge: bug-neomutt
* add strndup.c strnlen.c
* More careful file writing for aliases and attachments
* Bye srandom() and random()
* Don't whine if getrandom() fails.
* Remove TLS version notification
* Use unlocked libc IO everywhere.
* debian: hurd build fix
* quieten two compiler warnings
* build tweak to allow testing
* separate key bindings for <return> and <enter>
* Add browser sort by description, message count and new message count
David Sterba [Thu, 24 May 2012 13:34:53 +0000 (15:34 +0200)]
feature: limit-current-thread
Add command to limit view on the thread from any of its message.
Predefined on command <ESC>L, though the lowercase 'l' would be better
(less keystrokes), but it's already occupied by a not-so-useful command
"show limit".
Tested on large folders, no performance problems observed.
Mike Frysinger [Tue, 31 May 2016 20:17:41 +0000 (21:17 +0100)]
separate key bindings for <return> and <enter>
Split up <enter> (ctrl+j) and <return> (ctrl+m) into different bindings so
people can map them differently. The default behavior is unchanged as we
map them both to the same function.
David Wilson [Tue, 22 Oct 2013 18:34:57 +0000 (11:34 -0700)]
Use unlocked libc IO everywhere.
Since mutt does not use threads, there is no reason it should use the
locked variants of the FILE* IO functions. This checks if the unlocked
functions are available, and if so enables them globally via mutt.h.
Cuts load time for a 56k message, 1.8GB /var/mail mailbox from 14
seconds to ~6 seconds, since we avoid acquiring and releasing a mutex
for every character of input read.
Adam Borowski [Sun, 7 Aug 2016 03:48:14 +0000 (05:48 +0200)]
Don't whine if getrandom() fails.
Debian for example supports kernels down to 3.2, and getrandom() appeared
only on 3.16 on x86 or later on other archs. Current stable has only 3.16
(ie, no getrandom() outside of x86), and ARM vendor kernels are for most
machines even older.
There is no security risk in falling back to /dev/urandom, as mutt quits
if that fails instead of using unsecure randomness.
This is a fix to commit "Bye srandom() and random()"
Sami Farin [Wed, 16 Oct 2013 18:34:57 +0000 (11:34 -0700)]
Bye srandom() and random()
Prefer getrandom on Linux, use /dev/urandom otherwise to
get entropy for MIME boundaries, message-id, Maildir filename,
temporary filename. Using MUTT_RANDTAG_LEN (currently 16) base32
characters for boundaries and message-id.
Sami Farin [Wed, 16 Oct 2013 18:34:57 +0000 (11:34 -0700)]
More careful file writing for aliases and attachments
Use fsync and check for errors when appending to alias file,
saving attachments, and bouncing a message. Still more checks are needed.
Also preserve errno if safe_fsync_close fails.
Kevin McCarthy [Mon, 8 Aug 2016 20:13:30 +0000 (13:13 -0700)]
Clear pager position upon returning to the index menu.
This fixes a bug where opening a message sometimes shows it scrolled
down.
The easiest way to trigger this is to open a long message in a mailbox
with no new messages, scroll down, hit <next-new-then-unread> and then
reopen the message. The pager will "remember" the position and scroll
down. If you simply exit the message and re-enter it, the position is
not saved.
More annoyingly, once in a very great while I will open a new message
and have the message scrolled down partway. I believe this is due to
OldHdr happening to point to the same address as the Header of the new
message.
This is somewhat easily triggered on a mailbox with one message, which
you open, scroll down in, hit <next-new-then-unread> to exit, and then
delete/sync. In another mutt instance, copy the same messsage back to
the mailbox, then open the message in the original mutt instance. At
least some of the time, the OldHdr pointer matches the new message,
and so it opens scrolled down.
This patch solves the problem by clearing the pager position once all
redirections through the index menu are done.
Kevin McCarthy [Fri, 5 Aug 2016 21:33:39 +0000 (14:33 -0700)]
Remove nonsensical size check in mutt_choose_charset()
The charsets parameter is being tokenized by the : delimeter.
The checks against ENCWORD_LEN_MAX and ENCWORD_LEN_MIN make no sense,
and appear to be the result of a large merge a very long time ago
(changeset cb27682966d5).
I can only guess where this check was supposed to be, but it certainly
doesn't belong here.