convenient mime keys

convenient mime keys

[Wes Hardaker]

One of the things I've always hated about TM is that it forced me into 
the article buffer.  I *hate* doing that because there is no ideal way 
to switch back to the summary buffer ('h' is very slow for some
reason, and c-x o doesn't work because I have *bbdb* and *group*
displayed as well).

Anyway, what I think would be cool is to number the mime attachments
shown in the buffer, and then make a new key binding set that did the
equivalent of the button presses in the article buffer on that
attachment.

IE:

  [1: text/plain]

  [2: image/jpeg]

Keys:  1 M t -> toggles display
       2 M s -> saves the part
       1 M R -> replies to the message, using that part to quote from...

etc...

(the M prefix key is already used, I just didn't want to go searching
for someplace just for this example).

The problem will come into things like multi-part alternatives in a
message with attachments and the numbering system.  I wanted all
numbers since it could be used in the prefix arguments as shown above, 
but what about things like:

  [1a: text/plain]
  [1b: text/html]         (alternative)
  [2: image/jpeg] 

How should these be numbered so that we can keep a numerical prefix?
"1 2 3" is one possibility, but confuses the layout of the mime
message.  Maybe 11 12 3?  (watching for uniqueness)...

maybe:
  [1: 1a: text/plain]
  [2: 1b: text/html]         (alternative)
  [3: 2: image/jpeg] 

(ie, a weird labeling scheme)

Thoughts, ideas, flames?

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: convenient mime keys

[Didier Verna]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> One of the things I've always hated about TM is that it forced me into 
> the article buffer.  I *hate* doing that because there is no ideal way 
> to switch back to the summary buffer ('h' is very slow for some
> reason, and c-x o doesn't work because I have *bbdb* and *group*
> displayed as well).

M-TAB is shorter than C-x o, but I agree with you anyway :-)

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: convenient mime keys

[Justin Sheehy]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> Anyway, what I think would be cool is to number the mime attachments
> shown in the buffer, and then make a new key binding set that did the
> equivalent of the button presses in the article buffer on that
> attachment.
> 
> IE:
> 
>   [1: text/plain]
> 
>   [2: image/jpeg]
> 
> Keys:  1 M t -> toggles display
>        2 M s -> saves the part
>        1 M R -> replies to the message, using that part to quote from...

I like this a lot.  This would be a lot better than having to poke
around in the article buffer.

I'm not sure how to best fit this in with alternative parts, though.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: convenient mime keys

[Kai Grossjohann]

>>>>> On 25 Sep 1998-700, Wes Hardaker said:

  WH> One of the things I've always hated about TM is that it forced
  WH> me into the article buffer.  I *hate* doing that because there
  WH> is no ideal way to switch back to the summary buffer ('h' is
  WH> very slow for some reason, and c-x o doesn't work because I have
  WH> *bbdb* and *group* displayed as well).

I think the right way to go about it is to make `h' be fast.  It's
fast for me.  Emacs 20.3, pgnus 0.33, Solaris 2.5, Athena toolkit.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: convenient mime keys

[Kai Grossjohann]

>>>>> On 25 Sep 1998-400, Justin Sheehy said:

  JS> I'm not sure how to best fit this in with alternative parts,
  JS> though.

Isn't it obvious that `invoking' the alternative part should
cyclically switch between the alternatives?

Nevertheless, that doesn't help much with the possibility of
arbitrarily-nested multiparts.

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: convenient mime keys

[Wes Hardaker]

>>>>> On 25 Sep 1998 21:13:25 +0200, Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de> said:

Kai> Isn't it obvious that `invoking' the alternative part should
Kai> cyclically switch between the alternatives?

Kai> Nevertheless, that doesn't help much with the possibility of
Kai> arbitrarily-nested multiparts.

