Re: [PATCH] Re: [BUG] org-colview tests fail in Emacs 29 because of wrong org-colview's assumptions about current-column [9.5.4 (release_9.5.4-626-g45f9d8.dirty @ /home/yantar92/.emacs.d/straight/bui

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> On Emacs 29, make test will fail on both bugfix and main:
>>
>> 5 unexpected results:
>>FAILED  test-org-colview/columns-move-left
>>FAILED  test-org-colview/columns-move-right
>>FAILED  test-org-colview/columns-new
>>FAILED  test-org-colview/columns-next-allowed-value
>>FAILED  test-org-colview/columns-update
>
> I am attaching a tentative fix.

Applied onto main via 5a1b05031.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a1b050310b484426007d050c0c30bedca49ee5b

-- 
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92

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

[Joseph Turner]

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

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

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

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

[Joseph Turner]

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

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

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

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

[Joseph Turner]

Ihor Radchenko  writes:

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

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

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

Gladly.

Best,

Joseph

Re: [PATCH] ox-latex.el: `org-latex-language-alist' improved

[Juan Manuel Macías]

Max Nikulin writes:

> Likely never variant is ideal. Maybe language should be always in
> :babel and :babel-ini-only should be boolean. I am not sure though
> that it will not make code more complex in other places, so feel free
> to ignore this comment.

What you say makes a lot of sense. Really the only reason why I avoided
doing something like that was rather the economy, so I didn't have to
put things like (two properties instead of one):

:babel xx :babel-ini-only t etc.

It is also expected that babel-ini-only is a 'temporary' property. At
least I would like it to be so.

According to the Babel documentation:

> Babel is moving gradually from the old and fuzzy concept of language
> to the more modern of locale.

Which is precisely what the new ini files are meant for. Now these files
can only be loaded via \babelprovide or by adding provide=* (and some
other variants) to the babel arguments (this last option is not
supported by my patch, for pdfLaTeX compatibility, where ini files don't
work. I imagine that when that transition is complete, there will be a
more inclusive and universal interface in babel. 

Best regards,

Juan Manuel 

Re: [External] : Re: missing a character / font in agenda?

[Max Nikulin]

On 05/08/2022 13:15, Ihor Radchenko wrote:

Max Nikulin writes:


DejaVuSansMono has at least
- "\u{21fd}" "⇽" LEFTWARDS OPEN-HEADED ARROW
https://util.unicode.org/UnicodeJsps/character.jsp?a=21fd
- "\u{2190}" "←" LEFTWARDS ARROW
https://util.unicode.org/UnicodeJsps/character.jsp?a=2190
from https://en.wikipedia.org/wiki/Arrows_(Unicode_block)


"⇽" looks better on my system. However, I do not see "⇽" LEFTWARDS
OPEN-HEADED ARROW in Liberation Fonts used by default in Emacs on my
system. Though I only tested using emacs -Q + M-x describe-char


You are right. Courier New is immortal and fonts created to be 
metric-compatible with it will outlive this font. I forgot about such 
compatibility test.


Another approach would be assuming reasonable set of modern fonts and 
providing some defcustom to switch to legacy compatibility mode.

Re: Tracking todo state changes AND automatically change to done when all children are done

[Cletip Cletip]

It's ok, I managed to find it, thanks

I realize that I also have the same mistake as him (Can’t expand minibuffer
to full frame).


I'm not good enough in emacs-lisp, but I hope it's not too complicated to
solve for you ^^.

Le ven. 5 août 2022 à 04:27, Ihor Radchenko  a écrit :

> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>
>
> No problem. It's not like that thread is obviously related. I found the
> relation in the root cause, after debugging.
>
> Also, I don't understand why, but when I click on it, no site is
>> accessible. I tried to remove the "@localhost", also nothing.
>> Do you know how to follow the thread ?
>
>
> Copy-paste the link manually? IDK. The link works on my side.
> I guess you can search "org-auto-repeat-maybe: error "Can’t expand
> minibuffer to full frame" and missing log note
> " subject
> in https://list.orgmode.org/
>
> On Fri, Aug 5, 2022 at 10:11 AM Cletip Cletip 
> wrote:
>
>> Okay, I understand. Sorry for the duplicate, I didn't see this thread.
>>
>> Also, I don't understand why, but when I click on it, no site is
>> accessible. I tried to remove the "@localhost", also nothing.
>> Do you know how to follow the thread ?
>>
>> Thanks you again for your help.
>>
>> On Fri, 5 Aug 2022, 03:26 Ihor Radchenko,  wrote:
>>
>>> Cletip Cletip  writes:
>>>
>>> > So, can we consider this as a bug?
>>>
>>> Yup. And the linked thread may be the fix or at least something close.
>>>
>>> Best,
>>> Ihor
>>>
>>>

Re: folding problems

[Fraga, Eric]

On Friday,  5 Aug 2022 at 12:16, Fraga, Eric wrote:
> Thank you.  Back to "normal" (now having problems with latest Emacs updates 
> ;-)).

Heads up for those of you that might be using graphviz-dot-mode, e.g. in
dot src blocks.  The development version of Emacs has removed
font-lock-reference-face completely, marked obsolete since Emacs v20 but
still in use in the wild, specifically at least by graphviz-dot mode.

For me, this caused exporting to fail because I'm using engraved for
fontifying src blocks which depends on being able to fontify a buffer in
Emacs.

Not getting much work done today... ;-)

-- 
: Eric S Fraga, with org release_9.5.4-707-g215de6 in Emacs 29.0.50

Re: Bug? org-id-find not finding some IDs

[Ihor Radchenko]

Jack Kamm  writes:

> Ihor Radchenko  writes:
>
>> This is indeed inconsistent. The current behaviour is to scan only files
>> where it is known that IDs are present.
>>
>> Can you try the attached patch?
>
> Thanks, Ihor. I tried your patch and it solved my issue -- both the
> minimal example I sent, as well as the related issue I was experiencing
> with org-caldav.

Applied onto main via 8f5bf1725.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8f5bf172556564df89fb16ce8ecec68c5b7f0221

Best,
Ihor

> Jack

-- 
Ihor Radchenko,
Org mode maintainer,
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]: ox-latex: omit empty date

[Ihor Radchenko]

Ihor Radchenko  writes:

> Daniel Fleischer  writes:
>
>> Daniel Fleischer [2022-07-31 Sun 18:25] wrote:
>>
>> In other words \date{} is what prevents from the date being printed. Or
>> put differently \date{\today} and not putting \date is equivalent. See
>> http://www.emerson.emory.edu/services/latex/latex_125.html.
>
> Would you mind adding a short comment to the code of
> `org-latex-template' explaining this pitfall?

For record, this comment has been added in 5a49cc5f4.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a49cc5f4f09910fd03d5db590ae2b80f5981a66

Best,
Ihor

[Bug] Confusing appearance of bracket link in comment

[Max Nikulin]

Hi,

Consider an Org file containing comment with a link:

# commented out line with a [[https://orgmode.org/][link]]

At least in Emacs-26 it is rather confusing that link path and brackets
are hidden and font is the same as for comment. At the same time links 
remain active elements that can be opened.


I expect that either all components of links are visible when they are 
part of comment or font properties specific to links have higher 
priority than commented out text. Active element should not be 
indistinguishable.


At first I believed that such behavior is caused by new folding feature, 
but actually it was so long time ago (e.g. for the Org version bundled 
with Emacs-26).

Re: folding problems

[Fraga, Eric]

On Friday,  5 Aug 2022 at 19:37, Ihor Radchenko wrote:
> Hence, I have reverted the problematic commit in 1449bb31e.

Thank you.  Back to "normal" (now having problems with latest Emacs updates 
;-)).

-- 
: Eric S Fraga, with org release_9.5.4-707-g215de6 in Emacs 29.0.50

[SOLVED] Re: ?bug in org-fold-core

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ihor Radchenko  writes:

> Sharon Kimble  writes:
>
>>> I am not sure if I understand what you mean. Can you explain in more 
>>> details?
>>
>> Sure. This is one entry where 'org-lint' shows as '533 Link to non-existent 
>> local file ":~/path/to/directory/"'
>>
>> =
>> *** dired
>> # [[file+emacs:~/path/to/directory/]] ;;; opens dired at that directory
>> [[file::~/path/to/directory/]] ;;; opens dired at that directory
>> =
>>
>> This is the full org-lint for my 'instructions.org' file -
>>
>> =
>>533 low   Link to non-existent local file ":~/path/to/directory/"
>
> This is nothing wrong on Org side. Just an indication for you that you
> have issues with Org markup in your Org file. I suggest fixing them, for
> your own safety - Org may behave incorrectly on incorrect Org documents.
>
 Is it possible for it to have a file-only way of reverting to the old way 
 of 'file-local variables' please? As it currently stands, no org-headings 
 are
 shown in the colours that other org-files are showing them, and its 
 giving the appearance of org-mode not reading and displaying it!
