Re: org-ditaa woes

[Max Nikulin]

On 21/10/2023 04:39, Florin Boariu wrote:

   $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help


Does it work when executed from Emacs shell or eshell buffers?

Could you, please, provide complete sequence of commands to generate a 
graphics file from a ditaa source for a shell running in Emacs?


Flatpack is a means to prevent accessing system files by applications 
that may have less degree of trust. I expect that a package should be 
carefully prepared to allow `man' and `info' access docs installed 
system-wide, files from /usr/share/doc should be available for doc-view, 
compiler toolchains should be available if Emacs is used for 
development. It sounds like rather broad permissions for isolated 
applications.



I'm not exactly sure
which code version the current Emacs Flatpak has, and I don't know how
to look


Menu: Org → Documentation → Show version, Help → About Emacs
or M-x org-version, M-x emacs-version.


PS: I'm not sure how to read this in gmane.
[…] Apparently I need to do it via
NNTP?...


Yes, add news.gmane.io news server and subscribe to gmane.emacs.orgmode. 
You may send replies using your regular SMTP mail account.

Re: Feature request: IDs for everything

[Rodrigo Morales]

Currently, headlines can have an ID (see minimal working example below):

#+BEGIN_SRC org
* My headline 1
* My headline 2
:PROPERTIES:
:ID: e8745be0-906d-4e02-b427-d298f5751f6c
:END:
#+END_SRC

Blocks can't have IDs, but you could use a UUID as the for blocks (see
minimal working example below). You can do the same with tables.

#+BEGIN_SRC org
,#+NAME: 412f567b-26ce-4f21-b07f-f5296c830314
,#+BEGIN_SRC sh
seq 1 3
,#+END_SRC

,#+RESULTS: 412f567b-26ce-4f21-b07f-f5296c830314
,#+begin_example
1
2
3
,#+end_example

,#+HEADER: :noweb yes
,#+BEGIN_SRC sh
echo foo <<412f567b-26ce-4f21-b07f-f5296c830314()>>
,#+END_SRC

,#+RESULTS:
,#+begin_example
foo 1
foo 2
foo 3
foo
,#+end_example
#+END_SRC

What I understand from your message is that you would like to have a new
header argument called #+ID: that could be used for code blocks and tables.
Am I right? If so, I have a question: What could be the added benefits of
having such a header argument? I can think of this benefit: #+NAME would be
used for referencing them through a human-friendly name and the name could
change and the #+ID would be an UUID that is not expected to change.

On Fri, 20 Oct 2023 at 19:13, Tor Erlend Fjelde 
wrote:

> Hi all,
>
> I was wondering if there's a reason why we couldn't have IDs a la
> org-id.el for everything?
> It seem to me that it would be useful to use something like `#+ID` in
> place of `#+NAME` for tables, blocks, etc. as well as headlines.
> Would this go against the intended design of org-id.el, or is this a
> change that would be welcome but that no one has gotten around to
> implementing yet?
>
> Also, sorry if this is not correct way to go about this; it's my first
> time posting to a mailing list. Let me know if there are some guidelines or
> something somewhere that I should read and make use of.
>
> All the best,
> Tor
>
>

Re: org-ditaa woes

[Florin Boariu]

Can you give us the command-line you would like to use?
That would help to fix the problem you are confronting.


A "regular" one would be just simply "/usr/bin/ditaa":

---
  $ ditaa --help
  usage: java -jar ditaa.jar  [OUTFILE] [-A] [-b ] [-d]  
 [-E] [-e ] [-h] [--help] [-o] [-r] [-S] [-s ] [-T]

 [-t ] [-v] [-W]
   -A,--no-antialias  Turns anti-aliasing off.
  ...
---

For instance "ditaa diagram.txt -o diagam.png" would do exactly what
one would expect: translate diagram.txt into the coresponding image.

A more fancy one when using Flatpaks and container toolboxes are
involved would be "flatpak-spawn". E.g. this is what it takes from
within the org.gnu.emacs Flatpak sandbox to run "ditaa" in a Toolbox
container (different sandbox):

---
  $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help
  usage: java -jar ditaa.jar  [OUTFILE] [-A] [-b ] [-d]
 [-E] [-e ] [-h] [--help] [-o] [-r] [-S] [-s ] [-T]
 [-t ] [-v] [-W]
   -A,--no-antialias  Turns anti-aliasing off.
  ...
---

(Note that the self-reported message says "usage: java -jar
ditaa.jar...", but this really just behaves like a regular command
line application.)

Replying to Arne's comment:


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?

I've just tried setting org-babel-ditaa-java-cmd to "/usr/bin/ditaa",
and org-ditaa-jar-option to "", but now the error is something like:


/usr/bin/ditaa   /orgfile/base/folder  \
 /tmp/babel-0YxwcE/ditaa-NyIQwH \
 /orgfile/base/folder/network.png


where "/orgfile/base/folder" is the dirname of the full path of my
.org file (e.g. something like /orgfile/base/folder/file.org).

