[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] iCalendar support

From: Ken Hornstein
Subject: Re: [Nmh-workers] iCalendar support
Date: Fri, 07 Nov 2014 23:24:28 -0500

>> - What were your thoughts in terms of what the interface would look like
>>   at the "repl" level?  Just a new switch?  Did you want to make it more
>>   generic?
>Yeah, just a switch, something like:
>    -calendar accept | tentative | decline | cancel
>Is there a way to make that more generic?

Hrm.  It just seems ... if you want to make that more generic, you'd want
to be able to pass switches down to the modules that generate the reply
content.  I'm not sure what that would look like.  Just thinking out

Here's an idea.  pick allows --component to refer to an arbitrary header.
Maybe use two dashes to indicate a argument to a module?

>mhshow/mhstore:  no code changes, just add -text/calendar
>entries to mhn.defaults.  I have started playing with a format
>file for display, and it looks like it'll work with what we
>already have in the format engine.  (Thank you for fmttest :-)

Glad you found it useful!

>I haven't thought much about composing a new event request,
>mainly because I wouldn't use it.

I'm with you there as well.  Might be nice to have that capability, but
definitely don't need it now.

>> Now, replying to a message is kind of an unholy combination of
>> displaying and composition.
>Is it?  I don't view reply as incorporating display, other
>than to make sure I'm replying to the message I think I'm
>replying to.  When I reply to a message that's has pdf or
>html or whatever attachments, I don't read them again.

I'm just thinking of the general case.  In a reply, you generally
want to "process" the original content somehow and incorporate it in
your outgoing message.  Okay, fine, for things that are traditional
"attachments" you mostly don't care, but you normally want to take text
and prepare it for quoting, and now we have a case of wanting to process
a calendar request and send it in the reply.  I'm sure there are other
things that would be useful as well.

>It might be nice to be able to hit a key when viewing  a
>calendar request to accept, deny, or tentative it, but I don't
>think that's a job for nmh.  Front ends certainly could.  Or
>are you referring to something else?

I was just commenting on what other MUAs do.  I'm with you; this sounds
more like a job for the reply step.

>> The question is ... what do we do?  A general thought is that we
>> shouldn't have nmh commands output mhbuild directives into drafts.  That
>> just seems like the wrong approach; it gives special meaning to the
>> message body and it requires the user to know to run the "mime" command
>> at the WhatNow? prompt.
>Doesn't nmh 1.6 run "mime" if the user didn't?

Not exactly.  It runs mhbuild -auto; that doesn't process mhbuild directives
by default (it also silently exits if the draft has MIME headers).

>> So it occurs to me that maybe we should have some mechanism to allow
>> repl to insert generic headers into the reply draft that mhbuild could
>> later process.
>What would it need to do that annotate() doesn't already?

It would use the annotate() function, certainly.  I was just more thinking
of how to indicate from inside of something like mhical that we need to
add a special header.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]