Yeah, I sort of used the wrong example...  Though to some extent, I
could see the need for seeing both of the alternatives at the same
time (which is currently impossible, but since I don't feel the need I 
don't personally care).

The later case you point out is a better example.

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: convenient mime keys

[Lars Magne Ingebrigtsen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> One of the things I've always hated about TM is that it forced me into 
> the article buffer.  I *hate* doing that because there is no ideal way 
> to switch back to the summary buffer ('h' is very slow for some
> reason,

Huh.  Is it a menu thing, perhaps? 

> Anyway, what I think would be cool is to number the mime attachments
> shown in the buffer, and then make a new key binding set that did the
> equivalent of the button presses in the article buffer on that
> attachment.

I think that's a good idea.

> The problem will come into things like multi-part alternatives in a
> message with attachments and the numbering system.

Can't we just number all the parts?

> I wanted all
> numbers since it could be used in the prefix arguments as shown above, 
> but what about things like:
> 
>   [1a: text/plain]
>   [1b: text/html]         (alternative)
>   [2: image/jpeg] 

Like:

   [1: text/plain]
   [2: text/html]         (alternative)
   [3: image/jpeg] 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convenient mime keys

[Kai Grossjohann]

>>>>> On 29 Sep 1998, Lars Magne Ingebrigtsen said:

  LMI> Can't we just number all the parts?

That loses information about nesting.  WIBNI the nesting was somehow
represented in the article buffer?

kai
-- 
OOP: object oriented programming;  OOPS: object oriented mistakes

Re: convenient mime keys

[Steinar Bang]

>>>>> Kai Grossjohann <grossjohann@amaunet.cs.uni-dortmund.de>:

>>>>> On 29 Sep 1998, Lars Magne Ingebrigtsen said:
LMI> Can't we just number all the parts?

> That loses information about nesting.  WIBNI the nesting was somehow
> represented in the article buffer?

IMAP has a hierarchical numbering scheme for message parts that I
suggest we adopt.  See <ilu7lz6gq8g.fsf@gregory.pdc.kth.se> by Simon
Josefsson for an example.

See also:
	http://www.imap.org/docs/rfc2060.html
and [Page 42] in the rfc itself.

Side note:

This number can be used in IMAP URLs to fetch a specific message part,
see
	http://www.imap.org/docs/rfc2192.html
and section 7 in the rfc itself.

Which (completely unrelated to this thread on the ding mailing list)
suggests a scheme, for fulfilling 
	http://www.metis.no/private/sb/gnusmimereqs.html#REQ-20
where the nnimap backend returns URL MIME External-body message parts
	ftp://ftp.ntnu.no/pub/rfc/rfc2017.txt
instead of the actual 5MB videoclip, or whatever

The the MIME support of Gnus can feed the URL to the nnimap backend
whenever the user decides to display the part.

Re: convenient mime keys

[Wes Hardaker]

>>>>> On 29 Sep 1998 12:48:53 +0200, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

>> One of the things I've always hated about TM is that it forced me into 
>> the article buffer.  I *hate* doing that because there is no ideal way 
>> to switch back to the summary buffer ('h' is very slow for some
>> reason,

Lars> Huh.  Is it a menu thing, perhaps? 

As I mentioned in another message in this thread, the problem appears
fixed lately...  I suspect it was a TM problem.

>> The problem will come into things like multi-part alternatives in a
>> message with attachments and the numbering system.

Lars> Can't we just number all the parts?

That was one of my suggestions, if you'll recall...

Lars> Like:

Lars> [1: text/plain]
Lars> [2: text/html]         (alternative)
Lars> [3: image/jpeg] 

And I suggested this instead, to keep info the user may want to see:

Lars> [1: 1a: text/plain]
Lars> [2: 1b: text/html]         (alternative)
Lars> [3: 2: image/jpeg] 

Or something...

-- 
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

Re: convenient mime keys

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> IMAP has a hierarchical numbering scheme for message parts that I
> suggest we adopt.  See <ilu7lz6gq8g.fsf@gregory.pdc.kth.se> by Simon
> Josefsson for an example.
> 
> See also:
> 	http://www.imap.org/docs/rfc2060.html
> and [Page 42] in the rfc itself.

                        HEADER     ([RFC-822] header of the message)
                        TEXT       MULTIPART/MIXED
                        1          TEXT/PLAIN
                        2          APPLICATION/OCTET-STREAM
                        3          MESSAGE/RFC822
                        3.HEADER   ([RFC-822] header of the message)
                        3.TEXT     ([RFC-822] text body of the message)
                        3.1        TEXT/PLAIN
                        3.2        APPLICATION/OCTET-STREAM
                        4          MULTIPART/MIXED
                        4.1        IMAGE/GIF
                        4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
                        4.2        MESSAGE/RFC822
                        4.2.HEADER ([RFC-822] header of the message)
                        4.2.TEXT   ([RFC-822] text body of the message)
                        4.2.1      TEXT/PLAIN
                        4.2.2      MULTIPART/ALTERNATIVE
                        4.2.2.1    TEXT/PLAIN
                        4.2.2.2    TEXT/RICHTEXT


So to see the last part, the user would type...?

`4222b' would work if we assume that no part has more than 9 parts,
but we can't really assume that.  `b 4.2.2.2 RET' would be a
possibility, but is a mouthful.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: convenient mime keys

[Christopher K Davis]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> `4222b' would work if we assume that no part has more than 9 parts, but
> we can't really assume that.  `b 4.2.2.2 RET' would be a possibility,
> but is a mouthful.

Could we pad with zeros for parts with >9 parts, or would that require
too much look-ahead?  If part 4 had 12 subparts, we could use 40222b to
get to '4.02.2.2' and 412b to get to '4.12'.

-- 
Christopher Davis * <ckd-sig@ckdhr.com> * <URL:http://www.ckdhr.com/ckd/>
Put location information in your DNS! <URL:http://www.ckdhr.com/dns-loc/>

Re: convenient mime keys

[Lars Magne Ingebrigtsen]

Christopher K Davis <ckd@ckdhr.com> writes:

> Could we pad with zeros for parts with >9 parts, or would that require
> too much look-ahead?  If part 4 had 12 subparts, we could use 40222b to
> get to '4.02.2.2' and 412b to get to '4.12'.

That sounds like a plan.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen