Re: [TASK] Allow customizeable ditaa executable in ob-ditaa.el

[Leo Butler]

On Sat, Oct 21 2023, Ihor Radchenko  wrote:

> "Dr. Arne Babenhauserheide"  writes:
>
 In my current source I see [...]

 (use C-h v org-babel-ditaa-java-cmd to see the value of the java
 executable — you can then customize this to use a different command)
>>>
>>> As far as I understand that part of code it still kind-of assumes that
>>> I'm using a command line of type "java -jar ditaa.jar ...", just with
>>> more flexibility in choosing which "java" command I'm using, right?
>>
>> Yes, it does. ob-plantuml already migrated to allow a regular command,
>> but ob-ditaa still only enables using the jar directly.
>>
>> That is something which would be nice to fix — and ob-plantuml should
>> show the path forward.
>
> +1
> This is a relatively simple task.
> One can indeed use ob-plantuml as a reference to extend ob-ditaa.
> Patches welcome!

While I was reviewing the documentation, ob-doc-ditaa.org, and the
source, ob-ditaa.el, I realized that there is a simple way to run a
script file instead of a jar file. The documentation patch includes such
an example.

Leo

From 6424527dde6e487ce55dddae1260df3d84c2775e Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Thu, 26 Oct 2023 20:49:41 -0500
Subject: [PATCH] * org-contrib/babel/languages/ob-doc-ditaa.org: update
 documentation

* org-contrib/babel/languages/ob-doc-ditaa.org: Add a subsection that
documents the four DEFCUSTOM variables.  Modify the existing examples
so that the org code that is exported also creates the code-blocks
that are executed.  Add a subsection that documents how to use those
customization variables in order to run ditaa from a script, not
necessarily as a jar file.

* org-contrib/babel/languages/images/hello-world-from-script.png:
This is a new file created by the new example.

Ref: https://list.orgmode.org/ZTEML8zWrB6kQflk@toolbox/T/
---
 .../images/hello-world-from-script.png| Bin 0 -> 3314 bytes
 org-contrib/babel/languages/ob-doc-ditaa.org  |  86 --
 2 files changed, 77 insertions(+), 9 deletions(-)
 create mode 100644 org-contrib/babel/languages/images/hello-world-from-script.png

