Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> This does not make sense.  According to your profiler, you are 
> still using an older
> Ihor> version of org-in-src-block-p function. Can you please make sure 
> that no obsolete .elc
> Ihor> files are present in the Org distribution? (you can run make)
>
> My mistake. I attached the previous file. Sending now the correct file.

Thanks!

> >> Just out of curiosity. which bug or improvement or new feature on 
> agenda caused this delay on
> >> showing the agenda buffer?.
>
> Ihor> Previously, determining if diary sexp is located inside src block 
> (and thus must not be
> Ihor> considered a valid match) was done (incorrectly) relying on 
> fontification. That bug has
> Ihor> been fixed to ensure correctness at the cost of performance 
> degradation.
>
> Too bad. On my case my agenda files does not have src-block's
> inside. could I set a variable telling it. For avoiding such penalty?.

No. This will be against Org syntax.
You may advice `org-agenda-skip' function let-binding
`org-in-src-block-p' to #'ignore. At your own risk.

Also, we may remove this check in future in favour of
more reliable `org-element-context'. But not yet. That function is
currently slower compared to `org-in-src-block-p'.

> Ihor> It would be interesting to see the profiler results in emacs27.
>
> Sending the emacs27 profiler too. Do You think It would be relevant doing the
> same with emacs-28?

What do you mean? I thought that you were testing newest Org + emacs-28.

Comparing the profiler reports, I also noticed that an additional
overhead is coming from the new library loaded in org-modules.
We have added 'ol-doi default module. You may remove unused libraries
from org-modules to speed up the initial startup (there will be no
difference in agenda rebuild times).

I also pushed a couple of new small optimizations, according to your
profiler report. Can you try again with the latest main?

BTW, is your Emacs 28 using native-comp?

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

Re: svg file from tikz picture

[Edouard Debry]

Hi, I had this very same question to produce svg from latex src blocks.

First, consider this example :
#+HEADER: :file test1.png
#+HEADER: :exports results
#+HEADER: :results output silent graphics file
#+HEADER: :fit yes :noweb yes :headers '("\\usepackage{tikz}" 
"\\usetikzlibrary{backgrounds}")
#+begin_src latex
\begin{tikzpicture}[background rectangle/.style={fill=olive!30}, show 
background rectangle]
\draw[->] (-3,0) -- (-2,0) arc[radius=0.5cm,start angle=-180,end angle=0] 
(-1,0) -- (1,0) arc[radius=0.5cm,start angle=180,end angle=0] (2,0) -- (3,0);
\filldraw (-1.5,0) circle[radius=1mm];
\filldraw (1.5,0) circle[radius=3mm];
\end{tikzpicture}
#+end_src

When I run it, it does create a test1.png but, it is in fact a svg file
!! This is because, as you noticed, the `org-create-formula-image`
relies on `org-preview-latex-default-process` which is set to 'dvisvgm.
If you set it to 'dvipng, it creates again a regular png file.

