Re: Improving attachment viewing
On 20 Nov, Jon Steinhart wrote: Disagreement is good. I do it too! If I get a message with 20 photos attached, I hate having to hit Ctrl-C 20 times just to get to the next message. And I also have problems with multiple text parts since the way things get exec'd I haven't found a reasonable way to pipe the whole pile through a pager; short body parts that come before long ones scroll off the top of the screen. I do that with: showmimeproc: pagelast mhshow: -nopause in .mh_profile and the pagelast script does: mhshow $@|less But I don't have it display attachments like photos automatically: my actual pagelast script displays just the text parts and also does an mhlist. I quite like your next redefinition idea provided an option to next can specify whether or not to select attachments or skip to the next message. Would be good if it could even cope with attachments in message/rfc822 attachments. What bothers me more about mime handling is the lack of formatting of messages before quoting the message in a reply. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: Improving attachment viewing
So to summarize thus far, the MH-E needs of nmh are: - A boolean function for mh-format which is true if attachments are present (say, called attach). - Content-Disposition support (inline, attachment, filename). - Better PGP/MIME (RFC 3056) composition (perhaps this *can* be accomplished with the the #begin directive, although it would definitely be tedious to do manually.) S/MIME? -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Improving attachment viewing
Where we're had to move away from nmh towards gnus is in MIME composition (e.g. for the ability to specify inline/attachment). You might want to look at the attachment stuff that I checked in a while back. I implemented it in such a way that it could easily be incorporated into MH-E. The short summary is that you can specify the names of attachments using a header field, and send handles invoking mhbuild as required to package everything up before sending. Anno has been extended to assist in managing the header fields. It might be nice to be able to output a character in a scan column if attachments are present. MH-E could even replace that character with a paperclip glyph or something to pretty it up. Seems to me that my notion of scanning attachments is getting the most attention here, even though it's not the most important part to me. My main interest is in being able to read attachments in a more consistent way. Maybe an example would help... Right now, a session looks like this: % inc scan output % show (oh, this looks like a multipart message) % mhlist % mhshow -part 1 % mhshow -part 1.1 % mhshow -part 2 (...) % next ... What I'd like to be able to do is: % inc scan output % show % next (show first part of current message) % next (show next part of current message) % next (...) % next (show first part of next message) Jon
Re: Improving attachment viewing
Jon Steinhart [EMAIL PROTECTED] wrote: Where we're had to move away from nmh towards gnus is in MIME composition (e.g. for the ability to specify inline/attachment). You might want to look at the attachment stuff that I checked in a while back. I implemented it in such a way that it could easily be incorporated into MH-E. Great, Thanks. It might be nice to be able to output a character in a scan column if attachments are present. MH-E could even replace that character with a paperclip glyph or something to pretty it up. Seems to me that my notion of scanning attachments is getting the most attention here, even though it's not the most important part to me. Sorry, I know. I was really only commenting on the MH-E implications. We could use a MIME attachment marker in scan output, but we won't be using any nmh method to display message parts since we do that part in elisp. So go ahaed and add features in order to better display MIME parts from the shell (that's great!), but we won't need nor use them in MH-E. -- Peter S. Galbraith, MH-E developer [EMAIL PROTECTED] GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: Improving attachment viewing
In message [EMAIL PROTECTED], Jon Steinhart writes: Seems to me that my notion of scanning attachments is getting the most attention here, even though it's not the most important part to me. My main interest is in being able to read attachments in a more consistent way. Maybe an example would help... Right now, a session looks like this: % inc scan output % show (oh, this looks like a multipart message) % mhlist % mhshow -part 1 % mhshow -part 1.1 % mhshow -part 2 (...) % next ... What I'd like to be able to do is: % inc scan output % show % next (show first part of current message) % next (show next part of current message) % next (...) % next (show first part of next message) Hmm. I'm afraid I disagree about this redefinition of next. Currently, I don't need to do individual mhshows if I just want to sequence through all the parts: just show, and keep hitting Return, or Ctrl-C to skip a part. Cheers, Dave -- David Chin d w c h i n a t u m i c h d o t e d u We are all in the gutter, but some of us are looking at the stars.--Wilde http://www.fair.org/extra/0210/inspectors.html This is not the last line of my sig. Del^2 Phi == 0 :)
Re: Improving attachment viewing
Jon Steinhart wrote: If I get a message with 20 photos attached, I hate having to hit Ctrl-C 20 times just to get to the next message. I'm not disagreeing with you ;-), Jon... the interface *is* klunky. But, FWIW, Ctrl-\ will abort showing the current message. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Improving attachment viewing
I've changed the Subject and included [EMAIL PROTECTED] since we've spent the last year improving MIME handling in Gnus since raw MH wouldn't work for us. We should be able to provide some suggestions which would allow us to use more MH and less Gnus. Peter? Satyaki? Jon Steinhart [EMAIL PROTECTED] wrote: My interest in m_getfld is because I'd like to experiment with the way that attachments are shown. It'd be interesting to get a bit of discussion on this. Basically, I don't like the way that message parts are treated differently than messages. To me, there's little difference between receiving a message with two attachments and three messages. I'd like to see an indented scan that shows something like 5785+ 11/19 Eric Gillespie Re: The continuing install-mh sagaJon Steinhar .1 image/jpeg .2 image/jpeg ant then be able to do show/next/prev on stuff. I find it really annoying to have all body parts displayed in a single batch, especially those that involve some interaction to get rid of, like closing an image viewer. This might be an intriguing option to some, but it should not be the default. I wouldn't enable it. There is too much crap out there that would pollute the scan listing and make it awkward to read mail quickly. I can safely say that I do not view the majority of attachments I receive and considering them as separate messages would simply add the to (often oppressive) pile of mail. Consider all the midi and html attachments in spam, and winmail.dat attachments, and vCards, and multipart/encrypted which you would want to present as a single message rather than the pieces. To name just a few. You'll be sure to generate some good ideas though. Capture them in a Feature Request at Savannah. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Improving attachment viewing
I've changed the Subject and included [EMAIL PROTECTED] since we've spent the last year improving MIME handling in Gnus since raw MH wouldn't work for us. We should be able to provide some suggestions which would allow us to use more MH and less Gnus. Peter? Satyaki? Yeah, should have changed the subject myself. What I have in mind is twofold. First, I'd like to be able to optionally scan with message parts listed. Second, I'd like to be able to have an option to show/next/prev that says show the cur/next/prev message part. If the next/prev message part doesn't exist, then it should show the first/last part of the next/prev message. In other words, I just want to be able to read using a consistent interface, and the existing next/prev would let me skip attachments if I didn't want to see them. Also, I'd like to be able to show message.part file rather than have to do the clunky mhstore thing. Jon
Re: Improving attachment viewing
On Tue, Nov 19, 2002 at 08:42:42PM -0800, Bill Wohler wrote: This might be an intriguing option to some, but it should not be the default. Agreed. I'd use it sometimes. Matt If you're passed on the right, you're in the wrong lane. Or in Britain or some ex-British colony!
Re: Improving attachment viewing
Jon Steinhart [EMAIL PROTECTED] wrote: What I have in mind is twofold. First, I'd like to be able to optionally scan with message parts listed. Second, I'd like to be able to have an option to show/next/prev that says show the cur/next/prev message part. I just use mhlist next when I want that. But mostly, I'm with Bill in preferring the plain listing. Screen real estate is too valuable to clutter with attachment detail when you are scanning the list. -NWR
