Storing the group a message has been written to

Storing the group a message has been written to

[Kai.Grossjohann]

Lars told me that I could add stuff to nnmail-cache-insert to store
the group a message has been written to in ~/.nnmail-cache.  I expect
to be able to do useful stuff with it.

I have now produced the following horrible abomination:

,-----
| (defun nnmail-cache-insert (id)
|   (when nnmail-treat-duplicates
|     ;; Store some information about the group this message is written
|     ;; to.  This function might have been called from various places.
|     ;; Sometimes, a function up in the calling sequence has an
|     ;; argument GROUP which is bound to a string, the group name.  At
|     ;; other times, there is a function up in the calling sequence
|     ;; which has an argument GROUP-ART which is a list of pairs, and
|     ;; the car of a pair is a group name.  Should we check that the
|     ;; length of the list is equal to 1? -- kai
|     (let ((g nil))
|       (cond ((and (boundp 'group) group)
|              (setq g group))
|             ((and (boundp 'group-art) group-art (listp group-art))
|              (setq g (caar group-art)))
|             (t (setq g "")))
|       (unless (gnus-buffer-live-p nnmail-cache-buffer)
|         (nnmail-cache-open))
|       (save-excursion
|         (set-buffer nnmail-cache-buffer)
|         (goto-char (point-max))
|         (insert id "\t" g "\n")))))
`-----

This depends on the fact that nnmail-cache-insert is called
(indirectly) from nnchoke-request-accept-article which sets GROUP-ART
or from nnmail-split-incoming which sets GROUP.

Two questions:

(1) This is truly horrible, one should not depend on such an
    obfuscated fact.  Any suggestions for improving this?

(2) The group name is not unique.  Sometimes the group name is
    `drafts' which comes from the nndraft server, sometimes the group
    name comes from the normal nnml server.  I want to use this for
    mail splitting.  Mail splitting deals with one backend only.
    Thus, I would need to find out whether the group concerned is from
    that backend and to ignore it if it doesn't come from the backend
    where mail splitting is done.

kai
-- 
Life is hard and then you die.

MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> (1) This is truly horrible, one should not depend on such an
>     obfuscated fact.  Any suggestions for improving this?

We could document it, and rename the variable to something
reasonable. 

> (2) The group name is not unique.  Sometimes the group name is
>     `drafts' which comes from the nndraft server, sometimes the group
>     name comes from the normal nnml server.  I want to use this for
>     mail splitting.  Mail splitting deals with one backend only.
>     Thus, I would need to find out whether the group concerned is from
>     that backend and to ignore it if it doesn't come from the backend
>     where mail splitting is done.

Yes.  The mail fetching/splitting this is going to be redone, so that
instead of each mail backend trying to slurp in as much mail as
possible, there should be one slurping instance that dispathes the
mail to the backends where they should go.

Should I do that next, or is MIME composition more important?

Did we even discuss MIME composition?  How should it be done?

Here are some very, very general thoughts I have on this:

1) One should be able to create arbitrarily complex multiparts
2) The auto-save functions should work
3) Saving to drafts should work

I don't really see any easy way to do this...  Hm...  Invisible text
sucks...  Hm.

How about narrowing?

Say:

The user starts writing a message.  She hits the "insert an
attachment" command, which leads to the message being narrowed to what
was in the buffer before, and then a new message is appended outside
the narrowed region, which would, in this case, be in two parts -- the
text part, and the attachment parts.  Extra headers and separators
would enable nndraft to recreate the situation after a crash/save.

Well, ok, that's one (1) attachment, but how about fancier stuff?
What if she wants to remove the attachment and include two others
instead?  And multipart/alternative?  Er, what?

I just can't visualize how a MIME composition thingie could look. 

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

Re: MIME composition (was: Storing the group a message has been written to)

[Wes Hardaker]

>>>>> On 13 Nov 1998 19:47:12 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

Lars> Should I do that next, or is MIME composition more important?

MIME MIME  MIME

Lars> Did we even discuss MIME composition?  How should it be done?

I actually like the way TM does mime composition (but hated the
display usage, and like your set much better).

The C-c C-x C-i feature to include a new file was damn convenient...

Lars> 1) One should be able to create arbitrarily complex multiparts
Lars> 2) The auto-save functions should work
Lars> 3) Saving to drafts should work

Lars> I don't really see any easy way to do this...  Hm...  Invisible
Lars> text sucks...  Hm.

What's wrong with invis text?  Does it mess up auto-saving?  To pull
open a previous draft, you have to mime-parse it to re-hide the
pieces?  Why not have the article display functions work on the
message mode as well?  Simply bind keys to putting in the appropriate
stuff into the buffer?  Wow a true WYSIWG editor?

(Ok, modes that do replacements on the text rather than hiding like W3
does will have to be shot).

Lars> How about narrowing?

Lars> The user starts writing a message.  She hits the "insert an
Lars> attachment" command, which leads to the message being narrowed
Lars> to what was in the buffer before, and then a new message is
Lars> appended outside the narrowed region, which would, in this case,
Lars> be in two parts -- the text part, and the attachment parts.
Lars> Extra headers and separators would enable nndraft to recreate
Lars> the situation after a crash/save.

Ick:

text/plain
application/octet-string
text/plain

How do you edit the second text/plain, if you want to add text after
the stuff you just inserted.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> Lars> I don't really see any easy way to do this...  Hm...  Invisible
> Lars> text sucks...  Hm.
> 
> What's wrong with invis text?

XEmacs doesn't implement intangibility properly, so walking the cursor
past invisible text is a harrowing experience there. 

> Does it mess up auto-saving?

No, but there would have to be, er, stuff there to let nndraft
reinvisibilize the text.

> text/plain
> application/octet-string
> text/plain
> 
> How do you edit the second text/plain, if you want to add text after
> the stuff you just inserted.

Yes...  Well, there could be a...

[Imagine a light bulb switching on over my head.]

How about if the user types away, and then decides to insert a picture
at point.  Message inserts something that looks like a button at
point ([image/jpeg nice-picture.jpg 1] or something), and then, at the
end of the buffer (after the narrowed-to portion ends, one would have
the real part.  The parts-after-the-end-of-the-visible-buffer could
look like:

--Message non-text part 1 starts here--
binary gruft, or perhaps base64 or whatever
--Message non-text part 1 ends here--
--Message non-text part 2 starts here--
binary gruft, or perhaps base64 or whatever
--Message non-text part 2 ends here--

This would auto-save OK, and it wouldn't be difficult for nndraft to
reconstruct what goes where.

Then, when Message actually saves the thing, it would create a
multipart/mixed, where the "[image/jpeg nice-picture.jpg 1]" were
located and stuff.

One nice thing about this is that the user could just kill the region
containing the "button" if she decides not to include the part.

I think this is doable.  But it's only multipart/mixed.  Granted,
that's 99% of what gets sent, but...

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > I think this is doable.  But it's only multipart/mixed.  Granted,
  > that's 99% of what gets sent, but...

I don't think your mechanism is restricted to multipart/mixed.  You
could code the nesting in the part numbers (1.2.3 is the third part in
the second part of the first part).  You could put information on
whether it's multpart/alternative or multipart/mixed or
multipart/whatever either in the gruft that goes at the end of the
buffer, or in the button itself.

There's another problem with your suggestion.  Suppose users
inadvertently edit the button?  But maybe that's more of a feature
than a bug :-)

Though users shuffling around the buttons manually will screw up the
nesting relationship big time.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> I don't think your mechanism is restricted to multipart/mixed.  You
> could code the nesting in the part numbers (1.2.3 is the third part in
> the second part of the first part).  You could put information on
> whether it's multpart/alternative or multipart/mixed or
> multipart/whatever either in the gruft that goes at the end of the
> buffer, or in the button itself.

Yes, but how would the user specify what goes in the
multipart/alternative bits?  If I want to send the following message
as a multipart/alternative (if I'm in a disassociative mood):

-------------

You are so great.
-------------
Content-Type: text/richtext

You <b>suck</b>!
-------------

How would I do this?  And would I ever want to do this?  I can't
imagine ever using multipart/alternative, but perhaps that's just
me...

Or perhaps people use multipart/alternative if they compose things in
a non-text/plain language (say, HTML) and want to generate an
automatic text/plain alternative for those people who can't read that
other language?  In that case, this is moot, since that would be an
automatic translation that doesn't require any user interface.

> There's another problem with your suggestion.  Suppose users
> inadvertently edit the button?  But maybe that's more of a feature
> than a bug :-)
> 
> Though users shuffling around the buttons manually will screw up the
> nesting relationship big time.

Indeed.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Yes, but how would the user specify what goes in the
  > multipart/alternative bits?

The problem of delimiting `inline' parts occurs even with flat
multipart/mixed.

Let's say you have two kinds of buttons: inlined buttons and
attachment buttons.

Thus, "{{{ 1.3 text/plain }}}" would mark the beginning of an inlined
text/plain part, whereas "[[[ 1.4 text/html ]]]" would mark the
beginning of an attached text/html part (to be found at the end of the
buffer, made invisible by narrowing, as you suggest).

For the inline case, a part begins at its button and ends at the next
button or (point-max).

Of course, if users want to use text which looks like a button, they
lose.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Let's say you have two kinds of buttons: inlined buttons and
> attachment buttons.

No, let's not.  :-)

I'm now writing a text, and now I want to show you a picture.

[image/gif 1.2]

Now I'm writing more text.  Everything is inline; it's just that
non-plain/text parts aren't displayed at all, except as "buttons".
This means that the text/plain parts never have to be explicitly
marked as such.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > Let's say you have two kinds of buttons: inlined buttons and
  > > attachment buttons.
  > 
  > No, let's not.  :-) [...]
  > 
  > Now I'm writing more text.  Everything is inline; it's just that
  > non-plain/text parts aren't displayed at all, except as "buttons".

When I said `inline' and `attachment' I only meant whether they are
displayed fully or only as buttons when composing a message.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> When I said `inline' and `attachment' I only meant whether they are
> displayed fully or only as buttons when composing a message.

Well, I originally didn't want buttons for things that were inline
when composing, but I think the MML thing is more flexible anyway.
But in the trivial case (when including one external file), you get a
kind of button anyway for that:

<part type=image/gif><external name="~/rms.gif"></>

Well.  That's not a very button-looking button, is it?

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > This means that the text/plain parts never have to be explicitly
  > marked as such.

What if I want to compose a message consisting of two text/plain
parts?  You might think this is far-fetched, but what about a
multipart/alternative with English and French contents?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Wes Hardaker]

>>>>> On 13 Nov 1998 23:18:46 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

>> What's wrong with invis text?

Lars> XEmacs doesn't implement intangibility properly, so walking the
Lars> cursor past invisible text is a harrowing experience there.

See below...

Lars> How about if the user types away, and then decides to insert a
Lars> picture at point.  Message inserts something that looks like a
Lars> button at point ([image/jpeg nice-picture.jpg 1] or something),
Lars> and then, at the end of the buffer (after the narrowed-to
Lars> portion ends, one would have the real part.  The
Lars> parts-after-the-end-of-the-visible-buffer could look like:

Lars> --Message non-text part 1 starts here--
Lars> binary gruft, or perhaps base64 or whatever
Lars> --Message non-text part 1 ends here--
Lars> --Message non-text part 2 starts here--
Lars> binary gruft, or perhaps base64 or whatever
Lars> --Message non-text part 2 ends here--

I *really really* think you're going to shoot yourself later if you
try to deal with all the possible cases of things going wrong here...

I would, instead, go ahead with the invisible text and make the XEmacs 
group fix the invisible text pointer problems....  (this would
certainly give them the motivation to do it).

I'd hate to have to parse the text above to figure out when to put in
parts hidden below, and stuff.

Plus, narrowing should be a *user* feature that you'd be removing from 
their power by narrowing the buffer for them.  (If they narrowed the
buffer around a paragraph of theirs, and then hit C-c C-c, what do you 
do?  What if they narrow then un-narrow thus exposing all your junk at 
the end?  Confuse-a-user-R-us?

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> I would, instead, go ahead with the invisible text and make the
> XEmacs group fix the invisible text pointer problems....  (this
> would certainly give them the motivation to do it).

XEmacs doesn't implement intangible extent property not because of
lack of motivation but because of lack of consensus of how it should
be done.

FYI, handling the `intangible' property correctly is very very hard,
because you have to consider easiness of interface, easiness of
implementation, backward compatibility, and FSF Emacs compatibility.
These four are often in conflict in various ways -- I can elaborate on 
this if you're curious, and perhaps on another mailing list.

Take my word on this, as I tried.

> Plus, narrowing should be a *user* feature that you'd be removing
> from their power by narrowing the buffer for them.  (If they
> narrowed the buffer around a paragraph of theirs, and then hit C-c
> C-c, what do you do?  What if they narrow then un-narrow thus
> exposing all your junk at the end?  Confuse-a-user-R-us?

Although there are precedents for narrowing not being a user feature
(say `info.el'), I agree it should remain that way for message
composition.  As you pointed out, `C-x n w' removes *all* narrowing,
not just the most recent one.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
If we get involved in a nuclear war, will the electromagnetic pulses
from exploding bombs damage my videotapes?

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> I'd hate to have to parse the text above to figure out when to put in
> parts hidden below, and stuff.

The user shouldn't have to think about this at all.  The user taps,
`C-c C-a cindy.gif RET', and that's it.  Everything else is done with
smoke and mirrors.

> Plus, narrowing should be a *user* feature that you'd be removing from 
> their power by narrowing the buffer for them.  (If they narrowed the
> buffer around a paragraph of theirs, and then hit C-c C-c, what do you 
> do?  What if they narrow then un-narrow thus exposing all your junk at 
> the end?  Confuse-a-user-R-us?

Exposing the junk at the end would do no harm to the user interface,
but it might be confusing.  The same could be said of other narrowing
modes, like tar mode and info mode.  (Although one doesn't really edit
much there, so they are a bit different, I guess.)

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> Wes Hardaker <wjhardaker@ucdavis.edu> writes:
> 
> > I'd hate to have to parse the text above to figure out when to put in
> > parts hidden below, and stuff.
> 
> The user shouldn't have to think about this at all.  The user taps,
> `C-c C-a cindy.gif RET', and that's it.

It would be nice if the user were further prompted for content-type
(with the correctly guessed default) and a one-line description to go
to content-description.

> Exposing the junk at the end would do no harm to the user interface,
> but it might be confusing.  The same could be said of other
> narrowing modes, like tar mode and info mode.  (Although one doesn't
> really edit much there, so they are a bit different, I guess.)

Yup.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls."

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> It would be nice if the user were further prompted for content-type
> (with the correctly guessed default) and a one-line description to go
> to content-description.

Yup.  I've just ripped the defaulting MIME content type alist out of
TM. 

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

Re: MIME composition (was: Storing the group a message has been written to)

[Simon Josefsson]

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

> > It would be nice if the user were further prompted for content-type
> > (with the correctly guessed default) and a one-line description to go
> > to content-description.
> 
> Yup.  I've just ripped the defaulting MIME content type alist out of
> TM. 

You aren't forgetting about ~/.mime.types, are you? :-)

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> > Yup.  I've just ripped the defaulting MIME content type alist out of
> > TM. 
> 
> You aren't forgetting about ~/.mime.types, are you? :-)

There was oodles of code for mime.types in mailcap.el, so I'm nuking
the stuff I did yesterday.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > It would be nice if the user were further prompted for content-type
> > (with the correctly guessed default) and a one-line description to go
> > to content-description.
> 
> Yup.  I've just ripped the defaulting MIME content type alist out of
> TM.

Does TM parse mime.types?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
You can only be young once, but you can be immature forever.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Does TM parse mime.types?

I don't know, but Gnus now does.  (Courtesy of William Perry's code.)

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

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
>> Does TM parse mime.types?

No!

> I don't know, but Gnus now does.  (Courtesy of William Perry's code.)

Good!

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
>> It would be nice if the user were further prompted for content-type
>> (with the correctly guessed default) and a one-line description to go
>> to content-description.

> Yup.  I've just ripped the defaulting MIME content type alist out of
> TM. 

But pleasepleaseplease don't keep the hardcoded stuff around the text
major type!

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> But pleasepleaseplease don't keep the hardcoded stuff around the text
> major type!

I don't even know what that is, so I don't think that should be a
problem.  :-)

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

Re: MIME composition (was: Storing the group a message has been written to)

[Wes Hardaker]

>>>>> On 14 Nov 1998 03:07:28 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:

>> I'd hate to have to parse the text above to figure out when to put
>> in parts hidden below, and stuff.

Lars> The user shouldn't have to think about this at all.  The user
Lars> taps, `C-c C-a cindy.gif RET', and that's it.  Everything else
Lars> is done with smoke and mirrors.

I meant, I'd hate to try and write the correct smoke and mirrors
routine.  It would take far far less time to invisibilize (new word)
the portions you want, and wouldn't require doing a whole bunch of
cut/pasting later to put everything into place...

>> Plus, narrowing should be a *user* feature that you'd be removing from 
>> their power by narrowing the buffer for them.

Lars> Exposing the junk at the end would do no harm to the user
Lars> interface, but it might be confusing.  The same could be said of
Lars> other narrowing modes, like tar mode and info mode.  (Although
Lars> one doesn't really edit much there, so they are a bit different,
Lars> I guess.)

I think thats the point entirely.  Messages are much more prone to
being edited by the user.  By nature.  And much more prone to a C-x n
w.  It's not me I'm concerned about.  It's a less Emacs knowledgeable
user.  I have a friend in Switzerland that switched to gnus, because
he liked what I was doing.  I guarantee that if you put in narrowing
on a function, I'll get a message from him sometime afterwards because 
he got confused.

I can see I'm loosing this battle, so might I at least request that
you rebind the default narrowing keys to some wrappers around them
so that a widen will only widen to the original size?

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

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> I can see I'm loosing this battle,

Nah.  The narrowing thing is dead now.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

>>>>> Wes Hardaker <wjhardaker@ucdavis.edu>:

>>>>> On 13 Nov 1998 19:47:12 +0100, Lars Magne Ingebrigtsen <larsi@gnus.org> said:
Lars> Should I do that next, or is MIME composition more important?

> MIME MIME  MIME

Lars> Did we even discuss MIME composition?  How should it be done?

> I actually like the way TM does mime composition (but hated the
> display usage, and like your set much better).

> The C-c C-x C-i feature to include a new file was damn convenient...

Yep.  But native MIME composition should be easier to modify, than the 
one of TM.  At one point I looked at changing the inclusion of HTML
files from:
	Content-Type: text/html
	Content-Transfer-Encoding: 8bit
to
	Content-Type: text/html
	Content-Disposition: attachment; filename="filename.html"
	Content-Transfer-Encoding: 8bit

But so much was hard coded around the text major type, that this
wasn't doable.

(The reason I wanted to do this, was that I was sending some HTML
pages to someone with Lotus Notes, and Lotus Notes is unable to make
use of the MIME type, and needs the file name extension to discover
that this was an HTML page, and open it in a web browser)

Re: MIME composition (was: Storing the group a message has been written to)

[Wes Hardaker]

>>>>> On 16 Nov 1998 09:24:26 +0100, Steinar Bang <sb@metis.no> said:

Steinar> But native MIME composition should be easier to modify, than
Steinar> the one of TM.

Agreed!

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > (1) This is truly horrible, one should not depend on such an
  > >     obfuscated fact.  Any suggestions for improving this?
  > 
  > We could document it, and rename the variable to something
  > reasonable. 

That's a great way to remove a bug and add a feature :-)  How about
gnus-command-group, to go with gnus-command-method?

There's another tiny problem: nnfolder-save-mail uses GROUP-ART-LIST
rather than GROUP-ART, which is what all the other nnchoke-save-mail
functions use.  But the structure of the parameter suggests that
GROUP-ART-LIST is a more appropriate name...

And a question: I did a bit of tracing, and apparently, GROUP-ART
always contains exactly one cons cell when nnmail-cache-insert is
called.  (Well it did in all of the two cases I looked at...)  So I
just use the first one in the list.

  > > (2) The group name is not unique.  Sometimes the group name is
  > >     `drafts' which comes from the nndraft server, sometimes the group
  > >     name comes from the normal nnml server.  I want to use this for
  > >     mail splitting.  Mail splitting deals with one backend only.
  > >     Thus, I would need to find out whether the group concerned is from
  > >     that backend and to ignore it if it doesn't come from the backend
  > >     where mail splitting is done.
  > 
  > Yes.  The mail fetching/splitting this is going to be redone, so
  > that instead of each mail backend trying to slurp in as much mail
  > as possible, there should be one slurping instance that dispathes
  > the mail to the backends where they should go.
  > 
  > Should I do that next, or is MIME composition more important?

Hm.  I could add a kludge which finds the right backend most of the
time.  Here's a guess on finding the right server:

For each G in gnus-select-method, gnus-secondary-select-methods do:
    If (gnus-method-option-p G 'respool) then:
        Return G
    Fi
Rof

Does this have a non-negligible probability of finding the right
server?  If so, does this sound like a workable interim solution
(though solution is surely much too strong a word)?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> That's a great way to remove a bug and add a feature :-)  How about
> gnus-command-group, to go with gnus-command-method?

Well, it should probably be something like `nnmail-split-list' or
something. 

> And a question: I did a bit of tracing, and apparently, GROUP-ART
> always contains exactly one cons cell when nnmail-cache-insert is
> called.  (Well it did in all of the two cases I looked at...)  So I
> just use the first one in the list.

I think it can be a list of cons cells if the mail is crossposted
between groups.

But I kinda think we should hold off doing work in this area until
after the rewrite.  The group-art concept may go away completely --
it's hard to say in advance...

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > I don't really see any easy way to do this...  Hm...  Invisible
  > text sucks...  Hm.

In what way does invisible text suck?  Stupid question, maybe, but I
honestly don't know.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Here are some very, very general thoughts I have on this:
  > 
  > 1) One should be able to create arbitrarily complex multiparts
  > 2) The auto-save functions should work
  > 3) Saving to drafts should work
  > 
  > I don't really see any easy way to do this...  Hm...  Invisible text
  > sucks...  Hm.

Can you meaningfully use several buffers?  You could have articles
(no, just files) named "42.2.3" in nndraft:drafts...

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Can you meaningfully use several buffers?  You could have articles
> (no, just files) named "42.2.3" in nndraft:drafts...

Yes, that would be a possibility.  However, it does make things more
complex (what one file gets deleted or something?), so if keeping it
all in one buffer is feasible, I'd prefer that, I think.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > Can you meaningfully use several buffers?  You could have articles
  > > (no, just files) named "42.2.3" in nndraft:drafts...
  > 
  > Yes, that would be a possibility.  However, it does make things
  > more complex (what one file gets deleted or something?), so if
  > keeping it all in one buffer is feasible, I'd prefer that, I
  > think.

Displaying MIME already uses several files.  What if somebody nasty
comes along and deletes /tmp/emm.* while you're trying to show the
message?  So something similar could be devised for composing MIME
messages.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Displaying MIME already uses several files.  What if somebody nasty
> comes along and deletes /tmp/emm.* while you're trying to show the
> message?  So something similar could be devised for composing MIME
> messages.

I'm not saying it's impossible to do; I'm saying I see no advantages
and some disadvantages to doing it this way.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > 1) One should be able to create arbitrarily complex multiparts
  > 2) The auto-save functions should work
  > 3) Saving to drafts should work