Then, I changed the line :
((and (string-suffix-p ".png" out-file) (not imagemagick))
into
((and (or (string-suffix-p ".png" out-file) (string-suffix-p ".svg" out-file)) 
(not imagemagick))

so that I can correctly create a svg file when I want to and, to create
a real png file (or jpg one), I add the following line to the header :
#+HEADER: :imagemagick yes :iminoptions -density 600

There is also another way to create a svg file with `htlatex` with :

 ((and (string= "svg" extension)
   (executable-find org-babel-latex-htlatex))
  ;; TODO: this is a very different way of generating the
  ;; frame latex document than in the pdf case.  Ideally, both
  ;; would be unified.  This would prevent bugs creeping in
  ;; such as the one fixed on Aug 16 2014 whereby :headers was
  ;; not included in the SVG/HTML case.
  (with-temp-file tex-file
(insert (concat
 "\\documentclass[preview]{standalone}
\\def\\pgfsysdriver{pgfsys-dvisvgm4ht.def}
"
 (mapconcat (lambda (pkg)
  (concat "\\usepackage" pkg))
org-babel-latex-htlatex-packages
"\n")
 (if headers
 (concat "\n"
 (if (listp headers)
 (mapconcat #'identity headers "\n")
   headers) "\n")
   "")
 "\\begin{document}"
 body
 "\\end{document}")))
  (when (file-exists-p out-file) (delete-file out-file))
  (let ((default-directory (file-name-directory tex-file)))
(shell-command (format "%s %s" org-babel-latex-htlatex tex-file)))
  (cond
   ((file-exists-p (concat (file-name-sans-extension tex-file) 
"0x.svg"))
(if (string-suffix-p ".svg" out-file)
(progn
  (shell-command "pwd")
  (shell-command (format "mv %s %s"
 (concat (file-name-sans-extension 
tex-file) "0x.svg")
 out-file)))
  (error "SVG file produced but HTML file requested")))
   ((file-exists-p (concat (file-name-sans-extension tex-file) ".html"))
(if (string-suffix-p ".html" out-file)
(shell-command "mv %s %s"
   (concat (file-name-sans-extension tex-file)
   ".html")
   out-file)
  (error "HTML file produced but SVG file requested")

you will notice that this is a copy-paste from the html generation with
two major differences :
- for svg generation, do not use the driver
\\def\\pgfsysdriver{pgfsys-tex4ht.def}
but rather
\\def\\pgfsysdriver{pgfsys-dvisvgm4ht.def}
which handles better fonts and probably many other things
- the svg file produced to not have the same format with this driver
  ("0x.svg")

That would be great to reimplement ob-latex.el, at least correct the
first curious behavior when you end up with a svg file although you
wanted a png one.

Hope this helps.

Regards

reza  writes:

> By setting
>
>  (setq org-babel-latex-preamble (lambda (_) 
> "\\documentclass[preview]{standalone}\n")
>
> the tikz file svg generation does run fine. Obviously the part
>
>  \\def\\pgfsysdriver{pgfsys-tex4ht.def}
>
> inside `org-babel-latex-preamble` does not play well with the svg 
> generation.
>
>
> When having a look at the code inside ob-latex.el I also encountered a 
> few stuff which made me wondering:
>
> 1. png generation is done with the preview code inside org.el 
> (org-create-formula-image), there is also a perfectly fine svg preview 
> function but this does not get used for the svg extension which does the 
> svg conversion without any external tools like inkscape (see 
> 

Re: [PATCH] Fixing refile cache use for org-goto in indirect buffers.

[Max Nikulin]

On 20/09/2022 19:44, Yuchen Pei wrote:

Thanks for the reply.
On Mon 2022-09-19 22:48:34 +0700, Max Nikulin wrote:


On 19/09/2022 12:16, Yuchen Pei wrote:

To reprod:
- make sure the org-refile-targets generates a big enough list where
the refile cache makes a difference
- visit an org file in org-refile-targets
- M-x clone-indirect-buffer-other-window
- C-0 C-c C-w to clear cache
- M-: (org-refile-get-targets)


Have you tried to execute this command in the indirect buffer?


Yes, and it would be instant (assuming (org-refile-get-targets) has been
run in the original buffer).


My hypothesis is that if refile targets are requested from an indirect 
buffer at first then next attempt from the base buffer causes 
recalculation because of previous result is not properly stored. The 
code at the end of the function requires a similar fix.



diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 16cff25bd..7189ef595 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -306,7 +306,10 @@ converted to a headline before refiling."
(dolist (f files)
  (with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f))
(or
-(setq tgs (org-refile-cache-get (buffer-file-name) descre))
+(setq tgs (org-refile-cache-get
+(buffer-file-name (when (bufferp f)
+(buffer-base-buffer f)))
+descre))


Thank you for the attempt to improve handling of indirect buffers.

I am afraid, more serious refactoring is required to reuse result of
`buffer-base-buffer', for the previous attempt to avoid issues with
`buffer-file-name' see
satotake to emacs-orgmode… [PATCH] org-refile.el: Fix the case of
*scratch* buffer. Sat, 15 May 2021 19:38:39
+0900. https://list.orgmode.org/20210515103839.8574-2-doublequotat...@gmail.com

There are several corner cases with `org-refile-cache', `org-goto',
and buffers.
- Perhaps buffer name, not file name should be used as the cache key
   if some buffer is not associated with any file. Alternatively cache
   should not be used at all.


It seems there may be problem with this idea.  If buffer name is the
key, that will mean a buffer and its indirect clone will generate two
caches, which duplicates the work, no?


Certainly if a buffer has its base buffer then file name associated with 
the base buffer should be tried at first. However besides indirect 
buffers, buffers not associated with any files at all may exist. I am 
not sure that using buffer name is a good idea for them since temporary 
buffers may be discarded and new ones with same names may be created. My 
point is that refile targets for temporary buffers should not be cached 
at all or buffer name should be used as the key. Behavior should be 
deterministic. I do not request such change from you, but maybe it is 
just an additional couple of lines at the location you are changing anyway.



So the change is an improvement (I would prefer `and' instead of
`when' in such expression, but it does not really matter). Leaving
aside other issues and more serious refactoring, it seems, storing
results to the cache requires a similar fix, so perhaps it is possible
to move "(setq f ...)" code above of "(or ...)" and reuse f as the
cache key.


Sure, I will update my patch when I get around to it again.


Great!


Please, send patches produced by "git format-patch" command.


I guess you had some problem applying the patch?


No, I missed commit message in the expected format
https://orgmode.org/worg/org-contribute.html#commit-messages
Just send the patch as an attachment.

strange errors with org-element-cache-reset and jit-lock-function void-variable org-element-citation-prefix-re

[Daniel Ortmann]

Hmmm ...
While trying to investigate one bug I have run into another odd one:

 * emacs version: GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu,
   GTK+ Version 3.22.30, cairo version 1.15.12) of 2022-09-20
 * org version: Org mode version 9.5.5 (release_9.5.5-804-gf1a197 @
   /home/dortmann/src/git-org-mode/lisp/)


These two lines are in my *Messages* buffer:
File mode specification error: (void-function org-element-cache-reset)
Error during redisplay: (jit-lock-function 1) signaled (void-variable 
org-element-citation-prefix-re)



I ran this:
dortmann@ddo-linux:.emacs.d$ emacs -Q --debug-init asdf.el
... and then ran eval-buffer.

Where asdf.el has this content:
(add-to-list 'load-path "/home/dortmann/src/git-org-mode/lisp")
(require 'org)

(setq org-capture-templates
  `(("c" "Item to current clocked task" checkitem
   (clock)
   "%i%?" :prepend t :empty-lines 1)))



Then I loaded asdf.org which has this:
* TODO start clock on this test item


The result is the failure message above.  :-/

Re: Re [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Juan Manuel Macías]

Ihor Radchenko writes:

>> Can it be extended to add properties to a
>> #BEGIN_example
>> #END_example
>> snippet?
>
> Didn't we conclude that wrapping blocks during LaTeX export should be
> done via special blocks? (This question has been raised multiple times,
> I am unsure if you are referring to the same discussion I have in mind).

Special blocks is usually the best solution for these cases. But
(without wishing to add more fuel to old discussions) I think it would
be nice to have as attr_latex a series of positions similar to the hooks
in the etoolbox LaTeX package:

\AtBeginEnvironment 
\AtEndEnvironment 
\BeforeBeginEnvironment
\AfterEndEnvironment

Something like :pre :post :precontent :postcontent.

In the case of blocks, I think this would simplify the documents a lot
if what you are looking for makes sense only in LaTeX export (special
blocks are exported to everything).

And in the case of floating objects such as tables or figures, it would
be really useful, since here you cannot resort to the use of special
blocks (*inside* those environments, I mean), and the workarounds that are
usually provided are still a bit tricky.

Best regards,

Juan Manuel 

-- 
--
--
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Juan Manuel Macías]

Ihor Radchenko writes:

> I do not like this idea.
> Please remember that headlines may be exported as parts, sections,
> subsections, list items, or paragraphs depending on the headline level.
> Arbitrary pre/post commands may unexpectedly break things during export.

I don't see why, if the user knows LaTeX and knows what he/she is doing.
Sometimes it's just adding an "\addtocontents" just before the
section/subsection,etc. The property that adds the string before and the
property that adds the string after are understood to affect the entire
heading at the current level and its contents, including lower levels.
For example, if someone wants the current heading (and all its
sublevels) not to be included in the TOC but to be included in the
headers of the pages, it would suffice to (I keep here the original name
of the properties that I proposed in the patch, but I think Maxim's
proposed name is more accurate):

---

* Section
  :PROPERTIES:
  :presec:  \setcounter{secnumdepth}{0}
  :presec+:  \addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}
  :postsec: \setcounter{secnumdepth}{2}
  :postsec+: \addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
  :END:
Lorem ipsum dolor.

** Subsection one
lorem

** Subsection two
ipsum

Which would pass to LaTeX as:

\setcounter{secnumdepth}{0} 
\addtocontents{toc}{\protect\setcounter{tocdepth}{0}\ignorespaces}

\section{Section}
Lorem ipsum dolor.
\subsection{Subsection one}
lorem
\subsection{Subsection two}
ipsum

\setcounter{secnumdepth}{2} 
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}\ignorespaces}
--

(The above can even be simplified from LaTeX by defining a simple
environment, but I've exemplified it like this to make it look better).

In what situations might this return unexpected results?

> However, I do agree that per-heading control over latex export is
> currently cumbersome.
>
> The canonical ox-latex approach to customize headline export is
> org-latex-classes variable. This variable defines (among other things)
> pre/post commands during headline export:

Apologies in advance if I misunderstood what you're suggesting, but
isn't the "org-latex-classes" property supposed to affect the structure
of the entire document? What I'm proposing here is rather something
specific to particular headings (and its entire content), like the
":ALT_TITLE:" property. If I understand correctly, what you are
suggesting is that org-latex-classes can have "local values" for
specific headings, if such headings are 'marked' with some property?

Best regards,

Juan Manuel 

--
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree'

[Max Nikulin]

On 20/09/2022 20:16, Ihor Radchenko wrote:

Max Nikulin writes:


  When REMOVE is non-nil, remove the subtree from the clipboard."
(interactive "P")
-  (setq tree (or tree (and kill-ring (current-kill 0
+  (setq tree (or tree (current-kill 0)))
(unless (org-kill-is-subtree-p tree)


The main problem the old code solves is working around user error when
kill-ring is empty. We do not really want to err in such cases; just
handle empty kill ring specially.


From my point of view "kill ring is empty" user error clearly describes 
what happens in such case, so I do not see any point to spit suggestion 
to try simple yank instead.



I agree that (and kill-ring ...) condition misses the system clipboard.
The proper way to handle this issue is explicitly catching "Kill ring is
empty" error thrown by `current-kill' (i.e. `condition-case').


Why do you believe that just allowing to propagate this error is worse?


We have 3 occurrences of (and kill-ring (current-kill 0)) constructs in
the code and may fix the problem either by replacing each instance with
`condition-case' or we may create a separate macro/function in org-macs
and use it.


Other cases (such as the one at the end of `org-paste-subtree' to 
determine if yanked text should be folded) require more care.

Re: Org mode links: Open a PDF file at a given page and highlight a given string

[Max Nikulin]

On 20/09/2022 18:54, Ihor Radchenko wrote:

Max Nikulin writes:


Currently I believe that instead of injecting up to 6 entries into
`org-file-apps' for various combinations of page, anchor, and search
pattern, it is better to add single record with function handler. Notice
that the approach presented above is not affected by the bug with
multiple regexp group. Its additional advantage is that shell is not
involved, so peculiar file names can not cause execution of some code
when quoting and escaping are messed up.

I think a set of functions for popular PDF viewers (evince, zathura,
okular, xpdf, xpopple, firefox, chromium & Co., etc.) should be defined
in some package, but I am in doubts if it suitable for Org core.

Proof of concept implementation.


Thanks for taking time to implement this proof of concept!


I have realized that it misses customization of application binary 
(exact name or full path to non-standard location).



I think that it is a very good idea for Org core to support search terms
in file links that are handled by Free Software.


Maybe I misunderstand something, but your stress on Free Software here 
surprised me. I did not mention explicitly any proprietary application 
such as Adobe Reader. On the other hand support of Chromium (that is 
free) unavoidably assumes Google Chrome and likely MS Edge with other 
derived products with same customization as chromium vs. 
chromium-browser command name discrepancy in Linux distros.



Moreover, I think that we should, by default, auto-detect and use Free
Software to open file links, when such software is installed on user
machine (unless the user explicitly instruct otherwise).


Could you, please, elaborate? E.g. for PDF file default is docview mode. 
Unless a user has an override in `org-file-apps', likely it should be 
used. Perhaps system-wide handler may be considered as a candidate, but 
on linux it means XDG MIME handlers that is not supported by Emacs, so 
only mailcap remains. Both XDG database and mailcap have no notion of 
location within the file to open.



I see Free Software support as dedicated files like ol-evince,
ol-okular, etc. The file functionality and common function may probably
be factored out into ol-file library.


I am considering a single package, something like org-pdfviewer, that 
has definitions for all popular viewers: evince, okular, firefox, 
chromium, etc. I believed that user should explicitly configure 
preferred viewer by either adding an entry with supplied function to 
`org-file-apps' or this package has its own defcustoms and the entry 
injected to some variable as you suggested in
Ihor Radchenko. Re: [PATCH v2] org.el: Fix percent substitutions in 
`org-open-file' Mon, 05 Sep 2022 13:46:41 +0800. 
https://list.orgmode.org/875yi2xtj2.fsf@localhost


The point of defcustoms in the package instead of (or in addition to) 
`org-file-apps' is that evince and okular support more formats than PDF.

[no subject]

[Joshua Honeycutt]

To: emacs-orgmode@gnu.org
Subject: Bug: org-html-example-block can produce multiple class attributes [9.4 
(9.4-dist @ /usr/share/emacs/site-lisp/elpa/org-9.4/)]
From: Joshua Honeycutt 
--text follows this line--

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
 of 2021-03-27, modified by Debian
Package: Org mode version 9.4 (9.4-dist @ 
/usr/share/emacs/site-lisp/elpa/org-9.4/)

I added a class attribute to an example block as in:

  #+ATTR_HTML :class cmdout
  #+BEGIN_EXAMPLE
  text text text
  #+END_EXAMPLE

I expected this to produce a html tag like:

  

but the output was instead:

  

In my browser this second class assignment was ignored.

org-html-example-block could instead add the 'example' class to other
attributes which get placed in the  tag. I modified it to achieve
this outcome like this (from be2246a550b444560ec1718c11185ac7bfcfa646):

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 9024701aa..7036f44cd 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2546,8 +2546,11 @@ information."
   (let ((attributes (org-export-read-attribute :attr_html example-block)))
 (if (plist-get attributes :textarea)
(org-html--textarea-block example-block)
-  (format "\n%s"
+  (format "\n%s"
  (let* ((reference (org-html--reference example-block info))
+(class (plist-get attributes :class))
+(attributes (plist-put attributes :class
+   (if class (concat class " example") 
"example")))
 (a (org-html--make-attribute-string
 (if (or (not reference) (plist-member attributes :id))
 attributes

RE: You can now support Org-mode through https://liberapay.com/org-mode/

[Cook, Malcolm]

Thanks for all you do – donation forthcoming!

From: Emacs-orgmode  On Behalf 
Of Bastien
Sent: Saturday, September 17, 2022 3:32 AM
To: emacs-orgmode@gnu.org
Subject: You can now support Org-mode through https://liberapay.com/org-mode/

CAUTION: This email is from an External Source. Please use proper judgment and 
caution when opening attachments, clicking links, or responding to this email.


Dear all,

We recently set up a Liberapay team for processing donations made to
Org-mode contributors:

https://liberapay.com/org-mode/

For now, the team is comprised of Ihor, Timothy (TEC) and me.

If you have a Liberapay account and are a maintainer of one of Org's
core file, please don't hesitate to join this team.

The team is also open to non-code contributors: e.g. people who spend
time answering questions on this list or enhancing Worg documentation,
all these efforts that make Org valuable to everyone.

New members are added if current members all agree on adding them.

Donations are equally shared among members -- for now this amount of
donations is 10€ per week, so don't be shy.

Thanks to Ihor for triggering this change. For more context about it,
see this thread: https://list.orgmode.org/87iloyyd1y.fsf@localhost/

--
Bastien

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> Can you please try again with the newest Org?
>
> Done (f1a1974). There is NO improvement. It still takes 33s.
> ...
> JIC: I am attaching a new profiler report.

This does not make sense.
According to your profiler, you are still using an older version of
org-in-src-block-p function. Can you please make sure that no obsolete
.elc files are present in the Org distribution? (you can run make)

> Just out of curiosity. which bug or improvement or new feature on agenda
> caused this delay on showing the agenda buffer?.

Previously, determining if diary sexp is located inside src block (and thus
must not be considered a valid match) was done (incorrectly) relying on
fontification. That bug has been fixed to ensure correctness at the cost
of performance degradation.

> Ihor> Also, note that a good fraction of loading time is taken by 
> org-modules (19%) and loading
> Ihor> other libraries (10%). Subsequent agenda rebuilds should be faster.
>
> Sure. But remember I am comparing with the same conditions against
> emacs27 which takes 22s.

It would be interesting to see the profiler results in emacs27.

Also, the new code is capable of caching some data across Emacs sessions
during normal usage. Though it will only make a few second difference
in you specific situation (according to the profiler data).

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

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Ihor Radchenko]

Visuwesh  writes:

>> All in all, I feel that fully respecting `use-hard-newlines' in Org is
>> not a good idea. We can do it partially (for filling), but I am afraid
>> that it may create some confusion.
>
> I am not sure what you mean by confusion here: those who have
> `use-hard-newlines' turned on are explicitly asking for it.  If
> anything, I was confused when I found org-mode did not recognise
> hard-newlines.

Let me clarify.

Current state of affairs is: Org ignores `use-hard-newlines'
Proposed: Org sometimes ignores `use-hard-newline' and sometimes not.

I do believe that what you suggest is a good idea (respecting
`use-hard-newlines' when filling). However, I notice that some people
may be more confused if we implement this FR compared to the existing
situation. So, I am asking for feedback from other users instead of
accepting the FR.

>>> -  (fill-region-as-paragraph c end justify)
>>> +  (fill-region c end justify)
>>
>> There are 3 calls to `fill-region-as-paragraph' inside
>> `org-fill-element'. If we decide to support `use-hard-newlines'
>> partially, all 3 calls should probably be replaced.
>
> AFAICT, the rest two are comments (though I cannot tell the difference
> between "comment" and "comment-block").  I replaced the one in paragraph
> since that was where lack of hard-newlines support bit me.

# This is
# a comment

#+begin_comment
This is a
comment block.
#+end_comment

See 13.6 Comment Lines section of the manual.

I do not see why `use-hard-newline' should affect normal paragraphs but
not comments.

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

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:

>>> All in all, I feel that fully respecting `use-hard-newlines' in Org is
>>> not a good idea. We can do it partially (for filling), but I am afraid
>>> that it may create some confusion.
>>
>> I am not sure what you mean by confusion here: those who have
>> `use-hard-newlines' turned on are explicitly asking for it.  If
>> anything, I was confused when I found org-mode did not recognise
>> hard-newlines.
>
> Let me clarify.
>
> Current state of affairs is: Org ignores `use-hard-newlines'
> Proposed: Org sometimes ignores `use-hard-newline' and sometimes not.
>
> I do believe that what you suggest is a good idea (respecting
> `use-hard-newlines' when filling). However, I notice that some people
> may be more confused if we implement this FR compared to the existing
> situation. So, I am asking for feedback from other users instead of
> accepting the FR.

My point is that I don't see how this is confusing when the user who
turns on use-hard-newlines knows all its caveats, but like you say, lets
see what others say.

>> AFAICT, the rest two are comments (though I cannot tell the difference
>> between "comment" and "comment-block").  I replaced the one in paragraph
>> since that was where lack of hard-newlines support bit me.
>
> [...]
>
> I do not see why `use-hard-newline' should affect normal paragraphs but
> not comments.

I phrased my poorly.  I did not look at the calls of
fill-paragraph-as-region simply because the I hadn't tried to use
hard-newlines in comments.  I agree that we should support it comments
too.

Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Ihor Radchenko]

Juan Manuel Macías  writes:

> I don't know if the following scenario usually appears in the workflow
> of other Org users as well. Otherwise, I think this patch could be
> ignored.
>
> In my workflow I often need to pre- or postpend some LaTeX code
> immediately before or after a section. Consider the following example:
>
> --
> * A section
>
> Lorem ipsum
>
> #+latex: \foo
>
> * Another section
>
> Lorem ipsum
> -
>
> The \foo command affects the second section, but for Org it belongs to
> the content of the first section. If I comment this section out or mark
> it as non-exportable, then the LaTeX code has no effect. I think a
> simple solution could be to have the PRESEC AND POSTSEC properties to
> prepend or postpend arbitrary code to a section. These properties could be
> extended with PRESEC+ and POSTSEC+. An example of use:

I do not like this idea.
Please remember that headlines may be exported as parts, sections,
subsections, list items, or paragraphs depending on the headline level.
Arbitrary pre/post commands may unexpectedly break things during export.

However, I do agree that per-heading control over latex export is
currently cumbersome.

The canonical ox-latex approach to customize headline export is
org-latex-classes variable. This variable defines (among other things)
pre/post commands during headline export:

>> The sectioning structure of the class is given by the elements
>> following the header string.  For each sectioning level, a number
>> of strings is specified.  A %s formatter is mandatory in each
>> section string and will be replaced by the title of the section.
>> 
>> Instead of a cons cell (numbered . unnumbered), you can also
>> provide a list of 2 or 4 elements,
>> 
>>   (numbered-open numbered-close)
>> 
>> or
>> 
>>   (numbered-open numbered-close unnumbered-open unnumbered-close)
>> 
>> providing opening and closing strings for a LaTeX environment
>> that should represent the document section.  The opening clause
>> should have a %s to represent the section title.
>> 
>> Instead of a list of sectioning commands, you can also specify
>> a function name.  That function will be called with two
>> parameters, the (reduced) level of the headline, and a predicate
>> non-nil when the headline should be numbered.  It must return
>> a format string in which the section title will be added.

What about allowing to customize these open/close statements on
per-heading level during export? This will be more consistent with the
existing ox-latex structure.

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

Re: [PATCH] [BUG] org.el: Fix first call of `org-paste-subtree'

[Ihor Radchenko]

Max Nikulin  writes:

>  When REMOVE is non-nil, remove the subtree from the clipboard."
>(interactive "P")
> -  (setq tree (or tree (and kill-ring (current-kill 0
> +  (setq tree (or tree (current-kill 0)))
>(unless (org-kill-is-subtree-p tree)

The main problem the old code solves is working around user error when
kill-ring is empty. We do not really want to err in such cases; just
handle empty kill ring specially.

I agree that (and kill-ring ...) condition misses the system clipboard.
The proper way to handle this issue is explicitly catching "Kill ring is
empty" error thrown by `current-kill' (i.e. `condition-case').

We have 3 occurrences of (and kill-ring (current-kill 0)) constructs in
the code and may fix the problem either by replacing each instance with
`condition-case' or we may create a separate macro/function in org-macs
and use it.

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

Re: [PATCH] Updated patch, fixed data structure for table

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> +   ;; variable's value is a list from org-mode passed table 
> or list.
> +(if (listp (cdr (car vars)))
> +   (format "(let [%s]\n%s)"
> +   (mapconcat
> +(lambda (var)
> +  (format "%S '%S" (car var) (cdr var)))
> +vars
> +"\n  ")

Do I miss something, or you only test the first variable assignment here?
What if there are multiple assignments (:var a=X,b=Y)?

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

Re: Re [Patch] Pre-/postpend arbitrary LaTeX code to a section

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> Can it be extended to add properties to a
> #BEGIN_example
> #END_example
> snippet?

Didn't we conclude that wrapping blocks during LaTeX export should be
done via special blocks? (This question has been raised multiple times,
I am unsure if you are referring to the same discussion I have in mind).

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

Re: IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Russell Adams]

On Tue, Sep 20, 2022 at 05:22:50PM +0800, Ihor Radchenko wrote:
> The problem with the list is that emails often have ~minutes overheads.
> It sometimes takes unnecessary extra time to discuss small
> clarifications on list.
>
> I am wondering if we could create a common Org dev matrix room for quick
> discussions and then copy the transcript to the relevant ML thread, when
> necessary.

We have an IRC channel for real time chat. Join in anytime.

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

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Visuwesh]

[செவ்வாய் செப்டம்பர் 20, 2022] Ihor Radchenko wrote:

>> 1. When you want to end a line with a link and continue text in the
>>next line.  You don't care about the export since it will be
>>taken care of properly.
>> 2. When reflowing text with inline latex in them.  You adjust the
>>line width so that it looks like 80 columns are present in a
>>single line.  With hard-newlines, this becomes a very easy job
>>without with you have to isolate the line of interest into a
>>separate paragraph, then do the manual reflow, rinse and repeat.
>
> This sounds as a reasonable use case. However, the Emacs definition of
> hard newlines also involves re-defining paragraph breaks. I do not think
> that it is a good idea for Org to alter Org paragraph syntax depending
> on `use-hard-newlines' - it will create too much confusion when Org
> documents are opened outside Emacs.

I do not think it is necessary for org to recognise hard-newlines as a
paragraph break either since, after all, the presence of hard-newlines
is ephemeral.

>> 3. When writing a list, you give a short description at the top.
>>Then continue writing down below like this without the need to
>>insert a empty line after the first line.
>
> Note that _not_ having an empty line after the first line can be
> misleading. In Org syntax, absence of line will merge description and
> the text below into a single paragraph. It will, for example, affect
> export.

I do get your point, but sometimes there are situations where merging
does not cause confusion and I would like to have the ability to write
lists like no. 3.  This is more true when you, like me, treat org-mode
as a major-mode which enhances plain text files.  If i was exporting,
then I wouldn't rely on org-mode handling hard-newlines (kind of like
how HTML behaves wrt requiring ).

>> My point is that there are several instances where you need a solution
>> that is less aggressive than \\ and hard-newlines hit that sweet spot
>> perfectly.
>
> All in all, I feel that fully respecting `use-hard-newlines' in Org is
> not a good idea. We can do it partially (for filling), but I am afraid
> that it may create some confusion.

I am not sure what you mean by confusion here: those who have
`use-hard-newlines' turned on are explicitly asking for it.  If
anything, I was confused when I found org-mode did not recognise
hard-newlines.

>> -   (fill-region-as-paragraph c end justify)
>> +   (fill-region c end justify)
>
> There are 3 calls to `fill-region-as-paragraph' inside
> `org-fill-element'. If we decide to support `use-hard-newlines'
> partially, all 3 calls should probably be replaced.

AFAICT, the rest two are comments (though I cannot tell the difference
between "comment" and "comment-block").  I replaced the one in paragraph
since that was where lack of hard-newlines support bit me.

Re: [PATCH] Fixing refile cache use for org-goto in indirect buffers.

[Yuchen Pei]

Thanks for the reply.
On Mon 2022-09-19 22:48:34 +0700, Max Nikulin wrote:

> On 19/09/2022 12:16, Yuchen Pei wrote:
>> To reprod:
>> - make sure the org-refile-targets generates a big enough list where
>>the refile cache makes a difference
>> - visit an org file in org-refile-targets
>> - M-x clone-indirect-buffer-other-window
>> - C-0 C-c C-w to clear cache
>> - M-: (org-refile-get-targets)
>
> Have you tried to execute this command in the indirect buffer?

Yes, and it would be instant (assuming (org-refile-get-targets) has been
run in the original buffer).  This is because the code path from
org-goto has an overriding local binding of org-refile-targets to `((nil
. (:maxlevel . ,org-goto-max-level)) before calling
org-refile-get-location which calls org-refile-get-targets.

>
>> - org-goto in the original buffer takes no effort
>> - but, org-goto in the indirect buffer takes time, which is unexpected.
>
>> diff --git a/lisp/org-refile.el b/lisp/org-refile.el
>> index 16cff25bd..7189ef595 100644
>> --- a/lisp/org-refile.el
>> +++ b/lisp/org-refile.el
>> @@ -306,7 +306,10 @@ converted to a headline before refiling."
>>  (dolist (f files)
>>(with-current-buffer (if (bufferp f) f (org-get-agenda-file-buffer f))
>>  (or
>> - (setq tgs (org-refile-cache-get (buffer-file-name) descre))
>> + (setq tgs (org-refile-cache-get
>> +(buffer-file-name (when (bufferp f)
>> +(buffer-base-buffer f)))
>> +descre))
>
> Thank you for the attempt to improve handling of indirect buffers.
>
> I am afraid, more serious refactoring is required to reuse result of
> `buffer-base-buffer', for the previous attempt to avoid issues with
> `buffer-file-name' see
> satotake to emacs-orgmode… [PATCH] org-refile.el: Fix the case of
> *scratch* buffer. Sat, 15 May 2021 19:38:39
> +0900. 
> https://list.orgmode.org/20210515103839.8574-2-doublequotat...@gmail.com
>
> There are several corner cases with `org-refile-cache', `org-goto',
> and buffers.
> - Perhaps buffer name, not file name should be used as the cache key
>   if some buffer is not associated with any file. Alternatively cache
>   should not be used at all.

It seems there may be problem with this idea.  If buffer name is the
key, that will mean a buffer and its indirect clone will generate two
caches, which duplicates the work, no?

> - When an indirect buffer is narrowed down to some region
>   (e.g. created using `org-tree-to-indirect-buffer') jump targets
>   should be filtered to the displayed range.
>
> So the change is an improvement (I would prefer `and' instead of
> `when' in such expression, but it does not really matter). Leaving
> aside other issues and more serious refactoring, it seems, storing
> results to the cache requires a similar fix, so perhaps it is possible
> to move "(setq f ...)" code above of "(or ...)" and reuse f as the
> cache key.

Sure, I will update my patch when I get around to it again.

>
> Please, send patches produced by "git format-patch" command.
>

I guess you had some problem applying the patch?  I did use
(ma)git-format-patch, but had some difficulty of getting gnus to send
the formatted patch (I basically visited the patch file and ran
(message-mode), but it was missing a few header fields compared to
composing a new mail from gnus, so I manually copied over these fields).
This was why I sent two emails.  The first one[1] had an odd extra bit
of Message-ID at the bottom of the message.  Is this the one you were
referring to as not being "standard", or is the other one[2] also not
quite right?

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00322.html
[2] https://lists.gnu.org/archive/html/emacs-orgmode/2022-09/msg00323.html

Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
  

Re: FR: support hard-newlines [9.5.5 (release_9.5.5 @ /home/viz/lib/ports/emacs/lisp/org/)]

[Ihor Radchenko]

Visuwesh  writes:

> Hard-newlines [1] are an excellent way to inform Emacs to stop refilling
> lines.  In a way, this serves a similar purpose to org's \\ but with a
> major difference being that hard-newlines are not saved to file.  There
> are several cases where this is the desired behaviour:
> 1. When you want to end a line with a link and continue text in the
>next line.  You don't care about the export since it will be
>taken care of properly.
> 2. When reflowing text with inline latex in them.  You adjust the
>line width so that it looks like 80 columns are present in a
>single line.  With hard-newlines, this becomes a very easy job
>without with you have to isolate the line of interest into a
>separate paragraph, then do the manual reflow, rinse and repeat.

This sounds as a reasonable use case. However, the Emacs definition of
hard newlines also involves re-defining paragraph breaks. I do not think
that it is a good idea for Org to alter Org paragraph syntax depending
on `use-hard-newlines' - it will create too much confusion when Org
documents are opened outside Emacs.

> 3. When writing a list, you give a short description at the top.
>Then continue writing down below like this without the need to
>insert a empty line after the first line.

Note that _not_ having an empty line after the first line can be
misleading. In Org syntax, absence of line will merge description and
the text below into a single paragraph. It will, for example, affect
export.

> My point is that there are several instances where you need a solution
> that is less aggressive than \\ and hard-newlines hit that sweet spot
> perfectly.

All in all, I feel that fully respecting `use-hard-newlines' in Org is
not a good idea. We can do it partially (for filling), but I am afraid
that it may create some confusion.

I'd like to hear what others think about this.

> -(fill-region-as-paragraph c end justify)
> +(fill-region c end justify)

There are 3 calls to `fill-region-as-paragraph' inside
`org-fill-element'. If we decide to support `use-hard-newlines'
partially, all 3 calls should probably be replaced.

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

Re: Org mode links: Open a PDF file at a given page and highlight a given string

[Ihor Radchenko]

Max Nikulin  writes:

> Currently I believe that instead of injecting up to 6 entries into 
> `org-file-apps' for various combinations of page, anchor, and search 
> pattern, it is better to add single record with function handler. Notice 
> that the approach presented above is not affected by the bug with 
> multiple regexp group. Its additional advantage is that shell is not 
> involved, so peculiar file names can not cause execution of some code 
> when quoting and escaping are messed up.
>
> I think a set of functions for popular PDF viewers (evince, zathura, 
> okular, xpdf, xpopple, firefox, chromium & Co., etc.) should be defined 
> in some package, but I am in doubts if it suitable for Org core.
>
> Proof of concept implementation.

Thanks for taking time to implement this proof of concept!

I think that it is a very good idea for Org core to support search terms
in file links that are handled by Free Software.

Moreover, I think that we should, by default, auto-detect and use Free
Software to open file links, when such software is installed on user
machine (unless the user explicitly instruct otherwise).

I see Free Software support as dedicated files like ol-evince,
ol-okular, etc. The file functionality and common function may probably
be factored out into ol-file library.

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

Re: [BUG] org-agenda-list takes 4m compared to 27 that took 15 seconds [9.5.2 (release_9.5.2-25-gaf6f12 @ /usr/share/emacs/28.1/lisp/org/)]

[Ihor Radchenko]

andrés ramírez  writes:

> Ihor> Please try again on the latest main.
>
> Now it is taking 33s vs 22s from emacs-27 on a cold-boot.

Thanks for providing more profiling data.
I just pushed yet another performance improvement onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0057cc21e13769ec2f8971d49f4e832c6621a2ac

Can you please try again with the newest Org?

Also, note that a good fraction of loading time is taken by org-modules
(19%) and loading other libraries (10%). Subsequent agenda rebuilds
should be faster.

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

Re: [PATCH v6] New: auto display inline images under subtree when `org-cycle'.

[Christopher M. Miles]

I checked out your patch, it's fine to me. Should be fine to apply.

Ihor Radchenko  writes:

> "Christopher M. Miles"  writes:
>
>> Ok, I will submit the first patch of new property at first. If you're
>> going to implement this  cycling inline image display feature,
>> that's great!
>
> The changes to the manual are confusing after exporting. Note that
>
> #+vindex: org-image-actual-width will not be visible in html/pdf export.
> They only serve as info search nodes and do not appear in the actual
>
> text.
>
> I am attaching an alternative version of the patch. Let me know if you
> have any objections.
>
> From 475c607f874e4e78c1e13d15e36ae894b121acad Mon Sep 17 00:00:00 2001
> Message-Id: 
> <475c607f874e4e78c1e13d15e36ae894b121acad.1663656903.git.yanta...@gmail.com>
> From: stardiviner 
> Date: Thu, 15 Sep 2022 17:25:13 +0800
> Subject: [PATCH v6] org.el: Support subtree-level org-image-actual-width
>  overriding
>
> * lisp/org.el (org-display-inline-image--width): Support new property
> "ORG-IMAGE-ACTUAL-WIDTH" overriding global variable
> `org-image-actual-width'.
> ---
>  doc/org-manual.org | 186 +
>  etc/ORG-NEWS   |   4 +
>  lisp/org.el|  90 +++---
>  3 files changed, 155 insertions(+), 125 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index a37b8390c..4c9c087a7 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -11314,6 +11314,24 @@ ** Images
>startup by configuring the variable
>~org-startup-with-inline-images~[fn:119].
>  
> +
> +  #+vindex: org-image-actual-width
> +  #+cindex: @samp{ORG-IMAGE-ACTUAL-WIDTH}, property
> +  By default, Org mode displays inline images according to their actual 
> width.
> +  You can customize the displayed image width using ~org-image-actual-width~ 
> variable (globally) or =ORG-IMAGE-ACTUAL-WIDTH= property 
> (subtree-level)[fn:120].
> +  Their value can be the following:
> +  - (default) Non-nil, use the actual width of images when inlining them.
> +  - When set to a number, use imagemagick (when available) to set the
> +image's width to this value.
> +  - When set to a number in a list, try to get the width from any
> +=#+ATTR.*= keyword if it matches a width specification like:
> +#+begin_example
> +,#+ATTR_HTML: :width 300px
> +#+end_example
> +and fall back on that number if none is found.
> +  - When set to nil, try to get the width from an =#+ATTR.*= keyword
> +and fall back on the original width if none is found.
> +
>  ** Captions
>  :PROPERTIES:
>  :DESCRIPTION: Describe tables, images...
> @@ -11404,7 +11422,7 @@ ** Creating Footnotes
>#+vindex: org-footnote-define-inline
>#+vindex: org-footnote-section
>Otherwise, create a new footnote.  Depending on the variable
> -  ~org-footnote-define-inline~[fn:120], the definition is placed right
> +  ~org-footnote-define-inline~[fn:121], the definition is placed right
>into the text as part of the reference, or separately into the
>location determined by the variable ~org-footnote-section~.
>  
> @@ -11419,7 +11437,7 @@ ** Creating Footnotes
>| {{{kbd(d)}}} | Delete the footnote at point, including definition and 
> references. |
>  
>#+vindex: org-footnote-auto-adjust
> -  Depending on the variable ~org-footnote-auto-adjust~[fn:121],
> +  Depending on the variable ~org-footnote-auto-adjust~[fn:122],
>renumbering and sorting footnotes can be automatic after each
>insertion or deletion.
>  
> @@ -11609,7 +11627,7 @@ ** Export Settings
>  
>#+cindex: @samp{DATE}, keyword
>#+vindex: org-export-date-timestamp-format
> -  A date or a time-stamp[fn:122].
> +  A date or a time-stamp[fn:123].
>  
>  - =EMAIL= ::
>  
> @@ -11624,7 +11642,7 @@ ** Export Settings
>Language to use for translating certain strings
>(~org-export-default-language~).  With =#+LANGUAGE: fr=, for
>example, Org translates =Table of contents= to the French =Table des
> -  matières=[fn:123].
> +  matières=[fn:124].
>  
>  - =SELECT_TAGS= ::
>  
> @@ -11901,7 +11919,7 @@ ** Table of Contents
>  #+cindex: excluding entries from table of contents
>  #+cindex: table of contents, exclude entries
>  Org includes both numbered and unnumbered headlines in the table of
> -contents[fn:124].  If you need to exclude an unnumbered headline,
> +contents[fn:125].  If you need to exclude an unnumbered headline,
>  along with all its children, set the =UNNUMBERED= property to =notoc=
>  value.
>  
> @@ -12020,7 +12038,7 @@ ** Include Files
>  | =#+INCLUDE: "~/.emacs" :lines "10-"=  | Include lines from 10 to EOF   
> |
>  
>  Inclusions may specify a file-link to extract an object matched by
> -~org-link-search~[fn:125] (see [[*Search Options in File Links]]).  The
> +~org-link-search~[fn:126] (see [[*Search Options in File Links]]).  The
>  ranges for =:lines= keyword are relative to the requested element.
>  Therefore,
>  
> @@ -12060,7 +12078,7 @@ ** 

Re: svg file from tikz picture

[reza]

By setting

 (setq org-babel-latex-preamble (lambda (_) 
"\\documentclass[preview]{standalone}\n")

the tikz file svg generation does run fine. Obviously the part

 \\def\\pgfsysdriver{pgfsys-tex4ht.def}

inside `org-babel-latex-preamble` does not play well with the svg 
generation.


When having a look at the code inside ob-latex.el I also encountered a 
few stuff which made me wondering:

1. png generation is done with the preview code inside org.el 
(org-create-formula-image), there is also a perfectly fine svg preview 
function but this does not get used for the svg extension which does the 
svg conversion without any external tools like inkscape (see 
https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L156 and 
https://github.com/bzg/org-mode/blob/main/lisp/org.el#L3181)

2. there is a tikz extension switch which does insert the code verbatim, 
which in my opinion does create a whole bunch of problems (backend 
dependency issues). Not to mention that it also mimics behaviour which 
is reserved for the header :results (see 
https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L177).

3. there is a html extension switch with an unclear purpose to me (in 
what scenario would you want to produce an html file?). It also has some 
strange (and contradicting) checking if an svg or an html file got 
produced. As far as I can tell this code never gets executed and is 
therefore pointless (see 
https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L181).

4. the whole pdf generation looks like duplicate code which is already 
done in other parts of the code base (ox-latex.el and for the svg 
extension) it ais also not using the variable org-babel-latex-begin-env 
and org-babel-latex-end-env (see 
https://github.com/bzg/org-mode/blob/main/lisp/ob-latex.el#L225).

I don't want to criticize anyone, I just want to find answers for in my 
opinion some strange decisions.

My propositions for refactoring is:

1. use the svg preview code for svg generation (and therefore ditching 
the whole imagemagick headers)

2. remove the whole tikz generation completely

3. remove the whole html generation completely

4. try to merge pdf generation with org.el and ox-latex.el or 
incorporating it into he preview code and 
org-preview-latex-process-alist (this is probably a whole project of it own)

WDYT?

Best,
Reza


OpenPGP_0xC375C6AF05125C52.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature

Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Ihor Radchenko]

Bastien  writes:

>> Also, having an actual mirror in sr.ht means that we may set up automatic
>> tests. WDYT about this idea?
>
> Tests are useful if they prevent contributors from changing the code
> in a way that break them: this must happen before pushing changes to
> the bugfix or main branches.
>
> Automated tests are useful only if we fail to enforce this policy...
> so I'm not in favor of them.

I agree that running tests is a good idea before pushing changes.
However, it is a big ask for contributors when we need to ensure
compatibility with multiple Emacs versions. Running tests on all the
supported Emacs version simply takes too much time. Not to mention that
installing multiple Emacs versions may not be trivial. Automated tests
could cater backwards compatibility checks.

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

Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Bastien]

Ihor Radchenko  writes:

> Thanks! Should we then add an information about mirror to orgmode.org
> (or, at least, to WORG)?

On Worg, sure.

> Also, having an actual mirror in sr.ht means that we may set up automatic
> tests. WDYT about this idea?

Tests are useful if they prevent contributors from changing the code
in a way that break them: this must happen before pushing changes to
the bugfix or main branches.

Automated tests are useful only if we fail to enforce this policy...
so I'm not in favor of them.

-- 
 Bastien

Re: Org donations page statement: explain where the donations are coming to? (was: Fwd: Re: Typo in info pages)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I didn't want to disrespect you in any way. I am still glad that I made 
>> the contribution, and I know that money is not the motivation for the 
>> good development (I tried to be generous, nevertheless). However, may be 
>> it would be wise to add that link 
>> (https://list.orgmode.org/87iloyyd1y.fsf@localhost/) next to the 
>> donations link so that people understand about the context beforehand (I 
>> would have liked to read the thread). Also, I appreciate the implied 
>> transparency when you sent me the link. (That is what I think that 
>> people will like. It is also important to educate each other).
>>
>> In any case, it was just a recommendation, not a complaint :) . Cheers!
>
> I am CCing Bastien. Your suggestion sounds reasonable.

Done. Link to the discussion has been added to https://liberapay.com/org-mode

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

IM dev discussions? (was: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done)

[Ihor Radchenko]

Bastien  writes:

> Timothy  writes:
>
>> The whole top banner has become a bit messy, IMO. I’ll have a go at cleaning 
>> it
>> up later today. 
>
> As discussed on Matrix, please go ahead -- for future suggestions on
> the website, it's fine to discuss them on this list.

The problem with the list is that emails often have ~minutes overheads.
It sometimes takes unnecessary extra time to discuss small
clarifications on list.

I am wondering if we could create a common Org dev matrix room for quick
discussions and then copy the transcript to the relevant ML thread, when
necessary.

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

Re: contrib - ol-todo

[Ihor Radchenko]

Tyler Grinn  writes:

> I've built this small package which registers a todo type link:
>
> [[todo:~/projects.org::#my-todo][My todo]]
>
> And it is displayed like this:
>
>  My todo
>
> Where DONE is the actual todo keyword on the target heading. The keyword
> on the link and target stay in sync, so setting a different todo keyword
> either on the link or the target will update both. The link does not
> show up in the agenda and can be placed anywhere an org link is valid.
>
> I'm using this to create a list of todos I want done today from a larger
> list of all my todos.

Why don't just modify :activate-func in the ordinary file links?

> Is this something that would be appropriate for org-contrib?

Note that org-contrib is obsolete. See
https://git.sr.ht/~bzg/org-contrib/.

I recommend submitting your package to GNU ELPA or NonGNU ELPA.

> When I tried to register a :store function which is valid for org buffers
> backed by a file, the desired behavior was that I could choose between
> storing a file link and a todo link, but instead, it simply stores a
> todo link without confirmation. Is this a known problem?

See org-store-link-functions docstring:

>> Each function will be called in turn until one returns a non-nil
>> value.  Each function should check if it is responsible for
>> creating this link (for example by looking at the major mode).
>> If not, it must exit and return nil.  If yes, it should return
>> a non-nil value after calling org-link-store-props with a list
>> of properties and values.

Your store function can provide interactive query and return nil if the
user does not want to create todo: link.

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

Re: [PATCH] Add org-babel-tangle-finished hook

[Ihor Radchenko]

Timothy  writes:

> +(defcustom org-babel-tangle-finished-hook nil
> +  "Hook run at the very end of `org-babel-tangle'.
> +In this way, it is the counterpart to `org-babel-pre-tangle-hook'."
> +  :group 'org-babel
> +  :package-version '(Org . "9.6")
> +  :type 'hook)

I'd also mention the active buffer when the hook is ran. (And also add
the relevant info to org-babel-pre-tangle-hook docstring)

> From 167d548bf0e3434aab7af40826f7f31b8174ea27 Mon Sep 17 00:00:00 2001
> From: TEC 
> Date: Sun, 28 Aug 2022 01:29:56 +0800
> Subject: [PATCH 2/3] manual: Document org-babel-tangle-finished-hook
>
> * etc/ORG-NEWS: Mention new hook, `org-babel-tangle-finished-hook'.
>
> * doc/org-manual.org (Tangle hooks): Mention new hook,
> `org-babel-tangle-finished-hook'.
> ---
>  doc/org-manual.org |  4 
>  etc/ORG-NEWS   | 35 +--
>  2 files changed, 25 insertions(+), 14 deletions(-)
>
> diff --git a/doc/org-manual.org b/doc/org-manual.org
> index a37b8390c..2481d81e9 100644
> --- a/doc/org-manual.org
> +++ b/doc/org-manual.org
> @@ -18592,6 +18592,10 @@ *** Tangle hooks
>~org-babel-tangle~, making it suitable for post-processing,
>compilation, and evaluation of code in the tangled files.
>  
> +- ~org-babel-tangle-finished-hook~ ::
> +  #+vindex: org-babel-tangle-finished-hook
> +This hook is run after post-tangle hooks, in the original buffer.

There is no indentation in the hook description. It will start a new
paragraph after the item.

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

Re: [BUG] Info JS does not work [9.5.3 (release_9.5.3-467-g2bd34e @ /Users/salutis/src/org-mode/lisp/)]

[Ihor Radchenko]

Bastien  writes:

> FWIW, I just set this up: the org-mode.git Savannah repository is
> now mirrored to git.sr.ht and github.com every day at 1am CET.

Thanks! Should we then add an information about mirror to orgmode.org
(or, at least, to WORG)?

Also, having an actual mirror in sr.ht means that we may set up automatic
tests. WDYT about this idea?

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

Re: Properly handle defaults in org-set-property

[Ihor Radchenko]

Janek F  writes:

> As discussed in 
> https://emacs.stackexchange.com/questions/71774/pass-default-value-to-org-set-property/71777,
>  providing a default to org-set-property does not always work.
>
> It calls `org-read-property-value`, which only uses the supplied default 
> value if it can compute a list of allowed values for the property. But then, 
> the default value has to be part of that `_ALL` list.
>
> Can this be changed so it always uses the given default?

Why don't you just use

(map! :desc "Set ID property" "lI"
  '(lambda ()
 (interactive)
 (org-set-property "ID" (org-read-property-value "ID" nil 
"default-value"

?

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

Re: [PATCH] Babel evaluation: location and timing information

[Ihor Radchenko]

Timothy  writes:

> - (message "executing %s code block%s..."
> + (message "executing %s %s %s..."
>(capitalize lang)
> + (pcase (org-element-type (org-element-at-point))
> +   ('src-block "code block")
> +   ('babel-call "call")
> +   ('paragraph "inline code block"))

This will not work, for example, when inline src block is located inside
a headline. One can think of various other non-paragraph scenarios as well.

Also, even though org-element-at-point should be caching recent calls,
I'd try to test the performance before/after the patch on large number
of src blocks (like in your config). org-element-at-point can add a fair
bit of CPU load in some scenarios where we have fallback to the full
O(Log N) AVL-tree lookup.

> +(let ((time-info
> +   (if (and exec-time (> (float-time exec-time) 0.05))
> +   (format " (took %.1fs)" (float-time exec-time))

Why 0.05??

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

Re: Org donations page statement: explain where the donations are coming to? (was: Fwd: Re: Typo in info pages)

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I didn't want to disrespect you in any way. I am still glad that I made 
>> the contribution, and I know that money is not the motivation for the 
>> good development (I tried to be generous, nevertheless). However, may be 
>> it would be wise to add that link 
>> (https://list.orgmode.org/87iloyyd1y.fsf@localhost/) next to the 
>> donations link so that people understand about the context beforehand (I 
>> would have liked to read the thread). Also, I appreciate the implied 
>> transparency when you sent me the link. (That is what I think that 
>> people will like. It is also important to educate each other).
>>
>> In any case, it was just a recommendation, not a complaint :) . Cheers!
>
> I am CCing Bastien. Your suggestion sounds reasonable.

Done. Link to the discussion has been added to https://liberapay.com/org-mode

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

Re: [BUG] org-paste-subtree inserts empty line above paste

[Ihor Radchenko]

Felix Wiemuth  writes:

> Any idea what the reason could be? Could it be any configuration that 
> leads to this? Or is it probably a bug in spacemacs and I should post 
> the issue there?

If you do not see the issue using the same version of Org spacemacs uses
but without spacemacs or your config, the reason is, indeed, in
something other than Org. It should be either spacemacs tweaks to Org,
extra packages installed by spacemacs, you your personal customizations.

I would try to install stock standard spacemacs without any
configuration and try to reproduce. If you can reproduce, I'd ask
spacemacs users (probably, by filing an issue in spacemacs repo). If you
can't, the problem is likely in your config and you would try to bisect
the config (I usually use https://github.com/Malabarba/elisp-bug-hunter,
but not sure if it is easy to use with spacemacs configuration).

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

Re: orgmode.org welcome page says to install via MELPA but as writing, this cannot be done

[Bastien]

Timothy  writes:

> The whole top banner has become a bit messy, IMO. I’ll have a go at cleaning 
> it
> up later today. 

As discussed on Matrix, please go ahead -- for future suggestions on
the website, it's fine to discuss them on this list.

Thanks a lot !

-- 
 Bastien

[PATCH v6] Re: [PATCH 5] New: auto display inline images under subtree when `org-cycle'.

[Ihor Radchenko]

"Christopher M. Miles"  writes:

> Ok, I will submit the first patch of new property at first. If you're
> going to implement this  cycling inline image display feature,
> that's great!

The changes to the manual are confusing after exporting. Note that
#+vindex: org-image-actual-width will not be visible in html/pdf export.
They only serve as info search nodes and do not appear in the actual
text.

I am attaching an alternative version of the patch. Let me know if you
have any objections.

>From 475c607f874e4e78c1e13d15e36ae894b121acad Mon Sep 17 00:00:00 2001
Message-Id: <475c607f874e4e78c1e13d15e36ae894b121acad.1663656903.git.yanta...@gmail.com>
From: stardiviner 
Date: Thu, 15 Sep 2022 17:25:13 +0800
Subject: [PATCH v6] org.el: Support subtree-level org-image-actual-width
 overriding

* lisp/org.el (org-display-inline-image--width): Support new property
"ORG-IMAGE-ACTUAL-WIDTH" overriding global variable
`org-image-actual-width'.
---
 doc/org-manual.org | 186 +
 etc/ORG-NEWS   |   4 +
 lisp/org.el|  90 +++---
 3 files changed, 155 insertions(+), 125 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a37b8390c..4c9c087a7 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11314,6 +11314,24 @@ ** Images
   startup by configuring the variable
   ~org-startup-with-inline-images~[fn:119].
 
+
+  #+vindex: org-image-actual-width
+  #+cindex: @samp{ORG-IMAGE-ACTUAL-WIDTH}, property
+  By default, Org mode displays inline images according to their actual width.
+  You can customize the displayed image width using ~org-image-actual-width~ variable (globally) or =ORG-IMAGE-ACTUAL-WIDTH= property (subtree-level)[fn:120].
+  Their value can be the following:
+  - (default) Non-nil, use the actual width of images when inlining them.
+  - When set to a number, use imagemagick (when available) to set the
+image's width to this value.
+  - When set to a number in a list, try to get the width from any
+=#+ATTR.*= keyword if it matches a width specification like:
+#+begin_example
+,#+ATTR_HTML: :width 300px
+#+end_example
+and fall back on that number if none is found.
+  - When set to nil, try to get the width from an =#+ATTR.*= keyword
+and fall back on the original width if none is found.
+
 ** Captions
 :PROPERTIES:
 :DESCRIPTION: Describe tables, images...
@@ -11404,7 +11422,7 @@ ** Creating Footnotes
   #+vindex: org-footnote-define-inline
   #+vindex: org-footnote-section
   Otherwise, create a new footnote.  Depending on the variable
-  ~org-footnote-define-inline~[fn:120], the definition is placed right
+  ~org-footnote-define-inline~[fn:121], the definition is placed right
   into the text as part of the reference, or separately into the
   location determined by the variable ~org-footnote-section~.
 
@@ -11419,7 +11437,7 @@ ** Creating Footnotes
   | {{{kbd(d)}}} | Delete the footnote at point, including definition and references. |
 
   #+vindex: org-footnote-auto-adjust
-  Depending on the variable ~org-footnote-auto-adjust~[fn:121],
+  Depending on the variable ~org-footnote-auto-adjust~[fn:122],
   renumbering and sorting footnotes can be automatic after each
   insertion or deletion.
 
@@ -11609,7 +11627,7 @@ ** Export Settings
 
   #+cindex: @samp{DATE}, keyword
   #+vindex: org-export-date-timestamp-format
-  A date or a time-stamp[fn:122].
+  A date or a time-stamp[fn:123].
 
 - =EMAIL= ::
 
@@ -11624,7 +11642,7 @@ ** Export Settings
   Language to use for translating certain strings
   (~org-export-default-language~).  With =#+LANGUAGE: fr=, for
   example, Org translates =Table of contents= to the French =Table des
-  matières=[fn:123].
+  matières=[fn:124].
 
 - =SELECT_TAGS= ::
 
@@ -11901,7 +11919,7 @@ ** Table of Contents
 #+cindex: excluding entries from table of contents
 #+cindex: table of contents, exclude entries
 Org includes both numbered and unnumbered headlines in the table of
-contents[fn:124].  If you need to exclude an unnumbered headline,
+contents[fn:125].  If you need to exclude an unnumbered headline,
 along with all its children, set the =UNNUMBERED= property to =notoc=
 value.
 
@@ -12020,7 +12038,7 @@ ** Include Files
 | =#+INCLUDE: "~/.emacs" :lines "10-"=  | Include lines from 10 to EOF   |
 
 Inclusions may specify a file-link to extract an object matched by
-~org-link-search~[fn:125] (see [[*Search Options in File Links]]).  The
+~org-link-search~[fn:126] (see [[*Search Options in File Links]]).  The
 ranges for =:lines= keyword are relative to the requested element.
 Therefore,
 
@@ -12060,7 +12078,7 @@ ** Macro Replacement
 : #+MACRO: name   replacement text; $1, $2 are arguments
 
 #+texinfo: @noindent
-which can be referenced using ={{{name(arg1, arg2)}}}=[fn:126].  For
+which can be referenced using ={{{name(arg1, arg2)}}}=[fn:127].  For
 example
 
 #+begin_example
@@ -12179,7 +12197,7 @@ ** Comment Lines
 Finally, a =COMMENT= keyword