Re: [O] [feature proposal] Export in foreign buffers - ASCII (ox-ascii)
Hello Nicolas, Many thanks for your swift response! On 2018-10-24, at 09:04 , Nicolas Goaziou wrote: > [...] > I see you are not including Latin1 export. Is there any reason to > implement pure ASCII export? Wouldn't UTF-8 be sufficient? > > More generally, I wonder if, in 2018, it still makes sense to provide > ASCII-only and Latin1 export. I was of the same opinion, hence I didn't include Latin-1. Is pure ASCII still useful? I admit using UTF-8 99% of the time. But sometimes there's the odd guy using that arcane email client and who complains that my message came out garbled. That's when the pure ASCII comes in handy. That will always work; 100% guaranteed. No strong feelings on whether to include pure ASCII or not. On the other hand, it seems so cheap implementation wise, you might just as well choose to include all three (i.e. UTF-8, ASCII, and Latin-1). > [...] > (let ((org-ascii-charset 'utf-8)) >(org-export-replace-region-by 'ascii)) > > would be simpler. Bummer! This was my initial version, actually. But for some reason it didn't seem to work (maybe I forgot eval-region?). You are right (of course), and I have switched my implementation back to my original approach (which copied below for completeness). > The manual needs to be updated, too. > [...] Indeed. Many thanks again and cheers, --alexander -- (defun org-ascii-convert-region-to-ascii () "Assume the current region has Org syntax, and convert it to plain ASCII. This can be used in any buffer. For example, you could write an itemized list or a table in Org syntax in a mail buffer and then use this command to convert it." (interactive) (let ((org-ascii-charset 'ascii)) (org-export-replace-region-by 'ascii))) (defun org-ascii-convert-region-to-utf8 () "Assume the current region has Org syntax, and convert it to UTF-8. This can be used in any buffer. For example, you could write an itemized list or a table in Org syntax in a mail buffer and then use this command to convert it." (interactive) (let ((org-ascii-charset 'utf-8)) (org-export-replace-region-by 'ascii))) --
Re: [O] [feature proposal] Export in foreign buffers - ASCII (ox-ascii)
Hello Nicolas, On 2018-10-25, at 16:56 , Nicolas Goaziou wrote: > [...] > I added the functions to "ox-ascii.el", with an autoload cookie, > a simplified docstring, and an entry in the manual. > [...] Wow, many thanks for being so kind as to include them! That was faster and way easier than I had anticipated. ;-)) Many thanks again! --alexander
[O] [feature proposal] Export in foreign buffers - ASCII (ox-ascii)
Dear Org-Mode Developers, I was missing convert-region functions in the ox-ascii export back-end as are provided by the HTML, LaTeX, Texinfo, and MarkDown back-ends [1], and hence crafted my own (copied below) to go into my init file. My use case is composing emails using notmuch-message-mode. [1] https://orgmode.org/manual/Export-in-foreign-buffers.html I though this feature might be useful to others, too, and would likely also seem a low hanging fruit to implement? ;-)) It would be awesome to see this new feature in one of the next releases of ox-ascii. Many thanks in advance and cheers, --alexander -- (defun org-ascii-convert-region-to-ascii () "Assume the current region has org-mode syntax, and convert it to plain ASCII. This can be used in any buffer. For example, you could write an itemized list in org-mode syntax in a Mail buffer and then use this command to convert it." (interactive) (let ((my/org-ascii-charset org-ascii-charset)) (setq org-ascii-charset 'ascii) (org-export-replace-region-by 'ascii) (setq org-ascii-charset my/org-ascii-charset))) (defun org-ascii-convert-region-to-utf8 () "Assume the current region has org-mode syntax, and convert it to UTF-8. This can be used in any buffer. For example, you could write an itemized list in org-mode syntax in a Mail buffer and then use this command to convert it." (interactive) (let ((my/org-ascii-charset org-ascii-charset)) (setq org-ascii-charset 'utf-8) (org-export-replace-region-by 'ascii) (setq org-ascii-charset my/org-ascii-charset))) --
[feature request] org-agenda-skip-unless
Hello All,
I wanted to improve a bit on my current, simple agenda setup
(setq org-agenda-custom-commands
'(("n" "Agenda and all TODOs"
((agenda "" nil)
(alltodo "" ((org-agenda-block-separator "")))
and achieve an agenda with three sections:
1) (agenda "" nil)
2) all todos with some planning information (scheduled or deadline)
3) all todos without any planning information
Number 1 I already have. Number 3 can be achieved with
(org-agenda-skip-function '(org-agenda-skip-if nil '(scheduled deadline)))
But what about number 2? I searched the docs and code, bout couldn't
seem to find anything.
I hence ended up with the idea that I would need a new function,
hypothetically (and cunningly) called org-agenda-skip-unless, which
would do the same as org-agenda-skip-if, but with inverted logic.
With that, my dream agenda would be:
(setq org-agenda-custom-commands
'(("n" "Agenda and all TODOs"
((agenda "" nil)
(alltodo "" ((org-agenda-block-separator "")
(org-agenda-overriding-header "TODO items with a date:")
(org-agenda-skip-function '(org-agenda-skip-unless nil
'(scheduled deadline)
(alltodo "" ((org-agenda-block-separator "")
(org-agenda-overriding-header "Other TODO items:")
(org-agenda-skip-function '(org-agenda-skip-if nil
'(scheduled deadline)
Many thanks and looking forward to your thoughts,
--alexander
Re: basic org questions
Emanuel Berg via "General discussions about Org-mode." writes: > Re: basic org questions > Russell Adams wrote: > >>> 1) How do I make a region italic? [...] >> >> https://emacs.stackexchange.com/questions/18101/org-mode-multi-line-emphasis-and-bold > > OK, thanks, not the same good looking syntax tho but > good enough for government work, I suppose. > [...] I use visual-line-mode (which also enables word-wrap by default) for Org files. For instance: (add-hook 'org-mode-hook (lambda () (turn-off-auto-fill) (visual-line-mode) (flyspell-mode))) That way lines get wrapped to the buffer's width visually, but physically are still single lines. Hence, I can add italics. bold, whatever, across multiple _visual_ lines, and the formatting is what I expect, because in reality it's a single _physical_ line only. Hoping to have helped, --alex
Re: Org mode for meeting minutes
Hello Adam, All, Adam Spiers writes: > [...] >> His mail is from 2008 and a lot has happened in the mean time. I would >> suggest that today (1) and (2) can be handled with normal org export or >> even pandoc. Inline tasks[2] help a lot to add, well inline tasks. For (3) >> and (4) he mentions a dynamic block that could collect all action >> items. I have used this suggestion very successfully for my own purposes to implement (3) and (4): https://orgmode.org/worg/org-tutorials/org-meeting-tasks.html Inline tasks are an element here, too. It also features a function to extract all assigned actions and collect them in one place. Not a table though, but in exchange for keeping them as headings, they can appear in agenda views etc. Fully agree that (1) and (2) are fully covered by org export these days, btw. Just my two cents anyway. >> I never found that dynamic block he mentions, so I hacked one up (which >> was suprisingly easy). I haven't packaged it but the gist of it is >> below: > > [snip] > > I have no doubt that your modern solution is much better than my ancient > hack, but just for the record, the latter can be found here: > > https://github.com/aspiers/emacs/blob/master/.emacs.d/init.d/as-gtd.el#L79-L117 > [...] Thanks for sharing your code. It would seem to me that this can be very usefully combined with the worg tutorial I am pointing at above, to create a workflow. Cheers, --alexander
Re: [Interest] Determanistic Org IDs
Hello Timothy, TEC writes: > [...] > Pros: > - Reduced 'noise' if exported files are commited - (With HTML) > links to particular elements in a file keep working across >multiple versions, most of the time > - (With HTML) links become more descriptive > > Cons: > - Inceased chance of ID collisions across files Longer IDs I > - think this could make a nice option for export settings. I'm > - aware of the 9.5 feature freeze, but thought I'd mention the > - idea to see if there's any interest in it. > > If you want to see what I've got happening, see > https://tecosaur.github.io/emacs-config/config.html#nicer-generated-heading. > [...] Interesting. Just a thought: have you considered computing a SHA-2 hash over either the totality of the heading and all its children (if you want the links to change when the content changes), or only the heading itself (keeping the id invariant for as long as the heading remains unchanged, but content below it can change)? This would have the advantage of solving both, your "noise issue" and at the same time removing the threat of id collisions; but at the cost of not having "speaking" links. Hoping to have helped, --alexander
Re: Support for simultaneous running clocks?
Hello Carlo, Org Devs,
Carlo Tambuatco writes:
> I don't know if anyone has suggested or is working on the ability for
> org mode to keep track of multiple running clocks simultaneously. I'd
> like the ability to keep track of, for example, how long something
> takes to compile while I keep track of how long I am working on some
> other project task at the same time.
I have worked with quite a couple or work tracking tools, Org being one
of them (albeit my favourite one). I learnt that running multiple clocks
in parallel was an idea that didn't work out for me. In reality, I'm
only ever doing one thing at a time [1]. If I want to bill that one
thing multiple times, I clock it once, and just duplicate the time
clocked to "the other" project(s). Or, with Org an elisp support, you
can create a "magic timer", whose recorded times will be automatically
copied to all "linked" projects. If I ran multiple clocks at the same
time, I would - more often than not - forget to start or stop one of
them, messing up my accounting. Hence, my baseline is "run a single
clock only, tracking what I'm doing, and do any doubling-up-magic in the
accounting".
Also, to gauge build times, it might seem more promising to make the
bench marking part of the build process itself ("Build took ...")?
[1] https://hbr.org/2010/12/you-cant-multi-task-so-stop-tr
Just my two cents anyway.
Cheers,
--alexander
Re: [feature request] org-agenda-skip-unless
Hello Kyle,
Kyle Meyer writes:
> [ sorry for the slow response ]
Same here...
> [...]
>> With that, my dream agenda would be:
>>
>> (setq org-agenda-custom-commands
>> '(("n" "Agenda and all TODOs"
>> ((agenda "" nil)
>> (alltodo "" ((org-agenda-block-separator "")
>> (org-agenda-overriding-header "TODO items with a date:")
>> (org-agenda-skip-function '(org-agenda-skip-unless nil
>> '(scheduled deadline)
>
> org-agenda-skip-if accepts notscheduled and notdeadline conditions.
> Passing them both to a single org-agenda-skip-if wouldn't do what you
> want because org-agenda-skip-if combines its conditions with `or'.
> However, you could combine two separate org-agenda-skip-if calls:
>
> (org-agenda-skip-function
> '(and (org-agenda-skip-if nil '(notscheduled))
>(org-agenda-skip-if nil '(notdeadline
Ha, that's genius! Many thanks for sharing your wisdom!
While I'm apparently still on the learning curve, would you agree that
wishing for some more documentation around org-agenda would not bear the
danger of fostering opulence? ;-)
Many thanks and happy holidays,
--alexander
Re: How to use `open` to handle `message:*` links on macOS
Hello Tim, Tim Visher writes: > [...] > I'd like to be able to whack `C-c C-o` on `message:*` links on macOS and > have it call `open` on the contents. Is there a way to make that happen? > > My intent is to be able to save a deep link to a Mail.app message in an org > document. > [...] In my setup, I'm using this: Begin Quote - (org-add-link-type "mac-mail" 'org-mac-mail-link-open) (defun org-mac-mail-link-open (mid) "Visit the email message with message id MID." (start-process "open-mail" nil "open" (format "message:%%3C%s%%3E" mid))) - End Quote -- It gives me a new link type "mac-mail" for org-insert-link. Copy the message ID (without the angle brackets) from Mail.app, and insert it as the link location. This is a manual process, of course, but then I'm not using it often, and I don't need it for anything else but Mail.app. org-mac-link as suggested by Diego offers much more convenience by automating the entire process, and by giving you access to many other apps, too. So you might prefer that if you are going to use it often. Hoping to have helped, --alex
Re: How to use `open` to handle `message:*` links on macOS
Hello Tim, Tim Visher writes: > [...] > I do indeed trigger the capture by switching over to Emacs and whacking my > org-capture keybinding (`C-c C`). I have a todo item that's been sitting in > my list for a very long time to figure out how to move my email habits into > emacs but I've never gotten around to it. In this case it's even worse > because the only reason I'm using Mail.app in the first place is because my > work email got moved to an Exchange server so I now don't have a good web > based interface to read mail anymore like my beloved Gmail. > > One of these days though I'm going to break the habit and move email > directly into Emacs. :) I was in the exact same situation as you until about half a year ago, which was when I decided to (finally) act on my "move email to emacs" task. Coincidentally I have recently released a blog post covering some of the basic aspects of planning the switch: https://condition-alpha.com/blog/?p=1792 IMO, a decent amount up-front planning is crucial. With notmuch, emacs's mail message handling infrastructure, and elisp, anything is possible; the sky is the limit. Email is too central to our daily work to start with the defaults and see where it takes you (IMO). So think well what your dream email workflow is, and then work towards that. The smallest, and most isolated task is perhaps configuring msmtp for sending mail; so why not start with that? Importing existing mailboxes (from Apple's mail app in my case), is another important issue (which I'll cover in a future blog post). Once you've imported some mail, you can toy around with notmuch in emacs, and the settings, until you get a gist of how things work, and how far you are from your goal. Your everyday real work is still in Apple's mail app. Once you're confident that you'll be able to survive with your emacs setup, then you can make the move, and stop using Apple's mail app. If you start a big all-in-one migration, and it fails, you're left with a big mess. Thus, doing things step-by-step with an option to revert each step if it doesn't work, is crucial, too. Hoping to have helped, --alexander
Re: A requires/provides approach to linking source code blocks
> On 9. Jul 2021, at 19:01, autofrettage wrote: > > Tim wrote: >> This could just be me, but recently, I'm becoming very concerned >> about the growth of additional features and options in org mode. > > Count me in. I have been mostly been hanging around in the shadows, but this > is serious enough for me to wave a flag on the right side. > […] Same concern here. — Alex smime.p7s Description: S/MIME cryptographic signature
Re: How to use `open` to handle `message:*` links on macOS
Hello Tim, Tim Visher writes: > [...] > Thanks for the tips here. I finally got around to trying them out. Here's > what I ended up with and it's working perfectly. > [...] Glad I could be of assistance! > Pairing that with my org-capture TODO Current Mail Template is a dream come > true. :) > [...] That's interesting how you pull the information from Mail app. How do you trigger the capture? Do you have to select the message in Mail app, then move over to Emacs and trigger the capture there? or do you have a way to trigger the Emacs capture from within Mail app? The next level of productivity could perhaps be to switch to notmuch[1], and do all you email from within Emacs. Use yasnippet[2] for composing mails. And have snippets be presented to you by company[3]. Just saying... ;-) [1] https://notmuchmail.org/ [2] http://joaotavora.github.io/yasnippet/ [3] https://company-mode.github.io/ Cheers, --alexander
Re: [BUG] - Statistics cookie is part of the org heading title
Would “fixing” this also remove the statistics cookie from agenda views? That would be a pity as I find it very useful there for my ways of using Org. Cheers, --alex -- www.condition-alpha.com / @c_alpha Sent from my iPhone; apologies for brevity and autocorrect weirdness. > On 4. May 2022, at 14:24, Ihor Radchenko wrote: > > Ignacio Casso writes: > >> I replied to this bug report yesterday via the "reply via email to" >> button in >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-05/msg00058.html, >> assuming it would send it to the org-mode list, but now I see that it >> was only sent to Fabian. > > It is not directly related to Org, though indeed annoying. I reported > this unexpected behaviour to mail...@gnu.org > >> Still, I think it might be interesting to compare this topic with the >> one I linked in my reply, >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html, >> which it's basically the same bug report but about COMMENT keywords. In >> that regard, I have tested that org-capture targets do work regardless >> of statistcs cookies. Could not something equivalent be done so that >> they also work regardless of COMMENT keywords? Feel free to reply in >> that other thread if you feel this is off-topic here. > >> This bug is related with the issue I reported in >> https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00293.html. The >> problem is that `org-heading-components' uses >> `org-complex-heading-regexp', which does not consider statistics >> cookies, and neither COMMENT keywords as I reported. I think it should be >> updated to consider both. > > Note that org-complex-heading-regexp-format does consider statistics > cookies, but only at the beginning/end of the headline title. > Unfortunately, it is impossible to provide generic printf format to > match a headline title with arbitrary statistics cookies inserted in the > middle of it. > > As for your other report, it is a hard one - org-complex-heading-regexp > is hard to modify because we guarantee certain match groups and its hard > to fit COMMENT in there without breaking backward-compatibility. > > I generally dislike the idea of the available plethora of analytic > regexps with numbered match groups. I am currently working on > generalised Org element matcher that provides named groups for arbitrary > Org syntax elements, including headlines. > > Best, > Ihor > smime.p7s Description: S/MIME cryptographic signature
Re: [BUG] - Statistics cookie is part of the org heading title
Cool! Thanks for the swift confirmation. --alex -- www.condition-alpha.com / @c_alpha Sent from my iPhone; apologies for brevity and autocorrect weirdness. > On 4. May 2022, at 15:00, Ihor Radchenko wrote: > > Alexander Adolf writes: > >> Would “fixing” this also remove the statistics cookie from agenda views? >> That would be a pity as I find it very useful there for my ways of using >> Org. > > No > smime.p7s Description: S/MIME cryptographic signature
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Daryl Manning writes: > [...] > I'd just be excited to have us run through the basic use cases and then see > some more "tricky" ones. I imagine there are things we'd just have to > say... too tricky for (eg. flight takes off in one TZ and range allows it > to land in timezone... stuff like that might be tricky.). > [...] This case doesn't seem tricky to me for as long as both time specifications have time zone information. For cross-timezone flights, the VCS calendar appointments airlines send out by email to customers typically have start and end times given in UTC. The user's calendaring app will convert that to the time zone in which the OS of the user's laptop currently pretends to be. Same thing for flights spanning DST changeovers, btw. A UTC specification is unambiguous in this case, too.
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Robert Horn writes: > [...] > Getting the rules and explanation clear is the issue. It's a mistake > that a great many people make with scheduling meetings. Those two > behaviors need different encodings because they behave differently. > [...] AFAIU, setting "clear rules" for this seems impossible. Around DST changeovers, there are ambiguous time-of-day specifications, which occur more than once on that date. Hence, for such events UTC time specifications must be used, or everybody is doomed to either arrive hours early, or hours late for the appointment.
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Tim Cross writes: > [...] > Consider this scenario. I have a meeting with two other people. We are > all in different timezone. What is the timezone of the meeting? > > Thinking more about it, in this situation, you probably just need to > set the meeting time to UTC and that would work. > [...] Or to any other timezone. The key point here is that you _do_ specify a timezone. Then, everybody can convert that and have it displayed in any timezone they find useful.
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Robert Horn writes: > [...] > The issue is clarity of the expected rules for the format. If I > schedule a meeting for 10:05 DST, > [...] In all calendaring software I have used thus far, I don't do that. I can specify a date and time of day only (but never "DST"). The software then works out (likely with the help of the OS, and using POSIX APIs) whether that is DST or not, whenever the event's offset to UTC is needed (e.g. to display the event in another timezone).
Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Ihor Radchenko writes: > [...] > I don't imply that. What I am saying is that we first need to decide on > syntax and provide basic support for time zones. It will already be > helpful as I won't need to convert timestamps into local time or think > if I need to convert timestamps ahead of time before a flight to > different time zone. > > More things can be implemented once we have the basic support. > [...] > > Converting timestamps with time zone to local time is indeed one of the > basic features we need to support. > [...] I fully concur with Ihor.
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Hello Ihor, Many thanks for your swift response. Ihor Radchenko writes: > [...] >> Does anyone recall the rationale for this different behaviour? > > The "default" behaviour is to store summary of all the child property > value in each parent. > [...] > This is, however, not possible for CLOCKSUM because clocksum is not an > actual property, but a "special" one - it is derived from logbook data. > That's why its behavior is different. I see; thanks for explaining the rationale. Practically this seems to imply that for doing estimates, and to minimise my own confusion, I should probably use a strategy where I put all the effort properties in a subtree at the same level (for instance leaf-nodes-only, or top-nodes-only). And additionally, I should never modify effort properties by hand, but using the columnview overlay only (since that will not allow me to modify efforts computed from child nodes). > In fact, CLOCKSUM property does not support custom summaries. ??? >> Is there any way to change the summation behaviour for either or both >> column types? > > It is currently hard-coded. (Although, it is not too hard add some kind > of switch). > [...] I think that instead of a switch, I would prefer the columnview dblock to get a :formatter added. Knowing how the values have been computed in the dblock's write function, I can re-calculate whatever data I need in the formatter. I am already using this approach successfully with the clocktable dblock to generate invoices for me. Compared to a new switch, it would seem to me that adding a :formatter to the columnview dblock has several advantages: - it would likely be a smaller code change; - instead of implementing a single, new behaviour (activated by switch) it would give users the flexibility to implement any new behaviour they might want (user-supplied :formatter function). Thus, from my point of view, having a :formatter for the columnview dblock would be quite fabulous. 濾 Cheers, and looking forward to your thoughts, --alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Many thanks for the pointers, Ihor!
The instructions were clear and concise, so the patch creation went
smoothly. Results attached below.
I cloned the Org repository from git://git.sv.gnu.org/emacs/org-mode.git
and followed the instructions at
https://orgmode.org/worg/org-contribute.html#first-patch. I hope I
succeeded for most part. ;-)
`make compile` didn't complain at all, and `make test` ended with the
following:
Begin Quote -
Ran 1254 tests, 1238 results as expected, 4 unexpected, 12 skipped (2024-04-15
18:39:50+0200, 57.383197 sec)
2 expected failures
4 unexpected results:
FAILED ob-calc/matrix-inversion ((should (equal "[[-1, 0.625, -0.125],
[0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]" (org-babel-execute-src-block)))
:form (equal "[[-1, 0.625, -0.125], [0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]"
"[[-1, 625e-3, -125e-3], [250e-3, -500e-3, 250e-3], [500e-3, 125e-3,
-125e-3]]") :value nil :explanation (arrays-of-different-length 63 77 "[[-1,
0.625, -0.125], [0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]" "[[-1, 625e-3,
-125e-3], [250e-3, -500e-3, 250e-3], [500e-3, 125e-3, -125e-3]]"
first-mismatch-at 6))
FAILED test-ob-shell/bash-uses-assoc-arrays ((should (equal "two"
(org-trim (org-babel-execute-src-block :form (equal "two" "three") :value
nil :explanation (arrays-of-different-length 3 5 "two" "three"
first-mismatch-at 1))
FAILED test-ob-shell/bash-uses-assoc-arrays-with-lists ((should (equal "20
cm" (org-trim (org-babel-execute-src-block :form (equal "20 cm" "50 dl")
:value nil :explanation (array-elt 0 (different-atoms (50 "#x32" "?2") (53
"#x35" "?5"
FAILED test-org-table/sort-lines ((should (equal "| a | x |\n| B | 4 |\n|
c | 3 |\n" (org-test-with-temp-text "| a | x |\n| c | 3 |\n| B | 4 |\n"
(org-table-sort-lines nil 97) (buffer-string :form (equal "| a | x |\n| B |
4 |\n| c | 3 |\n" #("| B | 4 |\n| a | x |\n| c | 3 |\n" 0 9 (face org-table) 9
10 (face org-table-row) 10 19 (face org-table) 19 20 (face org-table-row) 20 29
(face org-table) 29 30 (face org-table-row))) :value nil :explanation
(array-elt 2 (different-atoms (97 "#x61" "?a") (66 "#x42" "?B"
12 skipped results:
SKIPPED org-missing-dependency/test-ob-R ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-clojure ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-haskell-ghci ((skip-unless nil)
:form nil :value nil)
SKIPPED org-missing-dependency/test-ob-julia ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-lua ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-maxima ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-octave ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-python ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-ruby ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-ob-scheme ((skip-unless nil) :form nil
:value nil)
SKIPPED org-missing-dependency/test-org-attach-git ((skip-unless nil) :form
nil :value nil)
SKIPPED test-org-fold/org-fold-display-inline-images ((skip-unless (not
noninteractive)) :form (not t) :value nil)
make: *** [test] Error 1
- End Quote --
At first glance, nothing seems to point into a direction suggesting that
I had broken anything (i.e. nothing about any breakage relating to
columnview)?
Many thanks and looking forward to your thoughts,
--alexander
>From c21b18475dd154eed8d3f2489daa5a468531dc82 Mon Sep 17 00:00:00 2001
From: Alexander Adolf
Date: Sun, 14 Apr 2024 18:14:05 +0200
Subject: [PATCH 1/2] lisp/org-colview.el: add formatter parameter to colview
dynamic block
* lisp/org-colview.el (org-dblock-write:column view): Factor out the
existing formatting code to new function
org-columns-dblock-write-default, and honour new dblock parameter
:formatter for specifying a different formatting function.
(org-columns-dblock-write-default): New function with current
formatting code.
(org-columns--capture-view): Amend docstring to better explain the
format of the data being passed to the formatting function.
(org-clock-clocktable-formatter): New option to define a global
default formatting function, defaulting to the current behaviour.
* doc/org-manual.org (Capturing column view): Describe new :formatter
parameter.
* etc/ORG-NEWS (New option ~org-columns-dblock-formatter~): Announce
new option.
(=colview= dynamic block supports custom formatting function):
Describe new custom formatting fun
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes:
> Alexander Adolf writes:
>
>>> In fact, CLOCKSUM property does not support custom summaries.
>>
>> ???
>
> AFAIU, you cannot do %CLOCKSUM{max}.
Ah, I see; that's what you meant.
>> [...]
>> Thus, from my point of view, having a :formatter for the columnview
>> dblock would be quite fabulous. 濾
>
> This will not prevent the property values from being changed by column
> view.
Correct. But I don't see that as a problem, as this has been the
behaviour of effort properties since - always.
> In any case, making column views more flexible is welcome.
> [...]
Lure me into contributing a patch? fair enough; I might just as well
give that a try. I presume I'd get some support here on this list?
And/or on IRC (e.g. libera.chat#org-mode)?
I have signed FSF copyright assignment for all of Emacs, so I guess
nothing would need to be done at the paperwork level?
Cheers,
--alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes: > [...] >> `make compile` didn't complain at all, and `make test` ended with the >> following: >> ... >> 4 unexpected results: >>FAILED ob-calc/matrix-inversion >>FAILED test-ob-shell/bash-uses-assoc-arrays >>FAILED test-ob-shell/bash-uses-assoc-arrays-with-lists >>FAILED test-org-table/sort-lines > > MacOS? There are known issues with locale rules in MacOS that may cause > test failures. > [...] Yes, macOS. So I won't be worried about these. --alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Many thanks for your swift response!
Ihor Radchenko writes:
> [...]
> When suggesting #+vindex, I was referring to
> org-columns-dblock-formatter variable.
> [...]
> #+cindex: @samp{formatter}, dynamic block parameter
I see; thanks for explaining. I've added both:
Begin Quote -
- =:formatter= ::
#+cindex: @samp{formatter}, dynamic block parameter
#+vindex: org-columns-dblock-formatter
A function to format column view data and insert it into the buffer.
See the option ~org-columns-dblock-formatter~.
- End Quote --
> [...]
> I see how. It is because CELL-CONTENT is not the original heading. It is
> the heading name processed with `org-columns--clean-item'.
>
> `org-column--clean-item' removes statistics cookies among other things.
> It actually removes more, leading to some edge cases in your patch:
>
> ** TODO Foo
>
> ** TODO src_elisp{"Hello"} world
>
>
> #+begin: columnview :id global :link t
> | <25> | | <3> | |
> | ITEM | TODO | PRIORITY | TAGS |
> |---+--+--+--|
> | [[file:/tmp/test.org::*Foo][Foo]] | TODO | B| |
> | [[file:/tmp/test.org::*src_elisp{"Hello"} world][world]] | TODO | B
> | |
> #+end:
>
> Note how inline src block is stripped from the link description.
Ah, `org-column--clean-item'; well spotted!
Two observations:
1) As is now, I'm generating the links in the data collection function
`org-columns--capture-view'. As `org-column--clean-item' is called
from code that runs after the data collection,
`org-column--clean-item' was probably never designed to be able to
handle strings containing links. That it still did sort of "the right
thing" seems more luck than anything else?
2) Considering what happens when I do `org-store-link' and
`org-insert-link', it would seem more advisable to:
a) move the link generation to the new formatting function
(re-removing it from `org-columns--capture-view');
b) pass the "cleaned" string to `org-link-make-string' as both, the
link and the description parameter.
> We should probably also change org-clock to use
> `org-columns--clean-item'.
> [...]
As a separate patch, or as a third commit to the patch we are discussing
now?
Many thanks and looking forward to your thoughts,
--alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes: > [...] > It would make sense then to include `org-quote-vert' call into > `org-columns--clean-item' then. Good point. I'll move the call to `org-quote-vert' there. > [...] >> (defun org-columns--capture-view (maxlevel match skip-empty exclude-tags >> format local) >>"Get the column view of the current buffer. >>... >> +When LOCAL is non-nil, only capture headings in current subtree. When >> +LINK is non-nil, item headlines will be linked to their origins. > > Looks like you removed the LINK parameter, but forgot to remove its > description from the docstring. Ah, ashes to my head for overlooking this. Well spotted! >> + (let ((search (org-link-heading-search-string >> raw))) >> + (org-link-make-string >> + (if (not (buffer-file-name)) search >> +(format "file:%s::%s" (buffer-file-name) >> search)) >> + cleaned)) > > This will unconditionally generate file: links, even when the dynamic > block only refers to headings in the same buffer. The clock tables do > use internal links when appropriate (see `org-clock-get-table-data'). Um, actually it does exactly the same as `org-clock-get-table-data' (from where I borrowed the code snippet): it generates file: links in buffers visiting files, and local links in buffers not visiting any file. Perhaps you were looking at a test case in which `org-clock-get-table-data' gets called in an Org buffer that is not visiting any file? > [...] > I am attaching a patch containing test case making sure that internal > links are generated when appropriate. The test case is failing with > the latest version of your patch. > > If you can, please add some more tests like mine checking > `org-columns--clean-item'. > [...] Thanks for the springboard hint to get started with adding tests, which I'm happy to do, of course. Is there any way for me to run a specific subset of the tests only, for instance "make test colview", or similar? Many thanks and cheers, --alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes:
> [...]
> Calling `org-columns--clean-item' is a must to create a valid table.
True.
Additionally, it would seem advisable to call `org-quote-vert' on the
data, too, as `org-columns--clean-item' does not take care of vertical
bars? This is done in a previous step in `org-columns--capture-view',
however, so that the vertical bars get converted to "\vert" before the
formatting function gets called.
`org-link-heading-search-string', and `org-link-make-string' (both
called from the formatting function _after_ `org-columns--clean-item')
OTOH take care of the link's path and description parts being
appropriate for a link.
Thus, we have both layers of safeguarding: "link-safe" data is generated
from "table-safe" data.
> [...]
>> 2) Considering what happens when I do `org-store-link' and
>>`org-insert-link', it would seem more advisable to:
>> [...]
>
> I do not recall seeing `org-store-link' in the patches you submitted.
> So, I am not sure what you are talking about. May you elaborate?
> [...]
Apologies for not having been clear enough. With "when I do" I wanted to
refer to the "cleanup" of headline text when using `org-store-link' and
`org-insert-link' interactively.
I have moved the link generation to the formatting function as
mentioned. This also removes the need for any new function parameters,
since the formatting function receives the dynamic block's parameter
list, which contains a :link property when set in the #+BEGIN line.
Kindly find updated patches below. I hope to have succeeded in
addressing all your comments; that was my intention at least.
Many thanks and looking forward to your thoughts,
--alexander
>From a36dba46a63d7d879bf2faf3c4c885b9ea3e28ad Mon Sep 17 00:00:00 2001
From: Alexander Adolf
Date: Sun, 14 Apr 2024 18:14:05 +0200
Subject: [PATCH 1/2] lisp/org-colview.el: Add formatter parameter to colview
dynamic block
* lisp/org-colview.el (org-dblock-write:column view): Factor out the
existing formatting code to new function
`org-columns-dblock-write-default', and honour new dblock parameter
:formatter for specifying a different formatting function.
(org-columns-dblock-write-default): New function with current
formatting code.
(org-columns--capture-view): Amend docstring to better explain the
format of the data being passed to the formatting function.
(org-clock-clocktable-formatter): New option to define a global
default formatting function, defaulting to the current behaviour.
* doc/org-manual.org (Capturing column view): Describe new :formatter
parameter.
* etc/ORG-NEWS (New option ~org-columns-dblock-formatter~): Announce
new option.
(=colview= dynamic block supports custom formatting function):
Describe new custom formatting function feature.
---
doc/org-manual.org | 7 +++
etc/ORG-NEWS| 29 +
lisp/org-colview.el | 41 +++--
3 files changed, 71 insertions(+), 6 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index d24230568..000783772 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6014,6 +6014,13 @@ This dynamic block has the following parameters:
Specify a column attribute (see [[*Column attributes]]) for the dynamic
block.
+- =:formatter= ::
+
+ #+cindex: @samp{formatter}, dynamic block parameter
+ #+vindex: org-columns-dblock-formatter
+ A function to format column view data and insert it into the buffer.
+ See the option ~org-columns-dblock-formatter~.
+
The following commands insert or update the dynamic block:
- ~org-columns-insert-dblock~ ::
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index dbf849422..84ea7cde9 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -999,6 +999,16 @@ even though it does not have its own ID. By giving files top-level id
properties, links to headlines in the file can also be made more
robust by using the file id instead of the file path.
+*** New option ~org-columns-dblock-formatter~
+
+=colview= dynamic blocks now understand a new ~:formatter~ parameter
+to use a specific function for formatting and inserting the contents
+of the dynamic block. This new option can be used to set the global
+default formatting function that will be used for =colview= dynamic
+blocks that do not specify any ~:formatter~ parameter. Its default
+value (the new function ~org-columns-dblock-write-default~) yields the
+previous (fixed) formatting behaviour.
+
** New features
*** ~org-paste-subtree~ now handles =C-u= and =C-u C-u= prefix arguments specially
@@ -1035,6 +1045,25 @@ Example:
: | PROYECTO EMACS |
: #+END:
+*** =colview= dynamic block supports custom formatting function
+
+The =colview= dynamic block understands a new ~:formatter~ parameter,
+which specifies a user-supplied function to format and insert the data
+in the dynamic block.
+
+A global default formatting function for =colview=
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes: > Bastien Guerry writes: > >> Ihor Radchenko writes: >> >>> Thanks! >>> The patch is ready to be merged. >>> Bastien, may you please confirm the FSF records? >>> Alexander should have the copyright signed. >> >> Yes, he has, thanks! > > Applied, onto main. > [...] > Thanks for your contribution! Many thanks for your kind support in getting it in shape; much appreciated. It was my pleasure working with you! One last question though: I'm developing an add-on package which will use the new features. I guess in "Package-Requires:" it should say (org "9.7") ? > [...] > Your name have been added to our contributor list: > https://git.sr.ht/~bzg/worg/commit/73d38812 > [...] More than I deserve... Many thanks and cheers, --alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes:
> [...]
>>> If you can, please add some more tests like mine checking
>>> `org-columns--clean-item'.
> [...]
I have added one test for each new feature (headline linkification, and
formatting function). Also, there's a third patch, which moves the call
to `org-quote-vert' to the cleanup function `org-columns--clean-item' as
you suggested.
Updated patches below.
One more thing caught my eye in `org-dblock-write:columnview' though.
When running the currently (i.e. before my patches) last test in
test-org-colview.el, the one with `org-columns-default-format' set to
"%ITEM %DEADLINE(d) %SCHEDULED(s) %TIMESTAMP(t)", `org-with-wide-buffer'
appears to modify the buffer and advances point by one (before the call
point is at 97, after the call at 98). In all other tests,
`org-with-wide-buffer' does not move point. In
`org-dblock-write:columnview' I have thus moved the sampling of point
for passing to the formatting function to after the call to
`org-with-wide-buffer'.
Many thanks and looking forward to your thoughts,
--alexander
>From 2bb19d9000f29d56295b70754f89f927e7a5740c Mon Sep 17 00:00:00 2001
From: Alexander Adolf
Date: Sun, 14 Apr 2024 18:14:05 +0200
Subject: [PATCH 1/3] lisp/org-colview.el: Add formatter parameter to colview
dynamic block
* lisp/org-colview.el (org-dblock-write:column view): Factor out the
existing formatting code to new function
`org-columns-dblock-write-default', and honour new dblock parameter
:formatter for specifying a different formatting function.
(org-columns-dblock-write-default): New function with current
formatting code.
(org-columns--capture-view): Amend docstring to better explain the
format of the data being passed to the formatting function.
(org-clock-clocktable-formatter): New option to define a global
default formatting function, defaulting to the current behaviour.
* testing/lisp/test-org-colview.el (test-org-colview/dblock): New test
for formatting function.
(test-org-colview/dblock-formatter): New function used in formatting
test.
* doc/org-manual.org (Capturing column view): Describe new :formatter
parameter.
* etc/ORG-NEWS (New option ~org-columns-dblock-formatter~): Announce
new option.
(=colview= dynamic block supports custom formatting function):
Describe new custom formatting function feature.
---
doc/org-manual.org | 7 ++
etc/ORG-NEWS | 29
lisp/org-colview.el | 38 +++-
testing/lisp/test-org-colview.el | 20 +
4 files changed, 89 insertions(+), 5 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index d24230568..000783772 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6014,6 +6014,13 @@ This dynamic block has the following parameters:
Specify a column attribute (see [[*Column attributes]]) for the dynamic
block.
+- =:formatter= ::
+
+ #+cindex: @samp{formatter}, dynamic block parameter
+ #+vindex: org-columns-dblock-formatter
+ A function to format column view data and insert it into the buffer.
+ See the option ~org-columns-dblock-formatter~.
+
The following commands insert or update the dynamic block:
- ~org-columns-insert-dblock~ ::
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index dbf849422..84ea7cde9 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -999,6 +999,16 @@ even though it does not have its own ID. By giving files top-level id
properties, links to headlines in the file can also be made more
robust by using the file id instead of the file path.
+*** New option ~org-columns-dblock-formatter~
+
+=colview= dynamic blocks now understand a new ~:formatter~ parameter
+to use a specific function for formatting and inserting the contents
+of the dynamic block. This new option can be used to set the global
+default formatting function that will be used for =colview= dynamic
+blocks that do not specify any ~:formatter~ parameter. Its default
+value (the new function ~org-columns-dblock-write-default~) yields the
+previous (fixed) formatting behaviour.
+
** New features
*** ~org-paste-subtree~ now handles =C-u= and =C-u C-u= prefix arguments specially
@@ -1035,6 +1045,25 @@ Example:
: | PROYECTO EMACS |
: #+END:
+*** =colview= dynamic block supports custom formatting function
+
+The =colview= dynamic block understands a new ~:formatter~ parameter,
+which specifies a user-supplied function to format and insert the data
+in the dynamic block.
+
+A global default formatting function for =colview= dynamic blocks can
+be set via the new option ~org-columns-dblock-formatter~ which
+defaults to the new function ~org-columns-dblock-write-default~, that
+implements the previous (fixed) formatting behaviour. Hence, the
+default behaviour is identical to previous versions.
+
+The global default function can be overridden for any given =colview=
+dynamic block individually by specifying a custom formatter function
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes: > Alexander Adolf writes: > >> Subject: [PATCH 1/2] lisp/org-colview.el: add formatter parameter to colview >> dynamic block > > Thanks for the patches! > See my comments below. Thanks for your swift review, and most helpful comments! While I'm implementing these, reactions of my own on a select, few comments of yours: > [...] >> +- =:formatter= :: >> + >> + A function for formatting the data in the dynamic block, overriding >> + the default formatting function set in >> + ~org-columns-dblock-formatter~. > > You can also mention that the function also inserts the data. Something > similar to what we do when describe the equivalent option for clock tables: > > - =:formatter= :: > > A function to format clock data and insert it into the buffer. > > Also, if you mention a variable in the manual, please add #+vindex: > entry. Maybe even #+cindex: entry for "formatter", to make the parameter > more discoverable. I kept it to the format of the existing parameter descriptions, which don't create index entries. Happy to add one though. #+cindex would seem more appropriate, as it's not a variable? On a loosely related note: the description of the :formatter parameter of the clock table does not have and index entry either. Should it get one too, then? Btw, I will also move the half-sentence about overriding the default formatting function from the manual to the docstring of org-dblock-write:columnview, where the :formatter parameter is explained, too. It somehow seems more appropriate there, since a user who is looking into implementing a formatting function will most likely be accessing that docstring anyway (so will find the information), whereas the information about the customization variable is likely adding more confusion than it tries to remove for the rest of the Org users (who will likely consult the manual only). > [...] > (defun org-columns--capture-view (maxlevel match skip-empty exclude-tags > format local link) > >> + (push (if (and link (string= p "ITEM")) >> + (let ((search (org-link-heading-search-string >> +cell-content))) >> + (org-link-make-string >> +(if (not (buffer-file-name)) search >> + (format "file:%s::%s" (buffer-file-name) search)) >> +cell-content)) > > In org-clock, we do > > (org-link-make-string >(if (not (buffer-file-name)) search > (format "file:%s::%s" (buffer-file-name) search)) >;; Prune statistics cookies. Replace >;; links with their description, or >;; a plain link if there is none. >(org-trim > (org-link-display-format > (replace-regexp-in-string > "\\[[0-9]*\\(?:%\\|/[0-9]*\\)\\]" "" > headline > > Is there any reason why you did not remove the statistics cookies here > as well? > [...] Somehow (how?) the statistics cookies get removed in my current implementation. org-link-make-string does not remove them (I double checked). I would thus speculate that perhaps the overlay creation (to show description only) removes them? OTOH, I'm happy to add the org-trim part to make things more robust. Will email updated patches when I will have addressed all your comments. Many thanks and cheers, --alexander
Re: columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Ihor Radchenko writes: > Alexander Adolf writes: > >> 4 unexpected results: >>FAILED ob-calc/matrix-inversion ((should (equal "[[-1, 0.625, -0.125], >> [0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]" (org-babel-execute-src-block))) >> :form (equal "[[-1, 0.625, -0.125], [0.25, -0.5, 0.25], [0.5, 0.125, >> -0.125]]" "[[-1, 625e-3, -125e-3], [250e-3, -500e-3, 250e-3], [500e-3, >> 125e-3, -125e-3]]") :value nil :explanation (arrays-of-different-length 63 >> 77 "[[-1, 0.625, -0.125], [0.25, -0.5, 0.25], [0.5, 0.125, -0.125]]" "[[-1, >> 625e-3, -125e-3], [250e-3, -500e-3, 250e-3], [500e-3, 125e-3, -125e-3]]" >> first-mismatch-at 6)) > > Will the failure disappear if you try the attached patch? > [...] Yes, your patch fixes that test failure on macOS. Hoping to have helped, --alexander
columnview dynamic block - different time summing behaviour for EFFORT and CLOCKSUM
Hello Org experts,
it seems that the time summing behaviour of columnview dynamic blocks is
different for CLOCKSUM than for EFFORT columns with respect to how the
contributions from sub-headlines are handled. When summing up CLOCKSUM
columns, a parent headline can have its own clocked time, which gets
added to the sum of its sub-items' clocked times to produce its CLOCKSUM
value. When summing up EFFORT columns, any effort a parent headline may
have been manually assigned gets overwritten with the sum of its
sub-items' efforts, however. In the example at the end of this message,
compare the results for tasks A and D. If you change the effort for
either task B or C, and then update the dynamic block, the EFFORT in the
property drawer of task A will get overwritten with the new sum of B's
and C's efforts.
I'd have two questions regarding this:
Does anyone recall the rationale for this different behaviour?
Is there any way to change the summation behaviour for either or both
column types?
I have no preference for either behaviour; they both will have their
merits and applications, depending on how one organises things. I do
think that being able to get the same behaviour would seem advantageous,
however.
Many thanks and looking forward to your thoughts,
--alexander
Begin Quote -
* Example Project
#+BEGIN: columnview :maxlevel 4 :skip-empty-rows t :indent t :format
"%70ITEM(Task) %17Effort(Estimated){:} %17CLOCKSUM(Clocked){:}" :id local
| Task| Estimated | Clocked |
|-+---+--|
| Example Project | 6d 0:00 | 15d 0:00 |
| \_ Task A | 3d 0:00 | 9d 0:00 |
| \_Task B|1d | 3d 0:00 |
| \_Task C|2d | 3d 0:00 |
| \_ Task D | 3d 0:00 | 6d 0:00 |
| \_Task E|1d | 3d 0:00 |
| \_Task F|2d | 3d 0:00 |
#+END:
** Task A
:PROPERTIES:
:EFFORT: 3d 0:00
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] => 9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task B
:PROPERTIES:
:Effort: 1d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] => 9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task C
:PROPERTIES:
:Effort: 2d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] => 9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
** Task D
*** Task E
:PROPERTIES:
:Effort: 1d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] => 9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
*** Task F
:PROPERTIES:
:Effort: 2d
:END:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 15:51 +0100]--[2023-12-09 Sat 01:50 +0100] => 9:59
CLOCK: [2022-01-07 Fri 18:35 +0100]--[2022-01-08 Sat 08:36 +0100] => 14:10
:END:
- End Quote --
