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

2022-07-21 Thread 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




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

2022-07-25 Thread 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



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

2022-07-27 Thread 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

2022-07-31 Thread 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





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

2022-08-03 Thread 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 v2] lisp/ob-plantuml.el: Insert results in buffer

2022-08-05 Thread 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 v3] lisp/ob-plantuml.el: Insert results in buffer

2022-08-05 Thread 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




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

2022-08-05 Thread 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




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

2022-08-06 Thread 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


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

2022-08-13 Thread 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.




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

2022-08-13 Thread 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

2022-09-15 Thread 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.




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

2022-09-21 Thread 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: [BUG] Server-side export problem in Worg?

2022-09-22 Thread 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 v2] lisp/ob-plantuml.el: Insert results in buffer

2022-10-31 Thread 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 


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

2023-09-24 Thread 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: org-ctags-find-tag should not prompt inside org-open-at-point

2023-09-26 Thread 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



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

2023-09-28 Thread 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



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

2023-10-10 Thread 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: How to HTML export non-Emacs/Elisp info manual links?

2023-10-10 Thread 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!!!



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

2023-12-28 Thread 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: Should org-link-parser add type "file" when link has no "file:" prefix?

2023-12-30 Thread 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 &optional 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)


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

2023-12-30 Thread 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 &optional 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?

2024-01-01 Thread 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?

2024-01-15 Thread 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 &optional 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 &optional 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?

2024-01-16 Thread 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 &optional _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



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

2024-01-18 Thread 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: [PATCH] Silently remove lockfiles from org-agenda-files

2024-01-31 Thread 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



Using search options in HTTP-style links

2024-04-15 Thread 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: Using search options in HTTP-style links

2024-04-17 Thread 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



Re: Using search options in HTTP-style links

2024-05-15 Thread 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

2024-05-18 Thread 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

2024-06-08 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> You probably meant to link to some different ticket here.
>>
>> https://todo.sr.ht/~ushin/ushin/188
>
> So, you want an equivalent of `org-safe-remote-resources'.

For now, we've added a command `hyperdrive-mark-as-safe`, which causes
automatic major modes activation when opening a file in a "safe" drive:

https://ushin.org/hyperdrive/hyperdrive-manual.html#Mark-a-hyperdrive-as-safe
https://git.sr.ht/~ushin/hyperdrive.el/commit/1e9b892e87979d3da5e9a1f04d0255a620500214

`org-file-contents' and `org-safe-remote-resources' already work with
hyperdrive.el.  We just need to figure out a way to treat

#+SETUPFILE: /foo/bar.org

as

#+SETUPFILE: hyper://CURRENT-DRIVE-PUBKEY/foo/bar.org

since the latter already works.  Perhaps this link conversion will work
when we implement magic file name handlers.  :)

> Generally, we might eventually move it to Emacs core, making a more
> general Emacs safety framework with unified preferences.
> But someone™ has to do this job. As usual.

Yes, a general Emacs safety framework would be an improvement.

Thank you for helping thinking through these security concerns!

Joseph



Adding text/org MIME type to jshttp/mime-db

2024-08-01 Thread Joseph Turner
Hello!

Based on this recent thread, the consensus seems to be that we'd like
the .org file extension to have a dedicated "text/org" MIME type:

https://yhetil.org/orgmode/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com/

Until the Org syntax spec is complete and a proposal submitted to and
approved by IANA, we can negotiate with downstream MIME libraries to
override "applicaion/vnd.lotus-organizer" with "text/org" on a
case-by-case basis.  As Max Nikulin wrote in the thread linked above,

> An alternative is to negotiate with maintainers of mime.types in
> RedHat and Debian.

Support for "text/org" in  would let
the Agregore browser () render Org files.
Then hyperdrive.el users could share Org files to be viewed in Agregore.

John Kitchin opened a PR back in 2017, which was rejected:

https://github.com/jshttp/mime-db/pull/82

After I posted a comment on the thread, the maintainer responded:

> I would suggest opening a new PR.  If you could also include those
> references inline into the description.  Ideally if you could also get
> someone to describe what is implied by "defacto" that would be awesome.

I'd like to open a new PR.  Would you elaborate on "de facto mimetype"?

Thank you!

Joseph



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-03 Thread Joseph Turner
Max Nikulin  writes:

> On 02/08/2024 02:55, Joseph Turner wrote:
>> Support for "text/org" in <https://github.com/jshttp/mime-db> would
>> let
>> the Agregore browser (<https://agregore.mauve.moe/>) render Org
>> files.
>> Then hyperdrive.el users could share Org files to be viewed in
>> Agregore.
>> John Kitchin opened a PR back in 2017, which was rejected:
>> https://github.com/jshttp/mime-db/pull/82
>
> I missed it at first, but it was *closed*, but not *rejected*.
>
> <https://github.com/jshttp/mime-db/commit/5797174e5434a8d2978d9fdc13ec6a47ba20a02f>
> 2017-07-25T01:12:28Z
>> Add text/x-org
>> closes #82

Thank you for catching my oversight!!

I dug a little deeper and discovered that the popular NPM packages that
make use of jshttp/mime-db rank the source of each MIME type and discard
duplicates which have lower "preference".  For example, the
jshttp/mime-types utility does this:

  // source preference (least -> most)
  var preference = ['nginx', 'apache', undefined, 'iana']

and then discards duplicate mappings which are of lower preference.

https://github.com/jshttp/mime-types/blob/eca390b71004a70f4551197638c077cdba8cf954/index.js#L155

I think https://github.com/broofa/mime does something similar.

The result is that the two popular NPM utilities for getting a MIME type
from a file extension (see <https://www.npmjs.com/search?q=mime>) ignore
the ".org" -> "text/x-org" mapping in favor of ".org" ->
"application/vnd.lotus-organizer".

> So you can use text/x-org.
>
>> After I posted a comment on the thread, the maintainer responded:
>> 
>>> I would suggest opening a new PR.
>
> I think, text/org may be added as well (without removing of
> text/x-org).

Shall we consider this this after we find a way for these low-preference
mappings to be useful?

> Perhaps a worg page may be created to clarify current state of media
> type for org files. The question is what is the appropriate directory.

I agree that it would be good to track this information in one place so
we don't repeat ourselves ;)

Thanks,

Joseph



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-03 Thread Joseph Turner
Joseph Turner  writes:

> I think https://github.com/broofa/mime does something similar.

Actually, broofa/mime relies on another package for ranking:

https://github.com/broofa/mime-score



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-04 Thread Joseph Turner
Max Nikulin  writes:

> On 04/08/2024 00:37, Joseph Turner wrote:
>> jshttp/mime-types utility does this:
>>// source preference (least -> most)
>>var preference = ['nginx', 'apache', undefined, 'iana']
>> and then discards duplicate mappings which are of lower preference.
>
> I can not say that I have consistent vision which way media type
> database should be designed. It is rather close to off-topic on this
> list (though `org-file-types' is a kind of override map, built-in
> mailcap.el is far from being perfect, and Emacs ignores
> shared-mime-info completely).
>
> - Both fallback and override entries should be implemented.
> - It seems there are differences which way custom entries should be
>   handled during compiling database and when an application uses third
>   party mappings. The reason is that version of external database may
>   be older or newer than version of an application. Some conflicts may
>   cause fatal error during compiling of database while applications
>   have to be more intelligent in respect to conflict resolution.
> - Priorities of media type to suffix and suffix to media type may be
>   different.
> - My impression is that multiple types may have the same suffix, so
>   there should be "get all media types for given suffix" method.
> - It should be possible to specify priorities within the same source.
>
> I am a bit surprised that jshttp/mime-types developers use added
> entries as fallback, not as overrides for IANA, but it is their design
> decision. Since it is a DB, not DB user, they can just drop
> conflicting entries. Perhaps they still want to preserve ambiguous
> mapping of multiple media types to the same suffix (otherwise
> text/x-org should be dropped due to a conflict).

Yes, I am also surprised that jshttp/mime-types does not offer a way to
customize MIME type source preference.

However, on the topic of Org mode support in Agregore, I am not sure
that the ability to specify a different preference or even a "get all
media types for given suffix" function would help.  In this case, we
want the browser to treat .org files as text files and attempt to render
them.  Currently, .org files are treated as non-text files and the
browser attempts to download them when the user opens one.  This means
that our code to render Org files doesn't even get a chance to run.

For now, perhaps we can override the MIME type map in the extension:

https://github.com/AgregoreWeb/extension-agregore-renderer/issues/8#issuecomment-2267958828

>> Max Nikulin writes:
>>> I think, text/org may be added as well (without removing of
>>> text/x-org).
>> Shall we consider this this after we find a way for these
>> low-preference
>> mappings to be useful?
>
> I still believe that the following behavior is preferable
>
> - applicaion/vnd.lotus-organizer -> .org
> - text/x-org -> .org
> - text/org -> .org
> - .org -> text/org (preferably without relying on x- heuristics)
>
> Unless a user explicitly configured local mapping .org to
> applicaion/vnd.lotus-organizer

I agree with your preference!

Thanks,

Joseph



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-05 Thread Joseph Turner
Max Nikulin  writes:

> On 05/08/2024 10:19, Joseph Turner wrote:
>> Max Nikulin writes:
>>> - My impression is that multiple types may have the same suffix, so
>>>there should be "get all media types for given suffix" method.
>>> - It should be possible to specify priorities within the same source.
> [...]
>> However, on the topic of Org mode support in Agregore, I am not sure
>> that the ability to specify a different preference or even a "get all
>> media types for given suffix" function would help.
>
> My idea is that this method pushes developers toward more flexible
> design in respect to specifying priorities of records. With its
> presence it is more probable that users of the DB will be prepared to
> cases when 2 step mappings media type -> suffix -> media type and
> suffix -> media type -> suffix give values that are different from the
> original ones.

I think a more flexible design could help in this case.

>> For now, perhaps we can override the MIME type map in the extension:
>> https://github.com/AgregoreWeb/extension-agregore-renderer/issues/8#issuecomment-2267958828
>
> I have added a comment. The issue may be Content-Type header sent by
> server (or other side of p2p connection).

Thank you.  I've responded on that thread.



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-09 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> I think, text/org may be added as well (without removing of
>>> text/x-org).
>>
>> Shall we consider this this after we find a way for these low-preference
>> mappings to be useful?
>
> If you mean "negotiate... to override "applicaion/vnd.lotus-organizer"
> with "text/org"", I have no objections.
>
>>> Perhaps a worg page may be created to clarify current state of media
>>> type for org files. The question is what is the appropriate directory.
>>
>> I agree that it would be good to track this information in one place so
>> we don't repeat ourselves ;)
>
> We can put such a page alongside /org-syntax.org, maybe even linked from
> there. Feel free to create such a page.

Would the following patch be appropriate?

Thanks!

Joseph

>From c898ba723faeb67929f52728c67e2b8858f99738 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Fri, 9 Aug 2024 05:55:52 -0700
Subject: [PATCH] org-media-type.org: New file; Describe state of NodeJS MIME
 database

---
 org-media-type.org | 37 +
 1 file changed, 37 insertions(+)
 create mode 100644 org-media-type.org

diff --git a/org-media-type.org b/org-media-type.org
new file mode 100644
index ..f5d69b7c
--- /dev/null
+++ b/org-media-type.org
@@ -0,0 +1,37 @@
+#+title: Org Media Type
+#+author: Joseph Turner
+#+options: toc:t ':t author:nil
+#+language: en
+#+category: worg
+#+bind: sentence-end-double-space t
+#+html_link_up:index.html
+#+html_link_home:  https://orgmode.org/worg/
+
+#+begin_comment
+This file is released by its authors and contributors under the GNU
+Free Documentation license v1.3 or later, code examples are released
+under the GNU General Public License v3 or later.
+#+end_comment
+
+* Introduction
+
+This page tracks information about the ~.org~ extension media type.
+
+Based on [[https://yhetil.org/orgmode/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com/][this thread on the Org mode mailing list]], the consensus is
+that the ~.org~ file extension should map to the ~text/org~ MIME type.
+
+Until the [[file:org-syntax.org][Org syntax spec]] is complete and a proposal submitted to and
+approved by IANA, we can ask downstream MIME libraries to override
+~applicaion/vnd.lotus-organizer~ with ~text/org~.
+
+* Downstream MIME Libraries
+
+** jshttp/mime-db - NodeJS
+
+[[https://github.com/jshttp/mime-db][jshttp/mime-db]] is the de facto standard MIME database for NodeJS.
+[[https://github.com/jshttp/mime-db/commit/5797174e5434a8d2978d9fdc13ec6a47ba20a02f][This commit]] adds a mapping from ~.org~ to ~text/x-org~, but the two
+popular NodeJS utilities for getting a MIME type from a file
+extension, [[https://github.com/jshttp/mime-types][jshttp/mime-types]] and [[https://github.com/broofa/mime][broofa/mime]], return
+~applicaion/vnd.lotus-organizer~.  Both libraries return only the
+highest preference media type, and IANA-sourced media types are
+preferred over other types.
-- 
2.41.0



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-10 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> We can put such a page alongside /org-syntax.org, maybe even linked from
>>> there. Feel free to create such a page.
>>
>> Would the following patch be appropriate?
>
> LGTM!
> But we also need to link this new page from other places.

How about this patch for orgweb?

Joseph

>From 5284e6cf66a8e4a8c2dcc0471e5285746c56a455 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Sat, 10 Aug 2024 11:45:53 -0700
Subject: [PATCH] index.org: Link to new worg org-media-type page

---
 index.org | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/index.org b/index.org
index 025b4aa..6bfa6d0 100644
--- a/index.org
+++ b/index.org
@@ -119,9 +119,10 @@ * More Org
   :CUSTOM_ID: more
   :END:
 
-The /de facto/ mimetype for Org files is =text/org=. Org files use the
-~.org~ extension. Most operating systems don't know to open ~.org~ files
-in Emacs, but they can be configured to do so without much effort.
+The /de facto/ [[https://orgmode.org/worg/org-media-type.html][mimetype for Org files]] is =text/org=. Org files use the
+~.org~ extension. Most operating systems don't know to open ~.org~
+files in Emacs, but they can be configured to do so without much
+effort.
 
 While the reference implementation of Org in Emacs lisp is by far the
 most featureful, there are many additional [[file:tools.org][tools]] that work with Org.
-- 
2.41.0



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-13 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>>> But we also need to link this new page from other places.
>>
>> How about this patch for orgweb?
>
> Thanks!
> Applied, onto master for orgweb and master for worg.
> https://git.sr.ht/~bzg/worg/commit/91954998
> https://git.sr.ht/~bzg/orgweb/commit/d9222e889ed1f5fee0d328490ed731509fd5a398
>
> I added the TINYCHANGE cookie to your orgweb patch, as orgweb is covered
> under FSF copyright requirements.
>
> Do note that your total contribution is ~15LOC at this point. You may
> consider doing FSF paperwork to make more contributions to org-mode and
> orgweb. worg is free from this requirement.

Thanks!  I completed the FSF copyright assignment paperwork in May 2023.

Joseph



Re: Adding text/org MIME type to jshttp/mime-db

2024-08-16 Thread Joseph Turner
Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Joseph Turner  writes:
>>
>>> Thanks!  I completed the FSF copyright assignment paperwork in May 2023.
>
> I updated our records.
> https://git.sr.ht/~bzg/worg/commit/29c58d61

Thank you!

Joseph



[PATCH] lisp/org.el: Fix removing timestamp overlays

2024-08-25 Thread Joseph Turner
Thank you!  Cheers!  -Joseph

>From 2289e6cd9f27bee04fa9004d757b23d3f1ef9e9c Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Sun, 25 Aug 2024 21:20:06 -0700
Subject: [PATCH] lisp/org.el: Fix removing timestamp overlays

---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index d5c1dcb35..9e80c4b70 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14614,7 +14614,7 @@ (defun org-toggle-timestamp-overlays ()
 (let ((p (point-min)) (bmp (buffer-modified-p)))
   (while (setq p (next-single-property-change p 'display))
 	(when (and (get-text-property p 'display)
-		   (eq (get-text-property p 'face) 'org-date))
+		   (memq 'org-date (get-text-property p 'face)))
 	  (remove-text-properties
 	   p (setq p (next-single-property-change p 'display))
 	   '(display t
-- 
2.41.0



Re: [PATCH] lisp/org.el: Fix removing timestamp overlays

2024-08-25 Thread Joseph Turner
Joseph Turner  writes:

> Thank you!  Cheers!  -Joseph
>
> [2. text/x-diff; 0001-lisp-org.el-Fix-removing-timestamp-overlays.patch]...

Woops!  The 'display text property may be symbol or list - here's a
better patch.

Thanks,

Joseph

>From 9351b3c8f960ac6d2fba3c2de0c46e8474719582 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Sun, 25 Aug 2024 21:20:06 -0700
Subject: [PATCH] lisp/org.el: Fix removing timestamp overlays

---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index d5c1dcb35..24a32227c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -14614,7 +14614,7 @@ (defun org-toggle-timestamp-overlays ()
 (let ((p (point-min)) (bmp (buffer-modified-p)))
   (while (setq p (next-single-property-change p 'display))
 	(when (and (get-text-property p 'display)
-		   (eq (get-text-property p 'face) 'org-date))
+		   (memq 'org-date (ensure-list (get-text-property p 'face
 	  (remove-text-properties
 	   p (setq p (next-single-property-change p 'display))
 	   '(display t
-- 
2.41.0



Re: Repeated Multi-day Events

2024-10-27 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> I'd like to mark an event which runs from 4PM on Saturday to 4PM on
>> Monday each week:
>>
>> <2024-09-07 Sat 16:00 +1w>--<2024-09-09 Mon 16:00 +1w>
>>
>> However, org-agenda does not show this event on subsequent weeks.
>
> There is nothing wrong with your timestamp range, AFAIU. However, agenda
> simply does not support repeaters in the date ranges. It is a missing feature.

Thanks.  Good to know.

>> This thread proposes using diary sexp syntax:
>>
>> https://yhetil.org/orgmode/9ai657-rdb@news.eternal-september.org/
>>
>> Any suggestions?
>
> diary-sexp should work.
> Also, M-x org-clone-subtree-with-time-shift

Thanks!  I didn't know about org-clone-subtree-with-time-shift.

For now, I'm using the following as a workaround.

<2024-07-20 Sat 16:00-24:00 +1w> <2024-07-21 Sun 0:00-24:00 +1w> <2024-07-22 
Mon 0:00-16:00 +1w>



Repeated Multi-day Events

2024-09-21 Thread Joseph Turner
Hello!

I'd like to mark an event which runs from 4PM on Saturday to 4PM on
Monday each week:

<2024-09-07 Sat 16:00 +1w>--<2024-09-09 Mon 16:00 +1w>

However, org-agenda does not show this event on subsequent weeks.

I recognize that the syntax I tried (adding a repeated to the start and
end timestamps) is problematic, since it's possible to choose different
repeaters for the start and end timestamps, e.g. "+1d" and then "+1w".

This thread proposes using diary sexp syntax:

https://yhetil.org/orgmode/9ai657-rdb@news.eternal-september.org/

Any suggestions?

Thank you!

Joseph



Re: Form feed characters break odt export

2024-12-28 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> From ce506caa0bffbd243a2aba384f75f7aaac7fdc4b Mon Sep 17 00:00:00 2001
>> From: Ihor Radchenko 
>> Date: Fri, 27 Dec 2024 10:21:02 +
>> Subject: [PATCH] ox-odt: Avoid putting forbidden characters into ODT xml
>
> Thanks for helping with the patch!
> I modified it further, adding ORG-NEWS entry announcing the new export
> option.
>
> From 89901da3a0d00598c5ac40cddb2f6dec7c7047cf Mon Sep 17 00:00:00 2001
> Message-ID: 
> <89901da3a0d00598c5ac40cddb2f6dec7c7047cf.1735374641.git.yanta...@posteo.net>
> From: Ihor Radchenko 
> Date: Fri, 27 Dec 2024 10:21:02 +
> Subject: [PATCH v3] ox-odt: Avoid putting forbidden characters into ODT xml
>
> * lisp/ox-odt.el (org-odt-with-forbidden-chars): New export option to
> control how to handle forbidden XML characters.
> (org-odt--remove-forbidden): New filter removing/replacing forbidden
> characters.
> * etc/ORG-NEWS (ox-odt: New export option
> ~org-odt-with-forbidden-chars~): Announce the new option.
>
> Co-authored-by: Joseph Turner 
> Link: https://orgmode.org/list/87o711l4u4@christianmoe.com
> ---
>  etc/ORG-NEWS   | 16 
>  lisp/ox-odt.el | 51 +-
>  2 files changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
> index d26813c983..a56e105481 100644
> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -182,6 +182,22 @@ now be pasted as an Org table using ~yank-media~.
>  # adding new customizations, or changing the interpretation of the
>  # existing customizations.
>
> +*** ox-odt: New export option ~org-odt-with-forbidden-chars~
> +
> +The new export option controls how to deal with characters that are forbidden
> +inside ODT documents during export.
> +
> +The ODT documents must follow XML1.0 specification and cannot contain
> +certain unicode characters.  For example, form feed characters like ^L
> +are disallowed.
> +
> +By default, =ox-odt= will strip such characters and display warning.
> +You may return to the previous behaviour by setting
> +~org-odt-with-forbidden-chars~ to t.
> +
> +Note that Emacs warnings can always be suppressed by clicking on ⛔
> +symbol or by customizing ~warning-suppress-types~.
> +
>  *** New option ~org-edit-keep-region~
>
>  Since Org 9.7, structure editing commands do not deactivate region
> diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
> index ec81637ef0..960bab286a 100644
> --- a/lisp/ox-odt.el
> +++ b/lisp/ox-odt.el
> @@ -94,7 +94,8 @@ (org-export-define-backend 'odt
>   . (org-odt--translate-latex-fragments
>  org-odt--translate-description-lists
>  org-odt--translate-list-tables
> -org-odt--translate-image-links)))
> +org-odt--translate-image-links))
> +   (:filter-final-output . org-odt--remove-forbidden))
>:menu-entry
>'(?o "Export to ODT"
> ((?o "As ODT file" org-odt-export-to-odt)
> @@ -108,6 +109,7 @@ (org-export-define-backend 'odt
>  (:keywords "KEYWORDS" nil nil space)
>  (:subtitle "SUBTITLE" nil nil parse)
>  ;; Other variables.
> +(:odt-with-forbidden-chars nil nil org-odt-with-forbidden-chars)
>  (:odt-content-template-file nil nil org-odt-content-template-file)
>  (:odt-display-outline-level nil nil org-odt-display-outline-level)
>  (:odt-fontify-srcblocks nil nil org-odt-fontify-srcblocks)
> @@ -170,6 +172,14 @@ (defconst org-odt-special-string-regexps
>  ("\\.\\.\\." . "…"))  ; hellip
>"Regular expressions for special string conversion.")
>
> +(defconst org-odt-forbidden-char-re
> +  (rx (not (in ?\N{U+9} ?\N{U+A} ?\N{U+D}
> +   (?\N{U+20} . ?\N{U+D7FF})
> +   (?\N{U+E000} . ?\N{U+FFFD})
> +   (?\N{U+1} . ?\N{U+10}
> +  "Regexp matching forbidden XML1.0 characters.
> +https://www.w3.org/TR/REC-xml/#charsets";)
> +
>  (defconst org-odt-schema-dir-list
>(list (expand-file-name "./schema/" org-odt-data-dir))
>"List of directories to search for OpenDocument schema files.
> @@ -364,6 +374,19 @@ (defgroup org-export-odt nil
>:tag "Org Export ODT"
>:group 'org-export)
>
> +(defcustom org-odt-with-forbidden-chars ""
> +  "String to replace forbidden XML characters.
> +When set to t, forbidden characters are left as-is.
> +When set to nil, an error is thrown.
> +See `org-odt-forbidden-char-re' for the list of forbidden characters
> +that cannot occur inside O

Re: Form feed characters break odt export

2024-12-27 Thread Joseph Turner
Ihor Radchenko  writes:

[...]

> +(defconst org-odt-forbidden-char-re
> +  (rx (not (in ?\N{U+9} ?\N{U+A} ?\N{U+D}
> + (?\N{U+20} . ?\N{U+D7FF})
> + (?\N{U+E000} . ?\N{U+FFFD})
> + (?\N{U+1} . ?\N{U+10}

Indentation mismatch ^

> +  "Regexp matching forbidden XML1.0 characters.
> +https://www.w3.org/TR/REC-xml/#charsets";)
> +
>  (defconst org-odt-schema-dir-list
>(list (expand-file-name "./schema/" org-odt-data-dir))
>"List of directories to search for OpenDocument schema files.
> @@ -364,6 +374,19 @@ (defgroup org-export-odt nil
>:tag "Org Export ODT"
>:group 'org-export)
>
> +(defcustom org-odt-with-forbidden-chars ""
> +  "String to replace forbidden XML characters.
> +When set to t, forbidden characters are retained.
> +When set to nil, an error is thrown.
> +See `org-odt-forbidden-char-re' for the list of forbidden characters
> +that cannot occur inside ODT documents.
> +
> +You may also consider export filters to perform more fine-grained
> +replacements.  See info node `(org)Advanced Export Configuration'."
> +  :package-version '(Org . "9.8")
> +  :type '(choice (const :tag "Strip forbidden characters" t)

According to the docstring, the above tag should say "Leave forbidden
characters as-is".  See patch which slightly rewords the docstring too.

> + (const :tag "Err when forbidden characters encountered" nil)
> + (string :tag "Replacement string")))
>
>   Debugging
>
> @@ -2892,6 +2915,24 @@ (defun org-odt--encode-tabs-and-spaces (line)
> (format " " (1- (length s)
> line))
>
> +(defun org-odt--remove-forbidden (text _backend info)
> +  "Remove forbidden and discouraged characters from TEXT.
> +INFO is the communication plist"
> +  (pcase (plist-get info :odt-with-forbidden-chars)

Should we use pcase-exhaustive?

> +((and (pred stringp) rep)
> + (prog1 (replace-regexp-in-string org-odt-forbidden-char-re rep text)
> +   (when (match-string 0 text)

The replacement appears to work well on my machine, but there are
unnecessary warnings.  Run org-odt-export-to-odt on a buffer containing:

--8<---cut here---start->8---
* foo

bar
--8<---cut here---end--->8---

the (match-string 0 text) form inside org-odt--remove-forbidden evals to

"(nil)
edebug--eval-defun(# nil)
apply(edebug--eval-defun # nil)
eval-defun(nil)
funcall-interactively(eval-defun nil)
command-execute(eval-defun)


Also with the replace-regexp-in-string design, there will only be one
warning even with multiple forbidden characters.  See patch below.

> + (display-warning
> +  '(ox-odt ox-odt-with-forbidden-chars)
> +  (format "Replacing forbidden character '%s' with '%s'"
> +  (match-string 0 text) rep)
> +(`nil
> + (if (string-match org-odt-forbidden-char-re text)
> + (error "Forbidden character '%s' found.  See 
> `org-odt-with-forbidden-chars'"
> +(match-string 0 text))
> +   text))
> +(_ text)))
> +
>  (defun org-odt--encode-plain-text (text &optional no-whitespace-filling)
>(dolist (pair '(("&" . "&") ("<" . "<") (">" . ">")))
>  (setq text (replace-regexp-in-string (car pair) (cdr pair) text t t)))
> --
> 2.47.1

>From ce506caa0bffbd243a2aba384f75f7aaac7fdc4b Mon Sep 17 00:00:00 2001
From: Ihor Radchenko 
Date: Fri, 27 Dec 2024 10:21:02 +
Subject: [PATCH] ox-odt: Avoid putting forbidden characters into ODT xml

* lisp/ox-odt.el (org-odt-with-forbidden-chars): New export option to
control how to handle forbidden XML characters.
(org-odt--remove-forbidden): New filter removing/replacing forbidden
characters.

Co-authored-by: Joseph Turner 
Link: https://orgmode.org/list/87o711l4u4@christianmoe.com
---
 lisp/ox-odt.el | 51 +-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index ec81637ef..960bab286 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -94,7 +94,8 @@ (org-export-define-backend 'odt
 		. (org-odt--translate-latex-fragments
 		   org-odt--translate-description-lists
 		   org-odt--translate-list-tables
-		   org-odt--translate-image-links)))
+		   org-odt--translate-image-links))
+   (:filter-final-output . org-odt--remove-forbidden))
   :menu-entry
   '(?o "Export to ODT"
((?

Re: [PATCH] Autoload org-link-set-parameters

2025-02-02 Thread Joseph Turner
Max Nikulin  writes:

> Sorry if I confused everything. Does it mean that loading of mu4e will
> cause immediate loading of ol and so whole org? Is it acceptable to use
> `with-eval-after-load' in packages?

Thanks for bringing this up.  AFAICT, requiring mu4e already loads all
of org.  It probably shouldn't.  Perhaps we can put the mu4e-org.el
integration logic behind a minor mode.

Thank you!

Joseph



Ignore Local Variables list in source blocks

2024-12-17 Thread Joseph Turner
Hello!

Is there a way to make Emacs ignore Local Variables lists which appear
inside of source blocks?

For example, is there a way to include the following content in an Org
file without Emacs attempting to locally set foo to bar?

#+BEGIN_EXAMPLE
  # Local Variables:
  # foo: 'bar
  # End:
#+END_EXAMPLE

This issue first came up in org-srs:

https://github.com/bohonghuang/org-srs/issues/7

Thank you,

Joseph



Ignore Local Variables list in source blocks

2024-12-17 Thread Joseph Turner
Hello!

Is there a way to make Emacs ignore Local Variables lists which appear
inside of source blocks?

For example, is there a way to include the following content in an Org
file without Emacs attempting to locally set foo to bar?

#+BEGIN_EXAMPLE
  # Local Variables:
  # foo: 'bar
  # End:
#+END_EXAMPLE

This issue first came up in org-srs:

https://github.com/bohonghuang/org-srs/issues/7

Thank you,

Joseph



[PATCH] org-info-other-documents: Fix defcustom safe-local-variable property

2024-12-19 Thread Joseph Turner
Minor fix.  Thanks!

Joseph

>From 5451da0d798f104e9a0d87445c516fd89e473a38 Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Thu, 19 Dec 2024 13:16:50 -0800
Subject: [PATCH] org-info-other-documents: Fix defcustom safe-local-variable
 property

:safe should be a function.
---
 lisp/ol-info.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ol-info.el b/lisp/ol-info.el
index fa9b23b84..b4e993a0b 100644
--- a/lisp/ol-info.el
+++ b/lisp/ol-info.el
@@ -149,7 +149,7 @@ (defcustom org-info-other-documents
   :group 'org-link
   :type '(alist :key-type string :value-type string)
   :package-version '(Org . "9.7")
-  :safe t)
+  :safe #'listp)
 
 (defun org-info-map-html-url (filename)
   "Return URL or HTML file associated to Info FILENAME.
-- 
2.46.0



Re: Ignore Local Variables list in source blocks

2024-12-20 Thread Joseph Turner
Max Nikulin  writes:

[...]

>>> (info "(emacs) Specifying File Variables")
>> By the way, is there a built-in command to copy that (info ...) sexp
>> when viewing that info page?
>
> A short answer "C-0 c" or "C-0 w". Maybe I will send a longer one,
> dropping bohonghuang from Cc.

Thanks!  Very good to know about!

>>> 
>> Thanks, I just re-read that page more carefully, and I see this:
>>  If some unrelated text might look to Emacs as a local variables
>>  list, you can countermand that by inserting a form-feed character (a
>>  page delimiter, *note Pages::) after that text.  Emacs only looks for
>>  file-local variables in the last page of a file, after the last page
>>  delimiter.
>
> I do not like non-printable characters. E.g. Thunderbird rendered your
> message with confusingly large vertical space in the middle. Outside
> of Emacs, kludges like ";;; org.el ends here" are not common. I would
> not be surprised by some issues on attempt to edit the README.org file
> on the GitHub site directly.

Also good to know about.

Thanks!

Joseph



Re: Ignore Local Variables list in source blocks

2024-12-20 Thread Joseph Turner
Nikolaos Chatzikonstantinou  writes:

[...]

> If I do something like
>
> #+begin_comment
> Local Variables:
> End:
> #+end_comment
>
> #+begin_src
> Local Variables:
> foo: 40
> End:
> #+end_src
>
> Then the variable is not set, as Emacs does not look for a Local
> Variables list more than once.

Thanks!  This approach is a bit fragile, though since Emacs only looks
at the last 3000 characters for "Local Variables:".

Joseph



Re: Ignore Local Variables list in source blocks

2024-12-20 Thread Joseph Turner
Nikolaos Chatzikonstantinou  writes:

[...]

> If I do something like
>
> #+begin_comment
> Local Variables:
> End:
> #+end_comment
>
> #+begin_src
> Local Variables:
> foo: 40
> End:
> #+end_src
>
> Then the variable is not set, as Emacs does not look for a Local
> Variables list more than once.

Thanks!  This approach is a bit fragile, since Emacs only looks at the
last 3000 characters for "Local Variables:".

Joseph



Re: Form feed characters break odt export

2024-12-21 Thread Joseph Turner
Max Nikulin  writes:

> On 21/12/2024 13:52, Joseph Turner wrote:
>> Max Nikulin writes:
>>>
>>> #+begin_comment
>>> ^L
>>> #+end_comment
>
>> Thank you!  Or even simpler:
>> # ^L
>
> It was first I tried, but Emacs-28.2 demands to decide if Local
> Variables should be applied.

Oops!  You're right.  The form feed needs to be at the beginning of the line.

> You may ask Emacs developers for a *plain text* spell to stop
> processing of local variables (or to take *last* found block).

Good idea:

https://yhetil.org/emacs-devel/87ttawewpx@breatheoutbreathe.in/T/#u

> Notice that commit diff looks confusing.

Joseph



Re: Form feed characters break odt export

2024-12-20 Thread Joseph Turner
Max Nikulin  writes:

> On 21/12/2024 08:48, Joseph Turner wrote:
>> I can export the following Org content to a .odt file, but the
>> exported
>> file cannot be opened ("Read Error. Format error discovered in the file
>> in sub-document content.xml at 368,2(row,col).")
> [...]
>> First reported by bohonghuang:
>> https://github.com/bohonghuang/org-srs/pull/10#issuecomment-2557417871
>
> In this specific context a workaround should be
>
> #+begin_comment
> ^L
> #+end_comment

Thank you!  Or even simpler:

# ^L

> Or a commented out empty local variables block above.
>
> I have wrote already that I do not like non-printable characters in
> Org files.

I agree that they make Org files less portable outside Emacs, and they
complicate org-export.

> I admit that special characters either should cause `org-lint'
> warnings or should be filtered out by exporters.
>
> Specifically to ^L, there was a request to treat it as a page break by
> all exporters (I would prefer some entity or macro instead to not
> deviate from plain text markup).
>
> Marvin Gülker. Feature request: export form feed as page break. Sat,
> 21 Oct 2023 09:42:33 +0200.
> <https://list.orgmode.org/87zg0ce6yi@guelker.eu>
>
> I have not had a close look at another proposed feature, but I suspect
> that it might make filtering special characters more tricky. (I would
> be happy to hear that I am wrong.)

Yes.  Without digging into it, my gut feeling is also that handling one
non-printable character specially would open Pandora's box.

> Nathaniel Nicandro. [PATCH] ANSI color on example blocks and fixed
> width elements. Wed, 05 Apr 2023 07:03:43 -0500.
> <https://list.orgmode.org/874jpuijpc@gmail.com>

Gratefully,

Joseph



Re: [PATCH] org-info-other-documents: Fix defcustom safe-local-variable property

2024-12-22 Thread Joseph Turner
Even better.  Thank you!

Joseph

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> Minor fix.  Thanks!
>
> Thanks!
> I applied an alternative fix, addressing all the instances of the same
> problem in Org code.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f2b6478de9
>
> Canceled. (this patch)



Re: [DISCUSSION] Contributing policy for WORG

2025-01-20 Thread Joseph Turner
jman  writes:

> Joseph Turner  writes:
>
>> Thanks for the suggestion!  I imagine such a command would do this:
> (...)
>
> I am not a Worg contributor but such workflow would definitively scare me off.

Understandable :) If we added some sort of bleeding-edge peer-to-peer
way to contribute to worg, it would certainly be in addition to
tried-and-true methods like emailed patches.

> Just out of curiosity: what is wrong with a git workflow to contribute to 
> Worg?

I really like the git+email workflow.  Perhaps we could also benefit
from something like https://git-send-email.io for teaching new Emacs
users how to submit patches with Emacs.  Maybe it could simply teach
people how to use M-x report-emacs-bug or M-x package-vc-prepare-patch.

I think the biggest hurdle is setting up Emacs for email, so maybe we
need a wizard command for that.

Joseph



Re: [DISCUSSION] Contributing policy for WORG

2025-01-20 Thread Joseph Turner
Ihor Radchenko  writes:

> Hi,
>
> Corwin recently noticed that our
> https://orgmode.org/worg/worg-about.html page is not very consistent
> about whom and how should contribute to WORG.
>
> One part of that page suggests to "Create an account on Sourcehut" and
> then push changes freely, while another part suggests going through the
> mailing list.
>
> My first reflex was to make things consistent with Org code
> contributions, but I recall that Bastien had somewhat different ideas
> about WORG contributions - more in line with "free to push changes" and
> generally with a spirit of wiki pages (Bastien, correct me if I am
> making things up).
>
> Now, thinking about it, I do believe that our general goal should be
> making it easier for users to push changes to WORG - easier than
> contributing code. And these days creating an account might be easier
> for people compared to writing to a mailing list.
>
> Maybe we can simplify things even more by settings something up so that
> people can download, edit, and upload WORG pages right from Emacs. For
> example, hyperdrive might be used as an alternative to git workflow,
> especially if we can cook some kind of setup via a simple M-x 
> command. (see 
> )

Thanks for the suggestion!  I imagine such a command would do this:

- install hyperdrive.el
- download and install external gateway program with hyperdrive-install
- open worg hyperdrive.  We could use the hyperdrive I created for the
  blog post hyper://bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy/
  which is also accessible here:
  https://bpb1bq6sdfajw4bok7k9tdmrq153pbwzcyfkrqrfxw3hhihyddhy.hyper.hypha.coop/
  but I'd suggest the worg maintainers (Ihor) create a new hyperdrive that
  mirrors worg, so that the maintainers control the keys.
- Create a new hyperdrive which mirrors the maintainers' worg hyperdrive.

Then the users edit their hyperdrive and then run a second command to:

- send the URL of the user-created hyperdrive to the maintainers.  How?
  Via email?  hyperdrive.el doesn't currently have a way to "push"
  changes to someone else, only "pull", although this could be added.

For the worg use-case, where all changes need to go back to a central
hub (the worg maintainers and the central git repository), I think
hyperdrive might not help all that much.

Hyperdrive is useful for distributing content like a personal website on
a peer-to-peer network.  The hyperdrive.el Emacs interface adds things
like Org mode link handling, but it doesn't support collaboratively
editing text documents.  [ The hypercore stack does include the
https://github.com/holepunchto/autobase library for creating multiwriter
data structures, but significant effort would be required to create an
auto-merging program on top of hyperdrive.  Here's an example of the
kind of multiwriter programs which can be written with autobase:
https://github.com/hypercore-protocol/p2p-multiwriter-with-autobase ]

>From Ihor's direct email to me:

> I imagined that we can simply point users to
> 1. install hyperdrive from ELPA
> 2. M-x magic
> 3. View/edit/add WORG pages locally in Emacs
> 4.  (involving me adding user hyperdrives to sync with mine,
>where I can push upstream)
> 5. The edits appear on WORG website

Something like this might work for one-time contributions, but
subsequent contributions would require restarting the process, since
after the maintainers copy the desired changes, there's currently no way
merge the two hyperdrive histories.

Perhaps someone wants to write a CRDT designed to handle Org documents. :)

Joseph



Re: [DISCUSSION] Contributing policy for WORG

2025-01-27 Thread Joseph Turner
Bastien Guerry  writes:

> Joseph Turner  writes:
>
>>> I am not a Worg contributor but such workflow would definitively
>>> scare me off.
>>
>> Understandable :) If we added some sort of bleeding-edge peer-to-peer
>> way to contribute to worg, it would certainly be in addition to
>> tried-and-true methods like emailed patches.
>
> Between the good old patch-based contribution way and the experimental
> peer-to-peer way, there is probably yet another (complementary) way.
>
> What about gollum?
>
> https://github.com/gollum/gollum
>
> From what I understand, it would provide a way to let users modify Org
> files by editing them from a web interface (without Git knowledge), on
> top of rendering the .org files as HTML pages.

Interesting project.  Would you want to allow contributions from anyone?
Or would you need to set up auth also?  I'm not sure if contributions
automatically push master.

> Would someone try to set up a proof-of-concept?



Re: [DISCUSSION] Contributing policy for WORG

2025-01-28 Thread Joseph Turner
Bastien Guerry  writes:

> Hi Joseph,
>
> Joseph Turner  writes:
>
>>> What about gollum?
>>>
>>> https://github.com/gollum/gollum
>>>
>>> From what I understand, it would provide a way to let users modify Org
>>> files by editing them from a web interface (without Git knowledge), on
>>> top of rendering the .org files as HTML pages.
>>
>> Interesting project.  Would you want to allow contributions from anyone?
>> Or would you need to set up auth also?
>
> If someone has the time to install a test-instance Gollum, then we can
> experiment with it and see if it feels like a good way to open Worg to
> more contributions. If sensible regarding spam and security, yes, I'd
> like anyone to be able to contribute.

I think it's a worthy experiment.  Right now, I cannot volunteer to set
this up, but I'll be happy to test it out.

>> I'm not sure if contributions automatically push master.
>
> I'm not sure either, the experiment could tell.



[PATCH] Autoload org-link-set-parameters

2025-01-25 Thread Joseph Turner
>From f395c9222f900dfe6b257c0d5846b6601102dd3e Mon Sep 17 00:00:00 2001
From: Joseph Turner 
Date: Sat, 25 Jan 2025 23:19:48 -0800
Subject: [PATCH] ol: Autoload org-link-set-parameters

This change allows other packages to autoload their own link handlers.
See this mu4e issue:

https://github.com/djcb/mu/pull/2798
---
 lisp/ol.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ol.el b/lisp/ol.el
index 43fac7433..1d160ca6e 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1230,6 +1230,7 @@ (defun org-link-get-parameter (type key)
   (plist-get (cdr (assoc type org-link-parameters))
 	 key))
 
+;;;###autoload
 (defun org-link-set-parameters (type &rest parameters)
   "Set link TYPE properties to PARAMETERS.
 PARAMETERS should be keyword value pairs.  See
-- 
2.46.0


Thank you!

Joseph


Re: Form feed characters break odt export

2024-12-25 Thread Joseph Turner
Ihor Radchenko  writes:

> Christian Moe  writes:
>
>> I don't think it's specific to ODT or LibreOffice, it's the underlying
>> XML 1.0 spec that "discourages" control characters and does not include
>> #xC in the range of characters that XML processors must accept.
>>
>> Spec: https://www.w3.org/TR/REC-xml/#charsets
>>
>> Some discussion:
>> https://stackoverflow.com/questions/404107/why-are-control-characters-illegal-in-xml-1-0
>
> Thanks!
> Then, we can simply remove the disallowed characters.
> See the attached tentative patch.
>
> From 5c9fdd9df32b87be9f81e037336332984bc3b16c Mon Sep 17 00:00:00 2001
> Message-ID: 
> <5c9fdd9df32b87be9f81e037336332984bc3b16c.1735049605.git.yanta...@posteo.net>
> From: Ihor Radchenko 
> Date: Tue, 24 Dec 2024 15:11:22 +0100
> Subject: [PATCH] ox-odt: Avoid putting forbidden  characters into ODT xml
>
> * lisp/ox-odt.el (org-odt-forbidden-char-re):
> (org-odt-discouraged-char-re): New constants codifying characters that
> are prohibited in XML spec.
> (org-odt--remove-forbidden): New function removing the prohibited
> characters.
> (org-odt--encode-plain-text): Remove the prohibited characters.
> (org-odt-plain-text): Update comment.
>
> Reported-by: Joseph Turner 
> Link: https://orgmode.org/list/87o711l4u4@christianmoe.com
> ---
>  lisp/ox-odt.el | 38 +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
> index ec81637ef0..61c8d4ec75 100644
> --- a/lisp/ox-odt.el
> +++ b/lisp/ox-odt.el
> @@ -170,6 +170,28 @@ (defconst org-odt-special-string-regexps
>  ("\\.\\.\\." . "…"))  ; hellip
>"Regular expressions for special string conversion.")
>
> +(defconst org-odt-forbidden-char-re
> +  (rx (not (in ?\N{U+9} ?\N{U+A} ?\N{U+D}
> + (?\N{U+20} . ?\N{U+D7FF})
> + (?\N{U+E000} . ?\N{U+FFFD})
> + (?\N{U+1} . ?\N{U+10}
> +  "Regexp matching forbidden XML1.0 characters.
> +https://www.w3.org/TR/REC-xml/#charsets";)
> +
> +(defconst org-odt-discouraged-char-re
> +  (rx (in (?\N{U+7F} . ?\N{U+84}) (?\N{U+86} . ?\N{U+9F})
> +   (?\N{U+FDD0} . ?\N{U+FDEF}) (?\N{U+1FFFE} . ?\N{U+1})
> +  (?\N{U+2FFFE} . ?\N{U+2}) (?\N{U+3FFFE} . ?\N{U+3})
> +   (?\N{U+4FFFE} . ?\N{U+4}) (?\N{U+5FFFE} . ?\N{U+5})
> +  (?\N{U+6FFFE} . ?\N{U+6}) (?\N{U+7FFFE} . ?\N{U+7})
> +  (?\N{U+8FFFE} . ?\N{U+8}) (?\N{U+9FFFE} . ?\N{U+9})
> +   (?\N{U+AFFFE} . ?\N{U+A}) (?\N{U+BFFFE} . ?\N{U+B})
> +  (?\N{U+CFFFE} . ?\N{U+C}) (?\N{U+DFFFE} . ?\N{U+D})
> +  (?\N{U+EFFFE} . ?\N{U+E}) (?\N{U+E} . ?\N{U+F})
> +   (?\N{U+10FFFE} . ?\N{U+10})))
> +  "Regexp matching discouraged XML1.0 characters.
> +https://www.w3.org/TR/REC-xml/#charsets";)
> +
>  (defconst org-odt-schema-dir-list
>(list (expand-file-name "./schema/" org-odt-data-dir))
>"List of directories to search for OpenDocument schema files.
> @@ -2892,18 +2914,28 @@ (defun org-odt--encode-tabs-and-spaces (line)
> (format " " (1- (length s)
> line))
>
> +(defun org-odt--remove-forbidden (text)
> +  "Remove forbidden and discouraged characters from TEXT.
> +https://www.w3.org/TR/REC-xml/#charsets";
> +  (replace-regexp-in-string
> +   org-odt-forbidden-char-re ""
> +   (replace-regexp-in-string
> +org-odt-discouraged-char-re ""
> +text)))
> +
>  (defun org-odt--encode-plain-text (text &optional no-whitespace-filling)
>(dolist (pair '(("&" . "&") ("<" . "<") (">" . ">")))
>  (setq text (replace-regexp-in-string (car pair) (cdr pair) text t t)))
> -  (if no-whitespace-filling text
> -(org-odt--encode-tabs-and-spaces text)))
> +  (org-odt--remove-forbidden
> +   (if no-whitespace-filling text
> + (org-odt--encode-tabs-and-spaces text
>
>  (defun org-odt-plain-text (text info)
>"Transcode a TEXT string from Org to ODT.
>  TEXT is the string to transcode.  INFO is a plist holding
>  contextual information."
>(let ((output text))
> -;; Protect &, < and >.
> +;; Protect &, < and >, and remove forbidden characters.
>  (setq output (org-odt--encode-plain-text output t))
>  ;; Handle smart quotes.  Be sure to provide original string since
>  ;; OUTPUT may have been modified.
> --
> 2.47.1

Thanks, Ihor!  Tested working on my machine.

Here's another potential solution to consider, which adds a defcustom to
let the user decide how to handle forbidden characters:

https://github.com/kjambunathan/org-mode-ox-odt/commit/07fde1e9b7cdda3e3ef8136f5b1d478499dfd780

Joseph



Re: Form feed characters break odt export

2024-12-25 Thread Joseph Turner
Max Nikulin  writes:

> On 21/12/2024 10:56, Max Nikulin wrote:
>> On 21/12/2024 08:48, Joseph Turner wrote:
>>> https://github.com/bohonghuang/org-srs/pull/10#issuecomment-2557417871
>> In this specific context a workaround should be
>> #+begin_comment
>> ^L
>> #+end_comment
>
> To avoid confusion of other contributors it should be more verbose:
>
> #+begin_comment
>   Keep this block at the bottom of the file.
>   It instructs Emacs to ignore examples
>   of local variables sections above, see
>   
>   The following line contains the form feed 0x0c character.
> ^L
> #+end_comment

Thank you, Max.  Submitted PR:

https://github.com/bohonghuang/org-srs/pull/12

Joseph



Re: [PATCH] Autoload org-link-set-parameters

2025-02-23 Thread Joseph Turner
Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> This change allows other packages to autoload their own link handlers.
>> See this mu4e issue:
>>
>> https://github.com/djcb/mu/pull/2798
>
>> +;;;###autoload
>>  (defun org-link-set-parameters (type &rest parameters)
>>"Set link TYPE properties to PARAMETERS.
>>  PARAMETERS should be keyword value pairs.  See
>
> Even though it would be useful to do such autoload, I cannot allow it.
> This will unfortunately lead to annoying bugs we face every single major
> Org release - mixing multiple Org versions.
>
> Because Elisp does not have a robust versioning of libraries, the
> version of ol.el that will be used as a source of for
> `org-link-set-parameters' will depend on the loading order of org
> vs. mu4e in the user init. If mu4e is loaded early, running
> `org-link-set-parameters' will trigger an autoload cookie for built-in
> Org mode. Later, when packaged Org mode is loaded, things will get crazy
> because of mixing multiple library versions and half-initialized variables.
>
> Canceled.
>
> Also, https://github.com/djcb/mu/pull/2798 will not work if Org is not
> yet loaded when `package-initialize' is called.

Thank you for the explanation!

Joseph