diff --git a/org-contrib/babel/languages/images/hello-world-from-script.png b/org-contrib/babel/languages/images/hello-world-from-script.png
new file mode 100644
index ..8a039e1bad997ebd31d8906cc1d1f234e9159e09
GIT binary patch
literal 3314
zcmchacQjn<8pcV8kQk!(8ex#lXzy7#|(_gZ`J_5HEm_xslOd!FyviDo7S%uIYtG
zMuxg@;Qbl6Q!btZo|w00qBJy@-x=vbET14Y3*C)5iNbLVb~e)IxEefsds>|opv_k9
zPE8Q{37)&3Qy<^oFLUp*Bu9@QK)ld=%yQFiy31UTQ#eu$Q!31msn~>zST1r@!fNBf
zS-z@s3&>ZV?cgZ}RmAdjI9I7l>BXY|Xo3G0go9r+tK_@P#ltZ(sF+|g+?ss{Qi9f1
zlaj~;L5<3y;cRQg|BqoQJ+2+OtZ!*)iT9r8a16+BUg6^*rj@}6(K
zDI)_*Hcnw`OtBMR9!L{>N~P3Hd(>1^R8&?@JRVnRsviO4`W?6T_f3tBrySXoB2uV_
zht7{4X+>mZWi>W7mZM(Ndzyfq939JzbFuVSzlw^9iK(fnNlLydF8(r-ue`dt8luV<
z$yK9@O98I*bmBR-T~=;xZa%({{U7ri8=g-R4N%U`xCIthxA8m+LU(sJ1B;LwZ6Ycn
z?Lk}69U~)%sIoF1m=a?&?pGP|>8lctE-k(GvAtBe%mmNWybG`8_ySuwE7;G<0
zMJIWt0N#YW*qp+E-dsFcPVX+Ii>Pzq_;Zla5GTx-4hw4}C4wJf84Ti;^yM
zJLL5EkW3C3mQ7Ah21=Cvj<%jqMukh^av>BJVT}R|29uMMlbvm4V^gu;%iCPil-2nM
zRR=tBxlveHxF{ndBQGy6H`l$vhWzhe3#!q98)hQWb%>4$>Qc&_nXS>{%1H^@B@Tdr
z74A{QWDea~`p=N`PQl;0Pkt>;*QmUIdNygc<>26OU|v>M_T7|+FWOM`$m$@clLSJTxsWZEbCBe}6y8m;8M^skKT^zF~Yy3z`JPX``$xcb74vi7PdiPF+uSqUvT2k@;8AbFL*uk5Xh`jEo=
zq?ntF%f;1o*>_{MA#J%>-p9x1SUuqT*zBy0xp+ujb@j${6*u4hpG0{Dg?a!oCY>_Tk~-
z=z`bQ^QMeG2t4advX1N
zHtsvern%Bnis!9?ljGyDOt)o`wDaJ80%N9(Wj(0`eE~gTy=(5MrA3n?V
zWpE?jk>_w`2gkdkdL8=r??%shb3TAESL=;xhX3b`oK(`Ej!gb3alBUW&u~*D}9OVN9-T8Wj}1qw@HGwKEEri
z2*0~DZ(SoKZg@B(-<4p>9Er!{@0`Tw;h6_|;tBzsU{kxg!U4}D*4zQ#ek-!u~_onY^XlU?cyN={JH`oL)|L!@<%E}r+T?1H16IA!~AS$^GcT2S3
z8=M9-LXW1b7X{ZfikMhf25zkYWc`@H!R+h=q|*gdqeMu~((B*s9nTE9!cLkNQX{XF
z9RsS%P}Mt`(?8xn@mlxnMb)Xh;YPEKat8+3bsq4XcKY|%EzIgMlWC?lSMKg_0PVTo_1
z*I9^R$#Evo2$$#A?o5DEBOP!}XF_$E{6RnK^*b=#ORna32`ej)EVUh{(uFlUYtb~~
zV#R)BO^I?ZTFs=C~iAz?)u{mD9pMgu{;`FD{1e7uINi6^**ZOx1t8P@d5U)GC1T
zva?4M0A^60t5Rmv*BZ0La7wa^esu#mu~*h0XRwe){(h>Fm%KR
zn^-7em>o3zC$X-1-ZZX<13t%xcNln$W@KcnAd|_LnVC1IUb9<|5xcEo?3=Mbh5^
z)MNWz)R@{=D=ZsO@6qFL?^#gwG(Hg5*QhTWF!$Cg|M~OiBLH4fy=jrg@`u#6u#+Re
z*nQMUqg6;or+%zowuD9uNad{0w*@bDg`Y*yUkZRKc+n=jyXK>I^@zG3>lS_X=!WQU!T6jg2XT__xAQa
zF6B8FZRoBbA`#~hTH{`fz5x#wxXFoz>q|-CuKN8`>F6v&2He$&|2`CbjRwxs>7bHC
zR7G`l01}yL4waXe-yXW&=gGmr0d&?O#Kh1U=H}*tlhKipk)%aYaQ%DR6y#
z{SN~JkAYk>+vq%$A*z!RYM7gs#{`z+O8#f|0mw-_i-^S}dF;s}_4M=vHJ+&`Dk{p!
z$;rr6)z_PC#Va*MjDRH;1OW18!qhV{F}ED|{5cfXCkdiBcH)fI?Wf1dcp
zan-Bh=p;=Fer|7nY;vFM%{xOB@nrAp>{Q*YyMC{+Z*tPVKZz5GL;@@ro0tH;8iYVB
ze8T(e`2i8?^DrC;Jis>S>FPclv`iS^rcgkPjE9HcikzIBHZ@rYqoeVRA*u!Aa5!n+
z!qO6*pZ^rFCp4Pl^XfKmSOF#i{weCHn{jW2`<{MnCUQmaWBhpqh9a{_66+eg;g^~szBQ;J5b;+B>#FG0d}SYBS5;M2US3{h
zpM_%}eOOpn)Ljve8vfT8VeD~#taD{IR#sM4S67#n(Iszl%Ok$%ziDi|VI{=oBs!6F
zEH*TF^F~^`IMr9HPEXto0mywpPww8%Qw)-gbc5ily>C@%vg=PNA%mxejE{_6X
qFe5|u|7~zz&&*;q`m06S8LeG+hGOd>J{tI!p)t}k(XG{f81;7r

literal 0
HcmV?d1

diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Hi,

Hi Ihor,

> A few months have passed since the last activity in this thread.
> May I know if you are still interested in the idea?

I apologize for being unresponsive all these months. Yes I'm still
interested in this idea, although I have not had time to work on it
recently.  Life events caused me to have to stop working on it
completely a few months back, I'm hoping to be able to put in more time
now.

I haven't even been able to put that much time into my more popular
personal projects recently either!

> Should you need any help, feel free to ask.

I have been working on some code to satisfy the set of rules you
provided in a previous email of this thread.  I've made some progress,
but the code is a little messy and buggy.  I would like to clean it up
first before I present it.

Where I'm having some trouble is processing the contents of greater
elements.  My approach for them is basically to define an ansi-context
(see `ansi-color-context-region`) for each greater element and process
the inner elements using that context.  This seems to work except for
plain-list elements which can have other plain-list elements within
them, e.g.

#+RESULTS:
- List item 1
  - Sub-list item 1
- List item 2
- List item 3

Should the sub-list's sequence affect the rest of list elements in the
parent list?  If that's the case, then I think I can keep with my
approach and define an ansi-context for the outermost plain-list which
is used by all the other plain-list elements contained within
it. Otherwise I think I would have to do something like copy the
ansi-context for each inner plain-list and use the copy to process the
sequences in the inner-list so that the context of the outer-list is
unaffected. WDYT?

-- 
Nathaniel

Re: Issue with org-persist and Tramp

[Fabio Natali]

On 2023-11-08, 18:01 +, Ihor Radchenko  wrote:
> I see the problem now.
> Does the attached patch solve the "freeze"?

Hey, thanks for sending this, really appreciate it.

Unfortunately that didn't seem to fix it though. Here's what I did.

- Added `(not (file-remote-p associated))' to the right place
- Revaluated the function `org-persist--normalize-associated'
- Tried to close the stale buffer (without repeating the entire
  workflow, just trying with the buffer from the previous test)

Result: the problem is still there, same backtrace.

If anything else comes to mind, happy to test it.

Cheers, Fabio.

Re: bash source code block: problem after ssh commands

[Matt]

  On Tue, 07 Nov 2023 09:53:46 +0100  Ihor Radchenko  wrote --- 
 > Matt m...@excalamus.com> writes:
 > 
 > >   On Mon, 06 Nov 2023 14:32:16 +0100  Ihor Radchenko  wrote --- 
 > >  > I am wondering about the possible downsides of using script approach
 > >  > instead of stdin redirection.
 > >  
 > > I'm curious to hear more about what you're thinking.
 > 
 > I am thinking to change the
 >   (t (org-babel-eval shell-file-name (org-trim body)))
 > clause in `org-babel-sh-evaluate' to something that uses a script file.
 > 
 > It will clearly solve the discussed problem, possibly at the cost of
 > small overhead to write the script file to disk.
 
Thanks for clarifying.  I've been away from the codebase for a bit and, now 
that the FSF paperwork is signed (still need to get Craig a copy), I'm 
reviewing =ob-shell= with an eye for what could be cleaned or improved.   I 
feel like =org-babel-sh-evaluate= could use some attention.

I'm open to your suggestion.  The good is that using a script is how :shebang 
and :cmdline are processed currently (like you pointed out) so there's 
precedence and experience with it.  Also, it would make all non-session 
execution use the same model (script versus comint).  I like how that would 
create a clean separation.

For bad, nothing jumps out to me as obviously a problem.  Let me "think out 
loud" for a moment.  We'd need to write to disk.  Like you say, this incurs 
overhead opening, writing, and closing the file.  It's not like we'd forget to 
close it, though.  Nor is running out of space or inodes our problem.  Writing 
requires permission.  That's not an issue with /tmp.  Then, it needs to 
execute.  Aside from permission, any code we insert needs to be correct.  For 
example, a shebang would need to point to the correct application and any 
arguments would need to correspond to the implementation being called.  I doubt 
we'd need anything beyond /bin/.   FWIW, it looks like there's been at 
least one instance where :shebang's formatting was questioned 
(https://yhetil.org/orgmode/ca+a2izz1vmmkiuf4fem1au7ca1m9gqap+bkvrosz+0bxrt6...@mail.gmail.com/).
  We'd also need to control for what environment the script runs in.  That was 
another issue I saw raised in the list 
(https://yhetil.org/orgmode/87609ug5ae@luisa.c0t0d0s0.de/).  Of course, 
we'd need to read the stdout and stderr.  This is handled by =process-file=.  
Any step I missed or some kind of failure I didn't consider?

Re: Issue with org-persist and Tramp

[Ihor Radchenko]

Fabio Natali  writes:

> Thanks for your email. Sure, glad to share the backtrace with you.
> ...
>   tramp-file-name-handler(file-attributes 
> "/ssh::/home/user/test.org")
>   org-persist--normalize-associated(#)

I see the problem now.
Does the attached patch solve the "freeze"?

>From ac571f9654ef5de8cef7157e216beeb0b91f6125 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Wed, 8 Nov 2023 19:58:42 +0200
Subject: [PATCH] org-persist--normalize-associated: Avoid TRAMP connection for
 remote files

* lisp/org-persist.el (org-persist--normalize-associated): Never try
to store inode association for remote TRAMP files.

Reported-by: Fabio Natali 
Link: https://orgmode.org/list/87jzqthdge@fabionatali.com
---
 lisp/org-persist.el | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lisp/org-persist.el b/lisp/org-persist.el
index 01078f459..f97e1d7a4 100644
--- a/lisp/org-persist.el
+++ b/lisp/org-persist.el
@@ -481,9 +481,14 @@ (defun org-persist--normalize-associated (associated)
  (unless (stringp associated)
(setq associated (cadr associated)))
  (let* ((rtn `(:file ,associated))
-(inode (and (fboundp 'file-attribute-inode-number)
-(file-attribute-inode-number
- (file-attributes associated)
+(inode (and
+;; Do not store :inode for remote files - it may
+;; be time-consuming on slow connections or even
+;; fail completely when ssh connection is closed.
+(not (file-remote-p associated))
+(fboundp 'file-attribute-inode-number)
+(file-attribute-inode-number
+ (file-attributes associated)
(when inode (plist-put rtn :inode inode))
rtn))
 ((or (pred bufferp) `(:buffer ,_))
-- 
2.42.0


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

Re: Issue with org-persist and Tramp

[Fabio Natali]

On 2023-11-08, 09:25 +, Ihor Radchenko  wrote:
> May you please share the backtrace?
> In particular, may you (1) M-x toggle-debug-on-quit (2) try to close the
> problematic file; observe Emacs "freeze" (3) C-g and post the obtained
> backtrace.

Hi Ihor,

Thanks for your email. Sure, glad to share the backtrace with you.

This is how the issue can be reproduced on my system.

- Enable debug, `toggle-debug-on-quit'
- Open a remote file, `(find-file "/ssh::~/test.org")'
- Bring the remote machine offline
- Try to close the remote file, `kill-buffer'
- The system hangs for a while as it tries to reach the remote machine
- Quitting (`keyboard-quit') produces the following backtrace

#+begin_export ascii
Debugger entered--Lisp error: (quit "")
  signal(quit (""))
  tramp-error(nil quit "")
  tramp-signal-hook-function(quit (""))
  signal(quit (""))
  tramp-maybe-open-connection((tramp-file-name "ssh" nil nil "" 
nil "/home/user/test.org" nil))
  tramp-send-command((tramp-file-name "ssh" nil nil "" nil 
"/home/user/test.org" nil) "echo \\\"`getconf PATH 2>/dev/null`\\\" 
2>/dev/null; e...")
  tramp-send-command-and-check((tramp-file-name "ssh" nil nil 
"" nil "/home/user/test.org" nil) "echo \\\"`getconf PATH 
2>/dev/null`\\\"")
  tramp-send-command-and-read((tramp-file-name "ssh" nil nil "" 
nil "/home/user/test.org" nil) "echo \\\"`getconf PATH 2>/dev/null`\\\"" 
noerror)
  tramp-get-remote-path((tramp-file-name "ssh" nil nil "" nil 
"/home/user/test.org" nil))
  tramp-get-remote-stat((tramp-file-name "ssh" nil nil "" nil 
"/home/user/test.org" nil))
  tramp-sh-handle-file-attributes("/ssh::/home/user/test.org")
  tramp-sh-file-name-handler(file-attributes 
"/ssh::/home/user/test.org")
  apply(tramp-sh-file-name-handler file-attributes 
"/ssh::/home/user/test.org")
  tramp-file-name-handler(file-attributes 
"/ssh::/home/user/test.org")
  org-persist--normalize-associated(#)
  org-persist-write-all(#)
  org-persist-write-all-buffer()
  kill-buffer("test.org")
  funcall-interactively(kill-buffer "test.org")
  command-execute(kill-buffer)
#+end_export

Glad to share other info if helpful.

Thanks, cheers, Fabio.

Re: [FR] STARTUP: hidechecked

[Fraga, Eric]

Although org doesn't have the feature you are asking for, I have the
following in my configuration that you may find useful:

#+begin_src emacs-lisp
  (font-lock-add-keywords
   'org-mode
   `(("^[ \t]*\\(?:[-+*]\\|[0-9]+[).]\\)[ 
\t]+\\(\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ 
\t]*\\)?\\[\\(?:X\\|\\([0-9]+\\)/\\2\\)\\][^\n]*\n\\)" 1 'org-headline-done 
prepend))
   'append)
#+end_src

-- 
: Eric S Fraga, with org release_9.6.6-418-g294a4d in Emacs 30.0.50

Re: [FR] STARTUP: hidechecked

[Ihor Radchenko]

Russell Adams  writes:

>> It'd be nice if there was an option to automatically fold list items
>> that are checked on startup, e.g.
>
> The behavior you describe works with headings. Plain lists don't have
> as many features.

AFAIK, not even for headings - that would be an equivalent of "hide all
the done headings on startup".

IMHO, this kind of feature is a bit too specific. Users are free to add
things to `org-mode-hook', achieving the desired effect.

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

Re: [FR] STARTUP: hidechecked

[Russell Adams]

On Wed, Nov 08, 2023 at 03:25:33PM +0100, unham...@fsfe.org wrote:
> Hi,
>
> It'd be nice if there was an option to automatically fold list items
> that are checked on startup, e.g.

The behavior you describe works with headings. Plain lists don't have
as many features.

Thanks.

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

[FR] STARTUP: hidechecked

[unhammer]

Hi,

It'd be nice if there was an option to automatically fold list items
that are checked on startup, e.g.

- [ ] open
I want to see the details here
- [X] closed
I don't want to see these details

would be shown on opening the file as

#+STARTUP: hidechecked

- [ ] open
I want to see the details here
- [X] closed...


(I didn't manage to find any previous discussion of this,
https://list.orgmode.org/ always gives ~800 unrelated hits when I try
searching, sorry if it's already been discussed.)


best regards,
Kevin

Re: [ELPA] New package: ob-asymptote.el

[Bastien Guerry]

Ihor Radchenko  writes:

>> It should be available within 24-48 hours at:
>>
>> https://elpa.gnu.org/packages/ob-asymptote.html

Good news, thanks!

> I am thus removing ob-asymptote from org-contrib.
> https://git.sr.ht/~bzg/org-contrib/commit/a56fb90b1696bb015abfbb04df08a1ebc589d686

Thanks.

-- 
 Bastien Guerry

Re: [RFC][PATCH v2] Allow to export to ascii custom link types as notes

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/11/2023 17:45, Ihor Radchenko wrote:
>> (unless (org-element-property :org-link-code-exported link)
>>   (setq link (org-element-copy link))
>>   (org-element-put-property link :org-link-code-exported t)
>>   (org-element-put-property :raw-link (org-element-create-inline-src-block 
>> ...)))
>
>  From my point of view a non-trivial element as :raw-link is a more ugly 
> kludge than returning a `cons'. Perhaps a fragment of plain text with 
> e.g. attr_ascii_note attribute set to inline source block is a better 
> alternative.

I think that a middle ground could be introducing pseudo objects, like
what we do in ox-latex: See latex-math-block, latex-matrices,
`org-latex-math-block-tree-filter', `org-latex-matrices-tree-filter',
and the corresponding transcoders.

We can introduce a special ox-ascii-specific object `object-with-note'
that will be exported by ox-ascii according to
`org-ascii-links-to-notes' settings. Then, we can transform link objects
into `object-with-note' that will later be used in
`org-ascii--describe-links'.

WDYT?

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

Re: [RFC][PATCH v2] Allow to export to ascii custom link types as notes

[Max Nikulin]

On 08/11/2023 17:45, Ihor Radchenko wrote:

(unless (org-element-property :org-link-code-exported link)
  (setq link (org-element-copy link))
  (org-element-put-property link :org-link-code-exported t)
  (org-element-put-property :raw-link (org-element-create-inline-src-block 
...)))


From my point of view a non-trivial element as :raw-link is a more ugly 
kludge than returning a `cons'. Perhaps a fragment of plain text with 
e.g. attr_ascii_note attribute set to inline source block is a better 
alternative.

Re: Exporting Hyperlinks ?

[Max Nikulin]

On 08/11/2023 16:37, Ihor Radchenko wrote:

Max Nikulin writes:


It would be nice to have a LaTeX package that redefines \label to
generated \hypertarget from its argument.


Can't we simply generate a pair of \label + \hypertarget when generating
.tex files in ox-latex? This way, we can make sure that labels in
Org-generated pdfs will be linkable from outside world.


I still have a hope that somebody can point us how to leverage hyperref 
facilities. Adding \hypertarget is a step forward, but ideally internal 
links generated by \ref, links in table of contents, PDF bookmarks 
(table of contents side bar) should consistently use #custom_id anchors 
as well. Usual #section.5 should be a fallback for cases with no user 
supplied labels.



I think that generating \hypertarget + converting .org file links to
.pdf links will already be a good improvement.

Using xr-hyper requires knowledge of external files we link to and thus
can only be used during publishing, where we have all the information
about multiple exported Org documents available.


I agree that some complications exist. Just like with HTML files for Org 
ones with  links. Several iterations of tex 
files compilation are required. .aux files for all .tex files must be 
available to get cross-file links working.

Re: [RFC][PATCH v2] Allow to export to ascii custom link types as notes

[Ihor Radchenko]

Max Nikulin  writes:

>> We can alternatively check function arity.
>
> 5 unnamed arguments for functions that are supposed to be implemented by 
> users looks rather close to a border when it becomes fragile. The 
> language does not enforce type checking for user-supplied functions and 
> users would not bother as well. Multi-argument functions was a painful 
> experience with FORTRAN for me (fortunately I was not deeply involved).

Makes sense.

>>> Do you mean something like the following?
>>>
>>> (defun org-man-export (link description backend)
>>> "Export a man page LINK with DESCRIPTION.
>>> BACKEND is the current export backend."
>>> (org-element-create-link
>>>  (format "http://man.he.net/?topic=%s=all; link)
>>>  description))
>> 
>> Yes.
>
> It is nice idea for most backends, but it is unclear for me what the 
> following function should return for ox-ascii
>
> Ihor Radchenko. Re: Exporting elisp: and shell: links. Sun, 08 Oct 2023 
> 09:48:07 +.
> https://list.orgmode.org/87r0m5phrc.fsf@localhost
>> +(defun org-link--export-code (path description _ info  lang)
>> +  "Export executable link with PATH and DESCRIPTION.
>> +INFO is the current export info plist.
>> +LANG is the language name, as in #+begin_src lang.  For example, \"elisp\"
>> +or \"shell\"."
>> +  (concat
>> +   (org-export-data
>> +(org-element-create
>> + 'inline-src-block
>> + `( :language ,lang
>> +:value ,path
>> +:parameters ":exports code :noweb no :eval never"))
>> +info)
>> +   (when description (format " (%s)" description
>
> Source code should be exported inline or as a note depending on 
> preferences. This case exported element is not a link, so description 
> should be treated separately.

In this scenario, :filter function may transform :raw-path in the link
object, replacing it with
(org-export-data (org-element-create-inline-src-block ...) info).

Or we may arrange ox-ascii to export :raw-link object

(format "[%s] <%s>" anchor (org-export-data (org-element-property :raw-link 
link) info))

Then, I imagine `org-link--export-code' to do something like

(unless (org-element-property :org-link-code-exported link)
 (setq link (org-element-copy link))
 (org-element-put-property link :org-link-code-exported t)
 (org-element-put-property :raw-link (org-element-create-inline-src-block ...)))

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

Re: Exporting Hyperlinks ?

[Max Nikulin]

On 08/11/2023 15:02, David Masterson wrote:

Max Nikulin writes:


On 07/11/2023 19:36, Ihor Radchenko wrote:

If \href{file.pdf#anchor} can work, we should indeed use it when
publishing org->pdf.


It would be nice to have a LaTeX package that redefines \label to
generated \hypertarget from its argument.


This would make it easy to create a PDF "website" that doesn't depend on
a webserver like HTML.  A PDF website could easily be put on a USB key
to take with you and access via a mobile phone.  This would be secure
because no network interaction.  This is the use case I've been working
toward for years.


I do not see clear advantages over a set of HTML files with relative 
links relative links. I am 
unsure concerning permissions to open sibling files for mobile 
applications (both HTML and PDF ones).


I expect that LaTeX still has issues with generation of PDF files 
suitable for reflow. With proper CSS styles, HTML are are more flexible 
in respect to adapting for particular screen size. ePUB is an HTML-based 
format, but links to other files may be prohibited.



Ideally, xr-hyper workflow should be supported as well. A downside is
anchors are not stable and unrelated to labels.


Stable in the sense that the CUSTOM_ID could be moved to new file?
Could IDs play a roll here?


No, I have in mind another case. LaTeX generates anchors like 
#section.6. If you insert another section, this one becomes #section.7. 
So all files having doc.pdf#section.6 links must be regenerated. Links 
based on CUSTOM_ID doc.pdf#export_note continue working even after 
rearranging structure of the target file. This is especially painful if 
target file is out of your control.


I consider the following link as a stable one:
https://www.gnu.org/software/grub/manual/grub/grub.pdf#true

When a heading with ID is moved to another file then anyway all files 
referencing it must be regenerated.

Re: [RFC][PATCH v2] Allow to export to ascii custom link types as notes

[Max Nikulin]

On 07/11/2023 18:58, Ihor Radchenko wrote:

Max Nikulin writes:


(funcall protocol path desc backend info *link-object*)


It would require another iteration with `condition-case' to deal with
functions having old signature.


Is it a problem?


Performance for large projects like Worg.


We can alternatively check function arity.


5 unnamed arguments for functions that are supposed to be implemented by 
users looks rather close to a border when it becomes fragile. The 
language does not enforce type checking for user-supplied functions and 
users would not bother as well. Multi-argument functions was a painful 
experience with FORTRAN for me (fortunately I was not deeply involved).



Earlier you considered :filter property that receives link object
instead of path and desc pair. I am unsure concerning name, but I like
that idea.


I feel that :filter + :export will be rather redundant - they will do
the same thing and only differ by calling convention. And we will have
issues with priority of :filter vs. :export if both happen to be
present (e.g. when a user defines a custom :export in personal config).


Fair point. :export should have precedence to not break user 
customization. Those who define :filter should set :export to nil. It is 
not perfect, but the extra argument is worse from my point of view.



Then, if the :export function returns non-string, the return value is
further processed as (org-export-data *return-value* info).


Do you mean something like the following?

(defun org-man-export (link description backend)
"Export a man page LINK with DESCRIPTION.
BACKEND is the current export backend."
(org-element-create-link
 (format "http://man.he.net/?topic=%s=all; link)
 description))


Yes.


It is nice idea for most backends, but it is unclear for me what the 
following function should return for ox-ascii


Ihor Radchenko. Re: Exporting elisp: and shell: links. Sun, 08 Oct 2023 
09:48:07 +.

https://list.orgmode.org/87r0m5phrc.fsf@localhost

+(defun org-link--export-code (path description _ info  lang)
+  "Export executable link with PATH and DESCRIPTION.
+INFO is the current export info plist.
+LANG is the language name, as in #+begin_src lang.  For example, \"elisp\"
+or \"shell\"."
+  (concat
+   (org-export-data
+(org-element-create
+ 'inline-src-block
+ `( :language ,lang
+:value ,path
+:parameters ":exports code :noweb no :eval never"))
+info)
+   (when description (format " (%s)" description


Source code should be exported inline or as a note depending on 
preferences. This case exported element is not a link, so description 
should be treated separately.

Re: [ELPA] New package: ob-asymptote.el

[Ihor Radchenko]

Stefan Kangas  writes:

> Ihor Radchenko  writes:
>
>> Stefan, may I know if there is anything else blocking the addition?
>
> AFAICT, nothing is blocking it, so I've added it to GNU ELPA.
>
> It should be available within 24-48 hours at:
>
> https://elpa.gnu.org/packages/ob-asymptote.html

I am thus removing ob-asymptote from org-contrib.
https://git.sr.ht/~bzg/org-contrib/commit/a56fb90b1696bb015abfbb04df08a1ebc589d686

CCing Bastien and Org mailing list as this update might be of interest.

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

Re: [PATCH] testing: Delete duplicate tests

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ilya Chernyshov  writes:
>
>> Thank you! If a function that checks for duplicate tests is a welcome
>> addition to org tests, I'll send is as a patch. What do you think?
>
> It would be great. Thanks in advance!

I saw you using your function to detect the existing duplicate tests.
However, it would also be nice to add it as a test of its own to detect
duplicates in future. WDYT?

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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Ihor Radchenko  writes:

> A few months have passed since the last activity in this thread.

Canceled.

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

Re: Exporting Hyperlinks ?

[Ihor Radchenko]

Max Nikulin  writes:

>> If \href{file.pdf#anchor} can work, we should indeed use it when
>> publishing org->pdf.
>
> It would be nice to have a LaTeX package that redefines \label to 
> generated \hypertarget from its argument.

Can't we simply generate a pair of \label + \hypertarget when generating
.tex files in ox-latex? This way, we can make sure that labels in
Org-generated pdfs will be linkable from outside world.

> Ideally, xr-hyper workflow should be supported as well. A downside is 
> anchors are not stable and unrelated to labels.

I think that generating \hypertarget + converting .org file links to
.pdf links will already be a good improvement.

Using xr-hyper requires knowledge of external files we link to and thus
can only be used during publishing, where we have all the information
about multiple exported Org documents available.

> P.S. (info "(org) Publishing")
> declares that conversion to PDF is supported.

It is indeed supported. But not with all the features HTML export
provides. Cross-references is one of the missing features in PDF
publishing.

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

Re: Issue with org-persist and Tramp

[Ihor Radchenko]

Fabio Natali  writes:

> I seem to be having an issue with org-persist and Tramp which is close
> to what discussed in this thread:
>
> https://lists.gnu.org/archive/html//emacs-orgmode/2022-05/msg00720.html

After that thread, Org should not (by default) examine remote files.

> - I open a Org file on a remote machine, via Tramp.
> - The SSH connection dies.
> - I try to kill the stale buffer with kill-buffer and from IBuffer.
> - The buffer is not killed, instead Emacs hangs for a while while still
>   trying to connect to the old SSH connection.
> - The buffer becomes sentient and gains immortality... either that or I
>   restart Emacs, which is clearly a big no-no. :D
>
> Looking at the backtrace, it looks like the kill operation insists on
> calling org-persist-write-all-buffer, which in turn seems to be calling
> Tramp and therefore SSH to the now unreachable machine.

May you please share the backtrace?
In particular, may you (1) M-x toggle-debug-on-quit (2) try to close the
problematic file; observe Emacs "freeze" (3) C-g and post the obtained
backtrace.

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

Re: Issue with org-persist and Tramp

[Fabio Natali]

On 2023-11-07, 22:08 +0100, Antonio Carlos Padoan Junior 
 wrote:
> My workaround is to save the buffer locally (perhaps in /tmp). This
> action releases the buffer.

Hi Antonio,

Thanks for getting back to me.

Unfortunately your work-around doesn't seem to work in my case. Just to
make sure I'm not missing anything, when you say you save the buffer
locally, you mean with `write-file' (C-x C-w), right?

If I use `write-file', the system lags for a while, then it prompts me
to insert a file name. Whatever path I insert, Emacs will try to use the
old SSH connection and therefore freeze. If I `keyboard-quit' (C-g), the
system "unfreezes" but the file won't be saved.

Thanks, best wishes, Fabio.

Re: Exporting Hyperlinks ?

[David Masterson]

Max Nikulin  writes:

> On 07/11/2023 19:36, Ihor Radchenko wrote:
>> If \href{file.pdf#anchor} can work, we should indeed use it when
>> publishing org->pdf.
>
> It would be nice to have a LaTeX package that redefines \label to
> generated \hypertarget from its argument.

This would make it easy to create a PDF "website" that doesn't depend on
a webserver like HTML.  A PDF website could easily be put on a USB key
to take with you and access via a mobile phone.  This would be secure
because no network interaction.  This is the use case I've been working
toward for years.

> Ideally, xr-hyper workflow should be supported as well. A downside is
> anchors are not stable and unrelated to labels.

Stable in the sense that the CUSTOM_ID could be moved to new file?
Could IDs play a roll here?

-- 
David Masterson