Re: org-cite: enable inserting citation (org-cite-insert) after list bullet [9.5 (9.5-7c78aca @ /home/yuu/.config/emacs/straight/build/org/)]

[Timothy]

Hi All,

I’ve waited a while and had no feedback, so I’ve just pushed this as f2b6f57,
tweaked to treat checkboxes appropriately too.

All the best,
Timothy

Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[No Wayman]

Tim, Allen:

The attached compromise implements the bare minimum.
Tags can be separated with "," or ":" in the previously mentioned 
cases.

Scrapped the defcustom and showing delimiters in the prompt.
Any objections?

>From 31fbfca4884083adacd95054155cda9ed0128fba Mon Sep 17 00:00:00 2001
From: Nicholas Vollmer 
Date: Fri, 3 Sep 2021 14:50:48 -0400
Subject: [PATCH] Allow "," to delimit tags

* org.el: Add `org-tags-crm-separtor' regexp
(org-set-tags-command, org-capture-fill-template): Use `org-tags-crm-separators'.
---
 lisp/org-capture.el | 2 +-
 lisp/org.el | 5 -
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index cbdb30c03..cd65f8e6d 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1739,7 +1739,7 @@ The template may still contain \"%?\" for cursor positioning."
 			(org-add-colon-after-tag-completion t)
 			(ins (mapconcat
   #'identity
-  (let ((crm-separator "[ \t]*:[ \t]*"))
+  (let ((crm-separator org-tags-crm-separator))
 (completing-read-multiple
  (if prompt (concat prompt ": ") "Tags: ")
  org-last-tags-completion-table nil nil nil
diff --git a/lisp/org.el b/lisp/org.el
index 8b9d57157..572e291c7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -12007,6 +12007,9 @@ tags."
 	;; it now points to BLANK-START.  Use COLUMN instead.
 	(if in-blank? (org-move-to-column column) (goto-char origin))
 
+(defvar org-tags-crm-separator (format "[ \t]*%s[ \t]*" (regexp-opt '("," ":")))
+  "Regexp to separate tags in commands which use `completing-read-multiple'.")
+
 (defun org-set-tags-command ( arg)
   "Set the tags for the current visible entry.
 
@@ -12066,7 +12069,7 @@ in Lisp code use `org-set-tags' instead."
 		  table
 		  (and org-fast-tag-selection-include-todo org-todo-key-alist))
 		   (let ((org-add-colon-after-tag-completion (< 1 (length table)))
- (crm-separator "[ \t]*:[ \t]*"))
+ (crm-separator org-tags-crm-separator))
 		 (mapconcat #'identity
 (completing-read-multiple
 			 "Tags: "
-- 
2.33.0

Re: behavior of (org-insert-heading-respect-content)

[Victor A. Stoichita]

Le 13 Sep 2021, Marco Wahl  a écrit :

> As far is I see it, the intended behavior of
> org-insert-heading-respect-content with point before the first heading
> is to
>
> - insert the new heading immediately before the first heading.  Respect
>   the content!
Hi Marco !

I agree with you. But this does not work. Say I have a buffer with this content 
:

--8<---cut here---start->8---
put point HERE and C-
Some more stuff 
* Heading
content
--8<---cut here---end--->8---

When point is at HERE and I C-, org inserts a new asterisk on
the after "stuff", but  on the same line → not a proper heading.
>
> - If there is no heading at all in the file the heading shall be
>   inserted at the bottom of the file.

Yes. But I get the same behavior with 
--8<---cut here---start->8---
put point HERE and C-
Some more stuff 
--8<---cut here---end--->8---

The asterisk is inserted right after "stuff", on the same line → not
a proper heading.

>
> Do we agree on the desired behavior of
> org-insert-heading-respect-content?

Yes, we do!
>
> With your proposition the respect for the content gets lost,
> doesn't it?

Yes, you’re right. It currently does not respect the content before
first heading. Therefore it’s not a fix for the behavior of
org-insert-heading-respect-content.
It’s just the quickest workaround I’ve come up with to make my own
function work (in my use-case, when I call that function, either point
is at point-min in a brand new buffer, or point is below the first
heading).

Regards,
Victor

Re: [PATCH] Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

Timothy  writes:

> Thanks for bumping your patch, unfortunately many of us (people who can push 
> to
> Org) seem to be stretched a bit thin as of late. I’ve just gone over it, it
> reads well IMO and I think looking at the non-trivial changes in your patch 
> it’s
> possible to charitably interpret this as <=15 non-trivial lines changed. I’ve
> applied this as 6600dc09 on Org master with a tweaked commit message .
>
> Documentation is vital to communicating what Org offers to users, so thanks
> again for going to the effort to clear up a possible point of confusion. 
> Should
> you wish to make any further contributions (which would be great!) it would be
> very helpful if you could get FSF assignment (see
> ), as we can’t accept more than 15 lines 
> of
> non-trivial lines as an FSF project.

Thanks Timothy for pushing this. I just received my FSF assignment so
looking forward to contributing more.

Best,

-- 

Daniel Fleischer

Re: [PATCH] Fix some typos

[Stefan Kangas]

Marco Wahl  writes:

> Thy nittpicker!

“This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man.”

Re: [PATCH] Re: [BUG] Creating sparse tree with regexp property matches

[Timothy]

Hi Daniel,

Thanks for bumping your patch, unfortunately many of us (people who can push to
Org) seem to be stretched a bit thin as of late. I’ve just gone over it, it
reads well IMO and I think looking at the non-trivial changes in your patch it’s
possible to charitably interpret this as <=15 non-trivial lines changed. I’ve
applied this as 6600dc09 on Org master with a tweaked commit message .

Documentation is vital to communicating what Org offers to users, so thanks
again for going to the effort to clear up a possible point of confusion. Should
you wish to make any further contributions (which would be great!) it would be
very helpful if you could get FSF assignment (see
), as we can’t accept more than 15 lines of
non-trivial lines as an FSF project.

All the best,
Timothy

Re: [PATCH] Fix some typos

[Marco Wahl]

Timothy and Stefan!

Praise thy effort!

Thou shall not change "memeory" to "memory" tho!


Thy nittpicker!

Re: Bug: Fontify error with markdown source block [9.4.4 (release_9.4.4 @ /usr/share/emacs/28.0.50/lisp/org/)]

[Timothy]

Hi Yikai,

Thanks you for reporting this bug. I was able to confirm it, and trying a few
similar such buffers can also say this only appears to affect `markdown-mode'.

I’ve prepared a patch that serves as a catch-all for this type of issue, but I’m
not sure if this is the best approach. If other people could chime in that would
be great :)

All the best,
Timothy
>From d74d588a004b36d67c603ccbd919e07192524281 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Fri, 17 Sep 2021 17:23:58 +0800
Subject: [PATCH] org: fix potential missing src match-data issue

A more detailed commit message if this actually gets applied...
---
 lisp/org.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index c22a69154..4c630f206 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5377,6 +5377,8 @@ (defun org-fontify-meta-lines-and-blocks-1 (limit)
 		 (min (point-max) beg-of-next-line))
 		 (min (point-max) end-of-endline))
 	   '(face org-block-end-line)))
+(unless (match-data)
+  (set-match-data '(0 0)))
 	t))
 	 ((member dc1 '("+title:" "+subtitle:" "+author:" "+email:" "+date:"))
 	  (org-remove-flyspell-overlays-in
-- 
2.33.0

Re: [PATCH] Fix some typos

[Timothy]

Hi Stefan,

Thanks again for going through our documentation and picking up these mistakes.
I’ve just applied this as 215d80d :)

All the best,
Timothy

Re: Publish error: wrong argument number

[Colin Baxter]

Hello Tim,
> Tim Cross  writes:

> Colin Baxter  writes:

>>> Colin Baxter  writes:
>> 
>> > Hello, Today I get a "wrong-number-of-arguments" publish >
>> error. This was not present a few weeks ago. It is also not >
>> present in Org-version 9.4.4 but does occur in the latest version
>> > of org-mode.
>> 
>> > I'd appreciate some help in tracking down the error. My
>> debugger > file is below.
>> 
>> Odd - error vanished after a fresh git pull and make - very
>> odd. 8-)

> I was going to post to say that the error you saw is very common
> type of error for when you have a 'mixed' install. Could it be
> possible that you already had org loaded when you upgraded the org
> package (which would result in a mixed install), but later when
> you upgraded again, it was not and therefore gave you a clean
> 'unmixed' install?

Yes, I think that is very likely. After pulling and compiling, I update
org-mode via "C-c C-x !" I do that all the time, but I don't think I'd
seen that error before. However, my emacs had been running for 3 or 4
weeks so perhaps things had gotten a little "confused" after that length
of time.

Thanks for the information.

Best wishes,