emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New face: org-agenda-calendar-timerange


From: Ruijie Yu
Subject: Re: New face: org-agenda-calendar-timerange
Date: Fri, 20 Jan 2023 11:32:49 +0800
User-agent: mu4e 1.8.13; emacs 29.0.60

gautier@gautierponsinet.xyz writes:

> Please find attached a patch containing two commits.
>
> [...]
>
> It seems to me that this should be done by creating repeating tasks
> rather than an entry with a timerange, because suppose I want to put
> in my agenda an event spanning on several days including the precise
> hours at which it starts and ends but which starts and ends on the
> same hour, for example an entry with the following timerange:
>
> <2023-01-19 jeu. 12:00>--<2023-01-26 jeu. 12:00> .

Slight tangent, it seems that this time range has French abbreviations,
is there any resource I can take a look to find recognized abbreviations
for each language that I am interested in?


> In this case, it makes no sense to print the time "12:00" everyday in
> the range. I would expect the agenda to show the event on each days it
> is, the time at which the event starts on the first day, and the time
> at which the event ends on the last day. Does that make sense?

I agree, this is what I am used to with other calendar programs for
displaying multi-day events.  For the in-between days, maybe these
events should be shown as full-day events?

> All the best,
> Gautier.

> From e3feebdf3596645d28d66c1baf6296bcaedf1f42 Mon Sep 17 00:00:00 2001
> From: Gautier Ponsinet <gautier@gautierponsinet.xyz>
> Date: Thu, 19 Jan 2023 21:34:37 +0100
> Subject: [PATCH 1/2] org-agenda: Apply the face `org-agenda-calendar-event'
>
> * list/org-agenda.el (org-agenda-get-blocks): Apply the face
>   `org-agenda-calendar-event' to entries with a time range within a
>   single day.
> ---
>  lisp/org-agenda.el | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index d983a0916..4f29f3eb6 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> [...]
> @@ -7109,6 +7108,9 @@ scheduled items with an hour specification like 
> [h]h:mm."
>         (setq donep (member todo-state org-done-keywords))
>         (when (and donep org-agenda-skip-timestamp-if-done)
>       (throw :skip t))
> +              (setq face (if (= d1 d2)
> +                             'org-agenda-calendar-event
> +                           nil))
>         (setq marker (org-agenda-new-marker (point))
>           category (org-get-category))
>                (setq effort (save-match-data (or (get-text-property (point) 
> 'effort)
> [...]
> --
> 2.39.1

I see an (if cond then nil) construct.   Not that it matters for the
entire patch, since the else case is updated in the second commit, but I
want to use this opportunity to fulfill my longstanding curiosity on
lisp styles.  For cases where the "else" branch is nil, I have seen the
following three types of constructs:

1. (if cond then nil) -- like this commit
2. (and cond then) -- what I have heard people prefer and have started to adopt
3. (if cond then) -- I found this construct in various patches and source files

Do people prefer one over the other two, and why?

> From 5dc50a84ab6adc1765eaf5bf3cf3c670df69f355 Mon Sep 17 00:00:00 2001
> From: Gautier Ponsinet <gautier@gautierponsinet.xyz>
> Date: Thu, 19 Jan 2023 22:18:12 +0100
> Subject: [PATCH 2/2] Define the face `org-agenda-calendar-daterange'
> [...]
> --
> 2.39.1

The patch applies cleanly on current main branch (52f29d4da), and all
tests from `make test` passed.  However, I don't see any effects on a
test org buffer (see attached) -- in particular, I don't see the
`org-agenda-calendar-daterange' face being shown anywhere on the buffer.
According to `C-u C-x =' (`what-cursor-position'), all three date ranges
use `org-date' face.

$ git am this.patch
$ make test
$ emacs -Q -L lisp -l org agenda.org
(type `C-u C-x =' on each date range to see `org-date')

Attachment: agenda.org
Description: test org file

Thoughts?  Will do the same on the original main branch to ensure I
didn't misunderstand something.

Best,


RY

reply via email to

[Prev in Thread] Current Thread [Next in Thread]