Now that 1.6 is (hopefully) soon going to be out the door, I figure it's
time to think about 1.7/2.0 (I have no feelings about what the right
number should be).
Specifically, better MIME handling. Wait, you say ... isn't that what 1.6
is about? Yes, but I was thinking we could do even better nex
> When I get a calendar request, I want to first "show" it. Okay, that's
> easy to understand. I could write something to take a text/calendar
> object and convert it to something more easily readable.
docs/README-iCalendar has a very crude setup using calcurse
to show what's in a calendar reque
Hi Ken,
> When I get a calendar request, I want to first "show" it. Okay,
> that's easy to understand. I could write something to take a
> text/calendar object and convert it to something more easily readable.
> But the NEXT thing I want to do is store it to my calendar. On MacOS,
> that's pret
Ken Hornstein writes:
> Sometimes I have a hard time dealing with abstract ideas, so let's deal
> with the specific case I've had to do a lot lately: Calendar requests,
> which oddly enough I've had to respond a lot of them lately.
I manually put them into my Google calendar, so it would be nice
>I manually put them into my Google calendar, so it would be nice to
>support that.
Wow, you parse it out by hand? You're more dedicated than I am.
I noticed that if I make sure the file suffix is .ics and I open(1) it
on MacOS X, it gets incorporated into Calendar and makes it way into
the clou
Bill Wohler wrote:
> Ken Hornstein writes:
>> Sometimes I have a hard time dealing with abstract ideas, so let's
>> deal with the specific case I've had to do a lot lately: Calendar
>> requests, which oddly enough I've had to respond a lot of them lately.
> I manually put t
Ken Hornstein writes:
>>I manually put them into my Google calendar, so it would be nice to
>>support that.
>
> Wow, you parse it out by hand? You're more dedicated than I am.
No, not at all. It beats using Microsoft webmail.
Speaking of which, Exchange's calendar invitations only have a URL,
>Speaking of which, Exchange's calendar invitations only have a URL, not
>an ICS attachment, and often even lack the meeting info so I'm forced to
>log in and check. Not sure if we can do anything about the latter, but
>we might be able to recognize a Microsoft invitation and parse out the
>salient
It understands more structured information as well, but seemingly only in
American style dates and without support for 24-hour times e.g;
% google calendar add "12/31 at 10:30-12:00AM Partay!"
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://
Bill Wohler wrote:
> Speaking of which, Exchange's calendar invitations only have a URL, not
> an ICS attachment, and often even lack the meeting info so I'm forced
> to log in and check. Not sure if we can do anything about the latter,
> but we might be able to recognize a Micros
Ken Hornstein writes:
>>Does anyone know if Exchange is capable of emitting ICS attachments and
>>this is just a setting I can ask our calendar admins to tweak?
>
> That, I do not know. I'm not part of the Exchange realm, so it may be
> because the Exchange server in question knows I'm an extern
Ken wrote:
> >[Bill wrote:]
> >Does anyone know if Exchange is capable of emitting ICS attachments and
> >this is just a setting I can ask our calendar admins to tweak?
>
> That, I do not know. I'm not part of the Exchange realm, so it may be
> because the Exchange server in question knows I'm a
>so with the microsoft output you have to parse, you can't just read...
>And the details of the meeting you have been invited to are in pseudo-html
>inside
I can't really do much about that, but as David pointed out earlier there
are some tools to deal with that (calcurse). But it's not ideal
Ken wrote:
> I can't really do much about that, but as David pointed out earlier there
> are some tools to deal with that (calcurse). But it's not ideal for our
> purposes. Some quick Googling leads me to:
>
> https://github.com/terabyte/mutt-filters
>
> which might be better.
Maybe, bu
Hi Jerrad,
> It understands more structured information as well, but seemingly only
> in American style dates and without support for 24-hour times e.g;
>
> % google calendar add "12/31 at 10:30-12:00AM Partay!"
Does the underlying API used by this command-line program support ICS
file import as
>> It understands more structured information as well, but seemingly only
>> in American style dates and without support for 24-hour times e.g;
>>
>> % google calendar add "12/31 at 10:30-12:00AM Partay!"
>
>Does the underlying API used by this command-line program support ICS
>file import as I un
Ken Hornstein wrote:
> Part of me thinks we should include a tool that interfaces with
> text/calendar format files and lets people easily view and generate a
> reply to them.
Yes, if not directly in nmh, then strongly recommended to install.
(In debian terms this would be a "recomme
>> Part of me thinks we should include a tool that interfaces with
>> text/calendar format files and lets people easily view and generate a
>> reply to them.
>
>Yes, if not directly in nmh, then strongly recommended to install.
>(In debian terms this would be a "recommended" dependancy,
for the record, here's the thread from april of last year where
this was last discussed...
http://lists.nongnu.org/archive/html/nmh-workers/2013-04/msg00077.html
my view, which seems to agree with current thinking: making 'repl'
calendar-aware seems like the wrong approach -- creatinga a specia
>as for writing it in C? i haven't seen an ics attachment lately, but
>is posix shell, plus utilities, really not up to the task?
My feeling is "yes". Here's the spec:
http://tools.ietf.org/html/rfc5545
You have to deal with things like RFC 822-style unfolding, time zone
conversion, and fu
20 matches
Mail list logo