Suggestion: use a convenient in-buffer representation, and use the
`correct' MIME representation on disk.  Use format-alist to convert
between the two upon disk i/o.

There's two kind of MIME parts.  One is the inline part.  For it, you
need to know where it begins and where it ends, and what the
content-type is and stuff.  Use properties for this.

The other is the attachment part.  Put the data at the end of the
buffer and insert into the buffer a button-like representation.
Attach text properties to the button, telling you where at the end of
the buffer the real data is to be found, and stuff.

By `inline' and `attachment' I don't mean content-disposition, I'm
referring to the looks of the message composition buffer.  `Inline'
parts are shown inline while one is editing the messages, and
`attachment' parts are represented by a button.  For Emacs, only
textual parts will be inline, but for XEmacs, images can be inline,
too, right?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Suggestion: use a convenient in-buffer representation, and use the
> `correct' MIME representation on disk.  Use format-alist to convert
> between the two upon disk i/o.

That would probably be rather slow when autosaving, I think.  And
there's not much to be gained, I think.

> By `inline' and `attachment' I don't mean content-disposition, I'm
> referring to the looks of the message composition buffer.  `Inline'
> parts are shown inline while one is editing the messages, and
> `attachment' parts are represented by a button.  For Emacs, only
> textual parts will be inline, but for XEmacs, images can be inline,
> too, right?

Yes, but I don't think displaying images inline when composing makes
much sense.  

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
> > Suggestion: use a convenient in-buffer representation, and use the
> > `correct' MIME representation on disk.  Use format-alist to convert
> > between the two upon disk i/o.
> 
> That would probably be rather slow when autosaving, I think.

Not if you do it right.  For example, image attachments needn't be
actually base64'ed -- you can simply add `X-Gnus-Something' header
that names the file name of the image, etc.

> And there's not much to be gained, I think.

You gain the goals you set:

* nndrafts and autosaving is (more or less) guaranteed to work
  correctly;

* everything is within a single buffer/file;

* you are not inventing an all-new all-weird format for storing stuff.

> > By `inline' and `attachment' I don't mean content-disposition, I'm
> > referring to the looks of the message composition buffer.
> > `Inline' parts are shown inline while one is editing the messages,
> > and `attachment' parts are represented by a button.  For Emacs,
> > only textual parts will be inline, but for XEmacs, images can be
> > inline, too, right?
> 
> Yes, but I don't think displaying images inline when composing makes
> much sense.

Agreed.  VM doesn't do that, either.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Not if you do it right.  For example, image attachments needn't be
> actually base64'ed -- you can simply add `X-Gnus-Something' header
> that names the file name of the image, etc.

One would have to copy the files somewhere (in case the user edits the
files after they have been included)...

Ah!  One could just copy the files to be included to the drafts
directory, and give them names like "<article-number>.1".  And
"[image/gif 1]" would refer to that file.  And when sending or
deleting, nndraft would delete all the external parts.  Yes.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Simon Josefsson]

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

> Ah!  One could just copy the files to be included to the drafts
> directory, and give them names like "<article-number>.1".  And
> "[image/gif 1]" would refer to that file.  And when sending or
> deleting, nndraft would delete all the external parts.  Yes.

Perhaps base64 encode the file immediately, keeping it as a
pseudo-article?  I'd like to be able to store drafts in another
backend, if possible.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> Perhaps base64 encode the file immediately, keeping it as a
> pseudo-article?  I'd like to be able to store drafts in another
> backend, if possible.

I think drafts have to be stored in nndraft groups.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > I think drafts have to be stored in nndraft groups.

WIBNI the drafts feature was orthogonal to the real backend used?  If
it was, people could decide whether their drafts should go in nnmh
(like they do now) or in nnfolder, or in nnimap.  I think especially
the latter possibility would be nice for the nnimap community -- that
would mean that you could start composing a message on one machine and
then finish it later on a different machine.

What about a `be a drafts group' parameter for the server or (better)
for the group?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> WIBNI the drafts feature was orthogonal to the real backend used? 

It would complicate matters somewhat, since the nndraft backend blanks 
out readedness marks and stuff, as well as looks for autosave files.
One main point of the drafts group is autosave crash recovery, and to
do that, we have to use the Emacs autosave facility, which rules
exotic features like storing drafts on an IMAP server, for instance.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> It would complicate matters somewhat, since the nndraft backend
> blanks out readedness marks and stuff, as well as looks for autosave
> files.  One main point of the drafts group is autosave crash
> recovery, and to do that, we have to use the Emacs autosave
> facility, which rules exotic features like storing drafts on an IMAP
> server, for instance.

Not necessarily; AFAIR, Emacs allows you to define your own
auto-saving hooks and stuff.

It's not that I say that you should actually implement the IMAP
autosaving idea, but that it should be possible in theory.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The end of the world is coming...  SAVE YOUR BUFFERS!

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> It's not that I say that you should actually implement the IMAP
> autosaving idea, but that it should be possible in theory.

Hm.  Would it be safe?  When Emacs crashes, you can often get it to
autosave the buffers.  Wouldn't it be difficult to have put things in
IMAP in that situation?

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

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> Hm.  Would it be safe?  When Emacs crashes, you can often get it to
> autosave the buffers.  Wouldn't it be difficult to have put things
> in IMAP in that situation?

When Emacs crashes, there's not much you can do to make things safe.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Call CIA and tell them that you have placed a bomb in a 7-11 shop!  Be
sure to let them trace you. Spend 10 years in jail and then regret it.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> When Emacs crashes, there's not much you can do to make things safe.

Not safe, but safer.  Slightly.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Simon Josefsson]

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

> One main point of the drafts group is autosave crash recovery, and to
> do that, we have to use the Emacs autosave facility, which rules
> exotic features like storing drafts on an IMAP server, for instance.

Yup. The Agent also seem to rely on a (local) nndraft for storing it's
queued articles.

However, nndraft is not only used internally by gnus (autosave stuff,
agent etc) but also by users, and users could want to have their
drafts in another backend. Perhaps one could have two draft
mechanisms...

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> However, nndraft is not only used internally by gnus (autosave stuff,
> agent etc) but also by users, and users could want to have their
> drafts in another backend. Perhaps one could have two draft
> mechanisms...

I don't think it's worth the added complexity.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

Simon Josefsson <jas@pdc.kth.se> writes:

  > Perhaps base64 encode the file immediately, keeping it as a
  > pseudo-article? [...]

Yes, MIME parts pretty much look like RFC822 messages already,
anyway.  So why not make them look like that always...

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Hrvoje Niksic]

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

> 1) One should be able to create arbitrarily complex multiparts
> 2) The auto-save functions should work
> 3) Saving to drafts should work
> 
> I don't really see any easy way to do this...  Hm...  Invisible text
> sucks...

Agreed.  VM creates a nice extent (an overlay under FSF Emacs) with
the necessary info encoded within its properties.  The behaviour of
VM's `C-c C-a' binding would probably be a nice thing to have in Gnus.