>>>
>>> If you have no fontification, please update Org. This issue has been
>>> fixed in a yesterday's commit.
>>>
>> 
>> I'm now running using 'Org mode version 9.5.4 (release_9.5.4-706-g4702a7 @ 
>> /home/boudiccas/git/org-mode/lisp/)'. Is this the most recent version 
>> please? Git pull says that its up-to-date.
>
> This is some very strange Org version - we have no commit 4702a7. I
> suggest removing your local copy and re-fetch Org from our official
> repo. See https://orgmode.org/
>
>> I'm not sure what you mean by 'no fontification'? The instructions file has 
>> the usual org-headings, and the occasional drawer. Can you elucidate please?
>
> I probably misunderstood you. I do not understand what you mean by
>
 ... no org-headings are shown in the colours that other org-files
 are showing them, and its giving the appearance of org-mode not
 reading and displaying it!"
>

Thanks Ihor, the reversion of the local variables change has worked through its 
pipelines and I can confirm that 'Org mode version 9.5.4 
(release_9.5.4-707-g215de6 @
/home/boudiccas/git/org-mode/lisp/)' now works perfectly and my file that I 
was having problems with is now back to working as before, with no problems. 
Although I do intend to sort out the
problems shown in org-lint, in due course.

Thanks
Sharon.
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 11, fluxbox 1.3.7, emacs 29.0.50, org 9.5.4
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmLtCOcdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1tTXhAAqj5evrfY2H6iwXRu
TTpFLnSzVMcuCprxFuXY5ozKyFJ17YrN1BSoA9/DOznVedg5/aikr3HtzTBkkOfB
muFN1+c4rqgb5qwvCdhNQmcWKbJeWsxcfFHkq+56a6u/vcjpgyxg+q8jTJDuMDZx
y0WhPeXO535zZ9omXsfyeAHfud+sZvZtF/rBAJtLUxLzN8o4irKH9u8iieZbI55n
+nSIn9XRNjMwrvpHpHbAfXavcRSEALtix+mDrvCMgfMfDntexahvbfkdJ+avT2C/
iAIysxC0T6ObelU6r8pbncj5fyib5hwuGXF/7FjKe0epniBE4h+F9ev6NF2FbyNK
9y/jkPSSCwZ0x5uBAMVhcrr2FPhS/P6SpMqQFpdcOjuWo/lVWqSsJg4MOJWtug7C
NhvbPE5sz1im5pXTreamjL47chU4QXjiU1DBCYL9u0c34woLKn8HFGhY3dpDt1sI
aYbAouY/mjCw6Bcnq5LeAlo8SYXqC9o4NUXr6tIjPjrtv7GSqgdHcK+/OWfVI8/v
eMDkTPcpPGFZsSXyGxOLC8yoPwvSu6oE3yPYJ14n/FYD5FBNVHjXtK1qX6g05atc
ltaSYM0f8FGmN3TaMftq5N+1HOPuA5z3RK9NAHq0yOBgrkAvCVCiy8zS4w04tlMk
HFdcQFl5ZhS/LuuEq+Yw3zDdpSw=
=WJWv
-END PGP SIGNATURE-

