Re: PATCH] Auto-complete PRINT_BIBLIOGRAPHY with a trailing colon

[Pedro Andres Aranda Gutierrez]

> From: Rudolf Adamkovič 
> To: emacs-orgmode@gnu.org
> Cc: Rudolf Adamkovič 
> Subject: [PATCH] Auto-complete PRINT_BIBLIOGRAPHY with a trailing
> colon
> Message-ID: <20240502162033.16420-1-rud...@adamkovic.org>
>
> * lisp/org.el (org-options-keywords): Add a trailing colon to the
> 'PRINT_BIBLIOGRAPHY' keyword to avoid unnecessary user confusion.

Hi Rudolf,

I don't see any confusion by not having a trailing colon in
#+print_bibliography. Where would there be? (I'm asking, because I'm
tutoring a couple novel users and it would be good to have an answer ready
if they ask ;-) )

Best, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[Q/Bug?] Comment for noweb reference comments content

[João Pedro]

Hi,

Ok so I don't know whether this is a bug or intended behaviour (though
if its the latter I propose we reconsider), but if I have the following

#+begin_src emacs-lisp :noweb yes :comments noweb :tangle /tmp/foo.el
(progn
  <>)
#+end_src

#+name: foo
#+begin_src emacs-lisp
(message "foo")
#+end_src

the resulting foo.el will have a syntax error, since the closing ) for
`progn' will have been commented like so

;; [[file:...][No heading:1]]
(progn
  ;; [[file:...][foo]]
  (message "foo")
  ;; foo ends here)
  ^
;; No heading:1 ends here

It seems like some macro let-bound in `org-babel-expand-noweb-refereces'
is doing this, but I couldn't pinpoint exactly what or where. What I
could achieve though, is to add a newline after the second call to
`c-wrap' inside `expand-body''s definition, which at least solve the
problem of throwing syntax errors, but I don't think that would be the
best solution.

Best regards,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

Re: Possible to set block switches "globally"?

[João Pedro]

Em sexta, 03/05/2024 às 10:12 (-07), Tom Gillespie  escreveu:

> Hi,
>Thanks for getting things going on this again João.

No problem! I've been meaning to get my feet wet on some Org-mode
hacking for a while now.

> Based on what is in org-element-example-block-parser
> and org-element-src-block-parser I think
>
> :number-lines (yes|no|continue) as João proposes
> :indent   (preserve|align|???) not sure about naming
> :labels  (link|keep|remove|remove-whitespace)
> :label-format  regexp-string

Yeah, as Ihor pointed out I did forget about -i, though I'm not really
sure what that does.