This doesn't cover the arbitrarily complex multiparts, though.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
A sadist is a masochist who follows the Golden Rule.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Agreed.  VM creates a nice extent (an overlay under FSF Emacs) with
> the necessary info encoded within its properties.

How does VM handle auto-saving / crash recovery and editing
postponement of these messages?  

> The behaviour of VM's `C-c C-a' binding would probably be a nice
> thing to have in Gnus.

Woo!  VM uses `C-c C-a'?  I just speculated what we should use, and
since `C-c C-i' (insert) was taken, I though `C-c C-a' (append) would
perhaps be nice.  :-)

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

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

I think we need a fascist widget based MIME compose method.  It may
not auto-save properly unless we do something smart with
`format-alist'.  But it should be easier for a novice user that the
`markup language' based approach.

Maybe the markup language can be used as the textual backend for a
widget based MIME editor.

Re: MIME composition (was: Storing the group a message has been written to)

[Edward J. Sabol]

Excerpts from mail: (16-Nov-98) Re: MIME composition (was: Storing the group a message has been written to) by Per Abrahamsen
> I think we need a fascist widget based MIME compose method.  It may
> not auto-save properly unless we do something smart with
> `format-alist'.  But it should be easier for a novice user that the
> `markup language' based approach.
>
> Maybe the markup language can be used as the textual backend for a
> widget based MIME editor.

