calendar (1) and possible changes

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Some of you may have been following a discussion in PR 41945 (from wiz)
about bugs in calendar.   There's a patch there now which should fix
most of the known bugs, and make it easier to use.

Last year, jeremy Reed sent a message (to tech-userlevel)
        http://mail-index.netbsd.org/tech-userlevel/2008/05/05/msg000543.html
that described most of the same bugs as wiz reported.

Someone (unfortunately I don't know who) sent him a patch that
corrects many of the bugs - the patch is remarkably similar to
my patch in intent (just a couple of minor differences, aside from
names and stuff) which probably indicates that we both saw  the same
problem and the fix adopted is the right direction to go.

That's just background - issue 1, question 1, is that that patch
also introduced a new option (-W) that allows the user to specify
which day should be treated as the "last day of the working week",
where calendar just "knows" that Friday is it.   (The patch required it
to be specified as an ordinal day of the week number, rather than as
a day name - if it gets included, that will be fixed.)

I believe the main issue is that calendar likes to "look head" and
show you tomorrow's entries as well as todays.   Except, if today
is the last day of the working week (ie: Friday), it also shows
the complete weekend, and the following Monday - that is, you get
today, tomorrow, the following working day, and any other days
that intervene - but only on Friday.

Where this causes a problem is if you ask for 2 days of looking
ahead (using the -l 2 option), what you'd like to see then would
be, today, tomorrow and the next day (on any ordinary day), but
on Thursday, you'd like Thurs, Fri and Monday (plys the weekend
as well).  Or that's what my guess is that most people want.
It isn't what calendar does however - instead, on Friday, you
get to see Friday Sat Sun Mon and Tues (which is justifiable
perhaps) but on Thursday, you just get Thurs Fri and Sat,

The added -W option allows you to pick Thursday as the "end of working week"
day, rather than Friday (it also allows this weekend magic to be
turned off, though calendar as it is already allows for that, with -w 0).

Rather than adding an option, that you have to know to set whenever
you vary the -l option, I could instead simply make the -l option
setting affect the last day or the working week knowledge, so 2
days of lookahead would make Thurs (and probably Friday as well) into
magic days, -l 3 would move that back to Wednesday - that is, whenever
the lookahead would naturally move you into (or across) the weekend,
simply stretch it by the weekend add factor (-w option, normally 2
days, to ship the regular 2 day weekend).

I'm asking here what people would like to happen - the new option
adds extra generality (you can pick Tuesday as the end of the week,
even though you have just 1 or 2 days of lookahead), but personally I
don't think that is necessary, or useful, and it is one more thing
that you have to know to do.

For a completely different issue, calendar runs cpp on the calendar
file, that allows #include (also #define though I'm not sure that
makes a lot of sense).

An issue arises as to where cpp should be looking for calendar files
to include - it always considers /usr/share/calendar, that's fine
(though the files there are woefully out of date - the calendar.netbsd
file that records notable events in the life of NetBSD hasn't been
touche since NetBSD 2.0 was released!).

But cpp will also include files from /usr/include (which makes no sense
at all) (and any other "standard" include directory on the system).
That I think should be removed (using -nostdinc as a cpp option).

calendar also passes -I. to cpp - so it searches the current directory,
but that directory is the user's home (from /etc/passwd) unless an
env var (CALENDAR_DIR) is set, in which case that is ".".    That's
all fine when parsing a useris .calendar file (which is normally
in $HOME but can be moved by setting CALENDAR_DIR - at least for when
you run calendar yourself, rather than "calendar -a" from root's crontab)
but if you use -f to give a different calendar file, normal cpp practice
would be that
        #include "file"
looks for file in the same directory (first) as the calendar file containing
the #include.   That cannot happen here, as cpp gets given the calendar
file on its stdin, and hence has no idea where it might be located.
The effect is that "" and <> includes are the same in calendar, and
only ever search $HOME (or CALENDAR_DIR), /usr/share/calendar, and
(currently, the absurd) /usr/include directories.   That's counter-intuitive.

I suspect that it would be better to pass cpp the file name, rather than
the open fd (stdin) for the calendar file, and allow it to do its work
more sanely.

Opinions?

kre