Re: [PATCH] Re: Help with assigning org-attach-id-dir using directory local variables

[Ihor Radchenko]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> I've seen multiple issues coming from the above behavior.
>> Hence, I'd like to propose Org to call `hack-local-variables' early
>> during startup. The patch is attached.
>
> Applied onto main via e22b4eb7a.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e22b4eb7aab9668826dc8ba76ea1d1d7b144a856

Unfortunately, I had to revert the patch.
It creates too many issues with no good workarounds.

I instead asked Emacs devs to implement an API to let major mode decide
when local variables are loaded.
See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57003

Best,
Ihor

[PATCH] Prevent mixed installation

[Ihor Radchenko]

Hi,

The annoying mixed installation problems keep popping up in the mailing
list and other communication channels.

The attached is a patch trying to forbid loading multiple Org versions.
The idea is putting a macro that internally expands Org git version at
compile time and later compares the expanded value with the runtime
value.

Comments? Alternative ideas?

In the past we also discussed checking load-history, but I am afraid
that it will spoil the loading time. load-history can get quite large.

Also, I was thinking about using
(provide 'library '(version-subfeature))
but I have no idea how to do it automatically.

The proposed patch only requires adding two lines to newly added Org
libraries in future. Otherwise, it should just work.

Best,
Ihor

>From d493ab5e467033919ab0ce0ebf502d39e0b131b2 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Thu, 4 Aug 2022 21:53:05 +0800
Subject: [PATCH] Assert all the Org files to load the same Org version

* lisp/org-compat.el (org-assert-version): New macro comparing Org
version at compile time and laod time.