I agree totally. This MML stuff might be a fine basis for doing MIME
composition behind the scenes, but it should be completely invisble to the
user. With all due respect to Lars, as a user interface goes, MML is
shockingly bad, IMHO. I think I would rather see the raw MIME information
instead, like mime-compose.el does. I honestly feel that some combination of
text properties and/or invisible/intangible text with buttons/widgets as
user-visible markers for non-editable MIME parts is the way to go.

Re: MIME composition (was: Storing the group a message has been written to)

[Matt Armstrong]

---------------------------------------------------------------------
"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> Excerpts from mail: (16-Nov-98) Re: MIME composition (was: Storing
> the group a message has been written to) by Per Abrahamsen
>
> > I think we need a fascist widget based MIME compose method.  It may
> > not auto-save properly unless we do something smart with
> > `format-alist'.  But it should be easier for a novice user that the
> > `markup language' based approach.
> >
> > Maybe the markup language can be used as the textual backend for a
> > widget based MIME editor.
> 
> I agree totally. This MML stuff might be a fine basis for doing MIME
> composition behind the scenes, but it should be completely invisble
> to the user. With all due respect to Lars, as a user interface goes,
> MML is shockingly bad, IMHO. I think I would rather see the raw MIME
> information instead, like mime-compose.el does. I honestly feel that
> some combination of text properties and/or invisible/intangible text
> with buttons/widgets as user-visible markers for non-editable MIME
> parts is the way to go.

I second the motion.  I need mime for sending attachments -- that's
it.  I'd like to avoid dealing with a markup language, however small
and easy to lean.

It'd be nice if gnus had a "bonehead mime" setting where C-x C-a
didn't insert sentinel text but instead added "Gnus-Attachment:"
headers (or something).

-- 
matta

Re: MIME composition (was: Storing the group a message has been written to)

