Re: In-Buffer LaTeX previews in org-mode

[Daryl Manning]

Wow, I had not even run across this one being mentioned before (nor did I
get joy on it from googling.).

Will try it in between meetings today and see if it works. Will report back
to group. Thanks for the pointer!

Daryl.

On Wed, Jan 13, 2021 at 2:42 PM Martin Schöön 
wrote:

> Fragtog?
> https://github.com/io12/org-fragtog
>
> Disclaimer: I have not managed to get it to work but then I have not tried
> very hard.
>
> /Martin
>

Re: In-Buffer LaTeX previews in org-mode

[Martin Schöön]

Fragtog?
https://github.com/io12/org-fragtog

Disclaimer: I have not managed to get it to work but then I have not tried
very hard.

/Martin

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

On 2021-01-12 20:40, Juri Linkov wrote:
> >> So customizing 'help-at-pt-display-when-idle' to the value
> >> '(htmlize-link) completely solves this problem.
> >
> > Is that true for non-gui emacs or just for gui emacs? I'm using
> > emacs-nox (no GUI) and your solution doesn't seem to work for me.
>
> I tried with emacs-nox, and it works fine.  This feature is activated
> only when customized, not just set by setq.  Also by default it has
> a quite long delay that requires waiting too long to see the link.
> Generally it should work quite reasonably by using such customization:
>
> (customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link))
> (customize-set-variable 'help-at-pt-timer-delay 0.1)

I verify that you are correct. Thank you for the explanation of the steps to
get it working and noticed.

Still, I would like to continue to promote my solution, because it's
much simpler and is instantaneous upon key-press. It might also be more
efficient: The help-at-pt solution runs code in all buffers, let's say
every 0.1 seconds, all the time; my solution only runs in the selected
mode(s) buffers but after every key-press, which for an 'average'
touch-typist taking a speed test would be 0.3 seconds.

  1 word/minute = 5 char/min = 0.0833 char/sec = 12.0 sec/char
 403. 0.3
120   10  0.1


--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

In-Buffer LaTeX previews in org-mode

[Daryl Manning]

Having flirted with Notion and Roam over the holidays I am trying to find a
way to steal some of the nicer features there for my org-mode/org-roam
setup. Use case: Formulas.

What's state of art these days for "reading over notes" use cases (not
necessarily publishing papers) for getting complex formulas (and I"m fine
with LaTeX to describe them) to display in-buffer in org-mode?

Notion (and Roam) use a simple `$$LaTeX$$` double $$ delimiters in their
markdown-flavoured markup to transform formulas into a rendered line and,
in the case of Notion, an "Equation block" which is a larger more visible
double-ish-size block (which is really nice and aesthetically great when
you're reading over notes tbh).

I've seen `magic-latex-buffer` (though it seems not to support conventions
like `\over` - critical for some astro and physics formulas I take notes
on), and have also seen the interesting work on `webkit-ketex-render` which
is amazing but want something persistent rather than on rollover (and was
not in melpa so still wrestling it). I've also seen some people render an
image and drop that in-note (osx hates this), but that seems, well...
kludgey.

Is there a way to achieve this nicely and in an on-the-fly fashion? It's a
fairly new need for me, but googling on this has been rabbit-hole of
various approaches without a clear winner, so curious as to what proper
researchers or academics who may be using emacs and I assume also need to
render this stuff in-buffer are doing.

thanks,
Daryl.

Re: [PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs

[Kyle Meyer]

TRS-80 writes:

> On 2021-01-10 19:57, Kyle Meyer wrote:

>> I'm planning to squash the following test in when applying.  Look okay
>> to you?
[...]
> I must admit that currently I am still unfamiliar with the testing
> framework(s).  It is something I am interested in learning, but haven't
> gotten around to /yet/.
>
> Therefore, hopefully some other set of eyeballs could give that another
> look?

Sure, I'll wait another day or two for any comments on this patch as a
whole before applying.

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Kyle Meyer]

Tim Visher writes:

> On Mon, Jan 11, 2021 at 8:19 PM Kyle Meyer  wrote:

>> Thanks for reporting.  Is this addressed by the in-progress series at
>> ?
>>
>
> IIUC yes. I believe the following section of the diff should address it.
[...]
> If I'm reading the code correctly, `org-html-plain-text` is a specialized
> form of converting org data into a plain text string with no markup. If I
> have that correct then I believe you're right.
>
> Is that your read as well?

Yep.  And as a light test:

#+title: a *b* c

exports

  a *b* c

rather than

  a b c

Re: [PATCH] I updated patch by deleteing duplicate tags

[Kyle Meyer]

Christopher Miles writes:

> Kyle Meyer  writes:
>
>> stardiviner writes:
 By this patch, will merge both buffer-local tags and user defined global
 `org-tags-alist`.
>>
>> It does a bit more than that.  It uses org-global-tags-completion-table,
>> which considers tags in all agenda files by default and takes into
>> account org-tag-alist (as well as org-tag-persistent-alist) via the use
>> of the org-current-tag-alist variable.
>
> That's what I want. Why obviously user pre-defined tags can't be used 
> globally.
> Right? It should be.

My point was that it's not just adding these pre-defined lists (#1);
it's also adding tags from agenda files (#2).  I think we certainly
don't want to do #2 unconditionally.  On the other hand, #1 is probably
okay, but as I said in my last email, I could see not wanting that
either.

Anyway, the patch I proposed (which you've adapted for your latest
round), avoids #2 by guarding the behavior behind the existing
org-complete-tags-always-offer-all-agenda-tags option, and I think
that's a good path forward.

> Subject: [PATCH] org.el: Complete tags from both global and buffer local
>
> * lisp/org.el (org-fast-tag-selection): Merge buffer local tags with
> global alist of tags. And it obey the option
> org-complete-tags-always-offer-all-agenda-tags.

s/obey//

> * doc/org-manual.org: Update the TAB key doc in tags selection UI.
>
> * etc/ORG-NEWS: Mention the change in org-set-tags-command.
> ---
>  doc/org-manual.org |  6 +++---
>  etc/ORG-NEWS   |  5 +
>  lisp/org.el| 24 ++--
>  3 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index b015b502c..01cec4b8d 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -4860,9 +4860,9 @@ In this interface, you can also use the following 
> special keys:
>  
>#+kindex: TAB
>Enter a tag in the minibuffer, even if the tag is not in the
> -  predefined list.  You can complete on all tags present in the
> -  buffer.  You can also add several tags: just separate them with
> -  a comma.
> +  predefined list.  You can complete on all tags present in the buffer
> +  and globally pre-defined tags from ~org-tag{-persistent}-alist~.

Please spell these two options out: ~org-tag-alist~ and
~org-tag-persistent-alist~.

> +  You can also add several tags: just separate them with a comma.
>  
>  - {{{kbd(SPC)}}} ::
>  
> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
> index 5e5f1954d..5e68d27c0 100644
> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -149,6 +149,11 @@ Example:
>  A new =u= mode flag for Calc formulas in Org tables has been added to
>  enable Calc units simplification mode.
>  
> +*** =org-set-tags-command= select tags from 
> ~org-global-tags-completion-table~
> +
> +Let =org-set-tags-command= complete tags from global tags list (both
> +buffer-local tags and ~org-tag{-persistent}-alist~).

Same note about avoiding shorthand for the option names.

Also, please rewrite this to make it clear that this is relevant for TAB
in the fast completion interface.  It's probably also worth mentioning
that org-complete-tags-always-offer-all-agenda-tags is now honored.

And, very minor, but any reason for the mix of =...= and ~...~ markup
here?

