For some reasons, we were using snprintf() to format a string into a
buffer, and then displaying this buffer to stdout using fputs().
That's exactly what fprintf() is here for, so use it.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
When we only want to display a string at a specific place of the
screen, there's no need to use the more complex mvwprintw(), use
mvwaddstr() instead.
This should be slightly more efficient, and, above all, it prevents
weird things to happen if our string contains a '%', being interpreted
as an unwanted format string.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Some strings are initialized without wrapping them in _(); instead,
_() is applied on the variable when it is used.
This is incorrect, since these strings don't get added to the catalog.
Fix that by applying _() only once, when the string is declared.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
It looks like cutting and pasting are only half-implemented: this only
avoids a segfault when trying to get help on these functions.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
When asking the user to choose between multiple alternatives, properly
handle resize events.
Note that we would also need to do so in getstring()...
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Introduce a new `status_ask_bool()` function, and use it where
applicable.
This greatly reduces code duplication, and will allow handling special
events (resize, user escape) much more uniformely.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
These cases are also candidates for the factorisation process, but
they are somewhat more tricky to get right.
Since we use a completely different approach, the result (from a user
perspective) looks different.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
We need a simpler version, based on the previously defined
`status_ask_choice()` function, that asks to choose amongst a number
of alternatives that can simply enumerated, without needing to bind
keys on them.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
This function allows the user to choose between various alternatives,
each one being associated to a given key.
This will allow a great deal of factorisation, which will make it
easier to handle special events (like resizing, user escape...) in an
uniform manner.
The cool part of the approach taken here is that it allows full i18n
(i.e. the key bound to an alternative can be different depending on
the language), at the expense of a somewhat less readable code on the
caller side.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Remove obsolete bits of code that weren't thrown away by b5c1981;
simplify some others areas of the code.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
Don't restrict ranges when entering durations. We now accept duration
like "+1d42h600m". This might not seem very logical, but it's
perfectly valid, and being able to enter "+36h" is useful when you
don't want to do the maths yourself.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
The duration format has recently changed to allow durations of the
form "2d18h42m", but the status message didn't advertize this new
possibility.
Signed-off-by: Baptiste Jonglez <baptiste--git@jonglez.org>
Signed-off-by: Lukas Fleischer <calcurse@cryptocrack.de>