> Defaults would be :number-lines no, :indent align,
> :labels remove-whitespace and :label-format would
> inherit from the default.
>
> The remove-whitespace option would remove the label
> itself along with any whitespace leading up to it, this
> avoids the user needing to specify the leading whitespace
> in :label-format. The remove option by itself is retained
> in the event that someone has aligned their labels and
> wants to retain the whitespace. This may be too complex
> though and remove-whitespace is not needed because
> :label-format can be modified as needed.
>
> Header arguments need to have a single value, so I think
> we should split :labels and :label-format, that way users
> can also specify :label-format without having to specify
> :labels first (otherwise there is ambiguity about what a single
> argument :labels means.

Sure, makes sense to separate it.

I tried searching for where switches are parsed in the code, but
couldn't find much. Could you provide me with some pointers and files I
should be looking at?

Cheers,

-- 
João Pedro de A. Paula
IT bachelors at Universidade Federal do Rio Grande do Norte (UFRN)

HowTo: Upgrade org-mode installation from the command-line

[Samuel Wales]

never mind.  package-initilalize if called in .emacs once will not repeat
or warn despite being not needed there normally.  at least in 27.



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

can clocktable link to IDs?

[Bill White]

When I create a clocktable, its entries are links to heading text: 

[ [file:/path/to/meetings.org::*featureset meeting][featureset meeting] ] 

But in my meetings.org file there are dozens of headings that simply read: 
``` 
​* featureset meeting 
``` 
so all clocktable links to these meetings point to the first instance in my 
meetings.org. 

However, when I run org-store-link with point on a particular heading I'm 
interested in, I get a link to a unique ID: 

[ [id:29FDF5EE-BD50-491F-9332-B007F8CE5CE9][featureset meeting] ] 

Is there a way to convince the clocktable mechanism to link to a unique ID 
(when it exists) rather than a possibly non-unique heading? 

Thanks - 

bw 
"No, ma'am, we're musicians." 

Re: [FR] Support headline as a function for file+headline target for org-capture-templates

[Nafiz Islam]

So far I have written this code...

(defun org-capture-expand-headline (headline)
  "Expand functions, symbols and strings for HEADLINE.


When HEADLINE is a function, call it.  When it is a form, evaluate


it.  When it is a variable, return its value.  When it is a string,


treat it as a headline title. When it is `t', select existing headline


title or enter a new one.  In any other case, raise an error."
  (let* ((headlines (org-map-entries (lambda ()
   (org-element-property :title
(org-element-at-point)
 (final-headline (cond ((stringp headline) headline)
   ((functionp headline) (funcall headline
headlines))
   ((eq headline t) (completing-read "Enter
headline: " headlines  nil 'confirm))
   ((and (symbolp headline) (boundp headline))
(symbol-value headline))
   (t nil
(or (org-string-nw-p final-headline)
(error "Invalid headline: %S" headline

and I updated `org-capture-set-target-location' to use that function when
handling with target `file+headline'

What I am concerned about is the amount of tests I might have to write or
update for `org-capture'.

testing/lisp/test-org-capture.el


125:  `(("t" "Todo" entry (file+headline ,file "A") "** H1 %?"


144: `(("t" "Todo" entry (file+headline ,file2 "A")


175:  `(("t" "Todo" entry (file+headline ,file "A") "** H1 %?"


221:  `(("t" "Todo" entry (file+headline ,file "A") "** H1 %?"


233:  `(("t" "Test" entry (file+headline ,file "A") "** H\nFoo"


243: `(("t" "Test" entry (file+headline ,file "A") "** "


279:  `(("t" "Item" item (file+headline ,file "A") "- X"


312:  `(("t" "Item" item (file+headline ,file "A") "- X"


323:  `(("t" "Item" item (file+headline ,file "A") "- X"


337:  `(("t" "Item" item (file+headline ,file "A") "- X"


358:  `(("t" "Item" item (file+headline ,file "A") "- X"


371:  `(("t" "Item" item (file+headline ,file "A") "- X"


538:`(("t" "Table" table-line (file+headline ,file "Inbox")


552:`(("t" "Table" table-line (file+headline ,file "Inbox")


723:`(("t" "Text" plain (file+headline ,file "A") "Foo"


733:`(("t" "Text" plain (file+headline ,file "A") "Foo"

How do you think it should be tested if the headline can be 4 different
types?

Apology in advance if the formatting is off.

Re: [PATCH] Add support for shortdoc link type

[Bruno Cardoso]

On 2024-05-02, 17:41 +0700, Max Nikulin  wrote:

> `condition-case' may help to avoid the internal `shortdoc--groups' 
> variable here. As to completion, it is better to ask for public API. 
> However emacs developers likely will decline such request.
>
> Consider the following just as ideas.
>
> - Support of search options. Buttons in help pages move point to 
> specific functions.
>
> 
>
> - At first I considered adding shortdoc to help links that may call 
> either `describe-function' or `describe-variable', but it is unlikely 
> possible.

Hi Max,

Thanks for your suggestions. Indeed `condition-case' might be better there.

I implemented the search option by borrowing the regexp from `ol-info':

(defun org-link--open-shortdoc (path _)
  "Open a \"shortdoc\" type link.
PATH is a group name or \"group::#function\"."
  (string-match "\\`\\([^#:]*\\)\\(?:[#:]:?\\(.*\\)\\)?\\'" path)
  (let ((group (match-string 1 path))
(fn (match-string 2 path)))
(condition-case nil
(progn
  (shortdoc-display-group group)
  (when fn
(re-search-forward (concat "^(" (string-remove-prefix "#" fn))
   nil t)
(beginning-of-line)))
  (error (message "Unknown shortdoc group: %s" group)

It works, but I'm not quite sure if this is the best approach.

It curently matches all the cases below, as I got confused about the correct 
link syntax:

shortdoc:text-properties:get-pos-property
shortdoc:text-properties::get-pos-property
shortdoc:text-properties#get-pos-property
shortdoc:text-properties:#get-pos-property
shortdoc:text-properties::#get-pos-property


Best,

Bruno.

Re: [FR]: thing-at-point 'org-table-cell

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>>> It would be great to have a thing-at-point handler that returns a cell in
>>> and org table. The most simple use case is to have a table in an org-file
>>> with data that you need to transfer to an online Web page. Being able to
>>> (copy-as-kill ...) a cell's contents could speed up the whole process...
>> 
>> May you please elaborate on how exactly `thing-at-point' will help 
>> copy-as-kill?
> 
> Hi Ihor, of course this was just an example. The thing-at-point would make it 
> easier to write a copy-as-kill-cell function.

Then, you can just use `org-element-context' and/or `org-element-at-point'.

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

Re: [FR]: thing-at-point 'org-table-cell

[Pedro Andres Aranda Gutierrez]


Hi Ihor, of course this was just an example. The thing-at-point would make it 
easier to write a copy-as-kill-cell function.

Best,/PA

Enviado desde mi iPhone

> El 3 may 2024, a las 13:17, Ihor Radchenko  escribió:
> 
> Pedro Andres Aranda Gutierrez  writes:
> 
>> It would be great to have a thing-at-point handler that returns a cell in
>> and org table. The most simple use case is to have a table in an org-file
>> with data that you need to transfer to an online Web page. Being able to
>> (copy-as-kill ...) a cell's contents could speed up the whole process...
> 
> May you please elaborate on how exactly `thing-at-point' will help 
> copy-as-kill?
> 
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Max Nikulin]

On 03/05/2024 18:14, Ihor Radchenko wrote:

Max Nikulin writes:


Yes, sure. It is fine to reuse an existing user option. Though reading
through its docstring and the code, I cannot tell what this is doing
exactly. Is it applying to all HTML elements, or just headings?

On my end, I have that option set to nil, but exported headings do use
their CUSTOM_ID.


It seems it was broken by
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5e9953fa0e

`user-label' is set to CUSTOM_ID when it is set, so checking the
variable is not effective any more.


Nothing is broken. CUSTOM_IDs for _headings_ were used unconditionally.

org-html-prefer-user-labels
 ...
 Independently of this variable, however, CUSTOM_ID are always
 used as a reference.


My bad. I believed that this option is (or was) necessary to get anchor 
names as CUSTOM_ID, but I have tried Org-9.1.9 and I see elements having 
id attribute with CUSTOM_ID values.

Re: Possible to set block switches "globally"?

[Tom Gillespie]

Hi,
   Thanks for getting things going on this again João.

Based on what is in org-element-example-block-parser
and org-element-src-block-parser I think

:number-lines (yes|no|continue) as João proposes
:indent   (preserve|align|???) not sure about naming
:labels  (link|keep|remove|remove-whitespace)
:label-format  regexp-string

Defaults would be :number-lines no, :indent align,
:labels remove-whitespace and :label-format would
inherit from the default.

The remove-whitespace option would remove the label
itself along with any whitespace leading up to it, this
avoids the user needing to specify the leading whitespace
in :label-format. The remove option by itself is retained
in the event that someone has aligned their labels and
wants to retain the whitespace. This may be too complex
though and remove-whitespace is not needed because
:label-format can be modified as needed.

Header arguments need to have a single value, so I think
we should split :labels and :label-format, that way users
can also specify :label-format without having to specify
:labels first (otherwise there is ambiguity about what a single
argument :labels means.

Best,
Tom

Re: Consecutive plain list items of different types

[Tom Gillespie]

IIRC I wrote the part about there being two types of lists at the syntax level,
which are bulleted and numbered, descriptive are effectively bulleted in the
context of this behavior, but I think it is fine to say multiple.

With regard to the stated behavior about consecutive being parsed separately
I don't remember writing that part unless as was suggested I mean that they
were fully separate lists, but that wouldn't make sense.

The behavior is that everything at a level is converted to the type of
the first occurring list item at that level.

One wrinkle is that when applied to individual list items org-element
will report the type as written (which is expected) however on export
they are converted to the type of the first occurring item.

So the now-removed sentence might have referred to the org-element behavior.

Regardless, the change is an improvement. Thanks!

Tom

Re: [BUG] Capture fails condition-case: Capture template ‘i’: Wrong type argument: sequencep, org-display-buffer-split [9.6.15 (release_9.6.15 @ /home/torysa/emacs/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

web...@toryanderson.com (Tory S. Anderson) writes:

> When I select any capture command, most crucially including the one from my 
> gnus emails and most simply just my save my own text, I am blocked by the 
> error
>
> Capture template ‘i’: Wrong type argument: sequencep, 
> org-display-buffer-split [9.6.15 (release_9.6.15 @ 
> /home/torysa/emacs/.emacs.d/straight/build/org/)]
>
> the template that causes the above error is this:
>
> ("i" "Icebox" entry (file+olp+datetree "~/org/icebox.org") "* TODO %U 
> %^{prompt} %^g\n  %?" :prepend t)

Please make sure that you are using the latest Org mode version from
main branch.

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

[BUG] Capture fails condition-case: Capture template ‘i’: Wrong type argument: sequencep, org-display-buffer-split [9.6.15 (release_9.6.15 @ /home/torysa/emacs/.emacs.d/straight/build/org/)]

[Tory S. Anderson]

When I select any capture command, most crucially including the one from my 
gnus emails and most simply just my save my own text, I am blocked by the error

Capture template ‘i’: Wrong type argument: sequencep, org-display-buffer-split 
[9.6.15 (release_9.6.15 @ /home/torysa/emacs/.emacs.d/straight/build/org/)]

the template that causes the above error is this:

("i" "Icebox" entry (file+olp+datetree "~/org/icebox.org") "* TODO %U 
%^{prompt} %^g\n%?" :prepend t)

However, I seem to receive the same error on the rest of them.


 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.




Emacs  : GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, 
cairo version 1.18.0)
Package: Org mode version 9.6.15 (release_9.6.15 @ 
/home/torysa/emacs/.emacs.d/straight/build/org/)

current state:
==
(setq
 org-special-ctrl-o nil
 org-link-elisp-confirm-function 'yes-or-no-p
 org-agenda-diary-file "~/org/agenda.org"
 org-directory "~/org/"
 org-agenda-skip-deadline-prewarning-if-scheduled t
 org-agenda-start-with-clockreport-mode t
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-agenda-custom-commands '(("l" . "schooL")
  ("ld" "schooL Day"
   ((agenda ""
 ((org-agenda-span 1) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset '("+:CLASS:" 
"-:TSA:")))
 )
)
   nil)
  ("lw" "schooL Week"
   ((agenda ""
 ((org-agenda-span 7) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset '("+:CLASS:" 
"-:TSA:")))
 )
)
   nil)
  ("lm" "schooL Month"
   ((agenda ""
 ((org-agenda-span 'month) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset '("+:CLASS:" 
"-:TSA:")))
 )
)
   nil)
  ("p" . "Priesthood")
  ("pd" "Priesthood Day"
   ((agenda ""
 ((org-agenda-span 1) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:PRIESTHOOD:" "-:TSA:")))
 )
)
   nil)
  ("pw" "Priesthood Week"
   ((agenda ""
 ((org-agenda-span 7) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:PRIESTHOOD:" "-:TSA:")))
 )
)
   nil)
  ("pm" "Priesthood Month"
   ((agenda ""
 ((org-agenda-span 'month) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:PRIESTHOOD:" "-:TSA:")))
 )
)
   nil)
  ("w" . "Work")
  ("wd" "Work Day"
   ((agenda ""
 ((org-agenda-span 1) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:ODH:\\|:AGENDA:\\|:CONFERENCE:" "-:TSA:\\|:PRIESTHOOD:")))
 )
)
   nil)
  ("ww" "Work Week"
   ((agenda ""
 ((org-agenda-span 7) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:ODH:\\|:AGENDA:\\|:CONFERENCE:" "-:TSA:\\|:PRIESTHOOD:")))
 )
)
   nil)
  ("wm" "Work Month"
   ((agenda ""
 ((org-agenda-span 'month) 
(org-agenda-start-on-weekday nil)
  (org-agenda-regexp-filter-preset 
'("+:ODH:\\|:AGENDA:\\|:CONFERENCE:" "-:TSA:\\|:PRIESTHOOD:")))
 )
)
   nil)
 

Re: link can not be created in a line with another link.

[Ihor Radchenko]

Max Nikulin  writes:

> On 02/05/2024 18:15, Ihor Radchenko wrote:
>> May you try the attached patch (on top of the latest main)?
>> Does it feel better?
>
> I see regressions only (Emacs 28).
>
> [[#foo]]
> [[#bar]]
>
> SPC causes permanent appearance of square brackets for [[#foo]].

That's minor. I can fix this edge case.

> I do not like flashes especially since they do not help to avoid issues 
> with prepending a new link
>
> - [[#bar]]

This is a more important problem.
But what would you consider better? Maybe something akin
https://github.com/awth13/org-appear, but for the whole line?

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

RE: HowTo: Upgrade org-mode installation from the command-line

[Ihor Radchenko]

"Cook, Malcolm"  writes:

>>May you prepare a patch modifying doc/org-manual.org with your suggestions?
>>See https://orgmode.org/worg/org-contribute.html
>
> Glad to try.  How's this?

Thanks!
Applied, onto main, with modifications.
I merged your new section into previous section explaining how to
install Org mode using package.el. I compressed the explanations to be
more in flow with the previous section and removed bash-specific code,
leaving an one-liner that has more chances to work with arbitrary
shells. I also added a TINYCHANGE cookie as you do not seem to have FSF
copyright assignment.

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=09520a056

You are also listed as one of Org mode contributors now.
https://git.sr.ht/~bzg/worg/commit/d1d32137

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

Re: Possible to set block switches "globally"?

[Ihor Radchenko]

João Pedro  writes:

> All right so if I understand correctly, we'd like to deprecate switches
> from the parser and introduce :key val pairs for each switch, but no one
> has gotten to it yet?

Yes

> If that's the case, I'd propose something like
>
> - (-|+)n => :number-lines (yes|*no*|continue)
> ^ +n
> - -r => :labels (link|keep|*remove*) ("label string")?
>  ^ -k ^ -l "label string"
>
> and could give it a try. What do you think?

Looks reasonable.
Although you forgot -i :)

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

Re: [DISCUSSION] The meaning of :cmdline header argument across babel backends

[Ihor Radchenko]

Matt  writes:

> Since we're considering this for all babel backends, "interpreter-args" 
> wouldn't describe gcc or other compilers.  What about :command-args, 
> :command-args, :cmd-args?  "Command" is the only thing I can think of that 
> describes all of the languages, other than maybe "binary" or "executable".  
> Maybe we could simply use ":args"?  Maybe ":meta-args" since gcc or bash is 
> meta to the script/artifact?

I am not a big fan. It might be easily confused with :script-args.

Maybe instead use two different extra arguments:
:interpreter-args / :compiler-args ?

Then, also :script-args / :program-args

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

Re: Importing "quoted" strings in `org-babel-import-elisp-from-file'

[Ihor Radchenko]

Max Nikulin  writes:

> What I do not like in `org-babel-read' is false positive for escaped 
> quote when actually backslash is escaped:
>
> (org-babel-read "\"1\" 2 \"3\"" t)
> "1\\"

This is a bug.
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=2028bb15c

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

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Protesilaos Stavrou  writes:

>>> Since we are now using labels for the HTML export, I think it makes
>>> sense to optionally use those for the anchor tags as well.
>> ...
>> We can indeed add such option, but is it of any practical use?
>> Do you have examples of workflows when such new option will be useful?
>
> An important purpose of using labels is sustainability. If the document
> changes, the labels remain (as would CUSTOM_ID). The problem when
> numbers are used in the anchor text is that if others want to make a
> reference to the footnote (cite it), they will use what they see (not
> the ID, which appears in the source only). And if the document changes,
> their references will be broken.

Sorry, but I am not convinced.
I can make the same argument, say, for headline titles:
It is very natural to refer to a headline when referencing a document,
but when headline changes, such reference is no longer going to work.

For headline titles, it is well-known that a more reliable way is to use
#anchor in the URL. Anchors are much less likely to change compared to
headline titles.

With your previous patch, footnote anchors became more stable and people
can now reliably link to footnotes using #anchor semantics, given that
the page author took care about naming the footnotes.
I find it good enough.

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

Re: [FR]: thing-at-point 'org-table-cell

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> It would be great to have a thing-at-point handler that returns a cell in
> and org table. The most simple use case is to have a table in an org-file
> with data that you need to transfer to an online Web page. Being able to
> (copy-as-kill ...) a cell's contents could speed up the whole process...

May you please elaborate on how exactly `thing-at-point' will help copy-as-kill?

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

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

>> Yes, sure. It is fine to reuse an existing user option. Though reading
>> through its docstring and the code, I cannot tell what this is doing
>> exactly. Is it applying to all HTML elements, or just headings?
>> 
>> On my end, I have that option set to nil, but exported headings do use
>> their CUSTOM_ID.
>
> It seems it was broken by
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5e9953fa0e
>
> `user-label' is set to CUSTOM_ID when it is set, so checking the 
> variable is not effective any more.

Nothing is broken. CUSTOM_IDs for _headings_ were used unconditionally.

org-html-prefer-user-labels
...
Independently of this variable, however, CUSTOM_ID are always
used as a reference.

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

Re: [FR] Support headline as a function for file+headline target for org-capture-templates

[Ihor Radchenko]

Nafiz Islam  writes:

>> > Would you be interested to submit a patch?
>> If I finish writing a patch for it. Sure.

You may refer to https://orgmode.org/worg/org-contribute.html
And feel free to ask anything if you have questions.

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

Re: Consecutive plain list items of different types

[Ihor Radchenko]

Ihor Radchenko  writes:

>> but more importantly, based on that description I would expect the following 
>> test document to parse into three separate plain lists, but it parses as a 
>> single plain list with 3 items:
>>
>> ```
>> 1. foo
>> - bar
>> - lorem :: ipsum
>> ```
>>
>> [1] https://orgmode.org/worg/org-syntax.html#Plain_Lists
>
> AFAIK, the first item determines the list type in our parser.
> Timothy, do you remember why you wrote about different list types being
> parsed separately?

I see no explanation, except reference to previous discussions with Tom
Gillespie. However, searching in the archives, I do not see anything
related to plain list parser.

Considering that the parser does not distinguish consecutive lists of the
same time (unless they are properly separated with double blank), I
removed the confusing statement.

Fixed.
https://git.sr.ht/~bzg/worg/commit/81425d84

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

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Max Nikulin]

On 03/05/2024 13:59, Protesilaos Stavrou wrote:

From: Max Nikulin Fri, 26 Apr 2024 16:53:23 +0700

Another option may be to rely on the existing one:
`org-html-prefer-user-labels'


Yes, sure. It is fine to reuse an existing user option. Though reading
through its docstring and the code, I cannot tell what this is doing
exactly. Is it applying to all HTML elements, or just headings?

On my end, I have that option set to nil, but exported headings do use
their CUSTOM_ID.


It seems it was broken by
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5e9953fa0e

`user-label' is set to CUSTOM_ID when it is set, so checking the 
variable is not effective any more.

Re: link can not be created in a line with another link.

[Max Nikulin]

On 02/05/2024 18:15, Ihor Radchenko wrote:

May you try the attached patch (on top of the latest main)?
Does it feel better?


I see regressions only (Emacs 28).

[[#foo]]
[[#bar]]

SPC causes permanent appearance of square brackets for [[#foo]].

I do not like flashes especially since they do not help to avoid issues 
with prepending a new link


- [[#bar]]

Re: [BUG] #+CALL - permission error -bash

[Max Nikulin]

On 02/05/2024 21:55, Ihor Radchenko wrote:

vitalij writes:


in org-babel-sh-evaluate
  file:~/.emacs.d/elpa/org-9.6.28/ob-shell.el::300

this do apply: (process-file "/tmp/babel-NfRG9P/sh-script-jmKNA4"
  "/tmp/babel-NfRG9P/sh-stdin-o3CEm5" # nil nil)

I don't allow executables in /tmp folder!


Why do you think that it is a bug in Org mode?
AFAIK, it is generally expected that anything can go into tmp.


There are various guides recommending noexec, however they warn that 
some issues should be expected.


Securing Debian Manual
- https://www.debian.org/doc/manuals/securing-debian-manual/ch04s10.en.html
  4.10. Mounting partitions the right way
- 
https://www.debian.org/doc/manuals/securing-debian-manual/checklist.en.html

  B.2. Configuration checklist

Security in Arch Linux wiki:
https://wiki.archlinux.org/title/Security#Mount_options
Mount options


How to make it this way:

(process-file "/use/bin/bash /tmp/babel-NfRG9P/sh-script-jmKNA4"
 "/tmp/babel-NfRG9P/sh-stdin-o3CEm5" # nil nil)

???

It is like when you do:
./a.sh

instead of:
bash a.sh


Likely you mean

(process-file "/usr/bin/bash"
 "/tmp/babel-NfRG9P/sh-stdin-o3CEm5" # nil 
"/tmp/babel-NfRG9P/sh-script-jmKNA4")


but it would ignore shebang. Try

#!/bin/sh -e
false
printf "Should not be executed\n"

So it is necessary to either drop :shebang or set temporary directory to 
a suitable path.

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Protesilaos Stavrou]

> From: Ihor Radchenko 
> Date: Sun, 28 Apr 2024 10:37:58 +
>
> Protesilaos Stavrou  writes:
>
>> Since we are now using labels for the HTML export, I think it makes
>> sense to optionally use those for the anchor tags as well.
>>
>> See the attached patch for a possible way of doing this.
>>
>> As always, you are welcome to make any further changes.
>
> We can indeed add such option, but is it of any practical use?
> Do you have examples of workflows when such new option will be useful?

An important purpose of using labels is sustainability. If the document
changes, the labels remain (as would CUSTOM_ID). The problem when
numbers are used in the anchor text is that if others want to make a
reference to the footnote (cite it), they will use what they see (not
the ID, which appears in the source only). And if the document changes,
their references will be broken.

Now, the problem with labels is that their are not visually appealing,
especially the longer they get. Another approach is to have a string for
the anchor text of the footnote references. Something like "[^]" with a
hover/tooltip effect, which shows the full label.

[ Of course, the hover/tooltip text can be further enhanced with CSS and
  JavaScript, but we are keeping it simple for now. Though I think that
  would ultimately be the best user experience. ]

For a proof of concept, see the attached patch, which expands on the
previous proposal.

While clicking around the footnotes, I noticed that we can also improve
the user experience by adding a CSS ":focus" state so that it is easier
to spot where we are after following an internal link. I can send this
as a separate patch/thread.

-- 
Protesilaos Stavrou
https://protesilaos.com
>From c6c0aebec12ee19da6ebf7daa972af5b23119358 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Protesilaos Stavrou 
Date: Fri, 3 May 2024 11:44:34 +0300
Subject: [PATCH] Add option on how to format of HTML footnote anchor text

* lisp/ox-html.el (org-html-footnote-anchor-text): Define new user option.
(org-html-footnote-section): Use the new option for the footnote definitions.
(org-html-footnote-reference): Use the new option for the footnote references.
---
 lisp/ox-html.el | 43 +--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index b35a31865..bbad21a7b 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -766,6 +766,25 @@ (defcustom org-html-prefer-user-labels nil
   :type 'boolean
   :safe #'booleanp)
 
+(defcustom org-html-footnote-anchor-text nil
+  "Choose how to format HTML footnotes.
+
+When the value is nil, automatically number footnotes and use the number
+for the anchor text in both references and definitions.
+
+When the value is non-nil, use the footnote label as the anchor text for
+both the references and definitions.
+
+When the value is a string, use it for the anchor text of references.
+For the anchor text of definitions use either the label, if present, or
+an automatically assigned number."
+  :group 'org-export-html
+  :version "30.1"
+  :package-version '(Org . "9.7")
+  :type '(choice (const :tag "Do not show labels in HTML anchor text; use numbers" nil)
+ (const :tag "Use labels in HTML anchor text for both references and definitions" t)
+ (string :tag "Use custom string for HTML anchor text for references and labels for definitions")))
+
  Inlinetasks
 
 (defcustom org-html-format-inlinetask-function
@@ -1898,7 +1917,12 @@ (defun org-html-footnote-section (info)
  #'identity nil t)))
 		   (anchor (org-html--anchor
 (format "fn.%s" (or label n))
-			n
+(cond
+ ((and org-html-footnote-anchor-text label)
+  label)
+ ((and org-html-footnote-anchor-text (null label))
+  (user-error "All footnotes must have labels for `org-html-footnote-anchor-text' to work"))
+ (t n))
 			(format " class=\"footnum\" href=\"#fnr.%s\" role=\"doc-backlink\"" (or label n))
 			info))
 		   (contents (org-trim (org-export-data def info
@@ -2757,6 +2781,7 @@ (defun org-html-footnote-reference (footnote-reference _contents info)
   (equal label (number-to-string (string-to-number label
   nil
label))
+  (anchor-is-string (stringp org-html-footnote-anchor-text))
 	  (id (format "fnr.%s%s"
 		  (or label n)
 		  (if (org-export-footnote-first-reference-p
@@ -2774,7 +2799,21 @@ (defun org-html-footnote-reference (footnote-reference _contents info)
  (format
   (plist-get info :html-footnote-format)
   (org-html--anchor
-   id n (format " class=\"footref\" href=\"#fn.%s\" role=\"doc-backlink\"" (or label n)) info)
+   id
+   (cond
+((string-blank-p 

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Protesilaos Stavrou]

> From: Ihor Radchenko 
> Date: Sun, 28 Apr 2024 10:22:50 +
>
> Protesilaos Stavrou  writes:
>
>>> See the attached tentative patch.
>>
>>> [... 144 lines elided]
>>
>> Thank you! I just tried it. I encountered two problems with it, which I
>> am addressing with the two attached patches (feel free to modify as
>> needed). In short:
>>
>> 1. The footnote definitions at the bottom of the file were still using
>> the ordinal HTML id, which did not correspond to the href with the
>> label.
>>
>> 2. If the file had a mixture of labeled and anonymous/unlabeled
>> footnotes, then the export would break as it would be passing a nil
>> value to 'string-to-number'.
>>
>> Please let me know how to proceed.
>
> Applied, onto main, after squashing the patches together.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=065af4b42
> Handled.

Thank you!

-- 
Protesilaos Stavrou
https://protesilaos.com

Re: [BUG] HTML export does not preserve footnote label [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/30.0.50/lisp/org/)]

[Protesilaos Stavrou]

> From: Max Nikulin 
> Date: Fri, 26 Apr 2024 16:53:23 +0700
>
> On 26/04/2024 15:17, Protesilaos Stavrou wrote:
>> Since we are now using labels for the HTML export, I think it makes
>> sense to optionally use those for the anchor tags as well.
> [...]
>
>> +(defcustom org-html-footnote-use-label-for-anchor-text nil
>
> Another option may be to rely on the existing one: 
> `org-html-prefer-user-labels'

Yes, sure. It is fine to reuse an existing user option. Though reading
through its docstring and the code, I cannot tell what this is doing
exactly. Is it applying to all HTML elements, or just headings?

On my end, I have that option set to nil, but exported headings do use
their CUSTOM_ID.

-- 
Protesilaos Stavrou
https://protesilaos.com