So org-ditaa apparently somewhere still tries to set a work directory
(or so?) after the org-ditaa-jar-option part. I'm not exactly sure
which code version the current Emacs Flatpak has, and I don't know how
to look (I'm not *that* much of a Flatpak nerd :-p ) But if I had to
bet, I'd assume it's a fairly recent one.

Cheers,
Florin.

PS: I'm not sure how to read this in gmane. I went to gmane.io, but
all I see is a green text and two links -- a kind-of blog entry with
gmane's history, and an admin interface. None of those looks like I'd
be able to browse the mailing list. Apparently I need to do it via
NNTP?...

--
   "Socks come in pairs. If you put a sock on your left foot, the other
sock of the pair instantly becomes the “right sock,” no matter where
it is located in the universe."
 -- quantum entanglement explained on /.

Re: org-ditaa woes

[Leo Butler]

On Fri, Oct 20 2023, "Dr. Arne Babenhauserheide"  wrote:

> Leo Butler  writes:
>
 [...]
(cmd (concat "java " java " " org-ditaa-jar-option " "
  (shell-quote-argument
   (expand-file-name
(if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
  " " cmdline
  " " (org-babel-process-file-name in-file)
  " " (org-babel-process-file-name out-file)))
 [...]
>
> From the commit, this is an ancient version of ob-ditaa (11 years ago).
>
> In my current source I see
>
>(cmd (concat org-babel-ditaa-java-cmd
> " " java " " org-ditaa-jar-option " "
> (shell-quote-argument
>  (expand-file-name
>   (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
> " " cmdline
> " " (org-babel-process-file-name in-file)
> " " (if pdf-cmd
> eps-file
>   (org-babel-process-file-name out-file)
>
> (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)
>
> Going forward we may want to adjust ob-ditaa to allow for an executable
> like ob-plantuml does it.
>
> Best wishes,
> Arne

Arne,
Thank you for the correction, you are right about the vintage (and
about the suggestion vis-a-vis ob-plantuml, imo).

Leo

Feature request: IDs for everything

[Tor Erlend Fjelde]

Hi all,

I was wondering if there's a reason why we couldn't have IDs a la org-id.el for 
everything?
It seem to me that it would be useful to use something like `#+ID` in place of 
`#+NAME` for tables, blocks, etc. as well as headlines.
Would this go against the intended design of org-id.el, or is this a change 
that would be welcome but that no one has gotten around to implementing yet?

Also, sorry if this is not correct way to go about this; it's my first time 
posting to a mailing list. Let me know if there are some guidelines or 
something somewhere that I should read and make use of.

All the best,
Tor

Re: org-ditaa woes

[Dr. Arne Babenhauserheide]

Leo Butler  writes:

>>> [...]
>>>(cmd (concat "java " java " " org-ditaa-jar-option " "
>>>   (shell-quote-argument
>>>(expand-file-name
>>> (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
>>>   " " cmdline
>>>   " " (org-babel-process-file-name in-file)
>>>   " " (org-babel-process-file-name out-file)))
>>> [...]

From the commit, this is an ancient version of ob-ditaa (11 years ago).

In my current source I see

 (cmd (concat org-babel-ditaa-java-cmd
  " " java " " org-ditaa-jar-option " "
  (shell-quote-argument
   (expand-file-name
(if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
  " " cmdline
  " " (org-babel-process-file-name in-file)
  " " (if pdf-cmd
  eps-file
(org-babel-process-file-name out-file)

(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)

Going forward we may want to adjust ob-ditaa to allow for an executable
like ob-plantuml does it.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: org-ditaa woes

[Leo Butler]

Hello Florin,

On Thu, Oct 19 2023, Florin Boariu  wrote:

> Hello everyone,
>
> I am not on the mailing list, so I'm hoping that some kind soul with
> moderator powers will have mercy and let my email through in a timely
> manner :-) Also, please CC me in on the answer. (I'll happily
> subscribe if you feel that I should, but this is likely to be my only
> encounter with the Org-mode list, so it's probably bogus...)

You can read (and post to?) this email list on gmane.

> But in the source code of org-ditaa.el
> (https://github.com/tkf/org-mode/blob/master/lisp/ob-ditaa.el) I can
> see something like this on lines 87 ff:
>
>> [...]
>>(cmd (concat "java " java " " org-ditaa-jar-option " "
>>(shell-quote-argument
>> (expand-file-name
>>  (if eps org-ditaa-eps-jar-path org-ditaa-jar-path)))
>>" " cmdline
>>" " (org-babel-process-file-name in-file)
>>" " (org-babel-process-file-name out-file)))
>> [...]
>

I think you have identified a bug in ob-ditaa.el. Your request is
perfectly reasonable and that CMD should not have such hard-coded
constants in it, imo.

> I suck at LISP, but I'm guessing this means that there simply
> is no way of just passing on a "/usr/bin/ditaa" command-line to
> "org-ditaa", or at least an alternative Java command like "flatpak
> spawn --host /usr/bin/java ...". Org-ditaa really *does* insist of
> glueing it together from "java -jar ..." pieces, and is stubbornly
> adamant on finding Java in the same FS namespace.

Can you give us the command-line you would like to use?
That would help to fix the problem you are confronting.

>
> Is there a deeper reason behind this? This pretty much breaks
> Flatpak, or any other sandboxing compatibility, as far as I
> understand. Can it be changed? Please? :-)

The deeper reason is likely that ob-ditaa worked for whomever wrote it,
and users have either accepted its limitations (if noted), worked around
them, or gave up.

>
> How can I make it accept a command line?
>
> Is there any "generic" way of making org-babel accept a command line,
> not necessarily going through "org-ditaa", as a workaround?

You could use ob-shell, but it would be preferable to fix the bug you
have identified.

>
> Thanks & cheers,
> Florin.

Leo

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

[Max Nikulin]

Hi,

In the following thread

Ihor Radchenko. Re: Exporting elisp: and shell: links.
Sat, 14 Oct 2023 08:13:35 +.
https://list.orgmode.org/87wmvp1v0w.fsf@localhost

it was discussed that attempts to customize export to plain text of link 
types such as "elisp:" and "shell:" break formatting as notes at the end 
of the heading (`org-ascii-links-to-notes').


The attached patches is a draft implementing this feature (new functions 
are not documented yet).


For ascii backend :export function from `org-link-parameters' may return 
(PATH . DESCRIPTION) `cons' instead of string. Depending on chosen link 
style it will be exported as "[DESCRIPTION]" with the "[DESCRIPTION] 
PATH" note at the end of heading or as the inline reference "DESCRIPTION 
(PATH)".


I believe that parenthesis should be skipped in the case of angle 
brackets "()", but I do not change this behavior. There is some 
inconsistency in respect to brackets for description of inline links, 
but it is preserved as well.


I do not like that :export functions are called twice: for text and for 
note. In my opinion it is better to collect links in a property of INFO 
to later format notes at the end of the heading. I would consider more 
dense style of notes with list markers instead of empty line as separator.


Namely "shell:" and "elisp:" links may be exported as notes in the 
current Org version since they have no :export property. The proposed 
feature allows to have custom :export e.g. to not add "shell:" prefix to 
the code.From 8a80605e608809fa450ee08d2601a0c7a27c5276 Mon Sep 17 00:00:00 2001
From: Max Nikulin 
Date: Fri, 20 Oct 2023 17:10:36 +0700
Subject: [PATCH 1/3] test-ox-ascii.el: Test custom links

* testing/lisp/test-ox-ascii.el (test-ox-ascii--restore-syntax)
(test-ox-ascii--link-export-inline): Helper functions.
(test-ox-ascii/link-custom-protocol-fallback)
(test-ox-ascii/link-custom-protocol-string): Test export of custom link
types having the :export parameters or relying on format provided by
default when `org-ascii-links-to-notes' enabled or disabled.
---
 testing/lisp/test-ox-ascii.el | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/testing/lisp/test-ox-ascii.el b/testing/lisp/test-ox-ascii.el
index fe12c0c27..07def1633 100644
--- a/testing/lisp/test-ox-ascii.el
+++ b/testing/lisp/test-ox-ascii.el
@@ -27,7 +27,91 @@ (require 'ox-ascii nil t)
 (unless (featurep 'ox-ascii)
   (signal 'missing-test-dependency "org-export-ascii"))
 
+(defun test-ox-ascii--restore-syntax ()
+  (org-link-make-regexps)
+  (when (featurep 'org-element) (org-element-update-syntax)))
+
+(defun test-ox-ascii--link-export-inline (path desc backend info)
+  (and (org-export-derived-backend-p backend 'ascii)
+   (let ((description (and (org-string-nw-p desc) (org-trim desc)))
+ (target (format "(|tststr:%s|)" path)))
+ (if description
+ (format "[|%s|] %s" description target)
+   target
 
+(ert-deftest test-ox-ascii/link-custom-protocol-fallback ()
+  "Test link custom protocol fallback."
+  (unwind-protect
+  (let ((org-link-parameters))
+(org-link-set-parameters "tstdflt")
+;; As notes.
+(let ((org-ascii-links-to-notes t))
+  (should ; With description.
+   (string-equal
+(org-export-string-as
+ "Link [[tstdflt:path-descr][with description]] as note."
+ 'ascii t)
+"Link [with description] as note.
+\n
+[with description] \n"))
+  (should ; No description.
+   (string-equal
+(org-export-string-as
+ "Link [[tstdflt:path-no-descr]] without description (note)."
+ 'ascii t)
+"Link  without description (note).\n")))
+;; Inline.
+(let ((org-ascii-links-to-notes nil))
+  (should ; With description.
+   (string-equal
+(org-export-string-as
+ "Inline link [[tstdflt:path-descr][with description]]."
+ 'ascii t)
+"Inline link [with description] ().\n"))
+  (should ; No description.
+   (string-equal
+(org-export-string-as
+ "Inline link [[tstdflt:path-no-descr]] without description."
+ 'ascii t)
+"Inline link  without description.\n"
+(test-ox-ascii--restore-syntax)))
+
+(ert-deftest test-ox-ascii/link-custom-protocol-string ()
+  "Test link custom protocol forced inline (string return value)."
+  (unwind-protect
+  (let ((org-link-parameters))
+(org-link-set-parameters "tststr"
+ :export #'test-ox-ascii--link-export-inline)
+;; Inline despite as notes is requested.
+(let ((org-ascii-links-to-notes t))
+  (should ; With description.
+   (string-equal
+(org-export-string-as
+ "Link [[tststr:path-descr][with description]] as string (opt note)."
+ 'ascii t)
+   

Re: Consider removing newlines from org-insert-link help message

[Ihor Radchenko]

Rudolf Adamkovič  writes:

>> What about replacing it with shorter description?
>
> +1 for making the message shorter,
>
> ... and while on it, perhaps also a bit clearer.

Patches welcome.

> - the key bindings are not propertized, and
> - the entire buffer is writable.

I see no obvious downsides. May as well.

>> Insert a link.
>
> How about we say "Insert link:" in the minibuffer and drop this sentence
> altogether?  Grammatically, the minibuffer prompt would be similar to
> 'C-x b', which says "Switch to buffer".

Currently, the minibuffer message is simply "Link: ". "Insert link:" is
also ok.

>> Use TAB to complete link prefixes, then RET for type-specific
>> completion support.
>
> How about:
>
>   Type TAB to complete link types, then RET to complete destinations.

Maybe "Press" rather than "Type".

>> Stored links are available with / or M-p/n (most recent with
>> RET):
>
> Could we show the default value in the minibuffer, as
>
>   Insert link (default [...]):
>
> and then drop the "(most recent with RET)" comment?

We may, but the default link might sometimes be long. Not sure how it
will look like.

> As for the rest of the message, ... actually let me stop here and zoom
> out a bit.  The optimal solution here would be to remove this entire UI
> and leverage standard Emacs completions.  Org could simply ask
>
>   Insert link (default [...]):
>
> in the minibuffer and then provide intelligent completions based on the
> current input.  If that can be done, then Emacs can handle the rest.  It
> can show completion candidates, handle past/future history, and more.

AFAIK, this is already done. We already use `completing-read'. The UI is
there historically and in addition to the normal Emacs completion.

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

Re: plantuml tikz format support

[Ihor Radchenko]

Ihor Radchenko  writes:

>> From 3c27bb94cb5a2cd66a5336dc9c69e3ca03232a91 Mon Sep 17 00:00:00 2001
>> From: Nan Jun Jie 
>> Date: Wed, 23 Aug 2023 20:23:40 +0800
>> Subject: [PATCH] Add plantuml tikz format support
>
> There is something off with the email formatting - I cannot apply it
> using git-am. May you re-send as an attachment?

I have addressed my own comments and applied the amended patch on your
behalf.
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=7ceefaf2d

You are now listed as an Org contributor.
https://git.sr.ht/~bzg/worg/commit/a85a664c

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

Re: [BUG] Search leaves draws open [9.7-pre (release_9.6.10-835-gf3de4c @ ~/.emacs.d/org-mode-git/lisp/)]

[Ihor Radchenko]

Paul Stansell  writes:

> However, strangely, it doesn't close drawers that have been opened by the
> bug that causes drawers to remain open after the searching (eg, those
> opened by searching for "text" in the file I included in my bug report).

It indeed does not. Because of a bug you reported. The buggy part is not
converting from the isearch overlays back to Org folds. isearch overlays
force the drawers to remain open.

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

Re: [BUG] Search leaves draws open [9.7-pre (release_9.6.10-835-gf3de4c @ ~/.emacs.d/org-mode-git/lisp/)]

[Paul Stansell]

> >> org-hide-drawer-all
> >>
> >
> > I don't seem to have that command.  I'm using Org mode
> > release_9.6.10-835-gf3de4c.
>
> It was made into a command in
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=13353f1fa34f6f085ffbf142b380af7308f02981


I see, I found the command, it's called org-fold-hide-drawer-all
(not org-hide-drawer-all).

However, strangely, it doesn't close drawers that have been opened by the
bug that causes drawers to remain open after the searching (eg, those
opened by searching for "text" in the file I included in my bug report).

Re: Consider removing newlines from org-insert-link help message

[Rudolf Adamkovič]

Salih Muhammed  writes:

> What about replacing it with shorter description?

+1 for making the message shorter,

... and while on it, perhaps also a bit clearer.

Also,

- the key bindings are not propertized, and
- the entire buffer is writable.

> Insert a link.

How about we say "Insert link:" in the minibuffer and drop this sentence
altogether?  Grammatically, the minibuffer prompt would be similar to
'C-x b', which says "Switch to buffer".

> Use TAB to complete link prefixes, then RET for type-specific
> completion support.

How about:

  Type TAB to complete link types, then RET to complete destinations.

> Stored links are available with / or M-p/n (most recent with
> RET):

Could we show the default value in the minibuffer, as

  Insert link (default [...]):

and then drop the "(most recent with RET)" comment?

As for the rest of the message, ... actually let me stop here and zoom
out a bit.  The optimal solution here would be to remove this entire UI
and leverage standard Emacs completions.  Org could simply ask

  Insert link (default [...]):

in the minibuffer and then provide intelligent completions based on the
current input.  If that can be done, then Emacs can handle the rest.  It
can show completion candidates, handle past/future history, and more.

Rudy
-- 
"We shall not cease from exploration
 And the end of all our exploring
 Will be to arrive where we started
 And know the place for the first time"
--- T. S. Eliot, Little Gidding, Four Quarters, 1943

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [BUG] parsing bug on org (accented characters not displayed) [9.7-pre (release_9.6.10-835-gf3de4c @ /home/juliend/.config/emacs/straight/build/org/)]

[Ihor Radchenko]

Julien  writes:

> In some files, accented characters are not displayed correctly (encoding
> with utf-8 is not enabled by default, I must specify it manually each time)
>
> Strangely enough, this bug seems to be NOT RELATED with my personal
> emacs settings.
> Looking for the origin of the bug, I deleted my init.el file and
> reinstalled emacs: the problem still occurs on vanilla emacs.
>
> Hence, I guess it really is an internal bug, could not find anyone else
> who add the same though ...

May you please describe how to reproduce the bug starting from emacs -Q?
See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: [BUG] Feature request: Add group checks for manual tag setting (not just fast tags) [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> ...
> In case of the default settings (org-use-fast-tag-selection = auto), the
> interface is different - prompt will list all the tags already present
> in the heading:
> ...
> In the above scenario, there is no non-ambiguous way to know which
> exclusive tag is implied by the user. So, I am inclined to keep the
> current behavior. Unless there are better ideas.

I am thus closing this bug, as partially addressed.
Fixed.

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

Colons in :var header arguments

[Stefano Ghirlanda]

Hi everyone,

I have been using org-mode for reproducible research for many years
now. This is my first message: thanks to everyone who is involved in
org-mode development and maintenance!

I have run into an inconvenience in that colons in :var header
arguments to source blocks are invariably interpreted as referring to
another file. However, I use cleveref in LaTeX export (via org-ref) to
automatically format references using labels like tab:data, and in
these cases :var data=tab:data gives a reference not found because tab
is interpreted as a filename.

I have found a workaround in that I can use #+name: data to name the
table as well as \label{tab:data} in the table's #+caption: line, and
this works. But I was wondering if it would be cleaner to change this
behavior to interpreting tab:data as referring to a file only if
#+name: tab:data is not found in the current file. I think this would
break very few org files currently in the world, because presumably
people using the external file mechanism have not been using the
cleveref mechanism, otherwise this would have popped up already :) In
org files that use external references only, the change would be
invisible. I see the magic happens in org-ref-resolve in org-ref.el,
but I don't feel confident enough to mess with that myself.

Thanks again for one of the most useful pieces of software around.

-- 
Stefano Ghirlanda
CTO, DataWorks - https://dataworks.consulting
Guest Professor - Stockholm University Centre for Cultural Evolution

[BUG] parsing bug on org (accented characters not displayed) [9.7-pre (release_9.6.10-835-gf3de4c @ /home/juliend/.config/emacs/straight/build/org/)]

[Julien]

In some files, accented characters are not displayed correctly (encoding
with utf-8 is not enabled by default, I must specify it manually each time)

Strangely enough, this bug seems to be NOT RELATED with my personal
emacs settings.
Looking for the origin of the bug, I deleted my init.el file and
reinstalled emacs: the problem still occurs on vanilla emacs.

Hence, I guess it really is an internal bug, could not find anyone else
who add the same though ...

Emacs : GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
Package: Org mode version 9.7-pre (release_9.6.10-835-gf3de4c @ 
/home/juliend/.config/emacs/straight/build/org/)

current state:
==
(setq
org-noter--doc-goto-location-hook '(org-noter-djvu--goto-location 
org-noter-nov--goto-location org-noter-pdf--goto-location)
org-link-elisp-confirm-function 'yes-or-no-p
org-hide-emphasis-markers t
org-bibtex-headline-format-function 'org-bibtex-headline-format-default
org-pdftools-get-desc-function 'org-pdftools-get-desc-default
org-startup-folded "overview"
org-agenda-files '("~/Dropbox/org-roam")
org-persist-after-read-hook '(org-element--cache-persist-after-read)
org-export-before-parsing-hook '(org-attach-expand-links)
org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)
org-roam-find-file-hook '(org-roam-buffer--setup-redisplay-h 
org-roam--register-completion-functions-h org-roam--replace-roam-links-on-save-h
org-roam-db-autosync--setup-update-on-save-h)
org-archive-hook '(org-attach-archive-delete-maybe)
org-noter--pretty-print-location-for-title-hook 
'(org-noter-djvu--pretty-print-location org-noter-nov--pretty-print-location
org-noter-pdf--pretty-print-location-for-title)
org-odt-format-inlinetask-function 'org-odt-format-inlinetask-default-function
org-ascii-format-drawer-function #[771 "\207" [] 4 "\n\n(fn NAME CONTENTS 
WIDTH)"]
org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines 
org-cycle-optimize-window-after-visibility-change 
org-cycle-display-inline-images)
org-persist-before-read-hook '(org-element--cache-persist-before-read)
org-font-lock-set-keywords-hook '(org-drill-add-cloze-fontification)
org-noter--pretty-print-highlight-location-hook 
'(org-noter-pdf--pretty-print-highlight)
org-mode-hook '(dw/org-mode-visual-fill (lambda nil (display-line-numbers-mode 
-1)) org-pdftools-setup-link
#[0 "\301\211\207" [imenu-create-index-function org-imenu-get-tree] 2] (lambda 
nil (org-indent-mode 1)) (lambda nil (org-bullets-mode 1))
org-auto-tangle-mode (lambda nil evil-org-mode) #[0 "\300\301\302\303\304$\207" 
[add-hook change-major-mode-hook org-fold-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook change-major-mode-hook 
org-babel-show-result-all append local] 5] org-babel-result-hide-spec
org-babel-hide-all-hashes)
org-babel-load-languages '((emacs-lisp . t) (latex . t) (shell . t) (python . 
t) (julia . t) (C . t) (haskell . t))
org-fc-index-function 'org-fc-awk-index
org-src-window-setup 'other-frame
org-roam-ref-annotation-function 'org-roam-ref-read--annotation
org-roam-directory "/home/juliend/Dropbox/org-roam"
org-noter--pretty-print-location-hook '(org-noter-djvu--pretty-print-location 
org-noter-nov--pretty-print-location org-noter-pdf--pretty-print-location)
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-roam-db-node-include-function #[0 "\300\207" [t] 1]
org-latex-format-headline-function 'org-latex-format-headline-default-function
org-confirm-shell-link-function 'yes-or-no-p
org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-roam-capture-preface-hook '(org-roam-capture--try-capture-to-ref-h)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
org-roam-preview-function 'org-roam-preview-default-function
org-babel-tangle-lang-exts '(("haskell" . "hs") ("D" . "d") ("C++" . "cpp") 
("julia" . "jl") ("python" . "py") ("latex" . "tex") ("emacs-lisp" . "el")
("elisp" . "el"))
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
org-roam-db-autosync-mode t
org-confirm-elisp-link-function 'yes-or-no-p
org-log-buffer-setup-hook '(org-roam-log--setup)
org-roam-capture-new-node-hook '(org-roam-capture--insert-captured-ref-h)
org-noter--show-arrow-hook '(org-noter-pdf--show-arrow)
org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)
org-html-format-inlinetask-function 'org-html-format-inlinetask-default-function
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
org-noter--add-highlight-hook '(org-noter-pdf--highlight-location)

org-ditaa woes

[Florin Boariu]

Hello everyone,

I am not on the mailing list, so I'm hoping that some kind soul with
moderator powers will have mercy and let my email through in a timely
manner :-) Also, please CC me in on the answer. (I'll happily
subscribe if you feel that I should, but this is likely to be my only
encounter with the Org-mode list, so it's probably bogus...)

To my problem.


What did I do
=

I was trying to create a diagram e.g. from the following org-mode
snippet:


 #+begin_src ditaa :file network.png

  +--+
  | moo  |
  +--+

 #+end_src


My init.el eventually gets to parse this configuration:


 (org-babel-do-load-languages 'org-babel-load-languages '(
 (python . t)
 (ditaa . t))
 )

 ;(setq org-ditaa-jar-path "/usr/bin/ditaa")
 ;(setq org-ditaa-jar-path "/usr/share/java/ditaa.jar")
 ;(setq org-babel-ditaa-java-cmd "/usr/bin/ditaa")
 ;(setq org-babel-ditaa-java-cmd "flatpak-spawn --host toolbox run ditaa")


There are several attempts on setting org-ditaa-* variables, or
org-babel-ditaa-*, but all fruitless (see below).

I pressed C-c C-c in order to have a diagram generated.


What did I expect would happen
==

The documentation says that a "#+results" section will appear, and it
will contain a link to the ditaa document.

Obviously I'd expect to have a network.png file appearing somewhere on
my filesystem, too, or a PNG inlined into my ORG document. Or
something.


What happend instead


A "#+RESULTS: ..." section with [[file:network.png]] does indeed
appear, but no network.png is to be found anywhere. Clicking on
network.png only opens a new and empty buffer named "network.png",
without any contents.

Essentially, the error messages I find in '*Messages*' so far vary,
depending on which org-ditaa / org-babel-ditaa variables I set, and
how I set them. They range from:


org-babel-execute:ditaa: Could not find ditaa.jar at 
/app/share/emacs/29.1/lisp/contrib/scripts/ditaa.jar


via:


Error: Invalid or corrupt jarfile /usr/bin/ditaa Code block evaluation complete.


to:


Error: Unable to initialize main class 
org.stathissideris.ascii2image.core.CommandLineConverter
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
Code block evaluation complete.



I'm fairly sure I know *why* this is the case, just not how to fix it.

...actually, I'm fairly sure that it can't be fixed on my part :-(

Essentially, emacs / org-babel tries to either execute "java -jar
/usr/bin/ditaa", or doesn't find any jar file, or finds one in
/usr/share/... but fails to actually make it run.

A little bit more background.

I have what would be considered an "exotic setup", although it's
pretty standard for the Linux distribution I'm using (Fedora
Silverblue):

  - My Emacs (29.1 apparently?) runs in a Flatpak

  - All other applications, including ditaa, run in a "Toolbox"
(https://containertoolbx.org/). Think: kind of a "mutable Docker
container". Think of it as of a chroot'ed environment where
everything else that isn't X-windows or Gnome is installed, and
that only shares /home/me, /var, and a few other non-relevant
directories with the host system. In particular, it does *not*
share /usr, /bin, /lib or anything of importance for applications.

  - ...alternatively, I can run an Emacs instance (a 28 version) in
the same toolbox as the other applications (i.e. ditaa), but the
results are the same.

  - ditaa within the toolbox is my "distribution standard", which is
an executable file at /usr/bin/ditaa, and which apparently is a
shell script with the following contents:

  #!/usr/bin/bash
  #
  
  source /usr/share/java-utils/java-functions


  MAIN_CLASS=org.stathissideris.ascii2image.core.CommandLineConverter
  BASE_JARS="ditaa commons-cli xml-commons-apis batik"

  set_classpath $BASE_JARS

  run "$@"

This is to show that it's similar to, but still quite a bit more
than just "java -jar ditaa.jar ...". This appears to be standard
e.g. for all Fedora distributions (and alike). FWIF, latest Debian
does something similar, only that /usr/bin/ditaa there is a
binary.


The core of the problem


Essentially, org-ditaa expects a jar and a java runtime to be able to
consruct a command line of the kind "java -jar /path/to/didaa.jar ..."
and expect everything to sail smoothly. And it's *very* opinionated
about that.

There's no way that I can provide that without a significant amount of
ugly hacking. What I can offer are a myriad of workarounds, but all
boil down to specifying a shell command that does what org-ditaa
expects, but doesn't begin with "java -jar ...". This is simply
because the premise -- namely that emacs, org-ditaa, ditaa.jar and
java-runtime, are in the same filesystem namespace, or the same
process namespace, is simply not true for me. This is by design --
both of the distribution I'm using, and of 

Re: [BUG] Search leaves draws open [9.7-pre (release_9.6.10-835-gf3de4c @ ~/.emacs.d/org-mode-git/lisp/)]

[Ihor Radchenko]

Paul Stansell  writes:

>> org-hide-drawer-all
>>
>
> I don't seem to have that command.  I'm using Org mode
> release_9.6.10-835-gf3de4c.

It was made into a command in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=13353f1fa34f6f085ffbf142b380af7308f02981

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

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

[Visuwesh]

[வெள்ளி அக்டோபர் 20, 2023] Ihor Radchenko wrote:

> Po Lu  writes:
>
>>> Because nobody added you manually to the CC in this branch of the
>>> discussion. You would only be automatically in the CC in the replies to
>>> your message (87bkdccihf@yahoo.com), but not the earlier branches.
>>
>> The follow-up I mentioned lists 87bkdccihf@yahoo.com within
>> In-Reply-To.
>
> I see. I use wide reply by default, personally. I did not drop you or
> anyone from CC in this thread on purpose.

I also use wide-reply but the problem was that I neglected to include Po
Lu in the CCs when I replied to a message in another sub-thread that
referred to Po Lu's message.  So the issue raised by Po Lu was addressed
but he was effectively dropped from the discussion due to my negligence.

>>> Do you mean something like a standardized entry in `dnd-protocol-alist'
>>> that is independent on OS? Instead of (REGEXP . FUNCTION),
>>> (SYMBOL . FUNCTION) with SYMBOL = 'file-list or so.
>>
>> I'm sorry, but I don't understand what you're proposing.  Would you
>> please couch it differently?
>
> Instead of passing dnd data as is from the OS, Emacs can convert it into
> a standardized format, independent of the OS. Then,
> `dnd-protocol-alist' can allow handlers for such standardized dnd type.
>
> In our scenario, the dnd data will be dropped file list. Emacs should
> internally detect such file lists for GNU/Linux / Windows / other
> platforms with dnd support and then convert them into the same format.
> Then, dnd users can add (file-list . FUNCTION) into `dnd-protocol-alist'
> and the FUNCTION will be passed with the converted data that will always
> be the same for all the OSes.
>
> Does it make sense?

BTW, I would also like to have something like dnd-protocol-alist but for
dropped _text_ instead.  Currently, every dropped text is handled by
dnd-insert-text but I would like to have a handler so that e.g., I can
add the relevant bibtex entry for the DOI _text_ (10.BLAH/BLAH no fancy
link) onto an Emacs window visiting a bibtex file.  I currently do this
via an advice but it would be nice to have something less hacky.

Re: COUNTER-SET for alphabetical ordered lists ignored for utf-8 exporter

[Ihor Radchenko]

"Tom Alexander"  writes:

> Idk if its been discussed, but personally if I were given dictatorship over 
> org-mode I would take all of these emacs variables that are defined outside 
> of the document, and instead of having them influence org-mode directly, I 
> would *only* use them to pre-populate values for in-buffer settings templates.

> For example, if a user had set `org-odd-levels-only` then I wouldn't have 
> that impact ANY existing document they open, but if they open a new document 
> then I would have it auto-insert `#+STARTUP: odd` at the top of the fresh 
> document.

That would be very annoying for many users.
What might be better is providing a way to "unload" the parser-affecting
non-standard settings into Org file header, so that the file can be
shared properly with other people.

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

Re: [BUG] Search leaves draws open [9.7-pre (release_9.6.10-835-gf3de4c @ ~/.emacs.d/org-mode-git/lisp/)]

[Paul Stansell]

>
> > In the meantime, is there a command that will close all drawers, even
> those
> > that are open in sections (headings) that are closed?  I searched but
> > didn't find anything.
>
> org-hide-drawer-all
>

I don't seem to have that command.  I'm using Org mode
release_9.6.10-835-gf3de4c.

I grep for org-hide-drawer-all there is the following entry that seems to
imply the command is obsolete:

(define-obsolete-function-alias 'org-hide-drawer-all
  'org-fold-hide-drawer-all "9.6")

If I try to run the command using

  M-x org-hide-drawer-all

I'm told "no match".

[PATCH] [DISCUSSION] Force `tab-width' to be 8 in Org mode (was: COUNTER-SET for alphabetical ordered lists ignored for utf-8 exporter)

[Ihor Radchenko]

"Tom Alexander"  writes:

> Thanks!
>
>> We aim to reduce config-dependent Org syntax in the long term.
>
> Thats wonderful news! Sometimes this stuff can really surprise you. For 
> example, the structure of the document created by running `echo "1. foo\n 
> 1.bar\n1.baz\n\t1.lorem"` changes based on the user's **tab-width**!!
> ...
> Absolute madness! I always considered tab-width to be a personal aesthetic 
> choice and not something that would functionally change how documents other 
> people wrote will be parsed.

I agree.
See the attached tentative patches for Org mode and org-syntax.

This is a breaking change, so I encourage people who might be affected
reply if they have objections.

>From 423cf9aef588ed93cbc06d6033feaf6bf1a91dfc Mon Sep 17 00:00:00 2001
Message-ID: <423cf9aef588ed93cbc06d6033feaf6bf1a91dfc.1697796750.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Fri, 20 Oct 2023 13:10:30 +0300
Subject: [PATCH] * lisp/org.el (org-mode): Force `tab-width' to be 8

* lisp/org-macs.el (org-current-text-column): Assert `tab-width' to be
8 to ensure consistency of the parser across user configurations.
* etc/ORG-NEWS (~tab-width~ value is now assumed to be 8): Document
the breaking change.

This breaking change is made to standardize Org mode format for list
items.  With variable `tab-width', indentation in lists may depend on
user settings leading to inconsistent Org documents when open by
different users.

Link: https://orgmode.org/list/2c9a6cbd-21c0-45bf-8fbb-4f7eccac4...@app.fastmail.com
---
 etc/ORG-NEWS | 34 ++
 lisp/org-macs.el | 13 ++---
 lisp/org.el  |  3 +++
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 78b75b578..ea8ebd3af 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,40 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** ~tab-width~ value is now assumed to be 8
+
+Org mode now assumes tab width to be 8 characters, when calculating
+list and other indentation.  ~tab-width~ is also set to 8 when Org
+major mode is loaded.
+
+This is done to improve consistency of the markup for lists, where
+indentation affects list items.
+
+Users with non-default values of ~tab-width~ should avoid overriding
+the value of 8 set by Org mode.  If the custom ~tab-width~ value is
+_smaller_ than 8, the existing Org documents can be converted to the
+new standard tab width using the following helper command:
+
+#+begin_src emacs-lisp
+(defun org-compat-adjust-tab-width-in-buffer (old-width)
+  "Adjust visual indentation from `tab-width' equal OLD-WIDTH to 8."
+  (interactive "nOld `tab-width': ")
+  (cl-assert (derived-mode-p 'org-mode))
+  (unless (= old-width 8)
+(org-with-wide-buffer
+ (goto-char (point-min))
+ (let (bound
+	   (repl (if (< old-width 8)
+		 (make-string old-width ?\s)
+   (concat "\t" (make-string (- old-width 8) ?\s)
+   (while (re-search-forward "^ *\t" nil t)
+	 (skip-chars-forward " \t")
+	 (setq bound (point-marker))
+	 (forward-line 0)
+	 (while (search-forward "\t" bound t)
+	   (replace-match repl)))
+#+end_src
+
 *** New export option ~org-export-expand-links~
 
 The new option makes Org expand environment variables in link and INCLUDE paths.
diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index fd0f508c5..1fd7dd704 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -1148,9 +1148,16 @@ (defun org-string-width (string  pixels)
 (/ pixel-width symbol-width)))
 
 (defmacro org-current-text-column ()
-  "Like `current-column' but ignore display properties."
-  `(string-width (buffer-substring-no-properties
-  (line-beginning-position) (point
+  "Like `current-column' but ignore display properties.
+Throw an error when `tab-width' is not 8.
+
+This function forces `tab-width' value because it is used as a part of
+the parser, to ensure parser consistency when calculating list
+indentation."
+  `(progn
+ (cl-assert (= 8 tab-width))
+ (string-width (buffer-substring-no-properties
+(line-beginning-position) (point)
 
 (defun org-not-nil (v)
   "If V not nil, and also not the string \"nil\", then return V.
diff --git a/lisp/org.el b/lisp/org.el
index bda64bb6c..671dfbe38 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4846,6 +4846,9 @@ (define-derived-mode org-mode outline-mode "Org"
 
 \\{org-mode-map}"
   (setq-local org-mode-loading t)
+  ;; Force tab width - indentation is significant in lists, so we need
+  ;; to make sure that it is consistent across configurations.
+  (setq-local tab-width 8)
   (org-load-modules-maybe)
   (when org-agenda-file-menu-enabled
 (org-install-agenda-files-menu))
-- 
2.42.0

>From 1ce9ef2f8e475bcb8b9be7367bb30aa0983da6ea Mon Sep 17 00:00:00 2001
Message-ID: 

Re: Case insensitivity of simple [[links]]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

>>> [...] call to 'org-toggle-link-display' does nothing.
>
>> It does nothing because it is one of the options that must be set before
>> Org mode is loaded. Resolving buffer-local variables happens after the
>> major mode is loaded.
>
> I have noticed that 'org-use-extra-keys', for example, is documented as
> "must set it before loading Org", but there is nothing similar in the
> 'org-link-descriptive' docstring.  So perhaps this is a bug, not a
> feature?

I was not precise. `org-link-descriptive' must be set before Org major
mode is loaded in current buffer. In general, all the Emacs
customization are not guaranteed to do anything when the major mode is
already loaded. There is a mechanism with :set function for defcustom,
but most people use setq that ignores this mechanism.

Anyway, I just added a :set function for `org-link-descriptive' on main.
It will be used when customization interface, `setopt', or
`custom-set-variables' is used.

> Upon a quick look, 'org-toggle-link-display' does exactly two things:
>
>   1. (setq org-link-descriptive (not org-link-descriptive)) and
>   2. (org-link-descriptive-ensure),
>
> where 'org-link-descriptive-ensure' wraps exactly one expression:
>
>   (org-fold-core-set-folding-spec-property
>  (car org-link--link-folding-spec)
>  :visible (not org-link-descriptive))
>
> Could Org execute this expression after loading a document, given the
> buffer-local value of 'org-link-descriptive' necessitates it?

No. Because the code execution during Org loading happens before Emacs
loads file-local variables. This is by major mode design and we cannot
do much about this. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003

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

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

[Po Lu]

Ihor Radchenko  writes:

> Instead of passing dnd data as is from the OS, Emacs can convert it into
> a standardized format, independent of the OS. Then,
> `dnd-protocol-alist' can allow handlers for such standardized dnd type.
>
> In our scenario, the dnd data will be dropped file list. Emacs should
> internally detect such file lists for GNU/Linux / Windows / other
> platforms with dnd support and then convert them into the same format.
> Then, dnd users can add (file-list . FUNCTION) into `dnd-protocol-alist'
> and the FUNCTION will be passed with the converted data that will always
> be the same for all the OSes.
>
> Does it make sense?

Yes, that is scrutable.  I will write this.

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

[Ihor Radchenko]

Po Lu  writes:

>> Because nobody added you manually to the CC in this branch of the
>> discussion. You would only be automatically in the CC in the replies to
>> your message (87bkdccihf@yahoo.com), but not the earlier branches.
>
> The follow-up I mentioned lists 87bkdccihf@yahoo.com within
> In-Reply-To.

I see. I use wide reply by default, personally. I did not drop you or
anyone from CC in this thread on purpose.

>> Do you mean something like a standardized entry in `dnd-protocol-alist'
>> that is independent on OS? Instead of (REGEXP . FUNCTION),
>> (SYMBOL . FUNCTION) with SYMBOL = 'file-list or so.
>
> I'm sorry, but I don't understand what you're proposing.  Would you
> please couch it differently?

Instead of passing dnd data as is from the OS, Emacs can convert it into
a standardized format, independent of the OS. Then,
`dnd-protocol-alist' can allow handlers for such standardized dnd type.

In our scenario, the dnd data will be dropped file list. Emacs should
internally detect such file lists for GNU/Linux / Windows / other
platforms with dnd support and then convert them into the same format.
Then, dnd users can add (file-list . FUNCTION) into `dnd-protocol-alist'
and the FUNCTION will be passed with the converted data that will always
be the same for all the OSes.

Does it make sense?

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

Re: [BUG] org-contrib: org-eldoc has an autload, but is incompatible with modern emacs. [9.6.8 (release_9.6.8-3-g21171d @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Vladimir Nikishkin  writes:

>> May you elaborate about incompatibility?
>>
>
> Yes. With org-eldoc loaded, and having a property '#+date: unpublished'
> in an org file, I am having the '*Messages*' buffer filled with
> #+begin_src elisp
> ⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
> 2015_Passwords.org.rclignore::53653. Resetting.
>  The error was: (error "Invalid search bound (wrong side of point)")
>  Backtrace:
> "  backtrace-to-string(nil)
>   org-element-at-point()

This has nothing to do with eldoc.
If you can reproduce this problem consistently, may you create a minimal
example as described in https://orgmode.org/manual/Feedback.html#Feedback ?

>> That would constitute incompatible change for the existing users.
>> Although, autoload may cause org-eldoc to be loaded for users of
>> org-contrib, who are not interested in org-eldoc.
>> What we might do as a compromise is removing the autoload cookie only
>> and leaving the (add-hook ...) to be executed upon (require 'org-eldoc).
>
> Yes, maybe that is even better. Why would one (require 'org-eldoc) with
> no intention of using it?

Fixed, on master.
https://git.sr.ht/~bzg/org-contrib/commit/6e208c87bf6ede9251c9c5733b81b004b1e44966

As for `require', it is not so simple. Things like C-h f can trigger
loading libraries. But addressing such peculiarities is beyond the level
of maintenance we can provide for org-contrib.

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

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

[Po Lu]

Ihor Radchenko  writes:

> Because nobody added you manually to the CC in this branch of the
> discussion. You would only be automatically in the CC in the replies to
> your message (87bkdccihf@yahoo.com), but not the earlier branches.

The follow-up I mentioned lists 87bkdccihf@yahoo.com within
In-Reply-To.

> Do you mean something like a standardized entry in `dnd-protocol-alist'
> that is independent on OS? Instead of (REGEXP . FUNCTION),
> (SYMBOL . FUNCTION) with SYMBOL = 'file-list or so.

I'm sorry, but I don't understand what you're proposing.  Would you
please couch it differently?

Re: [BUG] org-contrib: org-eldoc has an autload, but is incompatible with modern emacs. [9.6.8 (release_9.6.8-3-g21171d @ /usr/share/emacs/30.0.50/lisp/org/)]

[Vladimir Nikishkin]

Ihor Radchenko  writes:

> Vladimir Nikishkin  writes:
>
>> org-contrib has the following lines 206 and 207 in org-eldoc:
>> #+begin_src elisp
>> ;;;###autoload
>> (add-hook 'org-mode-hook #'org-eldoc-load)
>> #+end_src
>>
>> which set up that hook automatically when the package org-contrib is
>> installed.
>>
>> that hook is, seemingly, incompatible with the recent org-element,
>
> May you elaborate about incompatibility?
>

Yes. With org-eldoc loaded, and having a property '#+date: unpublished'
in an org file, I am having the '*Messages*' buffer filled with
#+begin_src elisp
⛔ Warning (org-element-cache): org-element--cache: Org parser error in 
2015_Passwords.org.rclignore::53653. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-eldoc-get-src-lang()
  org-eldoc-documentation-function(#f(compiled-function (string  plist) 
#))
  #(org-eldoc-documentation-function)
  eldoc-documentation-default()
  eldoc--invoke-strategy(nil)
  eldoc-print-current-symbol-info()
  #()
  apply(# nil)
  timer-event-handler([t 0 0 50 nil # nil idle 0 nil])
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
#+end_src

>> Could those lines be removed? If someone is interested in
>> patching/using/maintaining that code, he can probably try to refactor it
>> in a better way.
>>
>> (In any case, it is probably better to add such hooks in the :hook
>> clause of use-package.)
>
> That would constitute incompatible change for the existing users.
> Although, autoload may cause org-eldoc to be loaded for users of
> org-contrib, who are not interested in org-eldoc.
> What we might do as a compromise is removing the autoload cookie only
> and leaving the (add-hook ...) to be executed upon (require 'org-eldoc).

Yes, maybe that is even better. Why would one (require 'org-eldoc) with
no intention of using it?

-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: [BUG] org-contrib: org-eldoc has an autload, but is incompatible with modern emacs. [9.6.8 (release_9.6.8-3-g21171d @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Vladimir Nikishkin  writes:

> org-contrib has the following lines 206 and 207 in org-eldoc:
> #+begin_src elisp
> ;;;###autoload
> (add-hook 'org-mode-hook #'org-eldoc-load)
> #+end_src
>
> which set up that hook automatically when the package org-contrib is
> installed.
>
> that hook is, seemingly, incompatible with the recent org-element,

May you elaborate about incompatibility?

> ... and in general it seems dubious to automatically add features from a
> deprecated repo.

This repo not deprecated, but rather not much maintained.

> Could those lines be removed? If someone is interested in
> patching/using/maintaining that code, he can probably try to refactor it
> in a better way.
>
> (In any case, it is probably better to add such hooks in the :hook
> clause of use-package.)

That would constitute incompatible change for the existing users.
Although, autoload may cause org-eldoc to be loaded for users of
org-contrib, who are not interested in org-eldoc.
What we might do as a compromise is removing the autoload cookie only
and leaving the (add-hook ...) to be executed upon (require 'org-eldoc).

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

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

[Ihor Radchenko]

Po Lu  writes:

> Ihor Radchenko  writes:
>
>> Ideally, we should ask Emacs devs to provide OS-independent interface
>> for uri-list handling. I am not a big fan of adding special OS handling
>> to Org mode, unless absolutely necessary.
>
> Inasmuch as I had previously interposed myself into this conversation,
> it should have been clear that its subject is of interest to me.  So
> herein lies the question: why was I removed from its carbon copy list,
> from nothing less than a follow-up to my reply itself?  It is common
> courtesy for some advance notice to be given to a participant who is
> about to be subject to such treatment; and was I not, I would have be
> made aware of your plight earlier -- but I digress.

Because nobody added you manually to the CC in this branch of the
discussion. You would only be automatically in the CC in the replies to
your message (87bkdccihf@yahoo.com), but not the earlier branches.

> How about enabling programs to receive drops of multiple files instead?
> Since not all window systems supply drops of multiple files in the form
> of text/uri-lists, I account that a more robust and versatile interface.

Do you mean something like a standardized entry in `dnd-protocol-alist'
that is independent on OS? Instead of (REGEXP . FUNCTION),
(SYMBOL . FUNCTION) with SYMBOL = 'file-list or so.

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

Re: [BUG] Search leaves draws open [9.7-pre (release_9.6.10-835-gf3de4c @ ~/.emacs.d/org-mode-git/lisp/)]

[Ihor Radchenko]

Paul Stansell  writes:

> In the meantime, is there a command that will close all drawers, even those
> that are open in sections (headings) that are closed?  I searched but
> didn't find anything.

org-hide-drawer-all

Re: [BUG] emacs-lisp source blocks do not implement :prologue and :epilogue [9.6.9 ( @ /home/jet/.config/emacs/elpa/org-9.6.9/)]

[Ihor Radchenko]

Jeff Trull  writes:

> Thanks for the quick fix! If my bash one-liner is right there are another
> 12:

No worries. These have also been fixed alongside with the commit I
linked to. See recent commits in 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/

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