Thank  you so much! Appreciated.

The lack of empathy for one user's needs is disturbing...
It is really a lack of templating in the system, just like the 
signature conversation. Let the user decide, and
provide proper methods to do so. Never sit on the user's chair...

just in case anybody is interested in this functionality in current 
horde (until we have full message printing), I have done a 
quick'n'dirty port of Jan Schneider's patch from 
https://github.com/horde/horde/commit/693252f6ecca3f49901313d066a3df74278a04b4

Is there any way to print the complete email in IMP 6?

Is there no way to add this future again?
We had sponsored the changes from Jan which now rejected. :-(

Making the executive decision to reject.  The proper way to implement 
is to allow printing of an entire e-mail.  But until someone codes a 
correct solution, the current print button is designed to print a 
single part. PERIOD.

news about this enhancement?

True.

I think there is consensus about this descision.
This question doesn't make sense to me. As you explained above we 
decided to print individual parts instead of the complete message for 
technical reasons. Thus the user doesn't even have a chance to print 
the complete message. Of course it would make more sense to only print 
the attachment list when printing the complete message, but that's not 
possible.

And to the original point: it's been requested by end users a few 
times, for whatever reasons. I don't print out emails at all, so I 
can't answer the question, but there seems to be a good reason for 
this. And to repeat myself: I don't see a huge difference to the basic 
headers that are *not* the headers of the MIME part either, but the 
headers of the complete message.
Who are we to decide whether this is worthless information or not? If 
it's your concern that some users might not want this information to 
be printed with the message (I know it's not the message, but that's 
how users receive it), we can make it a preference. Just like adding 
the Printed By: header is configurable too.

Printing all parts individually is a solution to printing complete 
messages (though a rather annoying one), but not to printing an 
attachment list.

PDF is interesting but a) requires a PDF reader to be installed, and 
b) doesn't work with HTML messages.

I agree only partially. Printing messages (as few as sense it may make 
sense to us personally) is not feature bloat, but an important feature 
of a mail client.
Cleaning up features and tacked-on functionality is great, and you've 
done an awesome job at this with IMP 5. I can wholeheartedly 
understand that you don't want stuffed "hacked" into it again.
I think this approach is too academic or technical, if you want to say 
so. It's correct, no question, but it's not how users are gonna see or 
use this feature. They want to print their message, they see the print 
icon (and in 95% of the message only one single icon), they click on 
it, and they complain to their administrators that the printout no 
longer contains the attachment list. *If* there are multiple parts and 
multiple print icons, they will figure out quickly that they have to 
print them individually. They will moan but work around it, like users 
always do. But they cannot get their freaking attachment list back.

I can't believe we spend so much time and energy on such a useless 
thing like printing messages. :-D I hope a single user is going to 
appreciate this.

Not to sound like a jerk - but I had originally rejected this.  You 
overruled that decision and committed this.  Reverting is entirely 
appropriate. We need to stay at the status quo - only until we decide 
whether we want should we add if necessary
I had a long discussion about this when we implemented the IFRAME HTML 
rendering.  It really comes down to this:

* You correctly render HTML parts.
vs.
* You can print the entire message.

At this point, you MUST choose one or the other.  In the past, HTML 
mails weren't as prevalent as they are today.  Not to mention are 
rendering code and filtering code weren't all that great.

But now, I would say that text/html has pretty much become the defacto 
standard.  So viewing is more important than printing.

Sometimes you have to make tough decisions.  Yes, it is a regression 
with respect to printing messages.  But it is a vast leap forward in 
the more common use case of viewing an HTML part.  So I stand by this 
decision.
But going back to my original point: why is this attachment list 
important?  How can it possibly be important to have an attachment 
list when you are only printing (and caring about) a single part?   
When I print the portion of the message that contains the map to 
Grandma's house, I don't care that she also attached pictures of the 
cats that are going to be there to greet me when I arrive.  This is 
worthless information, and cuts into the printable space available on 
that first page.
Possible solutions: print as PDF; popup print screens reload after 
every printable part to load the next printable part while calling 
window.print() on each one.

