Re: org-search-view across all org-agenda-files ?

[Samuel Wales]

"This command searches the agenda files, and in addition the files
listed in ‘org-agenda-text-search-extra-files’ unless a restriction lock
is active." --

On 10/26/23, David Masterson  wrote:
> Can org-search-view work across all org-agenda-files?  Is there an
> alternative?
> --
> David Masterson
>
>


-- 
The Kafka Pandemic

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

org-search-view across all org-agenda-files ?

[David Masterson]

Can org-search-view work across all org-agenda-files?  Is there an alternative?
-- 
David Masterson

[BUG] org-comment-dwim does not work with temporary Transient Mark mode [9.7-pre (release_9.6.10-902-g41ff56 @ /home/jschmidt/work/org-mode/lisp/)]

[Jens Schmidt]

* Reproducer

Save the following files:

- /tmp/test.org -
#+begin_src bash
  foo
  bar
  baz
#+end_src
- /tmp/test.org -

- /tmp/test.el -
(transient-mark-mode -1)
(setq org-support-shift-select t)
- /tmp/test.el -

Then start Emacs as

  emacs -Q -l /tmp/test.el +2 /tmp/test.org

Select the three lines of the source block with `C-3 S-', then
press `M-;'.

For me the resulting buffer looks like:

- /tmp/test.org -
#+begin_src bash
  foo
  bar
  baz   # (point)
#+end_src
- /tmp/test.org -

where I would have expected:

- /tmp/test.org -
#+begin_src bash
  # foo
  # bar
  # baz(point)
#+end_src
- /tmp/test.org -

The latter result you get when Transient Mark mode is permanently on.

* My Educated Guess