> diff --git a/lisp/org.el b/lisp/org.el
> index 5b0ae389c..ba816dfa6 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -12139,7 +12139,7 @@ (defun org-fast-tag-selection (current inherited 
> table  todo-table)
> fulltable
>(buf (current-buffer))
>(expert (eq org-fast-tag-selection-single-key 'expert))
> -  (buffer-tags nil)
> +  (tab-tags nil)
>(fwidth (+ maxlen 3 1 3))
>(ncol (/ (- (window-width) 4) fwidth))
>(i-face 'org-done)
> @@ -12274,16 +12274,20 @@ (defun org-fast-tag-selection (current inherited 
> table  todo-table)
>   (setq current nil)
>   (when exit-after-next (setq exit-after-next 'now)))
>  ((= c ?\t)
> - (condition-case nil

Unlike the patch I sent, you've dropped the condition-case here, which I
don't think was intentional.

Thanks.

Re: Org to ConTeXt exporter?

[Jason Ross]

I'm happy to hear you're able to use it! Any feedback or criticism
is appreciated, and I'd like to know what your output format looks
like if you're able to share.


Thanks,

Jason

On 1/9/21 9:42 AM, Juan Manuel Macías wrote:

Hello, Jason,

Jason Ross  writes:


I recently had the same thought and I've started working on one.
You can see it here:

https://github.com/Jason-S-Ross/ox-context/

It's no substitute for the LaTeX exporter but it implements a lot
of the basics. I'm deriving from the LaTeX exporter but I have
to override most of the transcoders so it may be better to start
from scratch.

Disclaimer: I'm learning elisp as I go, so please excuse the
rough edges.


That's great news! I've been testing it a bit and it works very good. Of
course, I encourage you to keep up this excellent work.

Regards,

Juan Manuel



Jason Ross

Re: Org-capture template no longer recognised...

[Neil Shephard]

‐‐‐ Original Message ‐‐‐
On Friday, January 8, 2021 10:08 AM, Ihor Radchenko 
wrote:
>
> You can try bug-hunter package [1] to narrow down the cause. One example
> of using the package: https://github.com/yantar92/org/issues/11
>
> [1] https://github.com/Malabarba/elisp-bug-hunter
>
> Hope it helps.

Thanks for the suggestion.

Fortunately (for me) as mysteriously as the error cropped up after updating
packages this week it has disappeared and the org-capture templates work
again.  Didn't change anything in the template at all.

Useful to know about bug-hunter though so thank you for the pointer.

Neil
--
*Ignorance more frequently begets confidence than does knowledge* - Charles
Darwin

PGP Public : 0x700172212EF5818B

A minor mode for inserting things while typing

[Juan Manuel Macías]

Hi,

I've written a 'lazy' minor mode for inserting things while typing
(without leave the comfort zone of the keyboard) especially when you are
at the end of a paragraph and then you want to insert a block, a list, a
table, a footnote, etc. The idea is: you type ",,," plus one character
-> a white line (with org-return) is inserted -> (depending on the
character typed) something is inserted. For example: ",,,h" inserts a
new heading at the same level; ",,,t", a TODO heading; ",,,-", a list;
",,,1", a numbered list; ",,,k", a check box list; ",,,:", a description
list; ",,,s", a source block; ",,,q", a quote block; ",,,|", a table
(calling org-table-create); ",,,f", a footnote. And so on.

It's a way to insert things that I find more comfortable (in certain
scenarios) than using `org-tempo'.

In case it could be useful to someone, I share it in this GitLab
snippet: https://gitlab.com/-/snippets/2060125

Regards,

Juan Manuel

Re: ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

[Samuel Wales]

one option is to name your targets with <>.  i think, but
have not tested, that these will disappear upon export, but they might
or might not be annoying to you in the org buffer.  you can get to
them with [[my-target]] which can export to list number or so.


On 1/12/21, TRS-80  wrote:
> On 2021-01-12 15:33, Daniele Nicolodi wrote:
>> On 12/01/2021 21:21, TRS-80 wrote:
>>> Hello *,
>>>
>>> I just banged out a bit of Elisp implementing a new Orgmode link type
>>> for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]
>>
>> How do you deal with the lists being re-numbered when you edit them?
>
> Currently, just manually updating the links.
>
> I guess in my usage, I mostly keep adding on to the bottom of the Plain
> List (taking notes) so I rarely need to re-order anything.
>
> However you raise a good point, and suddenly I realize I have written an
> "80% solution."  Adding that other 20% would increase the complexity and
> amount of code by...?  For me, not worth it (for the time being).
>
> However, you are helping me to answer the question about where it should
> "live."  I now no longer[0] think it appropriate for that to be within
> Orgmode itself (and perhaps not even in contrib).  So, thanks for that.
> :)
>
> Basically, what I wrote so far is a "first pass."
>
> Cheers,
> TRS-80
>
> [0] Not that I necessarily did in the first place.  ;)
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

[TRS-80]

On 2021-01-12 15:33, Daniele Nicolodi wrote:

On 12/01/2021 21:21, TRS-80 wrote:

Hello *,

I just banged out a bit of Elisp implementing a new Orgmode link type
for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]


How do you deal with the lists being re-numbered when you edit them?


Currently, just manually updating the links.

I guess in my usage, I mostly keep adding on to the bottom of the Plain
List (taking notes) so I rarely need to re-order anything.

However you raise a good point, and suddenly I realize I have written an
"80% solution."  Adding that other 20% would increase the complexity and
amount of code by...?  For me, not worth it (for the time being).

However, you are helping me to answer the question about where it should
"live."  I now no longer[0] think it appropriate for that to be within
Orgmode itself (and perhaps not even in contrib).  So, thanks for that.
:)

Basically, what I wrote so far is a "first pass."

Cheers,
TRS-80

[0] Not that I necessarily did in the first place.  ;)

Re: ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

[Daniele Nicolodi]

On 12/01/2021 21:21, TRS-80 wrote:
> Hello *,
> 
> I just banged out a bit of Elisp implementing a new Orgmode link type
> for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]

How do you deal with the lists being re-numbered when you edit them?

Cheers,
Dan

ol-plo.el --- Orgmode Link type for navigating Ordered Plain Lists

[TRS-80]

Hello *,

I just banged out a bit of Elisp implementing a new Orgmode link type
for navigating Ordered (i.e., numbered/lettered) Plain Lists.[0]

As I tend to use Plain Lists extensively when taking notes, this is
something I (personally) have been wanting for some time.  But maybe
others might also find it useful.

Here is a teaser, copied from my (working title) ol-plo.el file:

#+begin_src emacs-lisp
  ;;; Commentary

  ;; Implements an Orgmode link type for nagivagting to other
  ;; locations within the same Ordered (numbered) Plain List in
  ;; Orgmode.
  ;;
  ;; The link type is "plo:" for Plain List, Ordered (see Plain
  ;; List section of Orgmode manual).
  ;;
  ;; Example: Following Orgmode link at position [Y] like
  ;; [[plo:1.2.1.][Description]] would move point from [Y] to [X]
  ;; below:
  ;;
  ;; * Heading
  ;;
  ;; 1. Section
  ;;1. Subheading
  ;;2. Another subheading
  ;;   1. [X]Link to
  ;; 2. Another Section
  ;;   1. Link from [Y]
  ;;
#+end_src

If there is any interest, I could post it up somewhere.  In which case,
more questions arise:

1. Where should this live?
   a. In Orgmode itself?
   b. In contrib?
   c. As an outside package?

Hence my thought to first float the idea on the mailing list.

I am also unsure I even like "plo:", maybe it should be "opl:" (for
Ordered Plain List)?  Or even something else?

Discuss!  :)

Cheers,
TRS-80

[0] https://orgmode.org/manual/Plain-Lists.html

Re: [PATCH] org-footnote: fix inserting new footnote mangling drawers (was: Re: Bug: inserting footnote when Footnotes heading has property drawer [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/user/.emacs

[TRS-80]

On 2021-01-10 19:57, Kyle Meyer wrote:

Thanks for the initial report and the patch.


I am very happy to contribute!

Thanks for taking it easy on me the first time around.  :)


TRS-80 writes:
Subject: [PATCH] org-footnote: fix inserting new footnote mangling 
drawers


convention nit: s/fix/Fix/ (no need to resend)


Duly noted!


I'm planning to squash the following test in when applying.  Look okay
to you?


diff --git a/testing/lisp/test-org-footnote.el
b/testing/lisp/test-org-footnote.el
index eca24d315..50a430785 100644
--- a/testing/lisp/test-org-footnote.el
+++ b/testing/lisp/test-org-footnote.el
@@ -138,7 +138,20 @@ (ert-deftest test-org-footnote/new ()
  (org-test-with-temp-text
  "Paragraph\n# Local Variables:\n# foo: t\n# End:"
(let ((org-footnote-section "Footnotes")) (org-footnote-new))
-   (buffer-string)
+   (buffer-string
+  (should
+   (equal "Para[fn:1]
+* Footnotes
+:properties:
+:custom_id: id
+:end:
+
+\[fn:1]"
+  (org-test-with-temp-text
+  "Para\n* Footnotes\n:properties:\n:custom_id: 
id\n:end:"

+(let ((org-footnote-section "Footnotes"))
+  (org-footnote-new))
+(org-trim (buffer-string))

 (ert-deftest test-org-footnote/delete ()
   "Test `org-footnote-delete' specifications."


I must admit that currently I am still unfamiliar with the testing
framework(s).  It is something I am interested in learning, but haven't
gotten around to /yet/.

Therefore, hopefully some other set of eyeballs could give that another
look?

Cheers,
TRS-80

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Juri Linkov]

>> So customizing 'help-at-pt-display-when-idle' to the value
>> '(htmlize-link) completely solves this problem.
>
> Is that true for non-gui emacs or just for gui emacs? I'm using
> emacs-nox (no GUI) and your solution doesn't seem to work for me.

I tried with emacs-nox, and it works fine.  This feature is activated
only when customized, not just set by setq.  Also by default it has
a quite long delay that requires waiting too long to see the link.
Generally it should work quite reasonably by using such customization:

(customize-set-variable 'help-at-pt-display-when-idle '(htmlize-link))
(customize-set-variable 'help-at-pt-timer-delay 0.1)

Re: ox-html Incorrectly (?) Puts HTML Into the `` Tag

[Tim Visher]

On Mon, Jan 11, 2021 at 8:19 PM Kyle Meyer  wrote:

> Tim Visher writes:
>
> > Hi all,
> >
> > I noticed over the weekend that the `` tag in an ox-html document
> is
> > populated with HTML when inline formatting like bold or italics is used.
> [...]
> > Is this something we'd take a patch for?
>
> Thanks for reporting.  Is this addressed by the in-progress series at
> ?
>

IIUC yes. I believe the following section of the diff should address it.

```
+  (let* ((title (org-html-plain-text
+ (org-element-interpret-data (plist-get info :title)) info))
+ ;; Set title to an invisible character instead of leaving it
+ ;; empty, which is invalid.
+ (title (if (org-string-nw-p title) title ""))
```

If I'm reading the code correctly, `org-html-plain-text` is a specialized
form of converting org data into a plain text string with no markup. If I
have that correct then I believe you're right.

Is that your read as well?

Re: [PATCH] ob-lilypond: allow user configuration of header-args

[Jonathan Gregory]

Hi Jamie

On 10 Jan 2021, Jamie Bayne wrote:


Hi all,

I hit the problem described in 
https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127317.html 
- I couldn't see that anyone else had fixed it so I had a go.


The problem is that, unusually, ob-lilypond has some conditional 
logic on its header-args. Its solution is to set the header-args 
internally when required, which overrides any user-specified 
value.


The quickest way I could see to preserve the conditional logic 
was to add a new variable to hold the user configuration, which 
I called ob-lilypond-header-args. Now the conditional logic sets 
org-babel-header-args:lilypond to the new variable's value when 
appropriate.


Another way would be to create a context which sets the variable 
when needed and then resets it. I opted against this as I'm not 
sure it would have the same behaviour in all cases. Happy to 
have a go if it would be preferable, though.


Cheers, Jamie


I'm not sure I understand the second proposal. Either way, the 
solution looks reasonable.


Thanks for your help

--
Jonathan

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

 On Sun, Jan
10, 2021 at 3:55 PM John Herrlin  wrote:
> ian martins  writes:
> > I think the problem was that I was missing static
> > imports, which you fixed in the first chunk of your patch. I don't
> > think the rest of the change is necessary. Could you revert the other
> > chunks and re-test?
>
> Thats looks correct! Thanks!
>
> Here is a patch with the regexp fix.

That's great. One small change, though. This only allows for a single space
between "import" and "static" so if someone were to put in two it wouldn't
work. I actually did the same thing in an earlier version and it caused a
problem. Since then I went to =(1+ space)= everywhere. Could you also move
the part that you're adding down to the next line. It's not that the line
is too long, but it keeps it to one thing per line.

The commit message is fine, but the first line shouldn't end in a period.

ref: https://orgmode.org/worg/org-contribute.html#commit-messages

bug#42484: 26.1: org-mode should display value of links in mini-buffer

[Boruch Baum]

On 2021-01-11 20:54, Juri Linkov wrote:
> So customizing 'help-at-pt-display-when-idle' to the value
> '(htmlize-link) completely solves this problem.

Is that true for non-gui emacs or just for gui emacs? I'm using
emacs-nox (no GUI) and your solution doesn't seem to work for me.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

[PATCH] Query when exiting with running clock

[Allen Li]

This is a patch adding a query function when exiting Emacs, warning the
user if there is a running clock.  This is useful for preventing the
user from accidentally leaving dangling clocks.  I have had success
using a modified personal version of this code.

My personal version instead prompts the user to clock out and save the
buffer.  I didn't use it for the patch because it seems a little hacky
to me; e.g., kill-emacs-query-functions doesn't mention whether
functions can have side effects, and the UI is inconsistent with
save-buffers-kill-emacs.  The code for my personal version:

(add-to-list 'kill-emacs-query-functions
   (lambda ()
 (if (not (org-clocking-p))
 t
   (if (y-or-n-p "Clock out and save?")
   (with-current-buffer (marker-buffer org-clock-marker)
 (org-clock-out)
 (save-buffer)
 t)
 (message "Aborting")
 nil

If there is great demand for this version, I might provide another patch.

I have also attached another patch which deduplicates two identical
functions that I noticed when preparing the first patch.

>From f6145afd7d457cec533c44c8a3297d28f11d7255 Mon Sep 17 00:00:00 2001
From: Allen Li 
Date: Tue, 12 Jan 2021 00:26:47 -0800
Subject: [PATCH 1/2] org-clock: Replace org-clocking-buffer with
 org-clock-is-active

org-clocking-buffer and org-clock-is-active have the same definition.
org-clocking-buffer is defined in org-clock.el while
org-clock-is-active is defined in org.el.  org-clock.el requires
org.el.

org-clocking-buffer is kept as an alias to preserve backward
compatibility with any user code.

* lisp/org-clock.el (org-clocking-buffer): Changed to alias.
(org-clocking-p): Changed reference to org-clocking-buffer.
(org-clock-out): Changed reference to org-clocking-buffer.
(org-clock-cancel): Changed reference to org-clocking-buffer.
(org-clock-sum): Changed reference to org-clocking-buffer.
(org-clock-out-if-current): Changed reference to org-clocking-buffer.
(org-clock-save): Changed reference to org-clocking-buffer.
---
 lisp/org-clock.el | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 892ae1810..37459580b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -503,13 +503,11 @@ of a different task.")
   (mapc (lambda (m) (org-check-and-save-marker m beg end))
 	org-clock-history))
 
-(defun org-clocking-buffer ()
-  "Return the clocking buffer if we are currently clocking a task or nil."
-  (marker-buffer org-clock-marker))
+(defalias 'org-clocking-buffer #'org-clock-is-active)
 
 (defun org-clocking-p ()
   "Return t when clocking a task."
-  (not (equal (org-clocking-buffer) nil)))
+  (not (equal (org-clock-is-active) nil)))
 
 (defvar org-clock-before-select-task-hook nil
   "Hook called in task selection just before prompting the user.")
@@ -1501,7 +1499,7 @@ to, overriding the existing value of `org-clock-out-switch-to-state'."
 	  ts te s h m remove)
   (setq org-clock-out-time now)
   (save-excursion ; Do not replace this with `with-current-buffer'.
-	(org-no-warnings (set-buffer (org-clocking-buffer)))
+	(org-no-warnings (set-buffer (org-clock-is-active)))
 	(save-restriction
 	  (widen)
 	  (goto-char org-clock-marker)
@@ -1652,7 +1650,7 @@ Optional argument N tells to change by that many units."
 (force-mode-line-update)
 (error "No active clock"))
   (save-excursion ; Do not replace this with `with-current-buffer'.
-(org-no-warnings (set-buffer (org-clocking-buffer)))
+(org-no-warnings (set-buffer (org-clock-is-active)))
 (goto-char org-clock-marker)
 (if (org-looking-back (concat "^[ \t]*" org-clock-string ".*"))
 	(progn (delete-region (1- (point-at-bol)) (point-at-eol))
@@ -1763,7 +1761,7 @@ PROPNAME lets you set a custom text property instead of :org-clock-minutes."
 	  (t ;; A headline
 	   ;; Add the currently clocking item time to the total
 	   (when (and org-clock-report-include-clocking-task
-		  (equal (org-clocking-buffer) (current-buffer))
+		  (equal (org-clock-is-active) (current-buffer))
 		  (equal (marker-position org-clock-hd-marker) (point))
 		  tstart
 		  tend
@@ -1897,8 +1895,8 @@ and is only done if the variable `org-clock-out-when-done' is not nil."
 		  (member org-state org-done-keywords))
 		 (and (listp org-clock-out-when-done)
 		  (member org-state org-clock-out-when-done)))
-	 (equal (or (buffer-base-buffer (org-clocking-buffer))
-			(org-clocking-buffer))
+	 (equal (or (buffer-base-buffer (org-clock-is-active))
+			(org-clock-is-active))
 		(or (buffer-base-buffer (current-buffer))
 			(current-buffer)))
 	 (< (point) org-clock-marker)
@@ -2816,7 +2814,7 @@ The details of what will be saved are regulated by the variable
 			  system-name (format-time-string
    (cdr 

[PATCH] incorrect timestamps with :time-prompt and datetrees

[Richard Lawrence]

Hi everyone,

Bumping this, since I forgot to put "PATCH" in the subject line before.

Richard Lawrence  writes:

> Here is a patch for this issue. It uses a narrower regex to match a time
> range. This regex requires time ranges to have ":MM" or an AM/PM
> specification in the end time, to prevent mangling strings that are
> interpreted as dates, like "11-12".
>
> This patch is a minimal change that gets the code working in the way
> that seems to have been intended, so it seems worth applying to maint.
>
> However, the way the code is intended to work doesn't seem right to me,
> because it simply throws away time range information at the time prompt.
> If you enter a time range like "13:00-14:00" at the time prompt, you
> will get a timestamp with "13:00" for the time when the %T template is
> expanded. (This is because org-capture-set-target-location uses the
> beginning of the entered time range to set :default-time, which must be
> an encoded time value, and there is no obvious way to set a time range.)
> This is a surprising contrast with the behavior of %^T, which preserves
> the time range information in the timestamp entered. But fixing this
> will be a larger change and possibly requires some discussion.

-- 
Best,
Richard

>From a6c223664aad6096943e236c9a51c30246e57669 Mon Sep 17 00:00:00 2001
From: Richard Lawrence 
Date: Wed, 6 Jan 2021 11:53:42 +0100
Subject: [PATCH] org-capture: fix expansion of %T when capturing to a datetree

* org-capture.el (org-capture-set-target-location): Use a narrower
regular expression to replace a time range by its start time when
setting :default-time, so that dates do not get mangled.

TINYCHANGE
---
 lisp/org-capture.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index f40f2b335..df0eccdbb 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1038,12 +1038,12 @@ Store them in the capture property list."
 			 (apply #'encode-time 0 0
 org-extend-today-until
 (cl-cdddr (decode-time prompt-time
-			((string-match "\\([^ ]+\\)-[^ ]+[ ]+\\(.*\\)"
+			((string-match "\\(--?\\([012]?[0-9]\\)\\(\\(:[0-5][0-9]\\)\\|\\(am\\|AM\\|pm\\|PM\\)\\>\\)\\)\\(.*\\)"
    org-read-date-final-answer)
 			 ;; Replace any time range by its start.
 			 (apply #'encode-time
 (org-read-date-analyze
- (replace-match "\\1 \\2" nil nil
+ (replace-match "\\6" nil nil
 		org-read-date-final-answer)
  prompt-time (decode-time prompt-time
 			(t prompt-time)))
-- 
2.20.1