Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> The case with hyperdrive.el is not the same.
>>> You may want to discuss it on emacs-devel.
>>
>> Thank you!  It is a good idea to get more input on securing
>> hyperdrive.el.  For now, I went through bug#58744 and took some notes in
>> two relevant hyperdrive.el issues:
>>
>> - https://todo.sr.ht/~ushin/ushin/178
>
> I think I mentioned earlier that a good way to make file links work
> magically is using TRAMP or `file-name-handler-alist'.

Thank you.  Yes, I'd like to explore these options more.

>> - https://todo.sr.ht/~ushin/ushin/178
>
> You probably meant to link to some different ticket here.

https://todo.sr.ht/~ushin/ushin/188

Thanks!

Joseph

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko  writes:

> I was mostly talking about commands like eww - I simply recall a similar
> proposal being made about activating Org mode when the URL points to Org
> file. That proposal has been rejected on the grounds of security. See
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774
>
> The case with hyperdrive.el is not the same.
> You may want to discuss it on emacs-devel.

Thank you!  It is a good idea to get more input on securing
hyperdrive.el.  For now, I went through bug#58744 and took some notes in
two relevant hyperdrive.el issues:

- https://todo.sr.ht/~ushin/ushin/178
- https://todo.sr.ht/~ushin/ushin/178

> As for untrusted-content, there is no point using it now - it was
> specifically introduced for Org mode. It may or may not become a part of
> more general security framework in Emacs.

Sounds good.

Thank you!!

Joseph

Re: Using search options in HTTP-style links

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> ...
>> (eww "https://ushin.org/needs-list.org#%3A%3A%23care;)
>>
>> ...loads the file in eww-mode with point at the top of the file.
>>
>> I think it would be more useful to instead activate org-mode (or a mode
>> which derives from it - "eww-org-mode"?), decode the link fragment, and
>> then jump to the location specified by the search option.
>
> There is a convention for pdfs:
> http://www.example.com/document.pdf#page=5
> But, AFAIK, it is not RFC.
>
> So, there is nothing stopping from creating an ad-hoc convention to
> parse URL locators in links to PDFs or org files or whatnot.

I'll need to dig a little more to see what changes would need to be made
in order for org-store-link to store properly formatted search options
with http: or hyper: links.  Currently, org-create-file-search-functions
is only used when creating a file: link.

> However, the question about activating a major mode on web content is a
> question to Emacs developers. It should be considered carefully, because
> activating major modes may not be safe.

hyperdrive.el activates a major mode with set-auto-mode when content is
loaded over the network.  This behavior is on by default.  Do you have
any advice about this?

Should hyperdrive.el set untrusted-content to t?

Thanks!

Joseph

Using search options in HTTP-style links

[Joseph Turner]

Hello!

[[info:org#Search Options]] says that search options are intended for
file: type links only.  However, since Org documents can also be loaded
over network protocols like HTTP and hyper://, I'd like to deliberate
if/how search options might be encoded inside HTTP-style link fragments.

HTTP-style links are URL-encoded with "#"-prefixed link fragments:

(let ((domain "https://ushin.org;)
  (filename "needs-list.org")
  (search-option "::#care"))
  (format "%s/%s#%s" domain (url-hexify-string filename)
  (url-hexify-string search-option)))

=>  "https://ushin.org/needs-list.org#%3A%3A%23care;

Currently, loading the above URL with EWW...

(eww "https://ushin.org/needs-list.org#%3A%3A%23care;)

...loads the file in eww-mode with point at the top of the file.

I think it would be more useful to instead activate org-mode (or a mode
which derives from it - "eww-org-mode"?), decode the link fragment, and
then jump to the location specified by the search option.

Web browsers like Firefox don't handle Org search options in link
fragments, but then again, they don't handle Org documents at all.  On my
machine, loading https://ushin.org/needs-list.org#%3A%3A%23care in
Firefox downloads the file as if the fragment weren't there.

What other issues might arise when encoding search options this way?

Any other comments/questions welcome :)

Thank you!

Joseph

Re: [PATCH] Silently remove lockfiles from org-agenda-files

[Joseph Turner]

Hi Ihor,

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> My Emacs setup broke today due to the presence of a lockfile inside
>> "~/.local/share/org/todo".  I use EXWM, and I show org-agenda on startup:
>>
>> (add-hook 'after-init-hook
>> (lambda () (org-agenda nil "t")))
>> (setq initial-buffer-choice (lambda () (get-buffer "*Org Agenda*")))
>>
>> org-agenda-files contained a non-existent file, so org-check-agenda-file
>> attempted to prompt me.  For some reason (maybe EXWM didn't fully load),
>> Emacs simply hung without prompting, leaving me with a black screen.
>
> You may consider reporting the hang to Emacs or EXWM bug tracker.

>> My configuration contains the equivalent of
>>
>> (setopt org-agenda-files
>>(directory-files-recursively "~/.local/share/org/todo" ".org$"))
>
> I'd recommend using a different approach - use org-agenda-file-regexp
> instead of ".org$"; or use #'file-directory-p as predicate - Org mode
> then select Org files inside all the listed directories by itself.

Good to know about org-agenda-file-regexp.

>> The attached patch silently removes lockfiles from org-agenda-files.
>
>> -  "Make sure FILE exists.  If not, ask user what to do."
>> +  "Make sure FILE exists.  If not, ask user what to do.
>> +Automatically exclude lockfiles."
>>(unless (file-exists-p file)
>> +(when (string-match-p (rx bos ".#") file) ; Exclude lockfiles
>> +  (org-remove-file file)
>> +  (throw 'nextfile t))
>
> I feel slightly reluctant about this patch:
>
> 1. You are only working around the actual problem with agenda file being
>deleted from disk while Emacs is loading. So, the patch is not
>solving a real Org mode problem - Org mode prompting about
>non-existing file is not wrong; your bug has nothing to do with Org
>mode itself.
>
> 2. In theory, there might be users with actual Org files starting from
>".#" for whatever reason. The probability is not high, but if users
>choose to set org-agenda-files directly, file-by-file, that's a
>choice we should better respect in order to not create a blocker.

Yes, I think you're right.  Thanks for your caution :)

Joseph

[PATCH] Silently remove lockfiles from org-agenda-files

[Joseph Turner]

My configuration contains the equivalent of

(setopt org-agenda-files
   (directory-files-recursively "~/.local/share/org/todo" ".org$"))

My Emacs setup broke today due to the presence of a lockfile inside
"~/.local/share/org/todo".  I use EXWM, and I show org-agenda on startup:

(add-hook 'after-init-hook
(lambda () (org-agenda nil "t")))
(setq initial-buffer-choice (lambda () (get-buffer "*Org Agenda*")))

org-agenda-files contained a non-existent file, so org-check-agenda-file
attempted to prompt me.  For some reason (maybe EXWM didn't fully load),
Emacs simply hung without prompting, leaving me with a black screen.

The attached patch silently removes lockfiles from org-agenda-files.

Thanks!

Joseph

P.S.

I'm not sure how the lockfile ended up there.  Maybe I killed Emacs with
SIGKILL while one of my agenda files was open and modified in a buffer,
and so the lockfile was not deleted?

>From e69e69a03c215704d83f8388370f0db2bc93891d Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Thu, 18 Jan 2024 22:24:10 -0800
Subject: [PATCH] * lisp/org.el (org-check-agenda-file): Silently exclude
 lockfiles

---
 lisp/org.el | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index 8929a7217..f48a8ff46 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -15563,8 +15563,12 @@ (defun org-file-menu-entry (file)
   (vector file (list 'find-file file) t))
 
 (defun org-check-agenda-file (file)
-  "Make sure FILE exists.  If not, ask user what to do."
+  "Make sure FILE exists.  If not, ask user what to do.
+Automatically exclude lockfiles."
   (unless (file-exists-p file)
+(when (string-match-p (rx bos ".#") file) ; Exclude lockfiles
+  (org-remove-file file)
+  (throw 'nextfile t))
 (message "Non-existent agenda file %s.  [R]emove from list or [A]bort?"
 	 (abbreviate-file-name file))
 (let ((r (downcase (read-char-exclusive
-- 
2.41.0

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>>> I'd like for users to be able to take an existing directory of Org mode
>>>> documents and copy them all into a hyperdrive.  I think the least
>>>> surprising behavior is for the links between those files to continue
>>>> working.  Perhaps the best option is for hyperdrive.el to make all "file"
>>>> type links, explicit or not, point to other files inside the hyperdrive?
>>>>
>>>> In that case, there would be no way for Org mode files in a hyperdrive
>>>> to point to the local filesystem.  Similarly, when Org documents are
>>>> exported to HTML, there's no way to export .
>>>
>>> May you please elaborate? How is hyperdrive directory different from
>>> local directory?
>>
>> On disk, hyperdrive data is stored by hash prefixes like so:
>>
>> /home/joseph/.local/share/hyper-gateway-nodejs/cores/
>> └── 00
>> ...
>> This is similar to the way .git/objects/ directories are structured.
>> ...
>> Does that answer your question?
>
> Not really.
> May you please provide an example with an Org file containing file links
> and how you envision to transform them? Will they be transformed
> depending on the directory the Org file is located in?

I don't want to transform the file links.  The idea is that an Org file
"foo.org" could be copied into a hyperdrive, and [[./bar.org]] would
point to a file called "bar.org" in the same folder in the hyperdrive.

That way, you could copy both "foo.org" and "bar.org" from your local
directory into a hyperdrive, the links between them would work as-is.

Pseudo-code for a hyperdrive.el :follow function for file: links:

(defun hyperdrive--org-file-link-follow (url  _prefix _link)
  (when hyperdrive-mode
(hyperdrive-open
  (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" into 
"hyper://PUBLIC-KEY/foo"
t))

(org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow)

>>>> (org-element-property :search-option link)
>>>
>>> :follow functions are passed both path and search option.
>>
>> How is the search option passed in?
>>
>> IIUC in org-link-open, the path argument passed in has no search option:
>>
>> (funcall (org-link-get-parameter type :follow) path arg)
>
> You are right.
> What we can do then is pass an extra argument to :follow function - the
> link object. That way, :follow function can get all the information it
> needs.

I like this idea!  Would this change break existing :follow functions
which only expect max two args?

>> By the way, I think this minor improvement could be made at the bottom
>> of org-link-open:
>>
>> From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner 
>> Date: Mon, 15 Jan 2024 00:24:30 -0800
>> Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow function
>
> Thanks!
> Applied, onto main; I added TINYCHANGE cookie to the commit message.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0254854ee

Thanks!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> See `org-open-file' IN-EMACS argument - we may use different handlers
>>> to open file links. Currently, IN-EMACS can be 'system or 'emacs. But
>>> nothing stops us from adding more options.
>>
>> Thanks!  Are you suggesting something like [[file+hyper:/README.org]] ?
>
> Yes.