In the following snippet from `org-comment-dwim'

  (org-babel-do-in-edit-buffer (call-interactively #'comment-dwim)))

the buffer-local setting of `transient-mark-mode' (having value `(only)'
when a region is shift-selected) from buffer test.org does not get
transferred to the intermediate source buffer.  However, function
`comment-dwim' relies on that to decide whether to operate on point or
on region:

  comment-dwim is an interactive native-compiled Lisp function in
  ‘newcomment.el’.

  Call the comment command you want (Do What I Mean).
  If the region is active and ‘transient-mark-mode’ is on, call
  ‘comment-region’ (unless it only consists of comments, in which
  case it calls ‘uncomment-region’); [...]

So probably somewhere in `org-babel-do-in-edit-buffer' the value of
`transient-mark-mode', if it is buffer-local and differs from the
default value, should be transferred to the intermediate source buffer.


Emacs  : GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
 of 2023-10-26
Package: Org mode version 9.7-pre (release_9.6.10-902-g41ff56 @ 
/home/jschmidt/work/org-mode/lisp/)

man pages references (Re: [PATCH] ox-ascii.el: Consistently add brackets around links)

[Max Nikulin]

On 25/10/2023 17:34, Ihor Radchenko wrote:

Max Nikulin writes:


Should be [man] ()


Side note: it should be either just "man(1)" or "man(8)" without any URL
for plain text export, but it is another story.


I would not say "should". May? Yes. URL also makes sense in some
scenarios (when the intended reader is not on Linux).


URL makes sense when it is particular version or a page generated 
without intermediate roff format, but this case it is https:, not man: 
link. Compare (sorry, man.he.net is terribly obsolete)

http://storaged.org/doc/udisks2-api/latest/udisks.8.html#id-1.2.4.7
that has more links than the page generated from man page (debiman still 
recognizes much more cross-references than emacs man buffers)

https://manpages.debian.org/bookworm/udisks2/udisks.8.en.html#DEVICE_INFORMATION

"man(1)" references were used in paper documents when internet was not 
always available. In books references may be emphasized by italics or 
fixed width font.


I like formatting similar to "systemd-resolved(8) § /ETC/RESOLV.CONF"
https://wiki.archlinux.org/title/Systemd-resolved
It makes clear that links point to man pages and precise enough since 
specific sections are provided.

Link translation & relative path export_file_name

[Psionic K]

When using an +#export_file_name directive, is it possible to have links
translated to match the directory offset of the target?

I came across this while working on a documentation generation scheme for
https://github.com/positron-solutions/elisp-repo-kit

The links in the org document are correct.  The links in the resulting
markdown are not translated, and break.

The manual has a slightly different problem.  I need to translate it as if
it will be exported to the root directory even though it's always in the
doc directory.  The links don't seem useful, and turning them off may be
more correct.  I haven't gotten a lot of experience with drafting texinfo
yet.

Re: org-ditaa woes

[Leo Butler]

On Tue, Oct 24 2023, Max Nikulin  wrote:

> On 23/10/2023 18:18, Florin Boariu wrote:
>>
>>> sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa
>>> /tmp/foo.txt -o /tmp/foo.png
>
> thanks
>
>> I really _need_ to generically execute a command.
>
> I hope, a couple of workarounds are still possible.
>
> 1. Get java command by adding bash -x (or /usr/bin/bash, or
> "/usr/bin/env bash")
>
> flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
> /tmp/foo.txt -o /tmp/foo.png
>
> - set `org-babel-ditaa-java-cmd' to something like
> "flatpak-spawn --host toolbox run /usr/bin/java",
> - set `org-ditaa-jar-path' to path to ditaa.jar reported by the
>   command above,
> - add other options to either `org-babel-header-args:ditaa' :java
>   property or to `org-babel-ditaa-java-cmd'
> - perhaps add /usr/bin/env JAVA_HOME=... and other required
>   environment variables before java binary.
>
>
> 2.
> - set `org-babel-ditaa-java-cmd' to
>   "flatpak-spawn --host toolbox run /usr/bin/ditaa".
> - set `org-ditaa-jar-option' to empty string.
> - Call of `shell-quote-argument' makes it impossible to set
>   `org-ditaa-jar-path' to empty string, so set the following variables
>   to some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added
>   through :java babel header argument):
>   + `org-ditaa-jar-path'
>   + `org-ditaa-eps-jar-path'
>
>
> I agree that it should be possible to call ditaa executable
> directly. Perhaps it is not possible because for a long time ditaa.jar
> was a part of Org mode repository (there were a lot of messages
> against dropping of jar files from the repository). It seems, nobody
> is ready to take responsibility and to become maintainer of
> ob-ditaa.el while active users have no ability to install ditaa as a
> package, so they anyway have to download .jar from upstream.
>
> I find it tedious to add "flatpak-spawn ..." to every tool used by
> Emacs. Who is the publisher of the flatpak? I would expect a directory
> with symlinks named ditaa, java, git, gcc, cpp, etc to a script line
>
> #!/bin/sh
> exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"
>
> (or "$(basename "$0")")
>
> mounted to flatpak runtime and added to $PATH. Perhaps another
> approach exist and it should be discussed with the packager and Emacs
> developers.

Florin,

Max is right, there are work-arounds possible, although a bit different
from what he suggests. The attached org file shows how to do what you
want using the existing ob-ditaa.el code. I have also attached the
exported html document with the image created.

Tell us if it works for the version of Org that you are using.

Leo

#+author: Leo Butler
#+title: Executing ditaa from a script

* Executing =ditaa= from a script

Org assumes that =ditaa= is run as a java jar file.  Users may need to
use a script to run =ditaa=.  This example shows how.

First, set ~org-babel-ditaa-java-cmd~ and ~org-ditaa-jar-option~ to
empty strings and ~org-ditaa-jar-path~ to the script's path; here, it
is =/usr/bin/ditaa=.  This example uses ~setq-local~ to change only
the values in this buffer.

#+name: hello-world-from-script.el.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script.el
,#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	org-ditaa-jar-option ""
	org-ditaa-jar-path "/usr/bin/ditaa")
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.el.org
#+name: hello-world-from-script.el
#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	org-ditaa-jar-option ""
	org-ditaa-jar-path "/usr/bin/ditaa")
#+end_src

Second, in the =ditaa= code-block, set the header argument =:java= to
the empty string =""=.  The =:cmdline= header argument can be used to
pass command-line options to =ditaa= via the script.

#+name: hello-world-from-script.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script
,#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
++
||
| Hello World|
| from a script! |
||
++
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.org
#+name: hello-world-from-script
#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
++
||
| Hello World|
| from a script! |
||
++
#+end_src

#+RESULTS: hello-world-from-script
[[file:images/hello-world-from-script.png]]
Title: Executing ditaa from a script






Executing ditaa from a script

Table of Contents


1. Executing ditaa from a script




1. Executing ditaa from a script


Org assumes that ditaa is run as a java jar file.  Users may need to
use a script to run ditaa.  This example shows how.



First, set org-babel-ditaa-java-cmd and org-ditaa-jar-option to
empty strings and org-ditaa-jar-path to the script's 

Re: [BUG] Undo eats buffer [9.7-pre (release_9.6.10-888-g098f08 @ /home/kdm/local/src/org-mode/lisp/)]

[Ken Mankoff]

Hi Ihor,

On 2023-10-26 at 05:10 -07, Ihor Radchenko 
wrote...
> Have you tried reporting your problem to emacs-jupyter devs? There
> might be a better chance that they can fix or suggest something.

There is an open issue on that GitHub repository but someone thought it might 
be org-cache related, which is why I posted here. Thank you for your 
suggestions, I will report back there and see if it helps us make progress.

  -k.

Re: bash source code block: problem after ssh commands

[Russell Adams]

On Wed, Oct 25, 2023 at 01:17:42PM +0200, alain.coch...@unistra.fr wrote:
>#+begin_src bash :results output
>ssh coch...@fruc.u-strasbg.fr "echo foo>foo_file"
>echo "bar"
>#+end_src

I know that Ihor has already reproduced, but are you using an SSH key
to connect, or entering a password?

If entering a password, I'd expect there is some mixup. That I defer
to Ihor.

If you use an SSH key for passwordless access, try adding -n (ie: "ssh
-n derp@host mycommand"). The "-n" flag helps prevent the remote
command from interfering with your local terminal by redirecting
/dev/null as the remote stdin. I have to use this commonly in systems
administration, scripts, and tools like Ansible.

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

> Ihor Radchenko writes on Thu 26 Oct 2023 08:44:
>
>  > I currently do not have a setup to test ssh commands,
>
> Sorry if that's irrelevant: I realized that one can ssh to the *same*
> machine.

You are indeed right.
I can now reproduce the problem locally.

It boils down to

(setq exit-status
  (process-file shell-file-name input-file
(if error-file
(list t error-file)
  t)
nil shell-command-switch command))

that is an equivalent of

bash -c bash /path/to/file-containing-the-source-code.sh

- file-containing-the-source-code.sh 
 ssh localhost 'echo foo>/tmp/foo_file'
  echo $(uname -a) |tee /tmp/uname1.txt
-

If one tries to evaluate the above, the second line is not produced. It
has nothing to do with Emacs itself.

However, if I try

(process-file "bash" "/tmp/test.sh"), the /tmp/uname1.txt is not
produced.

This time, it is Emacs problem.
The problem is caused by interactive password prompt displayed by ssh.

I guess we may try to report this upstream, though I am not sure if this
is something that is supported to start with.

>From Org perspective, it is not the first time when interactive shell
programs are causing problems. I'd say that we have no technical ability
to support them reliably and one has to use ob-screen or similar
libraries to properly interact with such code blocks.

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

Re: bash source code block: problem after ssh commands

[Alain . Cochard]

Ihor Radchenko writes on Thu 26 Oct 2023 08:44:

 > I currently do not have a setup to test ssh commands,

Sorry if that's irrelevant: I realized that one can ssh to the *same*
machine.

Re: [BUG] Undo eats buffer [9.7-pre (release_9.6.10-888-g098f08 @ /home/kdm/local/src/org-mode/lisp/)]

[Ihor Radchenko]

Ken Mankoff  writes:

> I'm running into a bug where if I (undo) after evaluating an Org Babel 
> emacs-jupyter code block, several hundred lines of the Org buffer below are 
> erased. Unfortunately I am having trouble creating an MWE that demonstrates 
> this, but I hope the org-element-cache warning below may still be helpful.
> ...
> 
> Warning (org-element-cache): org-element--cache: Unregistered buffer 
> modifications detected (57640 != 55418). Resetting.

This is most likely a problem with emacs-jupyter. It does something that
bypasses `after-change-functions', which is not allowed in Org mode.