Add `org-assert-version' call to all files:

* lisp/org-macs.el:
* lisp/org-crypt.el:
* lisp/org-ctags.el:
* lisp/org-cycle.el:
* lisp/org-datetree.el:
* lisp/org-duration.el:
* lisp/org-element.el (avl-tree):
* lisp/org-entities.el:
* lisp/org-faces.el:
* lisp/org-feed.el:
* lisp/org-fold-core.el:
* lisp/org-fold.el:
* lisp/org-footnote.el:
* lisp/org-goto.el:
* lisp/org-habit.el:
* lisp/org-id.el:
* lisp/org-indent.el:
* lisp/org-inlinetask.el:
* lisp/org-keys.el:
* lisp/org-lint.el:
* lisp/org-list.el:
* lisp/org-macro.el:
* lisp/org-mobile.el:
* lisp/org-mouse.el:
* lisp/org-num.el:
* lisp/org-pcomplete.el:
* lisp/org-persist.el:
* lisp/org-plot.el:
* lisp/org-protocol.el:
* lisp/org-refile.el:
* lisp/org-src.el:
* lisp/org-table.el:
* lisp/org-tempo.el:
* lisp/org-timer.el:
* lisp/org.el:
* lisp/ox-ascii.el:
* lisp/ox-beamer.el:
* lisp/ox-html.el:
* lisp/ox-icalendar.el:
* lisp/ox-koma-letter.el:
* lisp/ox-latex.el:
* lisp/ox-man.el:
* lisp/ox-md.el:
* lisp/ox-odt.el:
* lisp/ox-org.el:
* lisp/ox-publish.el:
* lisp/ox-texinfo.el:
* lisp/ox.el:
---
 lisp/ob-C.el   |  3 +++
 lisp/ob-R.el   |  3 +++
 lisp/ob-awk.el |  4 
 lisp/ob-calc.el|  4 
 lisp/ob-clojure.el |  4 
 lisp/ob-comint.el  |  4 
 lisp/ob-core.el|  4 
 lisp/ob-css.el |  4 
 lisp/ob-ditaa.el   |  4 
 lisp/ob-dot.el |  4 
 lisp/ob-emacs-lisp.el  |  2 ++
 lisp/ob-eshell.el  |  3 +++
 lisp/ob-eval.el|  3 +++
 lisp/ob-exp.el |  4 
 lisp/ob-forth.el   |  4 
 lisp/ob-fortran.el |  4 
 lisp/ob-gnuplot.el |  4 
 lisp/ob-groovy.el  |  4 
 lisp/ob-haskell.el |  3 +++
 lisp/ob-java.el|  4 
 lisp/ob-js.el  |  4 
 lisp/ob-julia.el   |  4 
 lisp/ob-latex.el   |  4 
 lisp/ob-lilypond.el|  4 
 lisp/ob-lisp.el|  4 
 lisp/ob-lob.el |  4 
 lisp/ob-lua.el |  4 
 lisp/ob-makefile.el|  3 +++
 lisp/ob-matlab.el  |  4 
 lisp/ob-maxima.el  |  4 
 lisp/ob-ocaml.el   |  4 
 lisp/ob-octave.el  |  4 
 lisp/ob-org.el |  4 
 lisp/ob-perl.el|  3 +++
 lisp/ob-plantuml.el|  4 
 lisp/ob-processing.el  |  4 
 lisp/ob-python.el  |  4 
 lisp/ob-ref.el |  4 
 lisp/ob-ruby.el|  4 
 lisp/ob-sass.el|  4 
 lisp/ob-scheme.el  |  4 
 lisp/ob-screen.el  |  4 
 lisp/ob-sed.el |  4 
 lisp/ob-shell.el   |  3 +++
 lisp/ob-sql.el |  4 
 lisp/ob-sqlite.el  |  4 
 lisp/ob-table.el   |  4 
 lisp/ob-tangle.el  |  3 +++
 lisp/ob.el |  4 
 lisp/oc-basic.el   |  3 +++
 lisp/oc-biblatex.el|  4 
 lisp/oc-bibtex.el  |  4 
 lisp/oc-csl.el |  4 
 lisp/oc-natbib.el  |  4 
 lisp/oc.el |  3 +++
 lisp/ol-bbdb.el|  3 +++
 lisp/ol-bibtex.el  |  3 +++
 lisp/ol-docview.el |  2 ++
 lisp/ol-doi.el |  3 +++
 lisp/ol-eshell.el  |  2 ++
 lisp/ol-eww.el |  4 
 lisp/ol-gnus.el|  3 +++
 lisp/ol-info.el|  3 +++
 lisp/ol-irc.el |  3 +++
 lisp/ol-man.el |  3 +++
 lisp/ol-mhe.el |  3 +++
 lisp/ol-rmail.el   |  3 +++
 lisp/ol-w3m.el |  3 +++
 lisp/ol.el |  3 +++
 lisp/org-agenda.el |  3 +++
 lisp/org-archive.el|  3 +++
 lisp/org-attach-git.el |  3 +++
 lisp/org-attach.el |  3 +++
 lisp/org-capture.el|  3 +++
 lisp/org-clock.el  |  3 +++
 lisp/org-colview.el|  3 +++
 lisp/org-compat.el |  3 +++
 lisp/org-crypt.el  |  3 +++
 lisp/org-ctags.el  |  3 +++
 lisp/org-cycle.el  |  3 +++
 lisp/org-datetree.el   |  3 +++
 lisp/org-duration.el   |  3 +++
 lisp/org-element.el|  2 ++
 lisp/org-entities.el   |  3 +++
 lisp/org-faces.el  |  3 

Re: folding problems

[Ihor Radchenko]

"Fraga, Eric"  writes:

> On Friday,  5 Aug 2022 at 09:45, Ihor Radchenko wrote:
>> If you have some time, can you try the attached patch?
>
> I have tried it but it doesn't seem to solve the issue of multiple
> responses required due to "unsafe" dir local variables unfortunately.
>
> I may remove that particular setting and do what I am doing slightly
> differently or maybe just record it as being safe...  But, for the
> record, the dir local setting is:
>
> ((org-mode . ((org-babel-pre-tangle-hook
> . (esf/update-julia-project-toml-version save-buffer)

Thanks for providing an example!
I was able to reproduce, and I have to say that fixing this is getting
into fragile terrain. I'm afraid that early loading of local variables is
too tricky to implement. It should better be done on Emacs side as an
option.

Hence, I have reverted the problematic commit in 1449bb31e.
Thanks for the heads-up and the patience!

Best,
Ihor

Re: Odd characters in the fast tags selection interface

[Hanno]

>> - after "a..z" runs out, '{', '|' and '}' are being used which seems
>>   reasonable -- but after that, I get '\200' and similar before reaching
>>   '©'...
>
>This is indeed true, but what can we do? There are only that many
>characters in the keyboard. We may instead start using two-key
>combinations for tags beyond #26, similar to org-capture. Patches are
>welcome!

Thanks for the fast reply and fully agreed! I would indeed argue that 
automatically generated keys are not useful beyond a certain number (N=26?) as 
they could change with new tags and thus are hard to memorize. And taking in >N 
random choices every time is hardly "fast select" anymore.

In fact, the docstring for =org-fast-tag-selection= says that only a-z would be 
automatically assigned. That sounds reasonable to me (otherwise one can define 
more keys via =org-tag-persistent-alist=). Maybe this is a bug after all? If 
more than 26 choices are desired, maybe A-Z (i.e. capital letters) could extend 
the list before more unusual characters?

What do you think?

I am not at my computer right now but could try to come up with a patch later.


>> - when defining my own keys, they are not displayed in the top; instead
>>   their characters are missing in the 'a'..'z' range leaving more room
>>   for odd and very difficult-to-type characters
>I think that it would make sense to have `org-tag-persistent-alist`
>staff being shown on top. Unless there are objections I can merge this
>trivial change.

Thanks, that already improves the usability a lot!

Thanks and cheers,
Hanno

[PATCH] org-export: Make results of named code blocks a valid link

[Ihor Radchenko]

reza  writes:

> On 8/5/22 03:48, Ihor Radchenko wrote:
>> 
>> This email is already a bug report :)
> Haha nice :)
>> 
>> However, we cannot just blindly carry over the name tag to the result.
>> 
>> Consider a case when you have ":results both" in your src block. Where
>> should the [[html transformation]] link refer to? The src block? The
>> resulting image?
>> 
> Perhaps it is sufficient to add a hint to the error message:
>
> unable to resolve link, name tag is on source but you specified :exports 
> results

This would be tricky. The export code is only presented with buffer
version to be exported. All the :exports none/:exports results code
blocks are removed when we resolve links.

> Or just carry it over for :exports results only?

I like this idea better. See the attached patch.
After the patch, links to :exports both blocks will be ambiguous, unless
the results are explicitly named. So, I documented this detail in the
manual.

Let me know if there are any objections.

Best,
Ihor

>From 0a0dda33cee7355602feb954e0645ed8652e0983 Mon Sep 17 00:00:00 2001
Message-Id: <0a0dda33cee7355602feb954e0645ed8652e0983.1659694297.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Fri, 5 Aug 2022 18:09:02 +0800
Subject: [PATCH] org-export: Make results of named code blocks a valid link
 target

* lisp/ox.el (org-export-search-cells): Use #+RESULTS keyword as
search cell when #+NAME is not provided.  Update the docstring
accordingly.
(org-export-resolve-fuzzy-link): Update the docstring.

* doc/org-manual.org (Exporting Code Blocks): Document the new
behavior and explain the details of exporting links to named code
blocks/results.

Fixes https://orgmode.org/list/010201826cb68597-bf75d596-7890-4dd0-b9ff-0c7b617b4dd4-000...@eu-west-1.amazonses.com
---
 doc/org-manual.org | 30 ++
 lisp/ox.el | 10 ++
 2 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 466718e6e..e03fd059a 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -18283,6 +18283,36 @@ ** Exporting Code Blocks
   exported file.  Whether the code is evaluated at all depends on
   other options.  Example: =:exports none=.
 
+If a source block is named using =NAME= keyword, the same name will be
+assigned to the results of evaluation.  This way, fuzzy links pointing
+to the named source blocks exported using =:exports results= will
+remain valid and point to the results of evaluation.
+
+Results of evaluation of a named block can also be explicitly named
+using a separate =NAME= keyword.  The name value set via =NAME=
+keyword will be preferred over the parent source block.
+
+: #+NAME: code name
+: #+BEGIN_SRC emacs-lisp :exports both value
+: (+ 1 2)
+: #+END_SRC
+:
+: #+NAME: results name
+: #+RESULTS: code name
+: 3
+:
+: This [[code name][link]] will point to the code block.
+: Another [[results name][link]] will point to the results.
+
+Explicit setting of the result name may be necessary when a named code
+block is exported using =:exports both=.  Links to such block may
+arbitrarily point either to the code block or to its results when
+results do not have a distinct name.
+
+Note that all the links pointing to a source block exported using
+=:exports none= will be broken.  This will make export process fail,
+unless broken links are allowed during export (see [[*Export Settings]]). 
+
 #+vindex: org-export-use-babel
 To stop Org from evaluating code blocks to speed exports, use the
 header argument =:eval never-export= (see [[*Evaluating Code Blocks]]).
diff --git a/lisp/ox.el b/lisp/ox.el
index 57d375b35..433272915 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -4312,7 +4312,7 @@ (defun org-export-search-cells (datum)
 - target's or radio-target's name as a list of strings if
   TYPE is `target'.
 