Thanks - that could be useful.

>>> This will cause major issues when trying to export such links.
>>> Except for HTML export that utilizes `org-html-link-use-abs-url', but
>>> only for relative links.
>>
>> Yes, there are many users who rely on [[file:/index.html]] exporting to
>>  instead of .
>
> This is not what Org HTML export does. Only relative links are affected
> by `org-html-link-use-abs-url':
>
> Documentation
> Should we prepend relative links with HTML_LINK_HOME?
>
> Absolute links always remain absolute.

You're right.  I just meant that ox-html should keep the existing
behavior when exporting implicit file: links.  Many websites would break
if implicit file: links started exporting as .

>>> Why not make [[hyper:/README.org]] use the "default" hyperdrive the
>>> Org file belongs to.
>>
>> I'd like for users to be able to take an existing directory of Org mode
>> documents and copy them all into a hyperdrive.  I think the least
>> surprising behavior is for the links between those files to continue
>> working.  Perhaps the best option is for hyperdrive.el to make all "file"
>> type links, explicit or not, point to other files inside the hyperdrive?
>>
>> In that case, there would be no way for Org mode files in a hyperdrive
>> to point to the local filesystem.  Similarly, when Org documents are
>> exported to HTML, there's no way to export .
>
> May you please elaborate? How is hyperdrive directory different from
> local directory?

On disk, hyperdrive data is stored by hash prefixes like so:

/home/joseph/.local/share/hyper-gateway-nodejs/cores/
└── 00
├── 6a
│   └── 006ae0628e1fad7c357fd4a1c6103d37bcb70797c6f0dba77c261871306b16b3
│   ├── bitfield
│   ├── data
│   ├── oplog
│   └── tree
└── de
└── 00de65a26162bbaad8f97bb89e81856ac1dd6a1bc10a46f06086b4a25b244ad5
├── data
├── oplog
└── tree

This is similar to the way .git/objects/ directories are structured.

Of course, inspecting the storage directories of this kind with Dired
does not provide a meaningful UI.  Special software is required for
users to explore and open the hyperdrive "directories" and "files".

To push the git analogy further, the way hyperdrive-find-file is like
magit-find-file.  Both use an external program, git or hyper-gateway, to
pick out the correct data and present it to Emacs as if it were a file.

Does that answer your question?

