nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] iCalendar support

2014-11-07 16:38:07
Ken wrote:

Some meta-thoughts:

- 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?

- What were you thinking in terms of implementation details?  Yes, I
  understand about the mhical utility, but I was thinking of what
  you'd need in all of the other tools to make it work.

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 :-)

I haven't thought much about composing a new event request,
mainly because I wouldn't use it.  I need to use a calendar
app to check schedules, anyway.  The calendar request itself
would be simple, but getting the start/stop times and
attendees from the user wouldn't be unless we just let the
user do it in their editor the way they do for any message.
We could provide a calendar event request template if
there's interest in that.

- Are you sure you want to have a mhbuild directive in the reply?

That's a good question.  I started with that as a proof of
concept and something that everyone here could understand.
Also, I'd like to support reply to an calendar request without
editing.  None of this rules out the header approach, and I'm
willing to pursue it.

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.

We've never really figured out how to bridge the gap here very well.
To be fair, nobody else seems to handle this really well either; a
few things are special-cased in MUAs (like calendar requests,
although in my experience what happens there is that you have to do
something at message display time)

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?

but mostly they don't deal with
non-text parts for replies.  Maybe we should do better!

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?

The more I use it, the more I think the attach command's general
interface is more reasonable; headers already have special meaning,
we have a specialized tool to manipulate them (anno) and it seems to
work out well in practice.

I buy that.

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?

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>