Re: Calendar hack: Displaying ISO weeks, update for emacs 22

[Alf-Ivar Holm]

address@hidden writes:

> Alf-Ivar Holm <address@hidden> writes:
>
>> Could you give me _one_ function that would break?  The displayed
>> calendar is quite static, e.g. it does not support dynamic display of
>> months when changing the width of the window (I could easily fit 5
>> months, included week numbers, on my screen if I do a horizontal
>> maximization of my calendar window), a functionality I would have had
>> to specifically test for if it were present.  When it comes to
>> calculating a date I can't see why the visual representation of the
>> calendar matters, e.g. the date structures is luckily not dependent of
>> what is displayed in the buffer.
>
> Code that will break: all the holiday determination for non-trivial holidays.

Ok, I'l discuss that in the other (sub) thread.

> This is the same thing I told you years ago: To determine the which diary
> entries or holidays are in the visible range, the 3-month size of the window
> is assumed; thus if you write the (trivial) loops to get, say, a 5-month
> calendar window, the holidays will not be properly determined or highlighted.
> The same is true for diary entries.

What I was trying to say with the 5-month comment was that IF such
functionality existed there would probably more work on my part (as
well).  With the calendar being static, it is quite easy to add visual
stuff, like the week display hack.

> Also, when you ask for information about a date under the cursor
> (holidays, diary entries, other calendars, sunset, etc, etc), the
> code needs to translate the physical cursor position to a date.

Ok, but the postion of the dates are not changed by the addition of
the week numbers, which is display in the 5 character empty space to
the right of each month.  

This is why the need for a seperate face is needed (which again
prompted this update) as the calendar gets a bit cramped with the week
numbers added.  There is another 5 characters on the left that would
be nice to use to put some air between the week number of one month
and the dates of the next, but *that* would change the positions of
the dates and therefore need tweeking of the date calculation.  (This
is left as an exercise to someone else.)

> That translation process assumes a rigid form to the calendar
> window--adding the ISO week or stretching the calendar to 5 months,
> say, screws up that translation process.

I agree that adding the stretching is a major rewrite (that I admit
that I would have liked to see implemented.)

> The problem with redoing the calendar code to include extraneous information
> (like ISO weeks) or changing the number of months displayed is that the
> assumptions about the window's contents are intrinsic to many parts of the
> code and very hard to ferret out.  It is very easy to make such changes so
> that work with YOUR PARTICULAR calendar usage, but it would require a MAJOR
> rewriting of the code to make it work generally.

Ok, I might have been a bit hasty in my comment about the visual
representation, but if the code only refers to positions, and not
content, the hack would still work as the date placements are not
changed.

> Sorry, but when the heart of the code was written in the mid 1980s,
> all that was generally available were 80-column aasci screens.

I still use 80 columns in my emacs windows, but as I display my
calendar in a separat window I could sometimes stretch it sideways
if I wanted to plan something which stretch over more than 3 months -
that's the idea I had about the 5 month comment.

        Affi