>>> For example, see WIP patch where we expose setting id: link properties:
>>> https://list.orgmode.org/orgmode/c98a38b0-6dea-4b5c-b00f-a39ea9225...@app.fastmail.com/
>>
>> How would the :follow function for "file:" links get access to the link
>> search option?  IIUC, `org-link-open' handles "file:" links specially because
>> they require
>>
>> (org-element-property :search-option link)
>
> :follow functions are passed both path and search option.

How is the search option passed in?

IIUC in org-link-open, the path argument passed in has no search option:

(funcall (org-link-get-parameter type :follow) path arg)

By the way, I think this minor improvement could be made at the bottom
of org-link-open:

>From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Mon, 15 Jan 2024 00:24:30 -0800
Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow function

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

diff --git a/lisp/ol.el b/lisp/ol.el
index 779175403..9bc2f5fb0 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1125,9 +1125,9 @@ (defun org-link-open (link  arg)
 	   ;; argument, as it was mandatory before Org 9.4.  This is
 	   ;; deprecated, but support it for now.
 	   (condition-case nil
-	   (funcall (org-link-get-parameter type :follow) path arg)
+	   (funcall f path arg)
 	 (wrong-number-of-arguments
-	  (funcall (org-link-get-parameter type :follow) path)
+	  (funcall f path)
 
 (defun org-link-open-from-string (s  arg)
   "Open a link in the string S, as if it was in Org mode.
-- 
2.41.0


Thank you!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> It would be more reliable to provide a separate link type.
>>> We might even extend the special file+application: link type syntax that
>>> already allows special behavior for opening file links.
>>
>> Thank you!  Would you explain about extending file+application syntax?
>
> See `org-open-file' IN-EMACS argument - we may use different handlers
> to open file links. Currently, IN-EMACS can be 'system or 'emacs. But
> nothing stops us from adding more options.

Thanks!  Are you suggesting something like [[file+hyper:/README.org]] ?

