* Use "$XDG_DATA_HOME/calcurse" for data files
* Use "$XDG_CONFIG_HOME/calcurse" for config files
* "$XDG_DATA_HOME" defaults to "$HOME/.local/share"
* "$XDG_CONFIG_HOME" defaults to "$HOME/.config"
* If "$HOME/.calcurse" exists, then it will be used instead for backward
compatibility.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
If the notify bar displays a recurrent appointment after midnight as next
upcoming appointment, the bar is not updated when the appointment/occurrence is
deleted. The problem is not seen in 4.3.0 because of the bug described in
commit 8cbd456, Fix next recurring appointment. The problem and the solution is
the same, this time in the function notify_same_recur_item().
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
If the update results in an empty string (return value GETSTRING_RET), the
original string remains whereas it should be empty.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
The default is "--"; a single space makes the text invisible.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Display a warning if any of the events reported by the server cannot be
found instead of bailing out.
Addresses GitHub issue #137 and #245.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
The patch adresses two issues with the function recur_item_find
ocurrence(), one major: mktime(), and one minor: item duration. In
addition, some refactoring is done.
The following recurrent appointments demonstrate the problems (as
described in the message) and are used as test cases in the associated
test commit.
03/29/2019 @ 12:00 -> 03/30/2019 @ 11:00 {2D -> 04/03/2019} |two-day - every other day - not on 1/4
03/31/2019 @ 12:00 -> 03/31/2019 @ 13:00 {1D -> 04/01/2019} |daily - not on 31/3, twice on 1/4
03/31/2019 @ 04:00 -> 03/31/2019 @ 05:00 {1W} |weekly - appears after one week
03/31/2019 @ 12:00 -> 03/31/2019 @ 12:00 {1M} |monthly - never appears
03/31/2019 @ 12:00 -> 03/31/2019 @ 12:00 {1Y} |yearly - never appears
10/20/2019 @ 00:00 -> 10/21/2019 @ 01:00 {1W -> 11/03/2019} |25 hours - ends on 27th, but continues on 28th
03/24/2019 @ 00:00 -> 03/25/2019 @ 00:00 {1W -> 04/07/2019} |24 hours - does not continue on April 1
The root cause is two mktime() calls in recur_item_find_occurrence(),
both of which use an inherited tm_isdst value in the tm structure. In
such cases mktime() will "normalize" the tm stucture if tm_isdst is 0 or
1 and in disagreement with the rest of the tm contents (just like 32 May
will be normalized to 1 June).
Example. In 2019 DST started on 31/3 at 02:00:00 (in the European
Union). If the (local) time "31/3/2018 00:00:00" is passed to mktime()
with tm_isdst = 0, the return value is (say) T sec and the tm structure
is unchanged, because DST is not in effect at midnight. If the same call
is performed with tm_isdst = 1, the return value becomes (T - 3600) sec
and the tm structure is normalized to "30/3/2018 23:00:00", tm_isdst =
0.
In recur_item_find_occurrence(), the normalized tm structure with wrong
day and time is used in ensuing calculations, leading to wrong dates and
the errors observed.
The first mktime() call is used to calculate the "day span" of the
occurrence before the occurrence itself has been determined. But once
the occurence is known, the "day span" is easily determined, and there
is no need for the first mktime() call.
Events have no explicit duration. However, recur_event_find_occurrence()
and recur_event_inday() set the duration of an event to DAYINSEC before
passing it on to recur_item_find_occurrence(). The value is not correct
on the day when DST begins or ends. The interpretation of the daylength
should be left to the called function. Hence, duration is set to -1 to
signal no (explicit) duration.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
A day begins on midnight (inclusive) and ends on midnight (exclusive). A
day as a whole is represented by the initial midnight, i.e. time-of-day
is 00:00.
On load of recurrent appointments (but not events) time-of-day for the
until day is set to 23:59. For a newly created recurrent appointment the
setting depends on the input method: time-of-day is set to 00:00 if
until day is given as a date (day, month and year), but to time-of-day
for the start day if given as an offset (+dd).
The resulting behaviour is only visible in interactive use of calcurse
as proved by the following scenario.
1) Create an appointment with start time 12:00, end time 11:59 (multi
day).
2) Turn it into a recurrent appointment of type daily, frequency 3,
until day +3.
The appointment is correctly displayed with two 2-day occurrences three
days apart.
3) Edit the appointment and select Repetition. Accept existing type,
frequency and end day (now as a date).
The second day of the second occurrence disappears.
4) Repeat 3), but set the end day as an offset (+3).
The second day of the second occurrence reappears.
The inconsistencies have been eliminated, and time-of-day for the until
day is now always 00:00.
Also, until day may equal start day, so midnights should be compared.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Explicit setting of Daylight Saving Time should be avoided before as well as
after the mktime() call.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
The calculation of the year of the most recent occurrence for year dates before
the start date (disregarding the year) is incorrect for frequencies greater than
one. The most recent occurrence (for a date as mentioned) is either too far or
too close in the past. In most cases it does no harm because the most recent
ocurrence is in the past and does not span the date (i.e. there is no occurrence
on the day). But the following appointment shows the presence of the bug:
12/31/2019 @ 12:00 -> 01/01/2020 @ 12:00 {2Y} |new year
The occurence on 1 Jan 2020 is missing, because the most recent occurrence is
too far in the past (31 Dec 2018 instead of 31 Dec 2019). An occurrence appears
on 1 Jan 2021, because the most recent occurence is too close in the past (31
Dec 2020 instead of 31 Dec 2019).
A similar miscalculation affects the monthly rule as proved by
3/31/2019 @ 12:00 -> 4/1/2019 @ 11:00 {2M} |change of month
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
An edit session, and in particular, a cancelled edit session should encompass
all parameters.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Since commit 987fa9d (Allow to omit end date in repetitions,
2019-06-03), one can provide an empty date instead of using the value 0
to omit the end date of a repetition. Use this as default value when
editing repetitions without an end date.
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
A scrollbar gives the impression of a fixed list. But the list on
display is automatically and silently changed as needed for movements in
the panel or the calendar, thus creating the illusion of an endless
list.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Instead of having the user tell how many days to load, calcurse can
calculate an overestimation from the running configuration (panel size,
appearance of headers and separators etc.)
The configuration variable conf.multiple_days is turned into a Boolean
that switches the feature on and off.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
... by adding a horizontal line from border to border above the day
heading and turning the event separator into an empty line. The
horizontal line is left out for the first day loaded.
Also reduce the number of empty lines at the end of a day to at most
one.
A new configuration variable, header_line, turns the horizontal line on
and off.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Previously, with only one day visible at a time, the appointments panel
displayed the details of the day selected in the calendar (slctd_day);
information required for operations on items (day_items) can often be
derived from the selected day. The items available are derived from the
selected day. In particular, the selected item is derived from the
selected day.
With multiple days in the APP panel, the relation between selected day
(in the calendar) and the selected item (in the APP panel) has, in a
way, been turned around. The selected item may now be moved between days
without explicitly changing the selected day. Implicitly it is changed
when the target day of a move is unavailable.
This commit draws the full consequence: the selected day in the calendar
is always (set to) the day of the selected item in the APP panel.
The static variable 'struct date slctd_day' lives in ui_calendar.c and
is accessible through various public functions. To these are added
ui_calendar_set_slctd_day() which sets slctd_day directly.
The selected day retains its significance for load of the day vector (in
day_store_items()): the range of loaded days begins with the selected
day. Movements (up/down) in the APP panel will change the selected day
as the selected item moves among the already loaded days. Only when the
target of a movement is unreachable, will further days be loaded. On the
other hand, if the same range of days must be reloaded because of a
changed item, the selected item - and with it the selected day - must be
reset to the first day item (see do_storage()).
Movements in the calendar (generic-next-day, etc.) are not affected and
behave as previously, i.e. they will cause a range of days to be loaded
with the selected day as the first and the selected item as the first of
the selected day.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
The number of days displayed in the APP panel has been made
configurable, maximum 21 days, default seven days.
With several days in the APP panel, it may be desirable to "squeeze" the
entries by leaving out the final empty line of each appointment and
lower the number of lines between consecutive days (0, 1, or 2). Both
are made general configuration options. To make a uniform display, an
empty line is added to a day without appointments, if appointments have
an empty line.
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
Much in the calendar is based on the selected day, struct date
slctd_day, in ui-calendar.c.
On the screen it is highlighted with a deviating colour. The highlight
effect has been changed to a pair of red square brackets that do not
obscure the day colour.
The week number (in the frame) used to be that of the selected day, but
has no obvious relation to the days in the APP panel. It has been
replaced by the year day number of the selected day. The week numbers of
all visible weeks are displayed to the left of the calendar.
Dates are displayed also for the overlapping parts of the first and last
week of the month (which do not belong to the month).
Days are accessible in the appointments panel as well as in the
calendar. Hence, validation of days (= inside UNIX time limits) must be
extended from the calendar (in ui_calendar_move()) to include loaded
days (in day_store_items()).
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
With multiple days in the APP panel, up/down movements should change
behaviour at the top and bottom of the list displayed, and load the
previous/next lot of days.
This requires that the move function returns the result of the
operation. Furthermore, the ability to move the selection to the
beginning of a day is needed when moving down (in order to move from the
first day to the last day). For this reason a DAY_SEPARATOR has been
inserted also after the last day of a lot.
Appointments have a listbox height of three to separate them clearly
when there is more than one in a day. This leaves a spurious empty line
at the end of a day with appointments. The DAY_SEPARATOR height is
reduced from two to one, and a new EMPTY_SEPARATOR of height one is
inserted in any day with only events.
When scrolling up the DAY_HEADING becomes visible when the selection
reaches the first item of the day.
The length of the separator (between events and appointments) is
adjusted to leave a space to the window border at both ends, thereby
making it a part of the day, not a separation between days.
The dummy event must also be recognisable when not the selected item and
is only inserted in interactive mode.
The test for a saved selection must also recognise caption items which
have item pointer NULL.
The function day_get_nb() has been renamed day_get_days().
Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>
