Re: inconsistency links and code line labels
I should have mentioned that I'm not exporting any of this. I only use org
by itself; I never export things to other formats. So the link behavior
that I need is for making and following links inside org/emacs; noweb and
other things aren't important.
The (ahem) link to the org-coderef-label-format is what I was looking for:
I set that to just (%s) and now something like the above example works
without adding the "ref:" bit. I'll update the emacs.sx post.
Thanks!
On Fri, Jul 7, 2023 at 4:48 AM Ihor Radchenko wrote:
> Dan Drake writes:
>
> > Hello -- I'm wondering about my question from here:
> >
> >
> https://emacs.stackexchange.com/questions/77768/why-the-inconsistency-with-org-mode-code-line-labels-and-links
> >
> > Copying my question: in a source code special block, I can add code line
> > labels, which have ref: in the label -- but when I make a link there, I
> > have to omit the ref:. For example:
> > ...
> > 1047 bar = 5; // (ref:my-code-line-label)
> > ...
> > There's a bug [[(my-code-line-label)][right here]].
> >
> > This seems inconsistent. Why do I have to omit the ref: bit? This always
> > confuses me; it seems like it would be simpler to just make the label and
> > the links to that line of code be exactly the same. I don't see any
> > particular reference to this in the org manual (
> > https://orgmode.org/manual/Internal-Links.html). Any insights?
>
> The way coderefs appear in the code are completely configurable using
> org-coderef-label-format ("(ref:%s)" by default) and using -l src code
> switch.
>
> > My idea would be to get rid of the special behavior for code line labels
> > and just make this work with dedicated targets: in regular parts of my
> org
> > file, I use <> and can make links to that. It would be
> simple
> > and consistent to make that also work the same when <> is
> > inside a code block.
>
> If you examine 12.6 Literal Examples section of Org manual, you will see
> that coderef links are exported specially:
>
>In literal examples, Org interprets strings like ‘(ref:name)’ as
> labels, and use them as targets for special hyperlinks like
> ‘[[(name)]]’—i.e., the reference name enclosed in single parenthesis.
> In HTML, hovering the mouse over such a link remote-highlights the
> corresponding code line, which is kind of cool.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
--
Ceci n'est pas une .signature.
inconsistency links and code line labels
Hello -- I'm wondering about my question from here:
https://emacs.stackexchange.com/questions/77768/why-the-inconsistency-with-org-mode-code-line-labels-and-links
Copying my question: in a source code special block, I can add code line
labels, which have ref: in the label -- but when I make a link there, I
have to omit the ref:. For example:
#+begin_src csharp
1044 string foo = someFunction(1234);
1045 if (foo == "1")
1046 {
1047 bar = 5; // (ref:my-code-line-label)
1048 }
// etc etc
#+end_src
There's a bug [[(my-code-line-label)][right here]].
This seems inconsistent. Why do I have to omit the ref: bit? This always
confuses me; it seems like it would be simpler to just make the label and
the links to that line of code be exactly the same. I don't see any
particular reference to this in the org manual (
https://orgmode.org/manual/Internal-Links.html). Any insights?
My idea would be to get rid of the special behavior for code line labels
and just make this work with dedicated targets: in regular parts of my org
file, I use <> and can make links to that. It would be simple
and consistent to make that also work the same when <> is
inside a code block.
Thanks!
--
Ceci n'est pas une .signature.
inconsistency with :eval yes in orgmode.org and gnu.org manuals for org 9.6, 9.5?
The online manuals for 16.5 Evaluating Code Blocks seem inconsistent and include a header argument that seems to no longer be respected. https://orgmode.org/manual/Evaluating-Code-Blocks.html, for version 9.6, right now says you can specify a header argument ":eval yes" on source code blocks to bypass confirmation. However, neither https://www.gnu.org/software/emacs/manual/html_node/org/Evaluating-Code-Blocks.html and https://www.gnu.org/savannah-checkouts/gnu/emacs/manual/html_node/org/Evaluating-Code-Blocks.html mention that. They are both for version 9.5. It seems like ":eval yes" was removed some time ago -- see https://emacs.stackexchange.com/a/3570/19526. Did that get re-added? It seems like it was replaced by the org-confirm-babel-evaluate mechanism -- https://www.gnu.org/savannah-checkouts/gnu/emacs/manual/html_node/org/Code-Evaluation-Security.html. Just curious/confused. Thanks! Dan -- Ceci n'est pas une .signature.
Re: specify time of day for org-resolve-clocks, not number of minutes
I like the idea of using g/G and intelligently interpreting the user's response -- it's good UI / UX design. (Imagine asking a friend when they "got back" -- both "20 minutes ago" and "8:35" are unambiguous answers to the question.) Now we need to decide how to distinguish the two. Would it work to just examine the user input for a colon and branch based on that? I'll see if I can get this working. On Thu, Feb 13, 2020 at 1:16 AM Bastien wrote: > Hi Kyle and Dan, > > Kyle Meyer writes: > > > Thanks, though sadly Dan had already taken the time to follow up with a > > patch: > > > > https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00175.html > > Err, my bad, sorry Dan -- and thanks Kyle for the warning. > > (I too hastily assume 1 thread = 1 topic, I should have checked.) > > I reverted my changes and pushed Dan's commit to master. > > I took the liberty of inlining the function and making the message a > bit more explicit. Dan, let me know if that's okay. > > Interestingly, our (different and complementary) implementations may > lead to a new idea: your implementation is like the `k' option while > mine is like the `g' option (when you "got back"). I guess both can > make sense, and what the user expect is to be able to enter a number > of minutes *or* a HH:MM time spec in both `t' and `g'. > > That would also have the advantage of having less options while still > having the possibility to use HH:MM. (Also, using org-read-date here > seems a bit too much here, but maybe that's okay.) > > Dan, what do you think? Would you like to try implementing this or > can I give it a try? > > Thanks, > > -- > Bastien > -- Ceci n'est pas une .signature.
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
I just wanted to add that I have no real opinion one way or the other on the TINYCHANGE bit; I was just following what I found at https://orgmode.org/worg/org-contribute.html. I also have no strong opinion on how copyright should be handled for this. I'm willing to assign copyright to the FSF, make my contribution public domain, or whatever is most convenient and easiest to get this into org. Regards, Dan On Sat, Feb 1, 2020 at 10:48 AM Nicolas Goaziou wrote: > Bastien writes: > > > Future maintainers may of course interpret the recommendations of > > the FSF differently, but that's mine for now. > > Of course, sir. > -- Ceci n'est pas une .signature.
Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
Thank you, Nicolas, for the review of my first patch. I've updated my code and have the new patch attached. I didn't inline the "time to minutes to keep function"; yes, that function is very short, but the function name makes the intent/purpose of the code obvious, and the org-clock-resolve a bit more readable. If it's important to inline that -- performance concerns about the function call overhead, accepting org-mode/emacs coding style, etc. -- I'm willing to do that. I added an entry to ORG-NEWS for version 9.4. I didn't write any tests, as the change seems so simple, and UI-focused. But again, if that's a dealbreaker, I can work on doing that. Further comments welcome. On Fri, Jan 24, 2020 at 5:31 PM Nicolas Goaziou wrote: > Hello, > > Dan Drake writes: > > > I asked about a way to specify a time when using org-resolve-clock > instead > > of a number of minutes: > > > > https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html > > > > I've implemented this myself and a patch is attached. Comments welcome -- > > my change works, but I'm not sure about coding style, and right now > there's > > no error checking. > > Thank you. Some comments follow. > > > I marked the patch as a tiny change, but it does add a new menu option > and > > behavior to org-resolve-clock, so there may be an argument that it's not, > > from a user perspective, a "tiny change", but code-wise it's quite > simple: > > the core logic really isn't more than "ask the user for a time and > > subtract". > > TINYCHANGE is only about the number of non-trivial lines of code in your > patch (15 or so). > > > +(defun time-to-mins-to-keep (start-time) > > + "Asks the user for a time and returns the number of minutes > > +from START-TIME to that time." > > + (floor (/ (float-time > > + (time-subtract (org-read-date t t) start-time)) 60))) > > The name of the function is wrong, it should start with "org-clock". > Also, docstring's first line must contain a full sentence. > > Anyway, this is used only once in your patch, I suggest to inline in > instead. > > + (or (and (memq ch '(?k ?K)) > > +(read-number "Keep how many minutes? " default)) > > + (and (memq ch '(?t ?T)) > > +(time-to-mins-to-keep last-valid > > See above about inlining. > > Would you mind adding an ORG-NEWS entry, and, if possible, writing > a test? > > Regards, > > -- > Nicolas Goaziou > -- Ceci n'est pas une .signature. From 52d53de5f67e9ba16b6efe91ac79b370d89c9fea Mon Sep 17 00:00:00 2001 From: Dan Drake Date: Sun, 19 Jan 2020 08:24:12 -0600 Subject: [PATCH] org-clock.el: add `t' option to org-clock-resolve * org-clock.el (org-clock-resolve): add `t' option. This works just like `k', but asks the user to specify a time, instead of a number of minutes. Often when you are interrupted at a task and get back to it, you know what time the interruption happened. This option makes it easy to tell org-resolve-clocks about that. For example, say you clocked into task A at, say, 9:37: * original task A :LOGBOOK: CLOCK: [2020-01-21 Mon 09:37] :END: While working on task A, you get a phone call. When the call is done, you'd like to update your time logging to reflect the phone call. Your phone says the call was at 11:09. With C-c C-x C-z, you can use the `K' option, but you need to figure out the number of minutes to keep. It's easier to look at the phone, or to mentally note the time when an interruption starts. With the new option, you can select `T', and just specify a time of 11:09. The state is now: * original task A :LOGBOOK: CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32 :END: You add the phone call to your org buffer and do C-c C-x C-i to clock in. Org asks you to start the time from when the previous task ended, you say yes, and the state is now: * original task A :LOGBOOK: CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32 :END: * task B, phone call :LOGBOOK: CLOCK: [2020-01-21 Mon 11:09] :END: At this point, you can clock back into task A, or any other task. The key feature here is to be able to just type in a time -- in any format accepted by org-read-date -- instead of specifying a number of minutes. TINYCHANGE --- etc/ORG-NEWS | 5 + lisp/org-clock.el | 22 -- 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS index 67c3ca2ed..00c1f453a 100644 --- a/etc/ORG-NEWS +++ b/etc/ORG-NEWS @@ -35,6 +35,11 @@ value in call to =java=. After editing a source block, Org will restore the window layout when ~org-src
[RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock
I asked about a way to specify a time when using org-resolve-clock instead
of a number of minutes:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html
I've implemented this myself and a patch is attached. Comments welcome --
my change works, but I'm not sure about coding style, and right now there's
no error checking.
I marked the patch as a tiny change, but it does add a new menu option and
behavior to org-resolve-clock, so there may be an argument that it's not,
from a user perspective, a "tiny change", but code-wise it's quite simple:
the core logic really isn't more than "ask the user for a time and
subtract".
I hope this change can be incorporated into the official Org release.
Regards,
Dan
--
Ceci n'est pas une .signature.
From 7c369696c2eb9ebcd72ac9e7415d2481c4da7d80 Mon Sep 17 00:00:00 2001
From: Dan Drake
Date: Sun, 19 Jan 2020 08:24:12 -0600
Subject: [PATCH] org-clock.el: add `t' option to org-clock-resolve
* org-clock.el (org-clock-resolve): add `t' option. This works just like
`k', but asks the user to specify a time, instead of a number of
minutes.
Often when you are interrupted at a task and get back to it, you know
what time the interruption happened. This option makes it easy to tell
org-resolve-clocks about that. For example, say you clocked into task A
at, say, 9:37:
* original task A
:LOGBOOK:
CLOCK: [2020-01-21 Mon 09:37]
:END:
While working on task A, you get a phone call. When the call is done,
you'd like to update your time logging to reflect the phone call. Your
phone says the call was at 11:09.
With C-c C-x C-z, you can use the `K' option, but you need to figure out
the number of minutes to keep. It's easier to look at the phone, or to
mentally note the time when an interruption starts. With the new option,
you can select `T', and just specify a time of 11:09. The state is now:
* original task A
:LOGBOOK:
CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
:END:
You add the phone call to your org buffer and do C-c C-x C-i to clock
in. Org asks you to start the time from when the previous task ended,
you say yes, and the state is now:
* original task A
:LOGBOOK:
CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
:END:
* task B, phone call
:LOGBOOK:
CLOCK: [2020-01-21 Mon 11:09]
:END:
At this point, you can clock back into task A, or any other task.
The key feature here is to be able to just type in a time -- in any
format accepted by org-read-date -- instead of specifying a number of
minutes.
TINYCHANGE
---
lisp/org-clock.el | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 06df2d497..a73b500a8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -986,6 +986,12 @@ CLOCK is a cons cell of the form (MARKER START-TIME)."
(org-flag-drawer nil element))
(throw 'exit nil)))
+(defun time-to-mins-to-keep (start-time)
+ "Asks the user for a time and returns the number of minutes
+from START-TIME to that time."
+ (floor (/ (float-time
+ (time-subtract (org-read-date t t) start-time)) 60)))
+
(defun org-clock-resolve (clock prompt-fn last-valid fail-quietly)
"Resolve an open Org clock.
An open clock was found, with `dangling' possibly being non-nil.
@@ -1022,6 +1028,9 @@ k/K Keep X minutes of the idle time (default is all). If this
that many minutes after the time that idling began, and then
clocked back in at the present time.
+t/T Like `k', but will ask you to specify a time, instead of a
+ number of minutes.
+
g/G Indicate that you \"got back\" X minutes ago. This is quite
different from `k': it clocks you out from the beginning of
the idle period and clock you back in X minutes ago.
@@ -1041,19 +1050,21 @@ to be CLOCKED OUT."
(while (or (null char-pressed)
(and (not (memq char-pressed
'(?k ?K ?g ?G ?s ?S ?C
- ?j ?J ?i ?q)))
+ ?j ?J ?i ?q ?t ?T)))
(or (ding) t)))
(setq char-pressed
(read-char (concat (funcall prompt-fn clock)
- " [jkKgGSscCiq]? ")
+ " [jkKtTgGSscCiq]? ")
nil 45)))
(and (not (memq char-pressed '(?i ?q))) char-pressed)
(default
(floor (org-time-convert-to-integer (org-time-since last-valid))
60))
(keep
- (and (memq ch '(?k ?K))
- (read-number "Keep how many minutes? " default)))
+ (or (and (memq ch '(?k ?K))
+ (read-number "Keep how many minutes? " default))
+ (and (memq ch '(?t ?T))
+ (time-to-mins-to-keep last-valid
(gotback
(and (memq ch '(?g ?G))
(read-number "Got back how many minutes ago? " default)))
@@ -1068,7 +1079,7 @@ to be CLOCKED OUT."
(org-clock-resolve-clock clo
specify time of day for org-resolve-clocks, not number of minutes
Hello,
I posted a question on emacs.stackexchange:
https://emacs.stackexchange.com/questions/54445/specify-time-of-day-for-org-resolve-clocks-not-number-of-minutes
...about using a time of day when using org-resolve clocks, but didn't get
an answer. Here's my question; perhaps this more targeted group can help:
I can use org-resolve-clocks if I've been away from a task but kept the
clock for the task running -- but when I do that and select K ("keeps
however many minutes you request and then immediately clock out of that
task."), I have to specify a number of *minutes*.
Instead, I want to specify a *time*, since usually that's what I remember
("my coworker stopped to ask a question at 10:45"). I'd like a way to get
the K functionality, but instead of doing the math to figure out a number
of minutes, I want to just type in a time of day.
Is there a way to do this already? Or would this require a new clock
resolution command -- perhaps "t", for "time": it would effectively just be
a wrapper around "k" that parses the provided time, looks at the current
clocked-in task, computes the appropriate number of minutes, and then just
does whatever "k" (or "K") does.
Thanks!
--
Ceci n'est pas une .signature.