> I've tried (setq org-element-use-cache nil) but that does not seem to help. 
> Any suggestions how to work around this, or help the emacs-jupyter effort 
> address this if it is their domain, will be much appreciated.

If disabling cache causes a problem, it is yet another problem (not the
warning you see from org-element). From my vague memory, emacs-jupyter
has non-standard treatment of code block results, so I again suspect
that the problem is with emacs-jupyter.

Have you tried reporting your problem to emacs-jupyter devs? There might
be a better chance that they can fix or suggest something.

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

[BUG] Undo eats buffer [9.7-pre (release_9.6.10-888-g098f08 @ /home/kdm/local/src/org-mode/lisp/)]

[Ken Mankoff]

I'm running into a bug where if I (undo) after evaluating an Org Babel 
emacs-jupyter code block, several hundred lines of the Org buffer below are 
erased. Unfortunately I am having trouble creating an MWE that demonstrates 
this, but I hope the org-element-cache warning below may still be helpful.

The bug occurs when the emacs-jupyter (Python) block produces are error, and 
results look like the following, and then I eval (undo):

#+RESULTS:
:RESULTS:
: some text here
# [goto error]
#+begin_example
  lots of text here
#+end_example
:END:

I've tried (setq org-element-use-cache nil) but that does not seem to help. Any 
suggestions how to work around this, or help the emacs-jupyter effort address 
this if it is their domain, will be much appreciated.

