* [PATCH 2/3] cal: Correctly center the year
2020-03-28 22:33 [PATCH 1/3] cal: use a const char* Aurelien LAJOIE
@ 2020-03-28 22:33 ` Aurelien LAJOIE
2020-03-29 14:39 ` J William Piggott
2020-03-28 22:33 ` [PATCH 3/3] cal: correctly set the week width Aurelien LAJOIE
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Aurelien LAJOIE @ 2020-03-28 22:33 UTC (permalink / raw)
To: util-linux; +Cc: Aurelien LAJOIE
Signed-off-by: Aurelien LAJOIE <orel@melix.net>
---
misc-utils/cal.c | 7 +++----
tests/expected/cal/weeknum-ymjw | 14 +++++++-------
tests/expected/cal/weeknum-ysjw | 14 +++++++-------
tests/expected/cal/year-ymj | 2 +-
tests/expected/cal/year-ymjw | 2 +-
tests/expected/cal/year-ysj | 2 +-
tests/expected/cal/year-ysjw | 2 +-
7 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 728600377..7cd6545d1 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -907,11 +907,10 @@ static void monthly(const struct cal_control *ctl)
static void yearly(const struct cal_control *ctl)
{
char out[FMT_ST_CHARS];
- int year_width = 0;
+ int year_width;
- year_width += (ctl->week_width + 1) * (ctl->julian ? 2 : 3);
- if (ctl->julian)
- year_width--;
+ year_width = ctl->months_in_row * (ctl->week_width - 1) +
+ (ctl->months_in_row - 1) * ctl->gutter_width;
if (ctl->header_year) {
snprintf(out, sizeof(out), "%04d", ctl->req.year);
diff --git a/tests/expected/cal/weeknum-ymjw b/tests/expected/cal/weeknum-ymjw
index d4a1072b9..bcf9a1ecd 100644
--- a/tests/expected/cal/weeknum-ymjw
+++ b/tests/expected/cal/weeknum-ymjw
@@ -1,5 +1,5 @@
Julian - Monday-based week with week numbers
- 2001
+ 2001
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -33,7 +33,7 @@ Julian - Monday-based week with week numbers
43 295 296 297 298 299 300 301 47 323 324 325 326 327 328 329 51 351 352 353 354 355 356 357
44 302 303 304 48 330 331 332 333 334 52 358 359 360 361 362 363 364
1 365
- 2002
+ 2002
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -67,7 +67,7 @@ Julian - Monday-based week with week numbers
43 294 295 296 297 298 299 300 47 322 323 324 325 326 327 328 51 350 351 352 353 354 355 356
44 301 302 303 304 48 329 330 331 332 333 334 52 357 358 359 360 361 362 363
1 364 365
- 2003
+ 2003
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -101,7 +101,7 @@ Julian - Monday-based week with week numbers
43 293 294 295 296 297 298 299 47 321 322 323 324 325 326 327 52 356 357 358 359 360 361 362
44 300 301 302 303 304 48 328 329 330 331 332 333 334 1 363 364 365
- 2009
+ 2009
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -135,7 +135,7 @@ Julian - Monday-based week with week numbers
43 292 293 294 295 296 297 298 47 320 321 322 323 324 325 326 52 355 356 357 358 359 360 361
44 299 300 301 302 303 304 48 327 328 329 330 331 332 333 53 362 363 364 365
49 334
- 2010
+ 2010
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -169,7 +169,7 @@ Julian - Monday-based week with week numbers
42 291 292 293 294 295 296 297 47 326 327 328 329 330 331 332 51 354 355 356 357 358 359 360
43 298 299 300 301 302 303 304 48 333 334 52 361 362 363 364 365
- 2011
+ 2011
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
@@ -203,7 +203,7 @@ Julian - Monday-based week with week numbers
42 290 291 292 293 294 295 296 47 325 326 327 328 329 330 331 51 353 354 355 356 357 358 359
43 297 298 299 300 301 302 303 48 332 333 334 52 360 361 362 363 364 365
44 304
- 2012
+ 2012
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
diff --git a/tests/expected/cal/weeknum-ysjw b/tests/expected/cal/weeknum-ysjw
index 16b91adc5..b5a85279a 100644
--- a/tests/expected/cal/weeknum-ysjw
+++ b/tests/expected/cal/weeknum-ysjw
@@ -1,5 +1,5 @@
Julian - Sunday-based week with week numbers
- 2001
+ 2001
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -33,7 +33,7 @@ Julian - Sunday-based week with week numbers
43 294 295 296 297 298 299 300 47 322 323 324 325 326 327 328 51 350 351 352 353 354 355 356
44 301 302 303 304 48 329 330 331 332 333 334 52 357 358 359 360 361 362 363
53 364 365
- 2002
+ 2002
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -67,7 +67,7 @@ Julian - Sunday-based week with week numbers
43 293 294 295 296 297 298 299 47 321 322 323 324 325 326 327 52 356 357 358 359 360 361 362
44 300 301 302 303 304 48 328 329 330 331 332 333 334 53 363 364 365
- 2003
+ 2003
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -101,7 +101,7 @@ Julian - Sunday-based week with week numbers
43 292 293 294 295 296 297 298 47 320 321 322 323 324 325 326 52 355 356 357 358 359 360 361
44 299 300 301 302 303 304 48 327 328 329 330 331 332 333 53 362 363 364 365
49 334
- 2009
+ 2009
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -135,7 +135,7 @@ Julian - Sunday-based week with week numbers
43 291 292 293 294 295 296 297 48 326 327 328 329 330 331 332 52 354 355 356 357 358 359 360
44 298 299 300 301 302 303 304 49 333 334 53 361 362 363 364 365
- 2010
+ 2010
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -169,7 +169,7 @@ Julian - Sunday-based week with week numbers
43 290 291 292 293 294 295 296 48 325 326 327 328 329 330 331 52 353 354 355 356 357 358 359
44 297 298 299 300 301 302 303 49 332 333 334 53 360 361 362 363 364 365
45 304
- 2011
+ 2011
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
@@ -203,7 +203,7 @@ Julian - Sunday-based week with week numbers
43 289 290 291 292 293 294 295 48 324 325 326 327 328 329 330 52 352 353 354 355 356 357 358
44 296 297 298 299 300 301 302 49 331 332 333 334 53 359 360 361 362 363 364 365
45 303 304
- 2012
+ 2012
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
diff --git a/tests/expected/cal/year-ymj b/tests/expected/cal/year-ymj
index caa3db01d..f3b71439b 100644
--- a/tests/expected/cal/year-ymj
+++ b/tests/expected/cal/year-ymj
@@ -1,5 +1,5 @@
Julian - Monday-based week
- 2006
+ 2006
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
diff --git a/tests/expected/cal/year-ymjw b/tests/expected/cal/year-ymjw
index b62e16703..e6a569ebe 100644
--- a/tests/expected/cal/year-ymjw
+++ b/tests/expected/cal/year-ymjw
@@ -1,5 +1,5 @@
Julian - Monday-based week with week numbers
- 2006
+ 2006
January February March
Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun
diff --git a/tests/expected/cal/year-ysj b/tests/expected/cal/year-ysj
index 080e2579a..2b40099e4 100644
--- a/tests/expected/cal/year-ysj
+++ b/tests/expected/cal/year-ysj
@@ -1,5 +1,5 @@
Julian - Sunday-based week
- 2006
+ 2006
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
diff --git a/tests/expected/cal/year-ysjw b/tests/expected/cal/year-ysjw
index 69dbae3ad..800ec0cf7 100644
--- a/tests/expected/cal/year-ysjw
+++ b/tests/expected/cal/year-ysjw
@@ -1,5 +1,5 @@
Julian - Sunday-based week with week numbers
- 2006
+ 2006
January February March
Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-28 22:33 ` [PATCH 2/3] cal: Correctly center the year Aurelien LAJOIE
@ 2020-03-29 14:39 ` J William Piggott
2020-03-30 11:14 ` Aurélien Lajoie
2020-03-31 13:41 ` Karel Zak
0 siblings, 2 replies; 13+ messages in thread
From: J William Piggott @ 2020-03-29 14:39 UTC (permalink / raw)
To: Aurelien LAJOIE; +Cc: util-linux
This is not intended to be a blocker for the submitted patch; more a
general comment.
I still believe the year header is nonsense. IIRC, when I brought this
up last time nobody replied with any justification for it.
On a standard terminal it scrolls off the screen; this means the user is
unable to tell what year they are looking at. For example, I often have
multiple years open, and when tabbing between them there is nothing
visible to differentiate them. So I have to use 'cal -n 12 1 2020'.
Why is it for 11 months we have 'month year', for 13 months we have
'month year', but for 12 months we have a year header? What is special
about 12 month output. I think this is just a throwback to old printed
calendars with 12 months on a single page.
So what is the justification? What is the use case for having -y drop
the 'month year' format that is used for all other output?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-29 14:39 ` J William Piggott
@ 2020-03-30 11:14 ` Aurélien Lajoie
2020-03-31 13:41 ` Karel Zak
1 sibling, 0 replies; 13+ messages in thread
From: Aurélien Lajoie @ 2020-03-30 11:14 UTC (permalink / raw)
To: J William Piggott; +Cc: util-linux
I agree with you, this is weird,
My goal is to rework all the computations on size and padding, they
are not easy to understand and there is some magic formula.
I will try to remove the trailing spaces in a second time.
Perhaps we can add a flag to force year with month name to avoid to
change the previous behavior.
ncal is more often the year header.
╭(11:23)──{~}──
╰┤suze ▶ ncal -B1 -A8
February 2020 March 2020 April 2020 May 2020
Su 2 9 16 23 1 8 15 22 29 5 12 19 26 3 10 17 24 31
Mo 3 10 17 24 2 9 16 23 30 6 13 20 27 4 11 18 25
Tu 4 11 18 25 3 10 17 24 31 7 14 21 28 5 12 19 26
We 5 12 19 26 4 11 18 25 1 8 15 22 29 6 13 20 27
Th 6 13 20 27 5 12 19 26 2 9 16 23 30 7 14 21 28
Fr 7 14 21 28 6 13 20 27 3 10 17 24 1 8 15 22 29
Sa 1 8 15 22 29 7 14 21 28 4 11 18 25 2 9 16 23 30
June 2020 July 2020 August 2020 September 2020
Su 7 14 21 28 5 12 19 26 2 9 16 23 30 6 13 20 27
Mo 1 8 15 22 29 6 13 20 27 3 10 17 24 31 7 14 21 28
Tu 2 9 16 23 30 7 14 21 28 4 11 18 25 1 8 15 22 29
We 3 10 17 24 1 8 15 22 29 5 12 19 26 2 9 16 23 30
Th 4 11 18 25 2 9 16 23 30 6 13 20 27 3 10 17 24
Fr 5 12 19 26 3 10 17 24 31 7 14 21 28 4 11 18 25
Sa 6 13 20 27 4 11 18 25 1 8 15 22 29 5 12 19 26
October 2020 November 2020
Su 4 11 18 25 1 8 15 22 29
Mo 5 12 19 26 2 9 16 23 30
Tu 6 13 20 27 3 10 17 24
We 7 14 21 28 4 11 18 25
Th 1 8 15 22 29 5 12 19 26
Fr 2 9 16 23 30 6 13 20 27
Sa 3 10 17 24 31 7 14 21 28
╭(11:23)──{~}──
╰┤suze ▶ ncal -B2 -A8
2020
January February March April
Su 5 12 19 26 2 9 16 23 1 8 15 22 29 5 12 19 26
Mo 6 13 20 27 3 10 17 24 2 9 16 23 30 6 13 20 27
Tu 7 14 21 28 4 11 18 25 3 10 17 24 31 7 14 21 28
We 1 8 15 22 29 5 12 19 26 4 11 18 25 1 8 15 22 29
Th 2 9 16 23 30 6 13 20 27 5 12 19 26 2 9 16 23 30
Fr 3 10 17 24 31 7 14 21 28 6 13 20 27 3 10 17 24
Sa 4 11 18 25 1 8 15 22 29 7 14 21 28 4 11 18 25
May June July August
Su 3 10 17 24 31 7 14 21 28 5 12 19 26 2 9 16 23 30
Mo 4 11 18 25 1 8 15 22 29 6 13 20 27 3 10 17 24 31
Tu 5 12 19 26 2 9 16 23 30 7 14 21 28 4 11 18 25
We 6 13 20 27 3 10 17 24 1 8 15 22 29 5 12 19 26
Th 7 14 21 28 4 11 18 25 2 9 16 23 30 6 13 20 27
Fr 1 8 15 22 29 5 12 19 26 3 10 17 24 31 7 14 21 28
Sa 2 9 16 23 30 6 13 20 27 4 11 18 25 1 8 15 22 29
September October November
Su 6 13 20 27 4 11 18 25 1 8 15 22 29
Mo 7 14 21 28 5 12 19 26 2 9 16 23 30
Tu 1 8 15 22 29 6 13 20 27 3 10 17 24
We 2 9 16 23 30 7 14 21 28 4 11 18 25
Th 3 10 17 24 1 8 15 22 29 5 12 19 26
Fr 4 11 18 25 2 9 16 23 30 6 13 20 27
Sa 5 12 19 26 3 10 17 24 31 7 14 21 28
On Sun, Mar 29, 2020 at 4:39 PM J William Piggott <elseifthen@gmx.com> wrote:
>
> This is not intended to be a blocker for the submitted patch; more a
> general comment.
>
> I still believe the year header is nonsense. IIRC, when I brought this
> up last time nobody replied with any justification for it.
>
> On a standard terminal it scrolls off the screen; this means the user is
> unable to tell what year they are looking at. For example, I often have
> multiple years open, and when tabbing between them there is nothing
> visible to differentiate them. So I have to use 'cal -n 12 1 2020'.
>
> Why is it for 11 months we have 'month year', for 13 months we have
> 'month year', but for 12 months we have a year header? What is special
> about 12 month output. I think this is just a throwback to old printed
> calendars with 12 months on a single page.
>
> So what is the justification? What is the use case for having -y drop
> the 'month year' format that is used for all other output?
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-29 14:39 ` J William Piggott
2020-03-30 11:14 ` Aurélien Lajoie
@ 2020-03-31 13:41 ` Karel Zak
2020-03-31 15:06 ` J William Piggott
2020-03-31 16:44 ` Bruce Dubbs
1 sibling, 2 replies; 13+ messages in thread
From: Karel Zak @ 2020-03-31 13:41 UTC (permalink / raw)
To: J William Piggott; +Cc: Aurelien LAJOIE, util-linux
On Sun, Mar 29, 2020 at 10:39:51AM -0400, J William Piggott wrote:
> I still believe the year header is nonsense. IIRC, when I brought this
> up last time nobody replied with any justification for it.
Backward compatibility? I personally have no problem with the year
number in "cal -y" output.
I don't think we can create output which will be esthetic enough
for everyone, but we can introduce --noyear-header if it will make
cal(1) more useful for you.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-31 13:41 ` Karel Zak
@ 2020-03-31 15:06 ` J William Piggott
2020-03-31 16:55 ` Aurélien Lajoie
2020-03-31 16:44 ` Bruce Dubbs
1 sibling, 1 reply; 13+ messages in thread
From: J William Piggott @ 2020-03-31 15:06 UTC (permalink / raw)
To: Karel Zak; +Cc: Aurelien LAJOIE, util-linux
On Tue, 31 Mar 2020, Karel Zak wrote:
> On Sun, Mar 29, 2020 at 10:39:51AM -0400, J William Piggott wrote:
>> I still believe the year header is nonsense. IIRC, when I brought this
>> up last time nobody replied with any justification for it.
>
> Backward compatibility?
I'm not going to waste time looking, but I'm very confident that there
are many instances when the output format of utilities have been changed
without regard to BC, including in cal(1). Essential BC for the -y option
is that it outputs months 1 through 12.
> I personally have no problem with ...
Clearly; that has been my frustration with this project. Fiat
development without any functional justification. Relentless pushback
void of rational beyond some variation of 'because I say so.'
>
> I don't think we can create output which will be esthetic enough
> for everyone
That just it Karel, this isn't about aesthetics; it's about function. The
year header just scrolls off the screen. It serves no *function*. I see
so much of this in projects, choosing form over function. Tell me, how
specifically is a year header more functional then 'month year'? Give me
an example where the year header is of any benefit to you. Not just 'I
have no problem with it', in what way, under what conditions, in what
scenario, do you find it useful? Is aesthetics alone good justification?
It seems like this trend stems from Apple. Jobs was fanatical about
form; but what seems have been lost, is that he was equally fanatical
about function. He required that both be satisfied. I cannot find any
function in cal's year header. Can anyone offer any?
>
> --
> Karel Zak <kzak@redhat.com>
> http://karelzak.blogspot.com
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-31 15:06 ` J William Piggott
@ 2020-03-31 16:55 ` Aurélien Lajoie
2020-04-01 16:05 ` J William Piggott
0 siblings, 1 reply; 13+ messages in thread
From: Aurélien Lajoie @ 2020-03-31 16:55 UTC (permalink / raw)
To: util-linux
On Tue, Mar 31, 2020 at 5:07 PM J William Piggott <elseifthen@gmx.com> wrote:
>
> It seems like this trend stems from Apple. Jobs was fanatical about
> form; but what seems have been lost, is that he was equally fanatical
> about function. He required that both be satisfied. I cannot find any
> function in cal's year header. Can anyone offer any?
I was not thinking triggering such discussion about cal.
I don't know if my argument is a good one, reading the code I have found that
for some locale the room available is not enough to put the month and
the year on a single line.
If someone can give me example of one or two locales with this issue
to do some test, I will appreciate it.
So I think for such locale it is better to have the year only at the top.
And this behavior is closed to the physical calendar and classic year
calendar as you can see on google image "year calendar" search.
So I think we can keep it as it and add an option to change the
behavior (--noyear-header as Karel has proposed)
What do you think about adding options -A and -B as in ncal ?
[-A months] [-B months]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-31 16:55 ` Aurélien Lajoie
@ 2020-04-01 16:05 ` J William Piggott
0 siblings, 0 replies; 13+ messages in thread
From: J William Piggott @ 2020-04-01 16:05 UTC (permalink / raw)
To: Aurélien Lajoie; +Cc: util-linux
[-- Attachment #1: Type: text/plain, Size: 2490 bytes --]
On Tue, 31 Mar 2020, Aurélien Lajoie wrote:
> On Tue, Mar 31, 2020 at 5:07 PM J William Piggott <elseifthen@gmx.com> wrote:
>>
>> It seems like this trend stems from Apple. Jobs was fanatical about
>> form; but what seems have been lost, is that he was equally fanatical
>> about function. He required that both be satisfied. I cannot find any
>> function in cal's year header. Can anyone offer any?
>
> I was not thinking triggering such discussion about cal.
No worries Aurélien, the year header is an unresolved (for me)
discussion from long ago. When I take time to make, what seems like, a
logical argument for a change and only get subjective or fiat responses
it makes my head explode or something. I like coding because it is
logical, I guess that is the way I'm wired.
> I don't know if my argument is a good one, reading the code I have found that
> for some locale the room available is not enough to put the month and
> the year on a single line.
>
> If someone can give me example of one or two locales with this issue
> to do some test, I will appreciate it.
>
> So I think for such locale it is better to have the year only at the top.
* the same issue is present for 11 months and 13 months. What makes 12
months special?
* it scrolls off the screen leaving the viewer with unknowable information.
I just think the output is far more functional if the year is always
visible. For locales with long month names that would wrap, use
abbreviated month names and/or 2 digit year. Worst case, use numerical
month label for such locales. What do those locales do now for 13 months?
Is there a locale that breaks the current 13 month output?
> And this behavior is closed to the physical calendar and classic year
> calendar as you can see on google image "year calendar" search.
Well, that is my complaint of choosing form over function.
> So I think we can keep it as it and add an option to change the
> behavior (--noyear-header as Karel has proposed)
No need for that; the upstream changes I attempt to make are not for me.
The cal(1) on my system does exactly what I want it to do (including
telling me when it switches to an entirely different calendar system).
> What do you think about adding options -A and -B as in ncal ?
> [-A months] [-B months]
I have not used ncal; didn't even know about it, to be honest.
Anyway Aurélien, pay no attention to me; carry on with your work. I'm
done now.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/3] cal: Correctly center the year
2020-03-31 13:41 ` Karel Zak
2020-03-31 15:06 ` J William Piggott
@ 2020-03-31 16:44 ` Bruce Dubbs
1 sibling, 0 replies; 13+ messages in thread
From: Bruce Dubbs @ 2020-03-31 16:44 UTC (permalink / raw)
To: Karel Zak, J William Piggott; +Cc: Aurelien LAJOIE, util-linux
On 3/31/20 8:41 AM, Karel Zak wrote:
> On Sun, Mar 29, 2020 at 10:39:51AM -0400, J William Piggott wrote:
>> I still believe the year header is nonsense. IIRC, when I brought this
>> up last time nobody replied with any justification for it.
>
> Backward compatibility? I personally have no problem with the year
> number in "cal -y" output.
>
> I don't think we can create output which will be esthetic enough
> for everyone, but we can introduce --noyear-header if it will make
> cal(1) more useful for you.
Why? A user can pipe the output through something like 'sed -e 1d'
instead of changing the code for everyone.
-- Bruce
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 3/3] cal: correctly set the week width
2020-03-28 22:33 [PATCH 1/3] cal: use a const char* Aurelien LAJOIE
2020-03-28 22:33 ` [PATCH 2/3] cal: Correctly center the year Aurelien LAJOIE
@ 2020-03-28 22:33 ` Aurelien LAJOIE
2020-03-28 22:40 ` [PATCH 1/3] cal: use a const char* Aurélien Lajoie
2020-03-31 13:34 ` Karel Zak
3 siblings, 0 replies; 13+ messages in thread
From: Aurelien LAJOIE @ 2020-03-28 22:33 UTC (permalink / raw)
To: util-linux; +Cc: Aurelien LAJOIE
There is seven values but only 6 spaces between them, that why the -1
The value is always used with a minus one, just set it correctly instead
of always fix when used
Signed-off-by: Aurelien LAJOIE <orel@melix.net>
---
misc-utils/cal.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/misc-utils/cal.c b/misc-utils/cal.c
index 7cd6545d1..feff1e805 100644
--- a/misc-utils/cal.c
+++ b/misc-utils/cal.c
@@ -452,6 +452,11 @@ int main(int argc, char **argv)
ctl.week_width = (ctl.day_width * DAYS_IN_WEEK) + WNUM_LEN;
} else
ctl.week_width = ctl.day_width * DAYS_IN_WEEK;
+ /*
+ * The day_width includes the space between days,
+ * as there is no leading space, remove 1
+ * */
+ ctl.week_width -= 1;
if (argc == 1 && !isdigit_string(*argv)) {
usec_t x;
@@ -688,7 +693,7 @@ static void headers_init(struct cal_control *ctl)
for (i = 0; i < MONTHS_IN_YEAR; i++) {
/* The +1 after year_len is space in between month and year. */
- if (ctl->week_width < strlen(ctl->full_month[i]) + year_len + 1)
+ if (ctl->week_width < strlen(ctl->full_month[i]) + year_len)
ctl->header_hint = 1;
}
}
@@ -757,19 +762,19 @@ static void cal_output_header(struct cal_month *month, const struct cal_control
if (ctl->header_hint || ctl->header_year) {
for (i = month; i; i = i->next) {
snprintf(out, sizeof(out), "%s", ctl->full_month[i->month - 1]);
- center(out, ctl->week_width - 1, i->next == NULL ? 0 : ctl->gutter_width);
+ center(out, ctl->week_width, i->next == NULL ? 0 : ctl->gutter_width);
}
if (!ctl->header_year) {
my_putstring("\n");
for (i = month; i; i = i->next) {
snprintf(out, sizeof(out), "%04d", i->year);
- center(out, ctl->week_width - 1, i->next == NULL ? 0 : ctl->gutter_width);
+ center(out, ctl->week_width, i->next == NULL ? 0 : ctl->gutter_width);
}
}
} else {
for (i = month; i; i = i->next) {
snprintf(out, sizeof(out), "%s %04d", ctl->full_month[i->month - 1], i->year);
- center(out, ctl->week_width - 1, i->next == NULL ? 0 : ctl->gutter_width);
+ center(out, ctl->week_width, i->next == NULL ? 0 : ctl->gutter_width);
}
}
my_putstring("\n");
@@ -909,7 +914,7 @@ static void yearly(const struct cal_control *ctl)
char out[FMT_ST_CHARS];
int year_width;
- year_width = ctl->months_in_row * (ctl->week_width - 1) +
+ year_width = ctl->months_in_row * (ctl->week_width) +
(ctl->months_in_row - 1) * ctl->gutter_width;
if (ctl->header_year) {
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 1/3] cal: use a const char*
2020-03-28 22:33 [PATCH 1/3] cal: use a const char* Aurelien LAJOIE
2020-03-28 22:33 ` [PATCH 2/3] cal: Correctly center the year Aurelien LAJOIE
2020-03-28 22:33 ` [PATCH 3/3] cal: correctly set the week width Aurelien LAJOIE
@ 2020-03-28 22:40 ` Aurélien Lajoie
2020-03-30 19:18 ` Karel Zak
2020-03-31 13:34 ` Karel Zak
3 siblings, 1 reply; 13+ messages in thread
From: Aurélien Lajoie @ 2020-03-28 22:40 UTC (permalink / raw)
To: util-linux
Hi,
I am starting to work on cal to add the vertical layout
https://github.com/karelzak/util-linux/issues/604
I am starting to share some cleaning before submitting the feature.
What do you prefer for the feature itself ?
A Pull-request on github or patch using the mailing list?
I have no idea about how many commits I will create.
I can squash them once it is ready and submit on the mailing list.
Best Regars,
Ôrel
On Sat, Mar 28, 2020 at 11:33 PM Aurelien LAJOIE <orel@melix.net> wrote:
>
> A put string function should not modify the char*
>
> Signed-off-by: Aurelien LAJOIE <orel@melix.net>
> ---
> misc-utils/cal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/misc-utils/cal.c b/misc-utils/cal.c
> index 6f192ccea..728600377 100644
> --- a/misc-utils/cal.c
> +++ b/misc-utils/cal.c
> @@ -108,7 +108,7 @@ static int setup_terminal(char *term
> return 0;
> }
>
> -static void my_putstring(char *s)
> +static void my_putstring(const char *s)
> {
> #if defined(HAVE_LIBNCURSES) || defined(HAVE_LIBNCURSESW)
> if (has_term)
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 1/3] cal: use a const char*
2020-03-28 22:33 [PATCH 1/3] cal: use a const char* Aurelien LAJOIE
` (2 preceding siblings ...)
2020-03-28 22:40 ` [PATCH 1/3] cal: use a const char* Aurélien Lajoie
@ 2020-03-31 13:34 ` Karel Zak
3 siblings, 0 replies; 13+ messages in thread
From: Karel Zak @ 2020-03-31 13:34 UTC (permalink / raw)
To: Aurelien LAJOIE; +Cc: util-linux
On Sat, Mar 28, 2020 at 11:33:39PM +0100, Aurelien LAJOIE wrote:
> misc-utils/cal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
All three patches applied. Thanks.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 13+ messages in thread