-- NAME affiliated keyword if TYPE is `other'.
+- NAME or RESULTS affiliated keyword if TYPE is `other'.
 
 A search cell is the internal representation of a fuzzy link.  It
 ignores white spaces and statistics cookies, if applicable."
@@ -4330,7 +4330,8 @@ (defun org-export-search-cells (datum)
 		(and custom-id (cons 'custom-id custom-id)))
 (`target
  (list (cons 'target (split-string (org-element-property :value datum)
-((and (let name (org-element-property :name datum))
+((and (let name (or (org-element-property :name datum)
+(car (org-element-property :results datum
 	  (guard name))
  (list (cons 'other (split-string name
 (_ nil)))
@@ -4362,8 +4363,9 @@ (defun org-export-resolve-fuzzy-link (link info  pseudo-types)
 
 - If LINK path matches a target object (i.e. <>) return it.
 
-- If LINK path exactly matches the name affiliated keyword
-  (i.e. #+NAME: path) of an element, return that element.
+- If LINK path exactly matches the name or results affiliated keyword
+  (i.e. #+NAME: path or #+RESULTS: name) of an element, return that
+  element.
 
 - If LINK path 

Re: folding problems

[Fraga, Eric]

On Friday,  5 Aug 2022 at 09:45, Ihor Radchenko wrote:
> If you have some time, can you try the attached patch?

I have tried it but it doesn't seem to solve the issue of multiple
responses required due to "unsafe" dir local variables unfortunately.

I may remove that particular setting and do what I am doing slightly
differently or maybe just record it as being safe...  But, for the
record, the dir local setting is:

((org-mode . ((org-babel-pre-tangle-hook
. (esf/update-julia-project-toml-version save-buffer)

Thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.4-706-g4702a7.dirty in Emacs 29.0.50

Re: Internal link to resulting image from source block

[reza]

On 8/5/22 03:48, Ihor Radchenko wrote:
> 
> This email is already a bug report :)
Haha nice :)
> 
> However, we cannot just blindly carry over the name tag to the result.
> 
> Consider a case when you have ":results both" in your src block. Where
> should the [[html transformation]] link refer to? The src block? The
> resulting image?
> 
Perhaps it is sufficient to add a hint to the error message:

unable to resolve link, name tag is on source but you specified :exports 
results

Or just carry it over for :exports results only?

WDYT?



OpenPGP_0xC375C6AF05125C52.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature

Re: [External] : Re: missing a character / font in agenda?

[Ihor Radchenko]

Max Nikulin  writes:

> DejaVuSansMono has at least
> - "\u{21fd}" "⇽" LEFTWARDS OPEN-HEADED ARROW 
> https://util.unicode.org/UnicodeJsps/character.jsp?a=21fd
> - "\u{2190}" "←" LEFTWARDS ARROW 
> https://util.unicode.org/UnicodeJsps/character.jsp?a=2190
> from https://en.wikipedia.org/wiki/Arrows_(Unicode_block)

"⇽" looks better on my system. However, I do not see "⇽" LEFTWARDS
OPEN-HEADED ARROW in Liberation Fonts used by default in Emacs on my
system. Though I only tested using emacs -Q + M-x describe-char

Best,
Ihor

[FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together

[Ihor Radchenko]

Greg Minshall  writes:

> hi.  this fails with [emacs -Q], which in my case
> : Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)
>
> and, also in whatever elpa'ish version i'm running
> : Org mode version 9.4.4 (release_9.4.4-277-g2e1c98 @ 
> /home/minshall/.emacs.d/straight/build/org/)
>
> when i specify [:results append] and also [:wrap foo], the results are
> not obviously appended.  below it seems as if the second evaluation is
> appended, then the following are prepended after the first one?

I am replying late, but let's have an explanation for this issue as a
record at least.

The observed issue is not a bug, but rather a non-intuitive behaviour.

Let me explain how Org treats the described sequence of block
executions:

#+begin_src R :results append :wrap foo
Sys.time()
#+end_src

#1:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo


#2:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo

#+begin_foo
2021-03-31 05:51:10
#+end_foo

#3:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo

#+begin_foo
2021-03-31 05:51:12
#+end_foo
#+begin_foo
2021-03-31 05:51:10
#+end_foo

And so on.

It is generally impossible to distinguish between a result consisting of
multiple paragraphs/drawers/other Org elements and the consequent
ordinary Org text. Consider:

#+begin_src elisp :results raw value
"paragraph 1

paragraph 2"
#+end_src

paragraph 3

Executing the above yields

#+begin_src elisp :results raw value
"paragraph 1

paragraph 2"
#+end_src

#+RESULTS:
paragraph 1

paragraph 2

paragraph 3

By looking at the #+RESULTS:, Org cannot possibly know if paragraph 2
belongs to the results or paragraph 3, or maybe just paragraph 1.

We may clarify this in the manual.

Another alternative could be treating
:results append drawer/code/pp/org/latex/html
differently and putting everything into a single drawer/src/export
environment like:

#+begin_src R :results append :wrap foo
Sys.time()
#+end_src

#3:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
2021-03-31 05:51:10
2021-03-31 05:51:12
#+end_foo

However, changing the behaviour will be a breaking change, which we do
not want for the sake of back-compatibility.

Instead, we may introduce something like
:results append-contents drawer
that will behave like the above.

Is there a demand to have such a feature?

Best,
Ihor