>> I'm trying to understand why you wouldn't want to show all text parts.
>> It seems like 90%+ of the emails I get have a text part (either plain or
>> HTML) as the first item, then non-text content afterwards.
>
>Where later parts are text, they are often intended as attachments: XML
>files, patc
Ken Hornstein wrote:
> Err ... that _would_ work with the proposed scheme, right? I mean, assuming
> you had a profile entry that used w3m to convert the HTML to text, this
> would continue to work. So I'm unclear why we need two mechanisms.
Yes, it continues to work. I should probably just thin
Hi Paul,
> [1] for some reason xv, my usual image viewer, is absolutely abysmal
> across a slow link. but i haven't found a viewer i like better.
You've xv(1) running remotely, displaying back locally over a slow link?
It's probably shipping the decompressed PNG or JPEG over the link to
the X se
On 07 Mar 2014, at 12:16, Lyndon Nerenberg wrote:
> On Mar 7, 2014, at 12:08 PM, Lyndon Nerenberg wrote:
>
>> Apple's mail client places images (and PDFs, and I suspect everything else)
>> inline
>
> Hmm ... I tell a lie. I see with 10.9.2 they silently turn it into
> text/html. Once upon
On March 7, 2014 12:54:38 PM PST, Ken Hornstein wrote:
>>This sort of rationalization leads to the argument that everything on
>>the internet should be converted to run over HTTP on port 80.
>
>You mean it doesn't?
>
>--Ken
>
>___
>Nmh-workers mailing li
>This sort of rationalization leads to the argument that everything on
>the internet should be converted to run over HTTP on port 80.
You mean it doesn't?
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listin
On Mar 7, 2014, at 12:30 PM, Ken Hornstein wrote:
> I mean, at some point you have to decide if
> your goal is to send RFC 2045-compliant messages, or be able to send and
> read email that the rest of the world can understand.
Why can't I do both?
If other people cannot see the utility of inli
>If other people are stupid, should I give myself a lobotomy? :-P
Is it a matter of being "stupid", or "not having the same vocabulary as
the rest of the world" ? I mean, at some point you have to decide if
your goal is to send RFC 2045-compliant messages, or be able to send and
read email that th
On Mar 7, 2014, at 12:21 PM, Ken Hornstein wrote:
> To paraphrase an old proverb ... If a standard is written but no one
> implements a feature, is it still worth supporting it?
If other people are stupid, should I give myself a lobotomy? :-P
signature.asc
Description: Message signed with Op
>Still, that's no excuse for nmh not to behave correctly. The MIME
>standards certainly support that mode of operation.
To paraphrase an old proverb ... If a standard is written but no one
implements a feature, is it still worth supporting it?
Okay, I hear you. To me that argues that my origina
On Mar 7, 2014, at 12:08 PM, Lyndon Nerenberg wrote:
> Apple's mail client places images (and PDFs, and I suspect everything else)
> inline
Hmm ... I tell a lie. I see with 10.9.2 they silently turn it into text/html.
Once upon a time that didn't happen (circa 10.6 or 10.7?).
I consider t
ken wrote:
> I'm fine with that, but I'm wondering if making it configurable and
> putting code to make a listing afterwards should be something post-1.6.
it seems to me that any sort of pre- or post- attachment listing could
be done out of band, using a wrapper around mhshow that invokes mhlist
On Mar 7, 2014, at 12:01 PM, Paul Fox wrote:
> from non-mh users, attachments are almost always at the end.
Apple's mail client places images (and PDFs, and I suspect everything else)
inline at the cursor location when you drag-n-drop them into the composition
window. (This when your prefere
>> I'm with you on that ... however, I'm wondering when was the last time
>> you got text interspersed with images in a MIME message?
>
>This morning. People I correspond with do this all the time.
Really? So you get email with:
Part 1: text/plain
Part 2: image/jpeg
Part 3: text/plain
Part 4: i
ken wrote:
> >And I have to disagree with this :-) When I receive a message with
> >inlined images interspersed with the text, having the markers at the
> >image's anchor point helps make the context *much* clearer when I
> >display the images.
>
> I'm with you on that ... however, I'm wonde
On Mar 7, 2014, at 11:54 AM, Ken Hornstein wrote:
> I'm with you on that ... however, I'm wondering when was the last time
> you got text interspersed with images in a MIME message?
This morning. People I correspond with do this all the time.
--lyndon
signature.asc
Description: Message si
>And I have to disagree with this :-) When I receive a message with
>inlined images interspersed with the text, having the markers at the
>image's anchor point helps make the context *much* clearer when I
>display the images.
I'm with you on that ... however, I'm wondering when was the last time
y
On Mar 7, 2014, at 2:39 AM, Oliver Kiddle wrote:
> I think a final summary of parts at the end is
> more useful than having the markers interspersed with text sections in
> the order they appeared.
And I have to disagree with this :-) When I receive a message with inlined
images interspersed
>> - Non-text entries will get a marker like:
>> [part 2.2 image/jpeg A cool new picture!]
>
>This is purely from the MIME details and not by reading the content's
>bytes at all? (Thinking of security issues with processing images,
>PDFs, etc., by default.)
I hadn't realy worked out the details
>It'd be useful to make it easier to have two mechanisms. HTML, I
>normally view through w3m. I even have pdftotext as the default for PDF
>but normally I view e-mail over remote ssh. So at home, I often do
>mhstore followed by firefox/zathura/evince/soffice/whatever instead of
>using mhshow.
Err
Hi Ken,
> - Non-text entries will get a marker like:
> [part 2.2 image/jpeg A cool new picture!]
This is purely from the MIME details and not by reading the content's
bytes at all? (Thinking of security issues with processing images,
PDFs, etc., by default.)
BTW Oliver, I specify content desc
Ken Hornstein wrote:
> In MH/nmh, each part was processed individually. Combining them all under
> one pager works great for text parts, but if you have graphical content
> then it sort of falls down, because you might want confirmation of that.
> But in my experience, usually you can divide your
So I took at look at why our mhshow performs so lousy on pretty much anything.
The basic reasons are:
- mhshow defaults to "-pause"
- The default display for text content is %p$PAGER (%p asks for confirmation
if -pause is set).
I looked at what meillo did; he got rid of pause support completely
23 matches
Mail list logo
