* Thomas Roessler [06-04-28 10:36:26 +0200] wrote:
On 2006-04-27 23:45:58 +0000, Rocco Rutte wrote:
This fixes an ugly speed issue over IMAP
Brendan, could you have a look at this one?
This not only affects IMAP. When using %X in $index_format, mutt counts
attachments according to user's configuration. After splitting up a
message into its MIME parts (which would normally only be done before
entering pager), mutt throws the parse tree away. When scrolling back to
a message, it does the same again.
Repeat: just configure attachment counting and hold <pgup> or <pgdown>.
There will be quite some disk load everytime doing up/down. With this
patch this only happens once.
For IMAP, the caching of bodies likely speeds this up drastically, but
it's not only limited to IMAP.
The only thing I'm not really sure about is the memory consumption,
This fixes support for IPv6 addresses in URLs
Something like this should go in, but it looks a bit ugly. I
think I'd like to review this patch a bit more before
committing. (Which may mean that you may have to re-ping me
before it happens.)
What I dislike about is the Pine-compatibility part, the change to
url.cpp looks okay to me. I don't know how other clients handle IPv6
addresses. With the generic URL parser we could ask users to encode
colons as %3A it doesn't look nice.
This removes HTML entities from the DocBook XML manual and stops
xsltproc printing tons of errors
Need to have a look at this one; I don't see the tons of errors
that you refer to.
I get exactly 1530 of the following errors:
manual.xml:129: parser error : Entity 'num' not defined
Visit channel <emphasis>#mutt</emphasis> on
manual.xml:462: parser error : Entity 'dollar' not defined
<link linkend="to-chars">$to_chars</link> variable.
$ xsltproc --version
Using libxml 20623, libxslt 10115 and libexslt 812
xsltproc was compiled against libxml 20623, libxslt 10115 and libexslt 812
libxslt 10115 was compiled against libxml 20623
libexslt 812 was compiled against libxml 20623
Besides these: pdmef+patch+ff.diff contains a replacement
for the current format=flowed handler which can really flow
lines and is more up-to-date.
This one, too, needs some more review -- in particular, I don't
believe in re-flowing lines just because there's some more
space on the screen.
Me too, but f=f was made to allow for adjusting the text to the local
display (preferences) and the patch does exactly that.