[Wes Hardaker]

>>>>> On 16 Nov 1998 18:08:10 -0800, Matt Armstrong <matta@geoworks.com> said:

Matt> I second the motion.  I need mime for sending attachments --
Matt> that's it.

But, thats not all that mime can be used for...

Matt> It'd be nice if gnus had a "bonehead mime" setting

That is a nice idea, as well, however, the fully feature mime
capability should be done first...

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

Re: MIME composition (was: Storing the group a message has been written to)

[Matt Armstrong]

---------------------------------------------------------------------
Wes Hardaker <wjhardaker@ucdavis.edu> writes:

> >>>>> On 16 Nov 1998 18:08:10 -0800, Matt Armstrong
> >>>>> <matta@geoworks.com> said:
> 
> Matt> I second the motion.  I need mime for sending attachments --
> Matt> that's it.
> 
> But, thats not all that mime can be used for...

It is all most people ever have a need to use it for.


> Matt> It'd be nice if gnus had a "bonehead mime" setting
> 
> That is a nice idea, as well, however, the fully feature mime
> capability should be done first...

Agreed.  "bonehead mime" can easily be implemented in terms of MML.


-- 
matta

Re: MIME composition (was: Storing the group a message has been written to)

[Yair Friedman]

Matt Armstrong <matta@geoworks.com> writes:

> ---------------------------------------------------------------------
> Wes Hardaker <wjhardaker@ucdavis.edu> writes:
> 
> > >>>>> On 16 Nov 1998 18:08:10 -0800, Matt Armstrong
> > >>>>> <matta@geoworks.com> said:
> 
> > Matt> It'd be nice if gnus had a "bonehead mime" setting
> > 
> > That is a nice idea, as well, however, the fully feature mime
> > capability should be done first...
> 
> Agreed.  "bonehead mime" can easily be implemented in terms of MML.

But reall, editing MML looks like editing .newsrc.eld.  It might be
useful for internal representation, but not for user interface.

Maybe I'm missing here something, but I thought that the purpose of MML
was to make message recognise the article composition when the message
is (auto) saved.
--
Yair Friedman.

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

>>>>> Yair Friedman <yfriedma@JohnBryce.Co.Il>:

> Maybe I'm missing here something, but I thought that the purpose of
> MML was to make message recognise the article composition when the
> message is (auto) saved.

Yes.  But as I understood it, it's hard to make emacsen translate from
the displayed form to the markup form, when auto saving.

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

Yair Friedman <yfriedma@JohnBryce.Co.Il> writes:

> But reall, editing MML looks like editing .newsrc.eld.  It might be
> useful for internal representation, but not for user interface.

Both are useful.  Some people like to edit score files and group
properties directly using the Lisp-like interface , and some people
prefer to edit them using the Customize-like interface.  Gnus offers
both, and should probably do the same with MIME composition.

Only problem is that writing a Customize-like interface for MIME
composition is a lot of work, and I have this unpleasant feeling that
it is not going to get done unless I do it.  So I'd settle with an
interface where `C-c C-a' adds a `Gnus-Attachment:' header, which is
expanded into some MIME stuff when the article is send.

Re: MIME composition (was: Storing the group a message has been written to)

[Matt Armstrong]

---------------------------------------------------------------------
Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Some people like to edit score files and group properties directly
> using the Lisp-like interface , and some people prefer to edit them
> using the Customize-like interface.  Gnus offers both, and should
> probably do the same with MIME composition.

I wasn't aware of the customize-like interface to group properties.
How do I get at it?


-- 
matta

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Matt Armstrong <matta@geoworks.com> writes:


> I wasn't aware of the customize-like interface to group properties.
> How do I get at it?

`G c' in the group buffer.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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

  > Matt Armstrong <matta@geoworks.com> writes:
  > 
  > > I wasn't aware of the customize-like interface to group properties.
  > > How do I get at it?
  > 
  > `G c' in the group buffer.

WIBNI there was M-x gnus-summary-customize-group RET, too?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:


> WIBNI there was M-x gnus-summary-customize-group RET, too?

All the other group configuraion stuff is in the group buffer, isn't
it?  Then this should be there as well.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

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


  > Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
  > 
  > > WIBNI there was M-x gnus-summary-customize-group RET, too?
  > 
  > All the other group configuraion stuff is in the group buffer, isn't
  > it?  Then this should be there as well.

Hm.  There is C-M-e in the summary buffer, which is like `G p' in the
group buffer, I think.  So why shouldn't there be something in the
summary buffer that's like `G c' in the group buffer?

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:


> Hm.  There is C-M-e in the summary buffer, which is like `G p' in the
> group buffer, I think.  So why shouldn't there be something in the
> summary buffer that's like `G c' in the group buffer?

I don't know.  I see no particular reason to duplicate that command in 
the summary buffer.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Jan Vroonhof]

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

> I don't know.  I see no particular reason to duplicate that command in 
> the summary buffer.

Maybe there should a general "apply group mode command to group in
this summary buffer" prefix?

Jan

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Jan Vroonhof <vroonhof@math.ethz.ch> writes:


> Maybe there should a general "apply group mode command to group in
> this summary buffer" prefix?

I've never felt any need for that.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

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

> I don't know.  I see no particular reason to duplicate that command in 
> the summary buffer.

I use it mostly in mail groups to set to-address, and I usually want
to do that from the summary buffer where I can _see_ the address.

Re: MIME composition (was: Storing the group a message has been written to)

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I use it mostly in mail groups to set to-address, and I usually want
> to do that from the summary buffer where I can _see_ the address.

Ok; I've now added this to 0.51.

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

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

Matt Armstrong <matta@geoworks.com> writes:

> It is all most people ever have a need to use it for.

