Re: Code Review Request: Step 1 for [FR] Allow emojis in tags (was: emojis in tags?)

[Ihor Radchenko]

Shuo Shen  writes:

> This is the first patch for the feature request: [FR] Allow emojis in
> tags (was: emojis in tags?)
> (https://list.orgmode.org/orgmode/87wn4pdarh.fsf@localhost/)

(Note that the exact changes needed to support emoji or other things may
need to be discussed first.)

> It's my first diff. I'm trying to get an understanding of code as well
> as the process at the same time, and don't want to get things
> complicated. Therefore, I'm keeping the change minimal.

Thanks! See my comments below.

> Subject: [PATCH] lisp/org.el: Define a const for the tag matching pattern
>
> * org.el (org-tag-valid-char-set, org-tag-re, org-tag-group-re)
> (org-tag-line-re): Defined the const org-tag-valid-char-set.

In the commit messages we quote symbols like `org-tag-valid-char-set'.

> org-tag-valid-char-set will be used as a single source of truth for
> matching tags. The problem is that the tag matching pattern is defined

... and use double space between sentences.
See https://orgmode.org/worg/org-contribute.html#org219e2af

> everywhere (org-tag-re, org-tag-group-re, org-tag-line-re, and a bunch
> of inline places. This is the first diff to address the problem. When
> the refactorizations are all done, we will add emoji support for tags

I am not sure if we need to be so granular in constants. Maybe we can
instead just have `org-tag-re' and derive other regexps from it?

> +(defconst org-tag-valid-char-set "[:alnum:]_@#%"
> +  "[Tag] A string representing the set of characters and character
> + classes valid within a tag.  This is the base definition for tag
> +characters and will be the place to add new patterns.")

We usually do not announce future plans in docstrings. Docstring are for
the users to read, and announcing changes in Org syntax that may or may
not happen is not a good idea.

> +(defconst org-tag-re (format "[%s]+" org-tag-valid-char-set)
>"Regexp matching a single tag.")

Since we are rewriting things here, may as well use rx for better readability.
  
> +(defconst org-tag-group-re
> ...
>  (defconst org-tag-line-re
> -  "^\\*+ \\(?:.*[ \t]\\)?\\(:\\([[:alnum:]_@#%:]+\\):\\)[ \t]*$"
> +  (format "^\\*+ \\(?:.*[ \t]\\)?\\(:\\([%s:]+\\):\\)[ \t]*$" 
> org-tag-valid-char-set)

Note that tag regexp is used manually in a number of places in Org
codebase. Search for "_@#%:" across Org codebase and see. All these
instances should be changed and ideally use the regexp constants instead
of hard-coded constants.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[BUG] When call org-html-export-to-html from org-export-dispatch, ext-plist is empty with #+OPTIONS: set [9.7.11 (release_9.7.11 @ /usr/share/emacs/30.1/lisp/org/)]

[Sébastien Gendre]

Hello,

I was modifying the ox-html options alist to add an OPTION key to
`:html-extension'. I do it like this:

(:html-extension nil "html-extension" org-html-extension)

But after re-evaluate the ox-html backend definition and adding this to
my org-mode file:

#+OPTIONS: html-extension:"bear"

The exported file still have an ".html" extension, and not a ".bear".

If I debug the function `org-html-export-to-html', its variable `ext-plist' is 
empty
and so the function don't use the value of option `:html-extension' but
of variable `org-html-extension' instead.

Ideally, `org-html-export-to-html' should use the value set with
`#+OPTIONS:' to define the extension of the exported file.

Best regards.



Emacs  : GNU Emacs 30.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 
3.24.43, cairo version 1.18.2)
 of 2025-03-13
Package: Org mode version 9.7.11 (release_9.7.11 @ 
/usr/share/emacs/30.1/lisp/org/)

current state:
==
(setq
 org-yank-image-file-name-function 'org-yank-image-autogen-filename
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-html-format-headline-function 'org-html-format-headline-default-function
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-latex-format-inlinetask-function 
'org-latex-format-inlinetask-default-function
 org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-latex-format-headline-function 'org-latex-format-headline-default-function
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-mode-hook '(#[0 "\301\211%10\207" [imenu-create-index-function 
org-imenu-get-tree] 2]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all append 
local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-babel-show-result-all 
append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-confirm-shell-link-function 'yes-or-no-p
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-occur-hook '(org-first-headline-recenter)
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 "%1\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-link-parameters '(("attachment" :follow org-attach-follow :complete 
org-attach-complete-link)
   ("id" :follow org-id-open :store org-id-store-link-maybe)
   ("eww" :follow org-eww-open :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store 
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store org-mhe-store-link)
   ("irc" :follow org-irc-visit :store org-irc-store-link 
:export org-irc-export)
   ("info" :follow org-info-open :export org-info-export 
:store
org-info-store-link :insert-description 
org-info-description-as-command)
   ("gnus" :follow org-gnus-open :store org-gnus-store-link)
   ("docview" :follow org-docview-open :export 
org-docview-export :store
org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store 
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export org-bbdb-export 
:complete
org-bbdb-complete-link :store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link)
   ("doi" :follow org-link-doi-open :export 
org-link-doi-export) ("file+sys")
   ("file+emacs") ("shell" :follow org-link--open-shell)
   ("news" :follow
#[514 "\301\300\302%4Q%2\"\207" ["news" browse-url ":"] 
6 "\n\n(fn URL ARG)"])
   ("mailto" :follow
#[514 "\301\300\302%4Q%2\"\207" ["mailto" browse-url 
":"] 6
  "\n\n(fn URL ARG)"]
)
   ("https" :follow
#[514 "\301\300\302%4Q%2\"\207" ["https" browse-url 
":"] 6 "\n\n(fn URL ARG)"]
)
   ("http" :follow
#[514 "\301\300\302%4Q%2\"\207" ["http" browse-url ":"] 
6 "\n\n(fn URL ARG)"])
   ("ftp" :follow
#[514 "\301\300\302%4Q%2\"\207" ["ftp" browse-url ":"] 
6 "\n\n(fn URL ARG)"])
   ("help" :follow org-link--open-help :store 
org-link--store-help)
   ("file" :com

Re: Question about contribution to improve svg handling in latex export

[Emin Martinian]

A patch is attached.

Ihor: I tried looking at the link you sent but could not understand how to
use org-persist cache. The conversion program needs an output location to
write a file to. Is there some variable or function which indicates a cache
directory to use? If so, I couldn't figure it out (apologies; I am not an
expert in emacs lisp).

Note: as asked in an earlier comment, rsvg-convert can be used instead of
inkscape. The attached patch tries to use inkscape if installed but if that
is missing and rsvg-convert is available, we use that instead. In
principle, the user could set the org-latex-svg-to-pdf-command and
org-latex-svg-to-pdf-command-options variables to control the conversion
program.

Thanks,
-Emin

On Sun, May 11, 2025 at 6:28 AM Ihor Radchenko  wrote:

> Emin Martinian  writes:
>
> > If latex experts and/or maintainers of org-mode are broadly in agreement
> > with the above, I would be happy to try and take the pull request to
> > el-easydraw  and
> > incorporate something like that into a PR for Org-mode. I think the way
> to
> > go would be to modify the (when (equal filetype "svg")
> > <
> https://github.com/bzg/org-mode/blob/b6dbf8881076191e1351d7cd15e26547a2531fea/lisp/ox-latex.el#L2877
> >
> > portion of ox-latex.org to call something like the
> > edraw-org-export-latex-link
> > <
> https://github.com/misohena/el-easydraw/pull/37/files#diff-d74d9626acb8016adf39b497068745979fef8789a108264c79e45c003a364997R57
> >
> > function in my original PR (renamed/modified to not be specific to
> edraw).
>
> Looks like there are no objections to the idea, so go ahead.
> Just one comment - rather than creating a .pdf file in the same folder
> with original .svg (which may or may not be writable), please use
> org-persist cache. See
>
> https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-latex-preview.el#L2973
> for an example how to do it.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


0001-lisp-ox-latex.el-Convert-SVG-to-PDF-on-latex-export.patch
Description: Binary data

Re: [PATCH] Improved mode line clock truncation behavior

[Rohit Patnaik]

I'm so sorry it took this long to get back to you. I got busy, and unfortunately
this patch slipped off my radar.

> Rather than hard-coding number 5, I'd rather
> 1. Let-bind "%s (%s) " value
> 2. Compute spaces-and-parenth-length by formatting that value with %s
>placeholders being empty.

This is the approach I took. I let-bound the format strings into variables and
formatted them with empty strings in order to get the length of the "overhead",
and used that to compute the value of spaces-and-paren-length.

Thanks for the feedback; the code looks much better now.

RohitFrom 727ec7fb129e9c09617c204537eb1b2e5ed24ddb Mon Sep 17 00:00:00 2001
From: Rohit Patnaik 
Date: Tue, 18 Mar 2025 04:45:06 -0500
Subject: [PATCH] org-clock: Make headline truncation behave better

* lisp/org-clock.el (org-clock-get-clock-string): Move the headline truncation
logic into `org-clock-get-clock-string', which enables much nicer truncation
behavior.  Now, `org-clock-get-clock-string' accepts an optional `max-length'
parameter.  If the length of the combined time string and headline exceeds
`max-length', the function truncates the headline, adds an ellipsis and
preserves the closing parenthesis.  If `max-length' is so small that even a
single character of the headline cannot be displayed, the function returns a
(possibly truncated) time string

* lisp/org-clock.el (org-clock-update-mode-line): Removed truncation code, as it
is now redundant with the truncation code in `org-clock-get-clock-string`.
Instead, the function now passes `org-clock-string-limit' to
`org-clock-get-clock-string' as the `max-length' argument.

* testing/lisp/test-org-clock.el (test-org-clock/mode-line): Added a few tests
to ensure that the new truncation logic is behaving correctly.

* etc/ORG-NEWS: (~org-clock-get-clock-string~ now takes an optional ~max-length~
argument): Document the change.
---
 etc/ORG-NEWS   |  9 
 lisp/org-clock.el  | 79 +++---
 testing/lisp/test-org-clock.el | 76 +---
 3 files changed, 132 insertions(+), 32 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4e9440b51..62502a678 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -453,6 +453,15 @@ When CHILDREN contains ~nil~ elements, they are skipped.  This way,
 
 will yield expected results rather than assigning literal ~nil~ as a child.
 
+*** ~org-clock-get-clock-string~ now takes an optional ~max-length~ argument
+
+When a ~max-length~ is passed to ~org-clock-get-clock-string~, it will first
+attempt to truncate the headline and add an ellipsis in order to make the entire
+clock string fit under the length limit. If the length limit is too small to
+accommodate even a single character of the headline, after accounting for spaces
+and the surrounding parentheses, it will omit the headline entirely and just
+show as much of the clock as fits under the limit.
+
 ** Removed or renamed functions and variables
 
 *** ~org-cycle-display-inline-images~ is renamed to ~org-cycle-display-link-previews~
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index a4b37ce59..4066e79c9 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -741,27 +741,61 @@ pointing to it."
 (defvar org-clock-update-period 60
   "Number of seconds between mode line clock string updates.")
 
-(defun org-clock-get-clock-string ()
+(defun org-clock-get-clock-string (&optional max-length)
   "Form a clock-string, that will be shown in the mode line.
 If an effort estimate was defined for the current item, use
 01:30/01:50 format (clocked/estimated).
-If not, show simply the clocked time like 01:50."
-  (let ((clocked-time (org-clock-get-clocked-time)))
-(if org-clock-effort
-	(let* ((effort-in-minutes (org-duration-to-minutes org-clock-effort))
-	   (work-done-str
-		(propertize (org-duration-from-minutes clocked-time)
-			'face
-			(if (and org-clock-task-overrun
- (not org-clock-task-overrun-text))
-'org-mode-line-clock-overrun
-			  'org-mode-line-clock)))
-	   (effort-str (org-duration-from-minutes effort-in-minutes)))
-	  (format (propertize "[%s/%s] (%s) " 'face 'org-mode-line-clock)
-		  work-done-str effort-str org-clock-heading))
-  (format (propertize "[%s] (%s) " 'face 'org-mode-line-clock)
-	  (org-duration-from-minutes clocked-time)
-	  org-clock-heading
+If not, show simply the clocked time like 01:50.  When the optional max-length
+argument is given, this function will preferentially truncate the headline in 
+order to ensure that the entire clock string's length remains under the limit."
+  (let* ((max-string-length (or max-length 0))
+ (clocked-time (org-clock-get-clocked-time))
+ (clock-str (org-duration-from-minutes clocked-time))
+ (clock-format-str "[%s]")
+ (clock-format-effort-str "[%s/%s]")
+ (mode-line-str-with-headline "%s (%s) ")
+ (mode-line-str-without-headline "%s ")
+ (effort-

Re: [PATCH] lisp/ox-html.el: Add file level option to manage headlines self link

[Ihor Radchenko]

Sébastien Gendre  writes:

> With the ox-html option `:html-divs', the value is list of lists that
> look like this:
>
>   '((preamble  "div" "preamble")
> (content   "div" "content")
> (postamble "div" "postamble"))
>
> It is to long to be set as an OPTION. But a KEYWORD only accept string
> if I understand correctly ?
>
> Do I pass the ox-html option with thi kind of values ?

Probably not. Elisp value is awkward inside Org document.
What we can do is the following:
1. Allow the value of :html-divs to be a string (in addition to alist, as
   now). Like ":preamble div preamble :content div content :postamble div 
postamble"
   This will require changing all the code that handles :html-divs
   values. You will likely need to write a helper function transform
   string into alist (maybe using `org-export-read-attribute')
2. Allow KEYWORD

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Language support for C# in org-babel

[Ihor Radchenko]

poverobuosodonati  writes:

> I've documented it accordingly and wrote a test for it here:
> ...
>
> There is now also a "proper" test for 
> `org-babel-csharp-additional-project-flags` and updated documentation 
> for the intended use of this customization:
> ...

Thanks!
Looks like you have addressed all my comments.

Let me do one more iteration through the code:

1. In the readme, you mention `org-babel-csharp-target-framework', but
   there is no such variable in the code. There is 
`org-babel-csharp-target-framework'
2. The value of `org-babel-csharp-target-framework' is hard-coded. Is
   this for a reason? Or maybe you can instead set it automatically, as
   you do in the tests. I do not recall you replying to similar ideas
   from Stefan Nobis in 
https://list.orgmode.org/orgmode/m11pvpt60k@nobis-it.eu/
3. `org-babel--csharp-default-compile-command' and similar private
   functions should probably be named as
   `org-babel-csharp--default-compile-command' (-- moved after
   org-babel-csharp prefix). This is to emphasize that these functions
   are not a part of org-babel core library.
4. Should `org-babel-csharp-additional-project-flags' be a defcustom?
5. "Construct a csproj file from a list of REFS for the target
   FRAMEWORK." docstring is a bit confusing. After first reading, I got
   an impression that the function will create an actual file on FS, not
   return the contents as string.
6. In #'(lambda (u), #' is redundant
7. (namespace (make-temp-name "obcs"))
   Do you really need to check FS and call `make-temp-name'? Or do you
   just need a unique symbol?
8. (string-search ".dll" full-ref)
   Maybe use `file-name-extension'?
9. (project-name  (make-temp-name "obcs"))
   As the docstring states, `make-temp-name' will only generate truly
   unique file name when the prefix is a full path. So, you probably
   want (make-temp-name (file-name-concat org-babel-temporary-directory "obcs"))
10. In the tests, (org-test-for-executable org-babel-csharp-compiler)
should go on top of the file. The tests are not evaluated in the
   order they are defined in the file. Instead, the file is evaluated
   (with all its top-level defuns and expressions) first, and then the
   tests defined that way are evaluated. So, your check for
   org-babel-csharp-compiler, if failed, will prevent the whole test
   file from be used anyway.
11. You are using `type-of' a lot. I recommend specific predicates
   instead, like `consp' or `stringp'. It will be slightly more compact.
12. ert--skip-when
Just (skip-when ...) will work inside `ert-deftest'
13. In `test-ob-csharp/additional-project-flags-are-respected'
I feel that you overdid lambdas. A simple `dolist' loop would do.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Seeking guidance for starting timezone patch

[Ihor Radchenko]

David Minh-Duy Cao via "General discussions about Org-mode."
 writes:

> I was thinking of contributing a patch to add timezone support for
> org-mode, and I was curious if I could get some pointers on where & how
> I should start. I’ve seen both the proposed syntax [0] and the most
> recent org meetup notes [1] on the matter, and since the latter
> recommended reaching out to the mailing list if someone was interested
> in having a go at the patch, I figured I would send a message to
> hopefully get some guidance on how to get started :^)

Thanks for your interest!
Here are initial tasks you need to do in order to get started:
1. Modify `org-element-timestamp-parser' to understand the new syntax
2. Add new tests into testing/test-org-element.el covering various
   possible timezone variants (basically, add tests for
   `org-element-timestamp-parser' you modify)
3. make sure that Org tests (make test) are not broken by your changes
4. Find the existing Org functions that should understand timezones,
   share them here. We will then discuss how they should be modified.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] Accept nil outline path for file+olp+datetree org-capture-templates target

[Kristoffer Balintona]

On Sun, May 11 2025, Ihor Radchenko wrote:

> Kristoffer Balintona  writes:
>
>> Thank you for the help. I've attached a diff for a set of proposed
>> changes. It has `org-capture-expand-olp' and
>> `org-capture-expand-headline' return the symbol 'file in certain cases
>> and has `org-capture-set-target-location' treat those cases specially,
>> inserting the capture entry at the top level. Additionally, I updated
>> the docstring of `org-capture-templates' appropriately and added an
>> additional test in `test-org-capture/org-capture-expand-olp'.
>
> Why not just using nil value as you initially suggested?

Currently, both `org-capture-expand-headline' and
`org-capture-expand-olp' error when the expanded headline or olp,
respectively, return nil. I wanted to preserve that assuming there was a
good reason behind this decision. Do you think interpreting a nil value
in this way is more appropriate?

>> ... Although I've never contributed to org before, so I will
>> have to read up on the conventions for patches.
>
> See https://orgmode.org/worg/org-contribute.html#patches

Thank you.

>> A separate matter:
>> I find it unusual that we have the file+olp and file target
>> specifications but not a file+datetree target specification. As a
>> result, file+olp+datetree accepts a nil olp to insert the datetree on
>> the top level but file+olp does not because that would just be
>> equivalent to the file target specification. I feel like we should
>> either add one or do something like removing the file specification and
>> having file+olp cover its case.
>
> We used to have file+datetree target, and a number of others. They have
> been consolidated into a single file+olp+datetree in Org 9.1, 8 years ago.
> See 
> https://list.orgmode.org/orgmode/CADn3Z2+AanLPvUO9ENhZ_2tkAvsmdnq9ewR3sFasn=zv--s...@mail.gmail.com/

Should we do the same with file and file+olp? Or would that be too
backwards incompatible?

-- 
Best,
Kristoffer

Re: [BUG] Warning I don't understand [9.7.11 (release_9.7.11 @ /usr/share/emacs/30.1/lisp/org/)]

[Ihor Radchenko]

Nicolas Buduroi  writes:

> This happens randomly, I don't understand it nor know how to reproduce it.
> There's nothing wrong as far as I can tell outside of the warning showing
> up. I was just editing bullet points inside a headline, nothing fancy. I'm
> sending this message as suggested in the warning. Hope this helps.
> ...
> Package: Org mode version 9.7.11 (release_9.7.11 @
> /usr/share/emacs/30.1/lisp/org/)

Thanks for reporting!
Could you upgrade to the latest Org mode version (9.7.29) and let me
know if you keep seeing the warning?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] org-element--cache [9.6.7 (9.6.7-??-ca873f7fe @ ~/.config/emacs/.local/straight/build-30.1/org/)]

[Ihor Radchenko]

pranavkalsi via "General discussions about Org-mode."
 writes:

> Usually whenever I write a heading in org mode for example
> ...
> The following error(Warning) was prompted:
>
> " Warning (org-element-cache): org-element--cache: Got element without 
> parent. Please report it to Org mode mailing list (M-x org-submit-bug-report).

Thanks for reporting!

> I updated emacs recently but used it few times after update with no issues.

Does it mean that you are no longer on Org 9.6.7? You can check with
M-x org-version command.

> P.S.
> This is my first time sending a bug-report, so please pardon me if I
> make a stupid mistake or report something which was very obvious/ easy
> to solve. Thankyou so much for maintaining such a great package.

No mistakes. Do no worry. (And mistakes are allowed; this mailing list
is a kind of forum)

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Subject: [BUG] Org request me to submit bug report; The error was: (error "Invalid search bound (wrong side of point)") [9.7.29 (9.7.29-79781b @ /home/mfl/.emacs.d/elpa/org-9.7.29/)]

[Ihor Radchenko]

kf  writes:

> Subject: [BUG] Org request me to submit bug report;  The error was: (error
> "Invalid search bound (wrong side of point)") [9.7.29 (9.7.29-79781b @
> /home/mfl/.emacs.d/elpa/org-9.7.29/)]
>
> Emacs  : GNU Emacs 30.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.49, cairo version 1.18.4)
>  of 2025-03-30, modified by Debian
> Package: Org mode version 9.7.29 (9.7.29-79781b @
> /home/mba/.emacs.d/elpa/org-9.7.29/)

Thanks for reporting!
Do you see this warning frequently?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type

[Ihor Radchenko]

Markus Huber-Liebl  writes:

> Subject: [PATCH] ox-md.el: Respect `:html-prefer-user-labels' for target type
>
> * lisp/ox-md.el (org-md-link): Use `raw-path' as reference for
> targets to match behaviour of `org-html-target'.
>
> `org-md-link' always called `org-export-get-reference' regardless of
> the `:html-prefer-user-labels' option.  This let to a mismatch of the
> used references.

Thanks for the patch, but I think it only partially solves the problem.
You addressed targets, but not radio-targets and named references.
I think that it will be more appropriate to call `org-html--reference'
directly rather than trying to repeat its logic. Same for headings.

Also, this is a breaking change, so please add a notice to etc/ORG-NEWS file.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] gc-lock.eld [9.7.26 (9.7.26-07e380 @ /home/pradmin/.emacs.d/elpa/org-9.7.26/)]

[Ihor Radchenko]

prad  writes:

>  org--warnings '("org-element--cache: Org parser error in 
> zzotes.org::30996. Resetting.\n The error was: (error \"Invalid search 
> bound (wrong side of point)\")\n Backtrace:\n\"  backtrace-to-string(nil)\n  
> org-element-at-point()\n  org-at-item-p()\n  
> org-indent-add-properties(#> 66896 (0 2 0))\n  
> org-indent-initialize-buffer(#> (0 2 0))\n  
> org-indent-initialize-agent()\n  apply(org-indent-initialize-agent nil)\n  
> timer-event-handler([t 0 0 20 t org-indent-initialize-agent nil idle 0 
> nil])\n\"\n Please report this to Org mode mailing list (M-x 
> org-submit-bug-report).")

Thanks for reporting, but I am a bit confused.
In the subject line you say "gc-lock.eld", but judging from warnings,
you had some issue with parser.
Could you explain a bit what exactly happened?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] Accept nil outline path for file+olp+datetree org-capture-templates target

[Ihor Radchenko]

Kristoffer Balintona  writes:

>> Why not just using nil value as you initially suggested?
>
> Currently, both `org-capture-expand-headline' and
> `org-capture-expand-olp' error when the expanded headline or olp,
> respectively, return nil. I wanted to preserve that assuming there was a
> good reason behind this decision. Do you think interpreting a nil value
> in this way is more appropriate?

There is no need to preserve the behavior of
`org-capture-expand-headline'/`org-capture-expand-olp'. Their purpose is
basically parsing allowed values of olp/headline target. You are
proposing to extend the allowed values, so it is 100% fine to handle nil
without error - I will be a valid value now. The error should only be
thrown when the user supplies invalid target.

>> We used to have file+datetree target, and a number of others. They have
>> been consolidated into a single file+olp+datetree in Org 9.1, 8 years ago.
>> See 
>> https://list.orgmode.org/orgmode/CADn3Z2+AanLPvUO9ENhZ_2tkAvsmdnq9ewR3sFasn=zv--s...@mail.gmail.com/
>
> Should we do the same with file and file+olp? Or would that be too
> backwards incompatible?

Backwards compatibility per se is not a problem. For example,
file+datetree target is still working. It is just deprecated.
However, forcing users to change their setup (even just because they
start seeing deprecation warning) without an obvious counter-benefit is
not a good idea. I do not see any significant gain from consolidating
file+olp and file targets.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Question about contribution to improve svg handling in latex export

[Ihor Radchenko]

Emin Martinian  writes:

> If latex experts and/or maintainers of org-mode are broadly in agreement
> with the above, I would be happy to try and take the pull request to
> el-easydraw  and
> incorporate something like that into a PR for Org-mode. I think the way to
> go would be to modify the (when (equal filetype "svg")
> 
> portion of ox-latex.org to call something like the
> edraw-org-export-latex-link
> 
> function in my original PR (renamed/modified to not be specific to edraw).

Looks like there are no objections to the idea, so go ahead.
Just one comment - rather than creating a .pdf file in the same folder
with original .svg (which may or may not be writable), please use
org-persist cache. See
https://code.tecosaur.net/tec/org-mode/src/branch/dev/lisp/org-latex-preview.el#L2973
for an example how to do it.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Seeking guidance for starting timezone patch

[General discussions about Org-mode.]

Hey y’all!

I was thinking of contributing a patch to add timezone support for
org-mode, and I was curious if I could get some pointers on where & how
I should start. I’ve seen both the proposed syntax [0] and the most
recent org meetup notes [1] on the matter, and since the latter
recommended reaching out to the mailing list if someone was interested
in having a go at the patch, I figured I would send a message to
hopefully get some guidance on how to get started :^)

Best,
David

[0] 
[1] 

Re: Join the Org Mode project as the Worg maintainer

[Christian Moe]

Bastien  writes:
> Several Org users have offered to help, some already contributing to
> Worg, which is great!
>
> Ihor and I are happy to announce that Christian Moe is the new Worg
> maintainer 🦄

Hello, everybody!

Thank you for the confidence -- I'll do my best to live up to it. I'm
very happy that we have so many volunteers, including so many new
people.

15 years ago, I nervously sent a bug report to this list. Carsten
Dominik swiftly replied and asked if I could send a patch as well, and
he was so nice about it that I learned my first elisp, learned to make a
patch, and have been involved in the Org community ever since. I aspire
to be as welcoming.

For those who don't know me, I'm a Slovenia-based translator, editor,
and writer with a humanities background (religious studies). I am not a
computer scientist or developer, but come to Org-mode mainly from a user
perspective. For the past decade and a half I have used it as my `office
suite' for pretty much everything, and my first thought when facing a
new problem is often how it could be solved with existing Org features.

You'll find me on:
- The mailing list and this e-mail address
- Sourcehut: https://sr.ht/~chrmoe/ (for Worg)
- Mastodon: https://toot.si/@noctuaminervae
- Personal site: https://christianmoe.com
- Codeberg: https://codeberg.org/chrmoe

I'll be following up continuously, but plan to schedule regular `office
hours' for Worg on Fridays.

Yours,
Christian

Re: [BUG] Unintuitive indentation behavior when editing org-src blocks

[Ihor Radchenko]

Ihor Radchenko  writes:

>>> May you elaborate on the edge cases you encountered?
>>> It may be a good idea to add such cases to the tests as well.
>>
>> I think they all reduced to the case where adding the spaces increased
>> the minimum indent of the block, in which case `org-indent-line' would
>> remove `block-content-ind' spaces from all other lines in the block. I
>> attached a patch with a simple test where I also cleaned up the use of
>> obsolete function `org-get-indentation' in `test-org.el'.
>
> May you please explain how the test in the patch is related to the
> change you made in the code? The test seems to be passing both with and
> without your change.

It has been a while since the last activity in this thread.
May I know if you had a chance to look into my comments?

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

org-html-export-to-html and export options alist

[Sébastien Gendre]

Hello,

I was modifying the ox-html option alist to add an OPTION to
`:html-extension'. I do it like this:

(:html-extension nil "html-extension" org-html-extension)

But after re-evaluate the ox-html backend definition and adding this to my 
org-file:

#+OPTIONS: html-extension:"bear"

The exported file still have an ".html" extension.

If I debug the function `org-html-export-to-html', `ext-plist' is empty
and so the function don't use the value of option `:html-extension' but
of variable `org-html-extension' instead.

Is it a bug, or is it planned ?


signature.asc
Description: PGP signature

Re: org-html-export-to-html and export options alist

[Ihor Radchenko]

Sébastien Gendre  writes:

> If I debug the function `org-html-export-to-html', `ext-plist' is empty
> and so the function don't use the value of option `:html-extension' but
> of variable `org-html-extension' instead.
>
> Is it a bug, or is it planned ?

Bug.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] gc-lock.eld [9.7.26 (9.7.26-07e380 @ /home/pradmin/.emacs.d/elpa/org-9.7.26/)]

[Ihor Radchenko]

prad  writes:

> Hi Ihor! Sorry for the confusion, but I don't really understand the
> error myself. I just reported it because it tells me to do so.
>
> What happens is sometimes when I come out of suspend I see in a buffer
> (not the messages one afaik), that it can't find the gc-lock.eld file
> and after consulting with an aibot I deleted it:
>
> rm ~/.cache/org-persist/gc-lock.eld

That sounds similar to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75209
I believe that this particular issues should be fixed on development (main)
branch. Could you test?

> I don't know if this next problem is related and it is also a sporadic
> issue. Right now if I have the following all folded:
>
> * h1...
> * h2...
> * h3...
> * h4...
>
> I can't unfold h4. If I try to unfold h3, h4 gets unfolded but not h3.
>
> If they are already unfolded (ie with ), then I can't fold h4.
> However, if I try folding h3, I can't but h4 gets folded (but under h3).
> I same thing happens with h2, if I fold it every heading underneath
> folds. H1 functions fine though.
>
>  (S-tab) always works fine even when tab doesn't.

This might be related to the same issue you have with gc-lock.eld (race
condition between multiple Emacs instances). To confirm (and maybe solve
it for yourself), you can (1) add (setq org-element-cache-persistent nil)
to your config; (2) close emacs; (3) clean your org-persist-directory

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ox-html.el: Add file level option to manage headlines self link

[Ihor Radchenko]

Sébastien Gendre  writes:

> What do you mean by "Allow KEYWORD" ?
>
> You mean a #+KEYWORD ? But these keyword only accept string as values,
> if I made no mistake.

I mean #+KEYWORD + modifying parts of ox-html that use :html-divs to
understand its value to be a string in addition to alist.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [FR] Accept nil outline path for file+olp+datetree org-capture-templates target

[Ihor Radchenko]

Kristoffer Balintona  writes:

> Thank you for the help. I've attached a diff for a set of proposed
> changes. It has `org-capture-expand-olp' and
> `org-capture-expand-headline' return the symbol 'file in certain cases
> and has `org-capture-set-target-location' treat those cases specially,
> inserting the capture entry at the top level. Additionally, I updated
> the docstring of `org-capture-templates' appropriately and added an
> additional test in `test-org-capture/org-capture-expand-olp'.

Why not just using nil value as you initially suggested?
 
> ... Although I've never contributed to org before, so I will
> have to read up on the conventions for patches.

See https://orgmode.org/worg/org-contribute.html#patches
 
> A separate matter:
> I find it unusual that we have the file+olp and file target
> specifications but not a file+datetree target specification. As a
> result, file+olp+datetree accepts a nil olp to insert the datetree on
> the top level but file+olp does not because that would just be
> equivalent to the file target specification. I feel like we should
> either add one or do something like removing the file specification and
> having file+olp cover its case.

We used to have file+datetree target, and a number of others. They have
been consolidated into a single file+olp+datetree in Org 9.1, 8 years ago.
See 
https://list.orgmode.org/orgmode/CADn3Z2+AanLPvUO9ENhZ_2tkAvsmdnq9ewR3sFasn=zv--s...@mail.gmail.com/

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] lisp/ox-html.el: Add file level option to manage headlines self link

[Sébastien Gendre]

What do you mean by "Allow KEYWORD" ?

You mean a #+KEYWORD ? But these keyword only accept string as values,
if I made no mistake.


signature.asc
Description: PGP signature

Re: [PATCH] lisp/ox-html.el: Add file level option to manage headlines self link

[Sébastien Gendre]

What if I add new export options in the alist:

* :html-div-preamble

* :html-div-content

* :html-div-preamble

Each one have nil as default value and can have one of these 2 values:

* "tag-name": A tag name (ex: "div") as a string

* (:tag "tag-name" :id "id-name" :class "class-name"): A plist where
  only :tag is non-optional


If one of these 3 option are set, ox-html use it. Otherwise it use the
value of :html-divs/org-html-divs.

So, a user could set its option like this:

#+OPTION: html-div-content:(:tag "article" :class "content")

Or with the variable `org-html-divs' if she or he want to set all in one
`(setq)'.

And for ox-html, I can write a function to extract the correct value
from the info plist.

What do you think ? Is it a good idea, or do I over-complicated it ?


signature.asc
Description: PGP signature