Re: [Nmh-workers] iCalendar support

[Ken Hornstein]

>For dealing with repl, which is what is the biggest concern to most of us,
>I think, the real question seems to be what that means.   Obviously a
>few things are fairly clear, but the general reqirements are a mystery to
>me - I have no idea what I wold like it to do - that makes designing a
>solution hard.

Well, here's my thinking on what repl should do:

- It should make "sensible" default choices.  What's sensible?  Well,
  we'd need to nail that one down.  What replyfilter does now is my idea
  of sensible; I assume that we'll have some discussion about what
  "sensible" means exactly.

- We should provide the ability for custom content processors to be
  run at reply time and generate output to be placed in the reply draft.

>I also understand Ken's point about te difficulty of teaching old dogs
>new tricks - and generally teaching new users about everything that is
>available.   I also understand that some users expect everything to
>"just work" out of the box, but I'm not sure that that kind of user
>will really get much benefit from nmh - for may people, hotmail or
>gmail (or whatever) really are what they need.   There's nothing wrong
>with that.

Well, I understand your point, but here's the problem with that.

Because nmh doesn't support IMAP, that means if you're using hotmail, gmail,
Apple Mail, whatever, that means you CAN'T use nmh.  Well, at least not
without some herculean effort.  As we've seen again and again, that means
you stop using nmh, period, even if you might want to use it otherwise.
So if you want to use gmail, fine, that's your business.  But to me that's
not an argument for not making MIME support in nmh better; I mean, if we're
going to say, "Well, if you want more seamless MIME support you should be
using gmail", then we might as well pack up and go home.

>Similarly, with most current MIME viewing, using a GUI
>type interface makes things much easier - and rather that attempting to
>figure out how to make everything perfect from the command line interface
>it might be better to spend more time commnicating with the exmh and
>sylpheed developers (and perhaps others, if there are any that can deal
>with MH format messages) and with procmail for mail reception, and get
>all of that better integrated.

Sigh.  I don't think, Robert, you quite realize the situation we're in.

In terms of MH front-ends, we've got a few categories:

- Sylpheed, Claws Mail, alpine, etc etc.  These programs can make use of the
  MH mail store, but that's it; they don't use any of the MH utilities
  and they handle all composition and display directly (I believe they
  all support IMAP).  I'm actually a little unclear why they use the MH
  mail store in the first place.  The feedback we've gotten from these
  people in terms of making things work better with nmh ranges from
  indifference to mild hostility; they, quite frankly, do not give a
  shit about us.  I do not foresee any change here; what would be their
  motivation for doing so?

- exmh, MH-E ... well, I think that's really it.  These really are more
  front-end programs; they handle display, but a lot of back-end work is
  done by MH/nmh programs.  In terms of exmh ... well, it hasn't seen
  a new release in over a decade.  Brent Welch doesn't do work on it
  anymore.  Valdis is nominally the maintainer, and he's on this list.
  But again, a new release hasn't happen in forever.  I'm an exmh user
  myself, but it's getting harder and harder to keep it limping along
  with recent changes in Tk.  The situation with MH-E is better, and
  MH-E has been more up to date, and Bill is on this list.  But I gather
  that MH-E's tactic has been to implement the MIME bits that MH and
  nmh has been lacking directly; I can't really fault this approach
  as it was so terrible for so long, but again I'm unsure what better
  communication will do here; if the MH-E people want to make things
  better they'll probably just do it themselves.  But hey, if we can do
  anything to make things better between us and MH-E or exmh, I'm all
  for it!

My point here is that for things like Sylpheed, they're ignoring us.
For things like exmh ... well, nobody is really minding the store.  If
we want to do better, we've got to do it ourselves.

>I disagree - that's entirely the wrong direction, show doesn't print
>some message about "Now do you want to reply, forwrd, ..." every time
>it displays a message, scan doesn't tell the user how to display the
>messages, ...

Well, I think the basic documentation has that covered.  It's the new
stuff that has a hard time getting the word out.  Anyway, that was
just a strawman proposal; if people hate it, we don't have to do it.

>Treating ical as a special case will just lead to demands for similar
>treatment of the next magic mime type that becomes popular.  Please
>don't go there.

Perhaps I wasn't clear; I don't want ical to be a special case, I want
to create a framework where we can have custom reply processors for any
MIME type and ical be the first instance of that.

--Ken