Attachments is all I can imagine _I_ would use MIME composing for.

I like plain text, especielly for mail.  But I have occationally
missed the ability to add files as attachments.

> "bonehead mime" can easily be implemented in terms of MML.

Then again, it can also be implemented in terms of plain MIME.  I'm
not sure going through MML would offer any benefits.  Plain MIME _is_
a markup language, just not a very pretty one.

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Then again, it can also be implemented in terms of plain MIME.  I'm
> not sure going through MML would offer any benefits.  Plain MIME
> _is_ a markup language,

I don't think message composers should be forced to deal with plain
MIME... 

> just not a very pretty one.

Exactly!  "Bug-ugly and unreadable" would be more accurate.

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
> 
> > Then again, it can also be implemented in terms of plain MIME.  I'm
> > not sure going through MML would offer any benefits.  Plain MIME
> > _is_ a markup language,
> 
> I don't think message composers should be forced to deal with plain
> MIME... 

In the above, _it_ referred to the hypothetical widget-based
front-end.  I don't think MML would be a benefit when implementing
_it_.

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

>>>>> Per Abrahamsen <abraham@dina.kvl.dk>:

> Steinar Bang <sb@metis.no> writes:
>> >>>>> Per Abrahamsen <abraham@dina.kvl.dk>:
>> 
>> > Then again, it can also be implemented in terms of plain MIME.  I'm
>> > not sure going through MML would offer any benefits.  Plain MIME
>> > _is_ a markup language,
>> 
>> I don't think message composers should be forced to deal with plain
>> MIME... 

> In the above, _it_ referred to the hypothetical widget-based
> front-end.  I don't think MML would be a benefit when implementing
> _it_.

OK.  How does the widget-based front end cooperate with autosave and
save to folders?  If this has been covered earlier, I apologize.  I've 
lost track of all threads of  this discussion.

Re: MIME composition (was: Storing the group a message has been written to)

[Per Abrahamsen]

Steinar Bang <sb@metis.no> writes:

> OK.  How does the widget-based front end cooperate with autosave and
> save to folders?  If this has been covered earlier, I apologize.  I've 
> lost track of all threads of  this discussion.

Earlier was mentioned doing magic with `format-alist'.  However, I
think having two buffers would be better.  One on MIME format (never
seen, associated with a file in the drafts folder), and one with the
widgets for presentation only.

Like `*Article*' and ` *Original Article*', just for message buffers.

Re: MIME composition (was: Storing the group a message has been written to)

[Kai.Grossjohann]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

  > I agree totally. This MML stuff might be a fine basis for doing
  > MIME composition behind the scenes, but it should be completely
  > invisble to the user. With all due respect to Lars, as a user
  > interface goes, MML is shockingly bad, IMHO.

Lots of people edit HTML and have no problem with it.  In fact, HTML
was touted as a simple language to use.  What's so different about
editing MML?  It is even simpler than HTML!

A UFI (user friendly interface) on top of MML might be nice, but I
don't think it is needed really badly.

kai
-- 
Life is hard and then you die.

Re: MIME composition (was: Storing the group a message has been written to)

[Vladimir Volovich]

"KG" == Kai Grossjohann writes:

 KG> Lots of people edit HTML and have no problem with it.  In fact,
 KG> HTML was touted as a simple language to use.  What's so different
 KG> about editing MML?  It is even simpler than HTML!

 KG> A UFI (user friendly interface) on top of MML might be nice, but
 KG> I don't think it is needed really badly.

I agree. The MML stuff looks pretty cute. :-) The markup used in TM is
similar, but less cool.

	Best regards, -- Vladimir.

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

>>>>> Vladimir Volovich <vvv@vvv.vsu.ru>:

> "KG" == Kai Grossjohann writes:

KG> Lots of people edit HTML and have no problem with it.  In fact,
KG> HTML was touted as a simple language to use.  What's so different
KG> about editing MML?  It is even simpler than HTML!

KG> A UFI (user friendly interface) on top of MML might be nice, but
KG> I don't think it is needed really badly.

> I agree. The MML stuff looks pretty cute. :-) The markup used in TM is
> similar, but less cool.

But that isn't really markup, is it?  It is based on hidden text,
which I understand was something larsi wanted to avoid, because it was
too messy in combination with autosave and save to drafts folders.

Re: MIME composition (was: Storing the group a message has been written to)

[Vladimir Volovich]

"SB" == Steinar Bang writes:

 >> I agree. The MML stuff looks pretty cute. :-) The markup used in
 >> TM is similar, but less cool.

 SB> But that isn't really markup, is it?  It is based on hidden text,
 SB> which I understand was something larsi wanted to avoid,

i'm not really sure about details of realization of mime in TM. i
thought that TM is able to create a MIME message from a markup which
could be typed by user. something like this:

--[[text/plain; filename="..."]]--

i do not remember the details.

	Best regards, -- Vladimir.

Re: MIME composition (was: Storing the group a message has been written to)

[Steinar Bang]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

>>>>> Vladimir Volovich <vvv@vvv.vsu.ru>:

> "SB" == Steinar Bang writes:

> i'm not really sure about details of realization of mime in TM. i
> thought that TM is able to create a MIME message from a markup which
> could be typed by user. something like this:

> 

[-- Attachment #2: Type: text/plain, Size: 287 bytes --]

> i do not remember the details.

Try including a huge image in this way, and use the cursor arrows to
move over what looks like a single line.

This takes noticable time on my PII300 running linux.

Looks like there are heaps and heaps of hidden data there.

But editing what's inside
	

[-- Attachment #3: Type: text/plain, Size: 120 bytes --]

So maybe there is some sort of combination.  Why didn't they just use
the MIME headers in the first place, I wonder...?