These are all arguments for the creation of a feature to allow 
printing of an entire message.  But NONE of these arguments are 
applicable to what we currently have available: printing of a single 
message part.

We can't be mixing UI elements/features just because we are lacking 
functionality.  I have spent a long time in IMP 5 to remove these kind 
of decisions we made in the past - feature bloat if you will.  Instead 
we need to focus on the UI as CURRENTLY implemented (not how we would 
LIKE it to be implemented).

As I have said multiple times in this ticket, having an attachment 
list doesn't make any sense when you look at what this UI element is 
intended to do: print a specific message part.  So this patch is not 
appropriate.

We actually had users that complained about not being able to print 
the attachment list like the old version provided.

Please don't simply revert while we're still discussing this. It's not 
like this breaks anything.

I don't buy your argument why we might include the basic headers but 
not the attachment list.
1) It's important, or at least useful, information about a message. 
Not printing those anymore is a regression from IMP 4.
2) It's unobtrusive and won't affect many messages (probably depends 
on how often you get messages with attachments. But then again, how 
often do you actually print messages?)

I understand the technical limitations that still keep us from 
printing all parts, and I don't have a smart solution for this. But 
limitations of browsers should not keep us from providing us better 
experience for the users. Actually the opposite, we need to provide 
users with alternative solutions if something is limiting them.

The crucial point is that currently the user is not able to print the 
whole message if it consists of multiple parts. But they don't care 
and will print messages anyway. In 95% (if not more) of the messages, 
there will be one single printable message part. Users don't care if 
they are looking at a multipart message. They are happy that their 
message will be printed (and without even knowing about that, that 
your worked around IFRAME printing browser bugs). They don't care that 
it's only one part of the message, because that's probably the only 
part they see inline anyway. Heck, the printout even has the message 
headers, they won't even notice. All that's missing is, gotcha, the 
attachments summary they had in their old version.

Reverted, and re-rejected.  As previously mentioned, this only makes 
sense if the ENTIRE message is being printed.

Changes have been made in Git for this ticket:

Revert "[jan] List attachments when printing messages (Request #10235)."
This reverts commit 693252f6ecca3f49901313d066a3df74278a04b4.

  3 files changed, 0 insertions(+), 14 deletions(-)
http://git.horde.org/horde-git/-/commit/2aa8698dcd2e286e9097bfd3ac029b9eb26bc6ff

The print button is not meant to produce a *summary* of the entire 
message.  That is not what it is currently designed to do.  As such, 
we shouldn't be including this kind of summary information when 
printing individual message parts.  Which is why this ticket was 
previously rejected.  Please revert.

Exactly.  But I decided to include because it might be useful to link 
a message part with who sent it/when it was sent/who it was sent to.   
There is a valid justification for the header.

I can't think of a valid reason why an attachment list would be useful 
for a single message part.  Example: it is irrelevant if there is an 
image attached to a message when printing a text/plain part.  How is 
that information useful?  (Answer: it isn't).

You could make the same arguments for not printing the message headers either.

I don't like this at all, for reasons besides just the above 
referenced tickets.  Namely: we are only printing message parts.  If I 
print ONLY part 10 of a 20 part message, I absolutely don't care about 
attachment information of the other 19 parts.  That is simply wasted 
space in my printout.

An attachment list only makes sense if we print the ENTIRE message.   
Since that is not yet possible, this is an inappropriate solution.

These are completely different issues. If we can inject message 
headers, we can inject attachment listings too.

Changes have been made in Git for this ticket:

[jan] List attachments when printing messages (Request #10235).

  3 files changed, 14 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/693252f6ecca3f49901313d066a3df74278a04b4

No.  See, e.g., Ticket #9475, Ticket #8708.

Email attachments (filename and size) should be visible on printed emails.