Thanks,

   -k.



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

Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected (57640 != 55418). Resetting.
If this warning appears regularly, please report the warning text to Org mode 
mailing list (M-x org-submit-bug-report).
The buffer is: misc.org
 Current command: nil
 Backtrace:
"  backtrace-to-string(nil)
  org-element--cache-sync(# 37660)
  org-element-at-point()
  (progn (org-element-at-point))
  (unwind-protect (progn (org-element-at-point)) (set-match-data 
save-match-data-internal 'evaporate))
  (let ((save-match-data-internal (match-data))) (unwind-protect (progn 
(org-element-at-point)) (set-match-data save-match-data-internal 'evaporate)))
  (let ((element (let ((save-match-data-internal (match-data))) (unwind-protect 
(progn (org-element-at-point)) (set-match-data save-match-data-internal 
'evaporate) (and (eq (org-element-type element) 'src-block) (>= 
(line-beginning-position) (let* ((parray (and t (let* ... ... (if parray 
(let* ((val ...)) (if (eq val ...) 'nil (let ... val))) (let* ((val ...)) (cond 
(... ...) (... ...) (t ...)) (<= (line-end-position) (save-excursion 
(save-restriction (widen) (goto-char (let* (...) (if parray ... ...))) 
(skip-chars-backward \" \\11\\n\") (line-end-position 
(org-element--property :language element nil nil)))
  org-eldoc-get-src-lang()
  (let ((lang (org-eldoc-get-src-lang))) (cond ((string= lang \"org\") nil) 
((or (string= lang \"emacs-lisp\") (string= lang \"elisp\")) (cond ((and 
(boundp 'eldoc-documentation-functions) (fboundp 'elisp-eldoc-var-docstring) 
(fboundp 'elisp-eldoc-funcall)) (let ((eldoc-documentation-functions ...)) 
(eldoc-print-current-symbol-info))) ((fboundp 
'elisp-eldoc-documentation-function) (elisp-eldoc-documentation-function)) (t 
(let (eldoc-documentation-function) (eldoc-print-current-symbol-info) ((or 
(string= lang \"c\") (string= lang \"C\")) (if (require 'c-eldoc nil t) (progn 
(c-eldoc-print-current-symbol-info ((string= lang \"css\") (if (require 
'css-eldoc nil t) (progn (css-eldoc-function ((string= lang \"php\") (if 
(require 'php-eldoc nil t) (progn (php-eldoc-function ((or (string= lang 
\"go\") (string= lang \"golang\")) (if (require 'go-eldoc nil t) (progn 
(go-eldoc--documentation-function (t (let ((doc-fun 
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car args))) 
(if (functionp doc-fun) (progn (if (functionp callback) (funcall doc-fun 
callback) (funcall doc-fun
  (or (org-eldoc-get-breadcrumb) (org-eldoc-get-src-header) (let ((lang 
(org-eldoc-get-src-lang))) (cond ((string= lang \"org\") nil) ((or (string= 
lang \"emacs-lisp\") (string= lang \"elisp\")) (cond ((and (boundp ...) 
(fboundp ...) (fboundp ...)) (let (...) (eldoc-print-current-symbol-info))) 
((fboundp 'elisp-eldoc-documentation-function) 
(elisp-eldoc-documentation-function)) (t (let (eldoc-documentation-function) 
(eldoc-print-current-symbol-info) ((or (string= lang \"c\") (string= lang 
\"C\")) (if (require 'c-eldoc nil t) (progn 
(c-eldoc-print-current-symbol-info ((string= lang \"css\") (if (require 
'css-eldoc nil t) (progn (css-eldoc-function ((string= lang \"php\") (if 
(require 'php-eldoc nil t) (progn (php-eldoc-function ((or (string= lang 
\"go\") (string= lang \"golang\")) (if (require 'go-eldoc nil t) (progn 
(go-eldoc--documentation-function (t (let ((doc-fun 
(org-eldoc-get-mode-local-documentation-function lang)) (callback (car args))) 
(if (functionp doc-fun) (progn (if ... ... ...
  org-eldoc-documentation-function(#f(compiled-function (string  plist) 
#))
  run-hook-with-args-until-success(org-eldoc-documentation-function 
#f(compiled-function (string  plist) #))
  eldoc-documentation-default()
  eldoc--invoke-strategy(nil)
  eldoc-print-current-symbol-info()
  #f(compiled-function () #)()
  apply(#f(compiled-function () #) nil)
  timer-event-handler([t 0 0 50 nil #f(compiled-function () #) nil idle 0 nil])
" Disable showing Disable logging



Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 

Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]

[Po Lu]

I have now installed an interface to this end into Emacs 30.  The
pertinent documentation is under the ``Drag and Drop'' node in the Lisp
reference manual.

Re: Feature request: IDs for everything

[Ihor Radchenko]

Max Nikulin  writes:

>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage.
>
> A defcusom user options whether id:UUID links for non-heading elements 
> are allowed. It is just an opinion/idea and nothing more.

> Are ids for whole files (placed before first headings) are problematic 
> for 3rd party packages?

Fair point. Even existing id links may not always point to a heading
(when pointing to IDs in top-level property drawer). So, the potential
breakage I was talking about is already there, and third-party packages
already have to adapt.

I still do not feel confident that it will be safe to blindly change
org-id in the proposed way though. Although I cannot think of clear
examples why it would cause problems worse compared to the existing id:
links to files. So, it may just be my unmotivated concern.

>>   [[id:unique-file-id:object-id-inside-the-file]]
>
> Perhaps than it should be id:FILE-UUID::SEARCH with usual search options 
> like #CUSTOM_ID, *Heading, etc., with the new variant id:OBJECT-UUID. 
> However I am unsure if search should be limited to a subtree if 
> HEADING-UUID is specified instead of FILE-UUID.

I indeed meant "::" search option. Sorry for the typo.

In any case, I agree with Tor that search option is less elegant. If we
can go for direct UUIDs, let's do it.

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

Re: Best practice for writing and debugging shell source blocks?

[Max Nikulin]

On 24/10/2023 21:54, Tim Landscheidt wrote:

The same thing happens if I add ":session my-test" to all source blocks,


Have you tried to combine variables and session?

#+name: get-random-value
#+begin_src bash
  echo "$RANDOM"
#+end_src

#+header: :var random_var=get-random-value
#+begin_src sh :session *sh-with-random*
  echo "$random_var + 10"
#+end_src

#+RESULTS:
: 19545 + 10

#+begin_src sh :session *sh-with-random*
  echo "$random_var + 20"
#+end_src

#+RESULTS:
: 19545 + 20

#+begin_src sh :session *sh-with-random*
  echo "$random_var + 30"
#+end_src

#+RESULTS:
: 19545 + 30

Or with noweb reference


#+begin_src sh :noweb-ref use-random
  echo "$random_var + 10"
#+end_src

#+begin_src sh :noweb-ref use-random
  echo "$random_var + 20"
#+end_src

#+begin_src sh :noweb-ref use-random
  echo "$random_var + 30"
#+end_src

#+begin_src sh :var random_var=get-random-value :noweb yes
  <>
#+end_src


P.S. For the case that you have not seen it, the following page contains 
some examples:

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-shell.html

Re: org-ditaa woes

[Ihor Radchenko]

Leo Butler  writes:

>> Writing a patch is also welcome.
>
> I am looking at ob-ditaa. Patching it looks within my reach.
>
> Is there no testsuite for it?

No test suite. But you may refer to testing/lisp/test-ob-jave.el to see
how to write simple ob-* tests.

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

Re: Feature request: IDs for everything

[Max Nikulin]

On 21/10/2023 20:05, Ihor Radchenko wrote:

Tor Erlend Fjelde writes:


I was wondering if there's a reason why we couldn't have IDs a la
org-id.el for everything? It seem to me that it would be useful to use
something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
well as headlines.


I think, another complication is referring source code blocks as 
variable values in header arguments and as noweb fragments. It would be 
great to be possible to specify "id:UUID" instead of fuzzy names. 
Perhaps it may be solved by explicit calls to new functions. If 
possible, I would avoid proliferation of keyword in favor of "#+name: 
id:UUID"


And there are references to particular lines inside code blocks...


Apart from #+NAME, we also have radio <<>> that can be used a
link anchors (#+NAME or other affiliated keywords are not allowed, for
example, in items).


I think, you mean <>, not <<>> targets that activates 
plain text words. It seems, the latter cannot be currently exported as 
explicit links [[radio][Radio]]. I am unsure what conflicts may appear 
during attempt to allow optional explicit types, e.g. <>.



We also discussed linking to #+name and <<>> globally, without
specifying the file path.


From my point of view, it should be either global id:UUID links or 
file:doc.org::name local links.



If we simply allow id: links to point to non-headings, it will be a
major breaking change that may affect third-party packages. So, we
need to design the extended ids carefully to avoid breakage.


A defcusom user options whether id:UUID links for non-heading elements 
are allowed. It is just an opinion/idea and nothing more.


Are ids for whole files (placed before first headings) are problematic 
for 3rd party packages?



  [[id:unique-file-id:object-id-inside-the-file]]


Perhaps than it should be id:FILE-UUID::SEARCH with usual search options 
like #CUSTOM_ID, *Heading, etc., with the new variant id:OBJECT-UUID. 
However I am unsure if search should be limited to a subtree if 
HEADING-UUID is specified instead of FILE-UUID.

Re: Are 'placement' and 'float' "obsolete terms" in inline images export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> What about :wrap?
>
> I like :wrap. What's more, remembering that old thread where
> some questions about code before/after the image were discussed,
> what if the expected value of :wrap were a kind of template? This would
> allow code to be placed before and/or after (not just an environment)
> the image, always within the float environment, if it exists. Something
> like this:
>
> #+ATTR_LaTeX: :float nil :wrap 
> \begin{minipage}[b]{10pc}\small\n%s\n\end{minipage} 
> #+CAPTION: caption
> [[file:foo.png]]
> ...
> #+ATTR_LaTeX: :float minipage :placement [b]{10pc} :caption 
> \captionof{figure}{caption} 
> [[file:foo.png]]
>
> I don't know if it would be appropriate to explain in the Manual that
> doing so would not be... "correct"? I don't know if there is any term in
> programming to designate these situations which, without being bugs, are
> functionalities not consciously sought...

What about making :wrap override :float completely + obsoleting :float.
We can allow wrap to have special values like in float:

:wrap t/:wrap multicolumn/:wrap sideways

With these special values, :placement will be taken into account.

Further, we can make templates a bit more detailed.
Starting from similar to what you proposed in the above

:wrap \begin{minipage}[b]{10pc}\small\n%{body}\n\end{minipage}

to more granular control over caption, centering, comment-include,
and image-code:

%{caption} %{caption-text} %{centering} %{comment} %{comment-text}
 %{image} %{image-path}.

If the :wrap text does not contain %{...} placeholder, it will be
treated as what  :float artbirary-environment does.

We may even consider something like

#+name: latex-template
#+begin_src latex :export none
\begin{minipage}[b]{10pc}\small
%{body}
\end{minipage}
#+end_src

#+attr_latex: :wrap latex-template[]

As a bonus, :wrap may allow prepending/appending arbitrary code to
headings:

* Heading starting at a new page
:PROPERTIES:
:ATTR_LATEX: :wrap \clarpage%{default}
:END:

>>> ... However, :float can still be useful for
>>> certain combinations. For example, a minipage environment cannot include
>>> a caption (it produces an error of the type "LaTeX Error: \caption
>>> outside float").
>>
>> Do we know in advance which environments support \caption and which not?
>> I feel that we may handle this programmatically without creating an array
>> of almost-identical attributes.
>
> I like the idea, but unfortunately, apart from the known float
> environments, there are those that a user can define using the \newfloat
> command from the float package.

We might also consider :caption-template \captionof{figure}{%{caption-text}}

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

Re: Feature request: IDs for everything

[Ihor Radchenko]

Tor Erlend Fjelde  writes:

>> If we simply allow id: links to point to non-headings, it will be a
>> major breaking change that may affect third-party packages. So, we
>> need to design the extended ids carefully to avoid breakage. For
>> example, `org-id-find' and other API function may need to work in two
>> modes: (1) legacy, only searching for headings; (2) new, searching for
>> anything. This can, for example, be done via an extra optional argument.
>
> This is a very good point, and definitively makes things non-trivial.
> Nonetheless, I'd be happy to have a go at it if this seems like the way
> to go! But I'll probably need quite a bit of help in the process as I
> haven't contributed to Org before.

This is a moderately difficult contribution. As a first step, you will
need to study org-id.el and see what should be changed there to support
the new feature.

If you encounter any difficulties, feel free to ask here.

Also, before you invest too much time into this, please check if you can
do FSF copyright assignment (see
https://orgmode.org/worg/org-contribute.html#copyright). As a GNU
project, we cannot accept large contributions without this paperwork.

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

Re: org-ditaa woes

[Max Nikulin]

On 26/10/2023 02:00, Leo Butler wrote:

I am looking at ob-ditaa. Patching it looks within my reach.

Is there no testsuite for it?


Unfortunately there is only a couple of examples at

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ditaa.html

Re: bash source code block: problem after ssh commands

[Ihor Radchenko]

Leo Butler  writes:

> It looks like an issue in comint-mode and the way that it is handling
> the temporary ssh session. This is not an issue with org-mode.
> ...
> Not working:
>
> #+begin_src bash :results output
>   ssh SSH-HOST 'echo foo>/tmp/foo_file'
>   echo $(uname -a) |tee /tmp/uname1.txt
> #+end_src

By default (no session), the above command should not use comint-mode.
So, something else might be going on here.

I currently do not have a setup to test ssh commands, so I would
appreciate someone trying to dig why `org-babel-eval' apparently not
returning the expected result.

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

Re: Feature request: IDs for everything

[Tor Erlend Fjelde]

> Although we have at least one caveat that we need to consider - the
> current users of the id: links blindly assume that they always link to
> headings. This includes many third-party packages, like org-roam.
>
> If we simply allow id: links to point to non-headings, it will be a
> major breaking change that may affect third-party packages. So, we
> need to design the extended ids carefully to avoid breakage. For
> example, `org-id-find' and other API function may need to work in two
> modes: (1) legacy, only searching for headings; (2) new, searching for
> anything. This can, for example, be done via an extra optional argument.

This is a very good point, and definitively makes things non-trivial.
Nonetheless, I'd be happy to have a go at it if this seems like the way
to go! But I'll probably need quite a bit of help in the process as I
haven't contributed to Org before.

> As an alternative option, we had a proposal that extends id: links to
> have a search option:
>
>  [[id::search-string]]
>
> Then, we may have top-level drawer like
>
> :PROPERTIES:
> :ID: unique-file-id
> :END:
>
> And then refer to anything inside the file as
>
>  [[id:unique-file-id:object-id-inside-the-file]]

Indeed; I was actually about to have a go at implementing this because
I thought this would be the quickest way of adding support for referencing
blocks in something like org-roam. But this does seem like a sub-optimal
solution vs. just adding support for more general IDs, and so I thought
it would be better to see if that could be done first (hence I'm here).

All the best,
Tor


On Sat, 21/10/2023, Ihor Radchenko  wrote:

> Tor Erlend Fjelde  writes:
>
>> I was wondering if there's a reason why we couldn't have IDs a la
>> org-id.el for everything? It seem to me that it would be useful to use
>> something like `#+ID` in place of `#+NAME` for tables, blocks, etc. as
>> well as headlines.
>
> This has been discussed in the past.
>
> Apart from #+NAME, we also have radio <<>> that can be used a
> link anchors (#+NAME or other affiliated keywords are not allowed, for
> example, in items).
>
> We also discussed linking to #+name and <<>> globally, without
> specifying the file path.
>
>> Would this go against the intended design of
>> org-id.el, or is this a change that would be welcome but that no one
>> has gotten around to implementing yet?
>
> Mostly nobody has gotten around.
>
> Although we have at least one caveat that we need to consider - the
> current users of the id: links blindly assume that they always link to
> headings. This includes many third-party packages, like org-roam.
>
> If we simply allow id: links to point to non-headings, it will be a
> major breaking change that may affect third-party packages. So, we
> need to design the extended ids carefully to avoid breakage. For
> example, `org-id-find' and other API function may need to work in two
> modes: (1) legacy, only searching for headings; (2) new, searching for
> anything. This can, for example, be done via an extra optional argument.
>
> -
>
> As an alternative option, we had a proposal that extends id: links to
> have a search option:
>
>  [[id::search-string]]
>
> Then, we may have top-level drawer like
>
> :PROPERTIES:
> :ID: unique-file-id
> :END:
>
> And then refer to anything inside the file as
>
>  [[id:unique-file-id:object-id-inside-the-file]]
>
> -- 
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at