Alf-Ivar Holm <[EMAIL PROTECTED]> 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. 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. 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. 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. 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. Sorry, but when the heart of the code was written in the mid 1980s, all that was generally available were 80-column aasci screens. _______________________________________________ gnu-emacs-sources mailing list gnu-emacs-sources@gnu.org http://lists.gnu.org/mailman/listinfo/gnu-emacs-sources