>> hyperdrive.el does add a separate "hyper://" link type which is used to
>> link to a hyperdrive file or directory by its "full" URL:
>>
>> hyper://aaj45d88g4eenu76rpmwzjiabsof1w8u6fufq6oogyhjk1ubygxy/hyperdrive/hyperdrive-manual.org
>>
>> Additionally, we want to make it possible for users to copy ("mirror") a
>> directory of Org mode documents into a hyperdrive for other users to
>> view and link to.  Ideally, when users upload a set of files to a
>> hyperdrive, the relative and absolute links between those files within
>> the same hyperdrive work without modification.
>>
>> We also wanted users to be able to link to files on the local filesystem
>> from within a hyperdrive.  Firefox and Chrome treat prefix-less links as
>> pointers to files on the same webserver and "file:" links as pointers to
>> files on the filesystem.  We thought that we could do the same thing in
>> hyperdrive.el: [[/README.org]] could point to a file in the same
>> hyperdrive while [[file:/README.org]] could point to a local file.
>
> This will cause major issues when trying to export such links.
> Except for HTML export that utilizes `org-html-link-use-abs-url', but
> only for relative links.

Yes, there are many users who rely on [[file:/index.html]] exporting to
 instead of .

> Why not make [[hyper:/README.org]] use the "default" hyperdrive the
> Org file belongs to.

I'd like for users to be able to take an existing directory of Org mode
documents and copy them all into a hyperdrive.  I think the least
surprising behavior is for the links between those files to continue
working.  Perhaps the best option is for hyperdrive.el to make all "file"
type links, explicit or not, point to other files inside the hyperdrive?

In that case, there would be no way for Org mode files in a hyperdrive
to point to the local filesystem.  Similarly, when Org documents are
exported to HTML, there's no way to export .

>> Would you be open to changing Org mode so that prefix-less links could
>> be handled in a special way by certain modes?  Here's an idea:
>>
>> - Add a buffer-local variable `org-current-uri-scheme' which could be
>> set to a string like "hyper".
>>
>> - When handling "file" type links, check if `org-current-uri-scheme'
>> matches one of the keys in `org-link-parameters', and use the
>> appropriate handler instead of the "file" handler.  (see attached patch
>> for an example usage in `org-link-open')
>>
>> What do you think?
>
> IMHO, it is too specific for Org core.
> What we might do is allow setting :follow function for file: links. We
> generally aim to remove hard-coded link types from `org-link-open',
> exposing them to `org-link-set-parameters'.
>
> For example, see WIP patch where we expose setting id: link properties:
> https://list.orgmode.org/orgmode/c98a38b0-6dea-4b5c-b00f-a39ea9225...@app.fastmail.com/

How would the :follow function for "file:" links get access to the link
search option?  IIUC, `org-link-open' handles "file:" links specially because
they require

(org-element-property :search-option link)

Thank you!!!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Joseph Turner  writes:
> - When handling "file" type links, check if `org-current-uri-scheme'
> matches one of the keys in `org-link-parameters', and use the
> appropriate handler instead of the "file" handler.  (see attached patch
> for an example usage in `org-link-open')

Please ignore the last patch - this one checks for a "file:" prefix.

Joseph

diff --git a/lisp/ol.el b/lisp/ol.el
index 20aab6bb8..947576ddb 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1097,12 +1097,16 @@ (defun org-link-open (link  arg)
   ;; first need to integrate search option, if any.
   ("file"
(let* ((option (org-element-property :search-option link))
-	  (path (if option (concat path "::" option) path)))
-	 (org-link-open-as-file path
-(pcase (org-element-property :application link)
-  ((guard arg) arg)
-  ("emacs" 'emacs)
-  ("sys" 'system)
+	  (path (if option (concat path "::" option) path))
+  (f (org-link-get-parameter org-current-uri-scheme :follow)))
+	 (if (and (not (org-element-property :type-explicit-p link))
+  (functionp f))
+ (funcall f path)
+   (org-link-open-as-file path
+  (pcase (org-element-property :application link)
+((guard arg) arg)
+("emacs" 'emacs)
+("sys" 'system))
   ;; Internal links.
   ((or "coderef" "custom-id" "fuzzy" "radio")
(unless (run-hook-with-args-until-success 'org-open-link-functions path)

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:

[...]

> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d15e52fef

Thank you for the quick fix!

>> In hyperdrive.el currently, "[[/foobar]]" and "[[file:/foobar]]" have
>> different meanings: a link with no protocol prefix, like "[[/foobar]]",
>> points to a file inside of the same hyperdrive (virtual p2p folder),
>> whereas a link with the "file" protocol prefix, like "[[file:/foobar]]",
>> points to a file on the local filesystem:
>
> I do not recommend such approach. From the point of view of most of the
> Org mode code, it makes no difference whether file link has file: or
> not. So, you may face unexpected issues.

You are certainly right about unexpected issues ;)

> It would be more reliable to provide a separate link type.
> We might even extend the special file+application: link type syntax that
> already allows special behavior for opening file links.

Thank you!  Would you explain about extending file+application syntax?

hyperdrive.el does add a separate "hyper://" link type which is used to
link to a hyperdrive file or directory by its "full" URL:

hyper://aaj45d88g4eenu76rpmwzjiabsof1w8u6fufq6oogyhjk1ubygxy/hyperdrive/hyperdrive-manual.org

Additionally, we want to make it possible for users to copy ("mirror") a
directory of Org mode documents into a hyperdrive for other users to
view and link to.  Ideally, when users upload a set of files to a
hyperdrive, the relative and absolute links between those files within
the same hyperdrive work without modification.

We also wanted users to be able to link to files on the local filesystem
from within a hyperdrive.  Firefox and Chrome treat prefix-less links as
pointers to files on the same webserver and "file:" links as pointers to
files on the filesystem.  We thought that we could do the same thing in
hyperdrive.el: [[/README.org]] could point to a file in the same
hyperdrive while [[file:/README.org]] could point to a local file.

Would you be open to changing Org mode so that prefix-less links could
be handled in a special way by certain modes?  Here's an idea:

- Add a buffer-local variable `org-current-uri-scheme' which could be
set to a string like "hyper".

- When handling "file" type links, check if `org-current-uri-scheme'
matches one of the keys in `org-link-parameters', and use the
appropriate handler instead of the "file" handler.  (see attached patch
for an example usage in `org-link-open')

What do you think?

Thanks!!

Joseph

diff --git a/lisp/ol.el b/lisp/ol.el
index 20aab6bb8..3808b9215 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1097,12 +1097,15 @@ (defun org-link-open (link  arg)
   ;; first need to integrate search option, if any.
   ("file"
(let* ((option (org-element-property :search-option link))
-	  (path (if option (concat path "::" option) path)))
-	 (org-link-open-as-file path
-(pcase (org-element-property :application link)
-  ((guard arg) arg)
-  ("emacs" 'emacs)
-  ("sys" 'system)
+	  (path (if option (concat path "::" option) path))
+  (f (org-link-get-parameter org-current-uri-scheme :follow)))
+	 (if (functionp f)
+ (funcall f path)
+   (org-link-open-as-file path
+  (pcase (org-element-property :application link)
+((guard arg) arg)
+("emacs" 'emacs)
+("sys" 'system))
   ;; Internal links.
   ((or "coderef" "custom-id" "fuzzy" "radio")
(unless (run-hook-with-args-until-success 'org-open-link-functions path)

Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Hello!

I expect the following to return "[[/foobar]]":

(with-temp-buffer
  (delay-mode-hooks (org-mode))
  (insert "[[/foobar]]")
  (goto-char (point-min))
  (let ((link (org-element-link-parser)))
(org-element-link-interpreter link nil)))

Instead, it returns "[[file:/foobar]]".

In hyperdrive.el currently, "[[/foobar]]" and "[[file:/foobar]]" have
different meanings: a link with no protocol prefix, like "[[/foobar]]",
points to a file inside of the same hyperdrive (virtual p2p folder),
whereas a link with the "file" protocol prefix, like "[[file:/foobar]]",
points to a file on the local filesystem:

https://git.sr.ht/~ushin/hyperdrive.el/tree/33d8cef0507fbbe25839a019b5c42fda862ac4de/item/hyperdrive-org.el#L137

In org-transclusion.el, org-element-context is used to parse a link, and
then org-element-link-interpreter is used to insert it into a buffer:

https://github.com/nobiot/org-transclusion/blob/b10d4de93c6c0523bd4e7e72c11ef3a9a5630370/org-transclusion.el#L372

The problem is that the "file" protocol prefix is added to links which
have no protocol prefix.  When you call org-transclusion-make-from-link
with point on "[[/foobar]]", org-transclusion.el ends up inserting this:

#+transclude: [[file:/foobar]]

which, at least with hyperdrive.el, doesn't point to the same file as

#+transclude: [[/foobar]]

All suggestions are welcome!

Thank you!!!

Joseph

Re: How to HTML export non-Emacs/Elisp info manual links?

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> I'd like for exported HTML output to include HTTP links to info manuals
>> besides the Emacs and Elisp manuals. Is this possible?
>> ...
>
> Now, you can.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=902975ca4
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7e7ce8113
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f32f5982a

Wow! Thank you!!!

How to HTML export non-Emacs/Elisp info manual links?

[Joseph Turner]

Hello!

I'd like for exported HTML output to include HTTP links to info manuals
besides the Emacs and Elisp manuals. Is this possible?

For example, the hyperdrive.el info manual links to the transient.el
info manuals using the info: protocol. In the exported HTML document
(),
the link to the transient.el info manual is broken. It points to

https://ushin.org/hyperdrive/transient.html#Introduction

instead of the expected

https://www.gnu.org/software/emacs/manual/html_mono/transient.html#Introduction

For reference, here's the org-mode hyperdrive.el info manual:

https://git.sr.ht/~ushin/hyperdrive.el/tree/master/doc/hyperdrive-manual.org

Here's the script that exports from org to texi to HTML:

https://git.sr.ht/~ushin/ushin.org/tree/master/item/build-site.el#L26

In this case, the expected URL points to , but it
would be useful to have the option to specify a different host, like:

https://magit.vc/manual/transient.html#Introduction

Thank you!!

Joseph

Re: org-ctags-find-tag should not prompt inside org-open-at-point

[Joseph Turner]

Rudolf Adamkovič  writes:

> Joseph Turner  writes:
>
>> (setopt org-ctags-open-link-functions nil)
>
> Oh, thank you!  This regularly drives me crazy.

You're welcome!

> I added the following to my Emacs/Org configuration:
>
> #+BEGIN_SRC emacs-lisp :results none
> (eval-after-load 'org-ctags
>   (setq org-ctags-open-link-functions nil))
> #+END_SRC

Yes, eval-after-load makes sense.

Joseph

Re: org-ctags-find-tag should not prompt inside org-open-at-point

[Joseph Turner]

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> When org-ctags-find-tag is a member of org-open-link-functions, fuzzy
>> links and custom-id links are broken. Instead of following those links,
>> Emacs prompts for a filename with "Visit tags table (default TAGS)".
>
> This is expected. As per org-ctags documentation:
>
> ;; By default, with org-ctags loaded, org will first try and visit the tag
> ;; with the same name as the link; then, if unsuccessful, ask the user if
> ;; he/she wants to rebuild the 'TAGS' database and try again; then ask if
> ;; the user wishes to append 'tag' as a new toplevel heading at the end of
> ;; the buffer; and finally, defer to org's default behavior which is to
> ;; search the entire text of the current buffer for 'tag'.
> ;;
> ;; This behavior can be modified by changing the value of
> ;; ORG-CTAGS-OPEN-LINK-FUNCTIONS.
>
>> I'm sure how org-ctags is getting required in my Emacs, but I think
>> (require 'org-ctags) probably shouldn't call org-ctags-enable.
>
> Check out
> https://list.orgmode.org/orgmode/87o7omg4ie@alphaville.usersys.redhat.com/

Thank you!! I'm glad to see such care taken in considering this issue!

> We generally agree that (require 'org-ctags) should ideally not have
> side effects, but do not want to introduce too breaking changes either.

Does this mean that org-ctag's disruptive behavior will be fixed?

Thanks!!

Joseph

org-ctags-find-tag should not prompt inside org-open-at-point

[Joseph Turner]

Hello!

When org-ctags-find-tag is a member of org-open-link-functions, fuzzy
links and custom-id links are broken. Instead of following those links,
Emacs prompts for a filename with "Visit tags table (default TAGS)".

To reproduce this issue with emacs -Q:

(require 'org-ctags)

Then open an org-mode buffer with the following:

--8<---cut here---start->8---
[[*header]]

* Header
--8<---cut here---end--->8---

Put point on the link and run org-open-at-point (C-c C-o).

Instead of jumping to the header, Emacs opens a prompt.

One potential solution is to avoid calling xref-find-definitions inside
org-ctags-find-tag, since xref-find-definitions prompts when there’s no
identifier at point.

I'm sure how org-ctags is getting required in my Emacs, but I think
(require 'org-ctags) probably shouldn't call org-ctags-enable.

Until this issue is fixed, a workaround for now is to set
org-ctags-open-link-functions to nil so that org-ctags-find-tag is never
added to org-open-link-functions. Add the following to init.el:

(setopt org-ctags-open-link-functions nil)

This may break some ctags functionality.

Thanks!

Joseph Turner

Re: [PATCH v2] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

No worries!!

Have a good day :)

On October 30, 2022 11:02:18 PM PDT, Ihor Radchenko  wrote:
>Ihor Radchenko  writes:
>
>>> Good catch! I will submit a v3 patch.
>>
>> Did you have a chance to work on the patch?
>
>Oops. I missed that you did and I even merged it. :facepalm:
>Sorry for the noise.
>
>-- 
>Ihor Radchenko // yantar92,
>Org mode contributor,
>Learn more about Org mode at .
>Support Org development at ,
>or support my work at 

Re: [BUG] Server-side export problem in Worg?

[Joseph Turner]

Thank you for the fix!

Joseph
Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Bastien, there seems to be an issue with Worg export on server. Can you
>> please check?
>
> This is now fixed, thanks:
>
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html#org6cd541e

Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output

[Joseph Turner]

Actually, I just looked at the org-mode documentation on the site today,
and noticed that the examples of use section
(https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html#org6cd541e)
has the wrong ASCII output. The output should be

  ,---.  ,-.
  |Bob|  |Alice|
  `-+-'  `--+--'
| Hello World!  |   
|-->|   
  ,-+-.  ,--+--.
  |Bob|  |Alice|
  `---'  `-'

but instead it's just

Bob -> Alice : Hello World!

The results appear just find when I execute the org src code block on my
local machine.

Joseph

Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output

[Joseph Turner]

No worries! Thanks for your patient help.

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Joseph Turner  writes:
>>
>>> You're right! Thank you for catching my mistake. I'll send another patch.
>>
>> Did you have a chance to work on the patch?
>
> Oops. Missed that you've sent a patch in another thread. Sorry for the noise.

[PATCH v2] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output

[Joseph Turner]

Document the new functionality of ob-plantuml to insert ASCII diagrams
directly in the buffer.
---
 .../babel/languages/ob-doc-plantuml.org   | 57 +++
 1 file changed, 46 insertions(+), 11 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-plantuml.org 
b/org-contrib/babel/languages/ob-doc-plantuml.org
index ec347de4..4ae3ca31 100644
--- a/org-contrib/babel/languages/ob-doc-plantuml.org
+++ b/org-contrib/babel/languages/ob-doc-plantuml.org
@@ -49,18 +49,23 @@ Diagram images can be generated in PNG, SVG, and LaTeX 
formats.
 =PlantUML= is integrated with [[https://plantuml.com/running][a wide variety 
of software applications]].
 Babel is a [[https://plantuml.com/emacs][standard way to use PlantUML in 
Emacs]].
 * Requirements and Setup
-=PlantUML= requires a working [[https://www.java.com/en/download/][Java]] 
installation and access to the
-=plantuml.jar= component.  A working [[https://graphviz.org/][GraphViz]] 
installation is required
-for many diagrams.
+=PlantUML= blocks can be executed in one of two ways, requiring either
+
+- a working [[https://www.java.com/en/download/][Java]] installation and 
access to the =plantuml.jar= component or
+- the =plantuml= executable available from your distribution's package manager
+
+A working [[https://graphviz.org/][GraphViz]] installation is required for 
many diagrams.
 
 Emacs has [[https://github.com/skuro/plantuml-mode][plantuml-mode]], a major 
mode for editing PlantUML sources.
 There are detailed 
[[https://github.com/skuro/plantuml-mode#installation][installation 
instructions]], as well as instructions
-for 
[[https://github.com/skuro/plantuml-mode#integration-with-org-mode][integration 
with Org]].
+for 
[[https://github.com/skuro/plantuml-mode#integration-with-org-mode][integration 
with Org]].  While [[https://melpa.org/#/plantuml-mode][plantuml-mode]] does 
allow use of a
+remote server to render the diagram, please note that =ob-plantuml= does
+not currently support this functionality.
 
 You will likely want to set the variables =plantuml-jar-path= and
 =org-plantuml-jar-path= with the path to your local installation of
-=PlantUML=.  Alternatively, set the variable
-=plantuml-default-exec-mode= to access =PlantUML= non-locally.
+=PlantUML=.  Alternatively, set the variable =plantuml-default-exec-mode=
+to =executable= to use your local =plantuml= executable.
 
 Activate evaluation of =PlantUML= source code blocks by adding
 =plantuml= to =org-babel-load-languages=.
@@ -77,15 +82,22 @@ Activate evaluation of =PlantUML= source code blocks by 
adding
 ** Header Arguments
 =PlantUML= code blocks default to =:results file= and =:exports results=.
 
-=PlantUML= has these language-specific header arguments and one requirement:
-   - file :: =PlantUML= code blocks require that an output file be specified
+If you wish to export the =PlantUML= code block to a file, you must
+specify a =:file= header argument.  Alternatively, if you set =:results=
+to a value other than =file=, such as =:results verbatim=, then the ASCII
+=PlantUML= output will be inserted into the buffer below the code block.
+
+=PlantUML= has these language-specific header arguments:
- cmdline :: specify [[https://plantuml.com/command-line][command line 
arguments]] for =PlantUML=
- java :: arguments for the =java= runtimes (JRE) 
 ** Sessions
 =PlantUML= does not support sessions. 
 ** Result Types
-A =PlantUML= code block returns a link to the file it generates.
- 
+When the =:file= header argument has been specified, =PlantUML= code
+blocks return a link to the generated file.  Alternatively, if
+=:results= is set to a value other than =file=, then the generated ASCII
+diagram will be inserted into the buffer.
+
 * Examples of Use
 :PROPERTIES:
 :header-args:plantuml: :eval no-export
@@ -119,7 +131,7 @@ b -> c
 ,#+end_src
 #+end_example
 
-HTML output of the =PlantUML= code block:
+PNG output of the =PlantUML= code block:
 #+begin_src plantuml :file images/theme-uml.png :exports both
 !theme spacelab
 a -> b
@@ -130,3 +142,26 @@ b -> c
 #+RESULTS:
 [[file:images/theme-uml.png]]
 
+Here is an example of ASCII output inserted directly into the buffer.
+
+The =PlantUML= code block in the Org buffer:
+#+begin_example
+,#+begin_src plantuml :results verbatim
+Bob -> Alice : Hello World!
+,#+end_src
+#+end_example
+
+ASCII output of the =PlantUML= code block:
+#+begin_src plantuml :results verbatim
+Bob -> Alice : Hello World!
+#+end_src
+
+#+RESULTS:
+:  ,---.  ,-.
+:  |Bob|  |Alice|
+:  `-+-'  `--+--'
+:| Hello World!  |   
+:|-->|   
+:  ,-+-.  ,--+--.
+:  |Bob|  |Alice|
+:  `---'  `-'
-- 
2.37.0

Re: [PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output

[Joseph Turner]

You're right! Thank you for catching my mistake. I'll send another patch.

Joseph


Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> Document the new functionality of ob-plantuml to insert ASCII diagrams
>> directly in the buffer.
>
> Thanks!
>
>> -=PlantUML= requires a working
>> [[https://www.java.com/en/download/][Java]] installation and access
>> to the
>> -=plantuml.jar= component.  A working [[https://graphviz.org/][GraphViz]] 
>> installation is required
>> -for many diagrams.
>> +=PlantUML= blocks can be executed in one of three ways, requiring either
>> +
>> +- a working [[https://www.java.com/en/download/][Java]]
>> installation and access to the =plantuml.jar= component or
>> +- the =plantuml= executable available from your distribution's package 
>> manager or
>> +- a connection to a remote 
>> [[https://github.com/plantuml/plantuml-server][PlantUML server]]
>
> I do not think that ob-plantuml.el supports server connections. We may
> need to clarify that server part and plantuml-* variables have nothing
> to do with ob-plantuml per se.
>
> Otherwise, the patch looks good.

Re: [PATCH v3] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

You're very welcome! Thank you for your guidance. I learned quite a lot of 
Elisp during this process.

On August 6, 2022 1:24:46 AM PDT, Ihor Radchenko  wrote:
>Joseph Turner  writes:
>
>> When :results header arg is set to a value that doesn't include
>> "file", insert txt output in buffer below src block.
>>
>> TINYCHANGE
>> ---
>>  etc/ORG-NEWS|  7 +++
>>  lisp/ob-plantuml.el | 12 +---
>>  2 files changed, 16 insertions(+), 3 deletions(-)
>
>Thanks!
>Applied onto main via 9cc60dee4.
>https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9cc60dee48851756dd95af46b37b7adc172952e2
>
>-- 
>Ihor Radchenko,
>Org mode contributor,
>Learn more about Org mode at https://orgmode.org/.
>Support Org development at https://liberapay.com/org-mode,
>or support my work at https://liberapay.com/yantar92

[PATCH] org-contrib/babel/languages/ob-doc-plantuml.org: ASCII output

[Joseph Turner]

Document the new functionality of ob-plantuml to insert ASCII diagrams
directly in the buffer.
---
This patch documents the changes made here: 
https://lists.gnu.org/archive/html/emacs-orgmode/2022-08/msg00110.html

 .../babel/languages/ob-doc-plantuml.org   | 55 +++
 1 file changed, 45 insertions(+), 10 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-plantuml.org 
b/org-contrib/babel/languages/ob-doc-plantuml.org
index ec347de4..2bd46861 100644
--- a/org-contrib/babel/languages/ob-doc-plantuml.org
+++ b/org-contrib/babel/languages/ob-doc-plantuml.org
@@ -49,9 +49,13 @@ Diagram images can be generated in PNG, SVG, and LaTeX 
formats.
 =PlantUML= is integrated with [[https://plantuml.com/running][a wide variety 
of software applications]].
 Babel is a [[https://plantuml.com/emacs][standard way to use PlantUML in 
Emacs]].
 * Requirements and Setup
-=PlantUML= requires a working [[https://www.java.com/en/download/][Java]] 
installation and access to the
-=plantuml.jar= component.  A working [[https://graphviz.org/][GraphViz]] 
installation is required
-for many diagrams.
+=PlantUML= blocks can be executed in one of three ways, requiring either
+
+- a working [[https://www.java.com/en/download/][Java]] installation and 
access to the =plantuml.jar= component or
+- the =plantuml= executable available from your distribution's package manager 
or
+- a connection to a remote 
[[https://github.com/plantuml/plantuml-server][PlantUML server]]
+
+A working [[https://graphviz.org/][GraphViz]] installation is required for 
many diagrams.
 
 Emacs has [[https://github.com/skuro/plantuml-mode][plantuml-mode]], a major 
mode for editing PlantUML sources.
 There are detailed 
[[https://github.com/skuro/plantuml-mode#installation][installation 
instructions]], as well as instructions
@@ -59,8 +63,9 @@ for 
[[https://github.com/skuro/plantuml-mode#integration-with-org-mode][integrat
 
 You will likely want to set the variables =plantuml-jar-path= and
 =org-plantuml-jar-path= with the path to your local installation of
-=PlantUML=.  Alternatively, set the variable
-=plantuml-default-exec-mode= to access =PlantUML= non-locally.
+=PlantUML=.  Alternatively, set the variable =plantuml-default-exec-mode=
+to =executable= to use your local =plantuml= executable or to =server= to
+access =PlantUML= non-locally.
 
 Activate evaluation of =PlantUML= source code blocks by adding
 =plantuml= to =org-babel-load-languages=.
@@ -77,15 +82,22 @@ Activate evaluation of =PlantUML= source code blocks by 
adding
 ** Header Arguments
 =PlantUML= code blocks default to =:results file= and =:exports results=.
 
-=PlantUML= has these language-specific header arguments and one requirement:
-   - file :: =PlantUML= code blocks require that an output file be specified
+If you wish to export the =PlantUML= code block to a file, you must
+specify a =:file= header argument.  Alternatively, if you set =:results=
+to a value other than =file=, such as =:results verbatim=, then the ASCII
+=PlantUML= output will be inserted into the buffer below the code block.
+
+=PlantUML= has these language-specific header arguments:
- cmdline :: specify [[https://plantuml.com/command-line][command line 
arguments]] for =PlantUML=
- java :: arguments for the =java= runtimes (JRE) 
 ** Sessions
 =PlantUML= does not support sessions. 
 ** Result Types
-A =PlantUML= code block returns a link to the file it generates.
- 
+When the =:file= header argument has been specified, =PlantUML= code
+blocks return a link to the generated file.  Alternatively, if
+=:results= is set to a value other than =file=, then the generated ASCII
+diagram will be inserted into the buffer.
+
 * Examples of Use
 :PROPERTIES:
 :header-args:plantuml: :eval no-export
@@ -119,7 +131,7 @@ b -> c
 ,#+end_src
 #+end_example
 
-HTML output of the =PlantUML= code block:
+PNG output of the =PlantUML= code block:
 #+begin_src plantuml :file images/theme-uml.png :exports both
 !theme spacelab
 a -> b
@@ -130,3 +142,26 @@ b -> c
 #+RESULTS:
 [[file:images/theme-uml.png]]
 
+Here is an example of ASCII output inserted directly into the buffer.
+
+The =PlantUML= code block in the Org buffer:
+#+begin_example
+,#+begin_src plantuml :results verbatim
+Bob -> Alice : Hello World!
+,#+end_src
+#+end_example
+
+ASCII output of the =PlantUML= code block:
+#+begin_src plantuml :results verbatim
+Bob -> Alice : Hello World!
+#+end_src
+
+#+RESULTS:
+:  ,---.  ,-.
+:  |Bob|  |Alice|
+:  `-+-'  `--+--'
+:| Hello World!  |   
+:|-->|   
+:  ,-+-.  ,--+--.
+:  |Bob|  |Alice|
+:  `---'  `-'
-- 
2.37.0

[PATCH v3] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

When :results header arg is set to a value that doesn't include
"file", insert txt output in buffer below src block.

TINYCHANGE
---
 etc/ORG-NEWS|  7 +++
 lisp/ob-plantuml.el | 12 +---
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4cda357f1..b8cd05d4e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -295,6 +295,13 @@ files that are exported to Texinfo.
 
 =org-at-heading-p= now returns t by default on headings inside folds.
 Passing optional argument will produce the old behaviour.
+
+*** =org-babel-execute:plantuml= can output ASCII graphs in the buffer
+
+Previously, executing PlantUML src blocks always exported to a file.  Now, if
+:results is set to a value which does not include "file", no file will be
+exported and an ASCII graph will be inserted below the src block.
+
 ** Removed or renamed functions and variables
 *** =org-plantump-executable-args= is renamed and applies to jar as well
 
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index ebbcdf166..a339d8485 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -109,8 +109,11 @@ If BODY does not contain @startXXX ... @endXXX clauses, 
@startuml
 (defun org-babel-execute:plantuml (body params)
   "Execute a block of plantuml code with org-babel.
 This function is called by `org-babel-execute-src-block'."
-  (let* ((out-file (or (cdr (assq :file params))
-  (error "PlantUML requires a \":file\" header argument")))
+  (let* ((do-export (member "file" (cdr (assq :result-params params
+ (out-file (if do-export
+   (or (cdr (assq :file params))
+   (error "No :file provided but :results set to file. 
For plain text output, set :results to verbatim"))
+(org-babel-temp-file "plantuml-" ".txt")))
 (cmdline (cdr (assq :cmdline params)))
 (in-file (org-babel-temp-file "plantuml-"))
 (java (or (cdr (assq :java params)) ""))
@@ -155,7 +158,10 @@ This function is called by `org-babel-execute-src-block'."
 (if (and (string= (file-name-extension out-file) "svg")
  org-babel-plantuml-svg-text-to-path)
 (org-babel-eval (format "inkscape %s -T -l %s" out-file out-file) ""))
-nil)) ;; signal that output has already been written to file
+(unless do-export (with-temp-buffer
+(insert-file-contents out-file)
+(buffer-substring-no-properties
+ (point-min) (point-max))
 
 (defun org-babel-prep-session:plantuml (_session _params)
   "Return an error because plantuml does not support sessions."
-- 
2.37.0

Re: [PATCH v2] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

Ihor Radchenko  writes:

> Let's take this opportunity and fix another omission in ob-plantuml.
> :results may generally contain Elisp sexps to be evaluated and the whole
> split-string busyness is not accurate. Please use :result-params list
> instead of :results.

Good catch! I will submit a v3 patch. Is this still a TINYCHANGE or
shall I do a copyright assignment?

> Also, can you please update the ob-plantuml documentation according to
> the changes made. The current version is in
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-plantuml.html

Gladly.

Best,

Joseph

[PATCH v2] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

When :results header arg is set to a value that doesn't include
"file", insert txt output in buffer below src block.

TINYCHANGE
---
 etc/ORG-NEWS|  7 +++
 lisp/ob-plantuml.el | 13 ++---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4cda357f1..b8cd05d4e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -295,6 +295,13 @@ files that are exported to Texinfo.
 
 =org-at-heading-p= now returns t by default on headings inside folds.
 Passing optional argument will produce the old behaviour.
+
+*** =org-babel-execute:plantuml= can output ASCII graphs in the buffer
+
+Previously, executing PlantUML src blocks always exported to a file.  Now, if
+:results is set to a value which does not include "file", no file will be
+exported and an ASCII graph will be inserted below the src block.
+
 ** Removed or renamed functions and variables
 *** =org-plantump-executable-args= is renamed and applies to jar as well
 
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index ebbcdf166..85dd34e62 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -109,8 +109,12 @@ If BODY does not contain @startXXX ... @endXXX clauses, 
@startuml
 (defun org-babel-execute:plantuml (body params)
   "Execute a block of plantuml code with org-babel.
 This function is called by `org-babel-execute-src-block'."
-  (let* ((out-file (or (cdr (assq :file params))
-  (error "PlantUML requires a \":file\" header argument")))
+  (let* ((do-export (member "file"
+(split-string (cdr (assq :results params)
+ (out-file (if do-export
+   (or (cdr (assq :file params))
+   (error "No :file provided but :results set to file. 
For plain text output, set :results to verbatim"))
+(org-babel-temp-file "plantuml-" ".txt")))
 (cmdline (cdr (assq :cmdline params)))
 (in-file (org-babel-temp-file "plantuml-"))
 (java (or (cdr (assq :java params)) ""))
@@ -155,7 +159,10 @@ This function is called by `org-babel-execute-src-block'."
 (if (and (string= (file-name-extension out-file) "svg")
  org-babel-plantuml-svg-text-to-path)
 (org-babel-eval (format "inkscape %s -T -l %s" out-file out-file) ""))
-nil)) ;; signal that output has already been written to file
+(unless do-export (with-temp-buffer
+(insert-file-contents out-file)
+(buffer-substring-no-properties
+ (point-min) (point-max))
 
 (defun org-babel-prep-session:plantuml (_session _params)
   "Return an error because plantuml does not support sessions."
-- 
2.37.0

Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

Ihor Radchenko  writes:
> You also need to change :result-params and :result-type.
> See `org-babel-execute-src-block'.

Here's what I've got so far:

```
(defvar org-babel-default-header-args:plantuml
  '((:exports . "results"))
  "Default arguments for evaluating a plantuml source block.")

(defun org-babel-execute:plantuml (body params)
  "Execute a block of plantuml code with org-babel.
This function is called by `org-babel-execute-src-block'."
  (let* ((do-export (cdr (assq :file params)))
 (params (if do-export
 (map-merge 'list params '((:results . "file") 
(:result-params "replace" "file")))
   params))
 (out-file (or do-export
   (org-babel-temp-file "plantuml-" ".txt"))) ; if ":file" 
is not provided, don't export, just print ASCII results
 (cmdline (cdr (assq :cmdline params)))
 (in-file (org-babel-temp-file "plantuml-"))
 (java (or (cdr (assq :java params)) ""))
 (executable (cond ((eq org-plantuml-exec-mode 'plantuml) 
org-plantuml-executable-path)
   (t "java")))
 (executable-args (cond ((eq org-plantuml-exec-mode 'plantuml) 
org-plantuml-executable-args)
((string= "" org-plantuml-jar-path)
 (error "`org-plantuml-jar-path' is not set"))
((not (file-exists-p org-plantuml-jar-path))
 (error "Could not find plantuml.jar at %s" 
org-plantuml-jar-path))
(t (list java
 "-jar"
 (shell-quote-argument 
(expand-file-name org-plantuml-jar-path))
 (full-body (org-babel-plantuml-make-body body params))
 (cmd (mapconcat #'identity
 (append
  (list executable)
  executable-args
  (pcase (file-name-extension out-file)
("png" '("-tpng"))
("svg" '("-tsvg"))
("eps" '("-teps"))
("pdf" '("-tpdf"))
("tex" '("-tlatex"))
("vdx" '("-tvdx"))
("xmi" '("-txmi"))
("scxml" '("-tscxml"))
("html" '("-thtml"))
("txt" '("-ttxt"))
("utxt" '("-utxt")))
  (list
   "-p"
   cmdline
   "<"
   (org-babel-process-file-name in-file)
   ">"
   (org-babel-process-file-name out-file)))
 " ")))
(with-temp-file in-file (insert full-body))
(message "\n%s\n" do-export)
(message "\n%s\n" params)
(message "%s" cmd) (org-babel-eval cmd "")
(if (and (string= (file-name-extension out-file) "svg")
 org-babel-plantuml-svg-text-to-path)
(org-babel-eval (format "inkscape %s -T -l %s" out-file out-file) ""))
(unless do-export (with-temp-buffer
(insert-file-contents out-file)
(buffer-substring-no-properties (point-min) 
(point-max))
```

I've added a couple of (message ...) blocks to log the value of
do-export and params. It appears that this combination is producing a
params value which is equivalent to the value of params produced by the
current org-babel-execute:plantuml function. However, when the above
function is executed on a block like:

#+begin_src plantuml :file "this.png"
  Bob->Alice : Hello1!
#+end_src

I get "Code block produced no output."

I suspect that setting the scoped params variable has no effect on the
execution of the function, since I can set params to '((:results .
"none")), and I'll still get a printed result if
org-babel-default-header-args:plantuml is set to the above value.

Is it safe to modify the value of org-babel-default-header-args:plantuml
from within the function? Would that even work?

Thank you for your patience in figuring this out with me :)

Joseph

Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

Ihor Radchenko  writes:
> You can examine :result-params property inside params plist. If that
> property does not explicitly mention different results Type (see 16.6
> Results of Evaluation), ob-plantuml may set the type to "file" with
> plist-put.

Perhaps I'm confused, but I think org-babel-default-header-args:plantuml
is actually an alist, right?

I tried removing the (:results . "file") from
org-babel-default-header-args:plantuml, and then overwriting the params
argument inside the let* block like so:

```
  (let* ((do-export (cdr (assq :file params)))
 (params (if do-export
 (add-to-list 'params '(:results . "file")))
 (out-file ...
```

Logging the params variable after the let* block reveals that :results
is set to "file", but I still get "Code block produced no output" when
I try to evaluate the plantuml org src block.

Thoughts?

Joseph

Re: [PATCH] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

Thank you for your feedback, Ihor!

> Most importantly, the patch does not change the default value of
> org-babel-default-header-args:plantuml. :results header arg is set to
> "file" by default.

Yes, I noticed this issue also.

> The solution will be simply removing the default :results setting.

I think you're suggesting something like this:

(defvar org-babel-default-header-args:plantuml
  '((:exports . "results"))
  "Default arguments for evaluating a plantuml source block.")

With this change, if you *do* add a :file arg, like in the following
example, then no output will be produced:

#+begin_src plantuml :file "this.png"
  Bob->Alice : Hello1!
#+end_src

#+RESULTS:

which is also wrong.

What would the code look like if we wanted to change the
org-babel-default-header-args:plantuml variable inside the
org-babel-execute:plantuml function based on the value of the params
arg? Or perhaps you have a different solution?

Once we straighten this issue out, I am happy to resubmit the updated
patch with your suggested style changes.

Warmly,

Joseph

[PATCH] lisp/ob-plantuml.el: Insert results in buffer

[Joseph Turner]

Allow src block execution without ":file" header arg. When ":file" is
omitted, insert txt output in buffer below src block.

TINYCHANGE
---
 etc/ORG-NEWS|  5 +
 lisp/ob-plantuml.el | 10 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 4cda357f1..1613fdab5 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -295,6 +295,11 @@ files that are exported to Texinfo.
 
 =org-at-heading-p= now returns t by default on headings inside folds.
 Passing optional argument will produce the old behaviour.
+
+*** =org-babel-execute:plantuml= can output ASCII graphs in the buffer
+
+Previously, executing PlantUML src blocks required a ":file" header argument. 
Now, if that header argument is omitted, an ASCII graph will be inserted below 
the src block.
+
 ** Removed or renamed functions and variables
 *** =org-plantump-executable-args= is renamed and applies to jar as well
 
diff --git a/lisp/ob-plantuml.el b/lisp/ob-plantuml.el
index ebbcdf166..f9b41c140 100644
--- a/lisp/ob-plantuml.el
+++ b/lisp/ob-plantuml.el
@@ -109,8 +109,9 @@ If BODY does not contain @startXXX ... @endXXX clauses, 
@startuml
 (defun org-babel-execute:plantuml (body params)
   "Execute a block of plantuml code with org-babel.
 This function is called by `org-babel-execute-src-block'."
-  (let* ((out-file (or (cdr (assq :file params))
-  (error "PlantUML requires a \":file\" header argument")))
+  (let* ((do-export (cdr (assq :file params)))
+ (out-file (or do-export
+  (org-babel-temp-file "plantuml-" ".txt"))) ; if ":file" 
is not provided, don't export, just print ASCII results
 (cmdline (cdr (assq :cmdline params)))
 (in-file (org-babel-temp-file "plantuml-"))
 (java (or (cdr (assq :java params)) ""))
@@ -155,7 +156,10 @@ This function is called by `org-babel-execute-src-block'."
 (if (and (string= (file-name-extension out-file) "svg")
  org-babel-plantuml-svg-text-to-path)
 (org-babel-eval (format "inkscape %s -T -l %s" out-file out-file) ""))
-nil)) ;; signal that output has already been written to file
+(unless do-export (with-temp-buffer
+(insert-file-contents out-file)
+(buffer-substring-no-properties (point-min) 
(point-max))
+
 
 (defun org-babel-prep-session:plantuml (_session _params)
   "Return an error because plantuml does not support sessions."
-- 
2.37.0