Colorize tags in org-clock-report table

[KaratasFurkan]

The table has a Tags column if generated with :tags t option. It would be nice to colorize them too.

[wigingtont2]

I was finally coming back to this project to make the small update I mentioned for my last PR. Then I found this. I have something that works, but it's a lot more involved than my prior update. So, I'm not going to just copy-paste it here. I'm going to try to clean it up, and see if I can make it any less complicated, then put out a PR. I haven't used this feature before, so I'm only testing it against what running org-clock-report gave me for a random headline and a few variations that seemed obvious to me. If you have a sample file I can test against, that would be great.

[KaratasFurkan]

Hi @wigingtont2 , thanks for the help. Would just the table without headings be enough?

#+BEGIN: clocktable :scope file :maxlevel 10 :tags t :properties ("TODO") :emphasize t :link t :block thisyear
#+CAPTION: Clock summary at [2023-08-20 Paz 17:34], for the year 2023.
| Tags           | TODO | Headline   |   Time |       |
|----------------+------+------------+--------+-------|
|                |      | Total time | 114:26 |       |
|----------------+------+------------+--------+-------|
|                |      |            |  14:04 |       |
| planning       | REPT |            |        | 0:38  |
| research       | DONE |            |        | 0:47  |
| reporting      | DONE |            |        | 0:35  |
| AWS            | DONE |            |        | 4:11  |
| AWS            | DONE |            |        | 0:37  |
| meeting        | REPT |            |        | 0:44  |
| meeting        | REPT |            |        | 2:44  |
| testing        | DONE |            |        | 0:09  |
| reporting      | REPT |            |        | 0:37  |
| research       | DONE |            |        | 3:02  |
|                |      |            |  42:09 |       |
| meeting        | REPT |            |        | 2:12  |
| meeting        | REPT |            |        | 1:36  |
| implementation | DONE |            |        | 1:13  |
| planning       | DONE |            |        | 0:27  |
| implementation | DONE |            |        | 1:48  |
| bugfix         | DONE |            |        | 1:25  |
| AWS            | DONE |            |        | 0:04  |
| bugfix         | TODO |            |        | 0:01  |
| implementation | DONE |            |        | 4:36  |
| implementation | CNCL |            |        | 0:17  |
| deployment     | DONE |            |        | 0:50  |
| bugfix         | DONE |            |        | 0:18  |
| planning       | DONE |            |        | 0:10  |
| testing        | DONE |            |        | 1:05  |
| miscellaneous  | DONE |            |        | 1:29  |
| reporting      | DONE |            |        | 0:22  |
| bugfix         | DONE |            |        | 0:05  |
| miscellaneous  | DONE |            |        | 0:29  |
| reporting      | DONE |            |        | 0:56  |
| implementation | DONE |            |        | 2:34  |
| miscellaneous  | DONE |            |        | 0:19  |
| miscellaneous  | DONE |            |        | 0:56  |
| AWS            | DONE |            |        | 0:15  |
| research       | DONE |            |        | 0:58  |
| implementation | DONE |            |        | 17:44 |
|                |      |            |  20:48 |       |
| meeting        | REPT |            |        | 1:17  |
| meeting        | REPT |            |        | 0:54  |
| meeting        | REPT |            |        | 0:27  |
| implementation | DONE |            |        | 0:52  |
| bugfix         | DONE |            |        | 0:27  |
| bugfix         | DONE |            |        | 1:13  |
| bugfix         | DONE |            |        | 2:56  |
| implementation | DONE |            |        | 0:03  |
| implementation | DONE |            |        | 0:18  |
| bugfix         | DONE |            |        | 0:14  |
| bugfix         | DONE |            |        | 0:06  |
| implementation | DONE |            |        | 2:12  |
| implementation | DONE |            |        | 5:12  |
| implementation | STRT |            |        | 2:48  |
| implementation | DONE |            |        | 0:41  |
| bugfix         | DONE |            |        | 0:06  |
| implementation | WAIT |            |        | 1:02  |
|                |      |            |  23:06 |       |
| deployment     | DONE |            |        | 0:05  |
| implementation | DONE |            |        | 9:39  |
| implementation | DONE |            |        | 2:37  |
| bugfix         | WAIT |            |        | 2:33  |
| bugfix         | DONE |            |        | 0:37  |
| bugfix         | DONE |            |        | 0:39  |
| implementation | WAIT |            |        | 4:36  |
| bugfix         | DONE |            |        | 2:20  |
|                |      |            |   3:37 |       |
| pr_review      | DONE |            |        | 0:22  |
| pr_review      | DONE |            |        | 2:11  |
| pr_review      | DONE |            |        | 1:04  |
|                |      |            |  10:42 |       |
| implementation | DONE |            |        | 10:42 |
#+END:

[wigingtont2]

@KaratasFurkan That's definitely helpful. I was mainly looking for examples of actual usage and edge cases, since I've never used this feature. Stuff like one versus many tags or variation in which column has the tags are ones I'd thought of already.

My current implementation has one major bug I need to fix, and then I want to see if I can improve the performance any. I think it's already fast enough for most cases though. I'm getting ~0.05-0.15 seconds to process a file with 1,000 overlays applied. Something isn't scaling linearly though, because a 20,000 overlays torture file takes ~4.0-4.5 seconds. This is on Emacs 29 though, and I've heard that they improved performance for overlays in general.

[wigingtont2]

The issue was using add-to-list for populating org-rainbow-tags--overlays. I changed that to use push, and the 20,000 overlays file now takes ~1.15 seconds. There's much less change for the 1,000 overlays file though. It's coming in at ~0.035-0.12 seconds now.

As far as I'm aware, the only downside of push compared to add-to-list is that it doesn't check for uniqueness, but I'm not sure that's really needed. The way org-rainbow-tags--overlays is populated shouldn't add any duplicates in the first place.

Also, delete-overlay doesn't seem to care if you call it with an overlay that's already been removed. You do get a message about it, but there's very little performance impact. Deleting 20,000 took ~0.005 seconds, and that same list with all the elements duplicated to bring the total up to 1,200,000 took ~0.037 seconds.

cl-pushnew seems modestly faster than add-to-list, if you think enforcing no duplicates needs to stay.