Re: [BUG] Eval src block does not redisplay inline image [9.5.1 (9.5.1-g36086a @ /Users/rob/.emacs.d/elpa/org-9.5.1/)]

[Greg Minshall]

Robert,

i have the following commented out in my .emacs.  i have no memory of
it, why i put it in, why i took it out, or if it might provide you any
clue.  but, with all those caveats...

;; in org-mode, display images inline after execution
;; except, after a while, this gets tiresome.  one can C-c C-x C-v
;; (add-hook 'org-babel-after-execute-hook 'org-display-inline-images)


cheers, Greg

bug#52399: 28.0.60; easier access to ORG-NEWS

[Kévin Le Gouguec]

Kyle Meyer  writes:

>> 3. The entry in NEWS for the Org mode update mentions ORG-NEWS, but it
>> doesn't say how to get to it.  (Yes, I know how to get to ORG-NEWS from
>> NEWS.  Do we expect random users to understand the layout of an
>> installed Emacs at that level of detail?)
>
> And I guess this one is for Emacs's side at the time of the sync.
>
> I was looking through the NEWS* files in the Emacs repo for guidance
> from other packages, but I see mostly the same thing ("GNUS-NEWS",
> "MH-E-NEWS", "ERC-NEWS", ...).  I guess there is one that's a little
> different, though I'm not sure how helpful tacking on "./" is: "See the
> file ./MH-E-NEWS for details".
>
> Do you have any suggestions for what would be more helpful to put there?

28.1 introduces etc-authors-mode; perhaps, in a similar vein, we could
add etc-news-mode, and add have the mode initialization function
buttonize these cross-references?

(Older emacsen would get confused by the "mode: etc-news" clause in
newer NEWS files, though…)

bug#52341: Fwd: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

close 52341
quit

Kyle Meyer writes:

> I suppose one solution would be to check for " " and translate that to
> the ?\s so that the remove is triggered.  I'll plan to apply the change
> below to Org's bugfix branch in a day or two unless the author of the
> above commit (+cc) or someone else has another suggestion.

Applied to the Org repo (4aca51fcb).

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Tim Cross]

"Dr. Arne Babenhauserheide"  writes:

> [[PGP Signed Part:Undecided]]
>
> Russell Adams  writes:
>
>> Did Org break your Org editing experience in Emacs for your Org files,
>> or did this change just break some of the finer formatting details of
>> your exported Org file?
>
> The change to electric indent broke my workflow badly (always having to
> undo the indentation after every new headline), and it took long until I
> found out how to avoid that.
>

That is probably a good example of how change can be imposed by external
events outside the control of org-mode. While I would agree that more
analysis of that change may have resulted in better initial
documentation and in turn, less inconvenience to users. that is only
obvious now with the benefit of hindsight. The fact it was a change
triggered by a change in Emacs rather than a change initiated by org
demonstrates that at times, org has to adapt to its evolving
environment. While this change may have 'broken' your workflow, the
previous behaviour was breaking other users workflows because org did
not honour electric-indent-mode and was not consistent with other core
emacs modes. 

bug#52399: 28.0.60; easier access to ORG-NEWS

[Kyle Meyer]

Mike Kupfer writes:

> Finding ORG-NEWS seems harder than it should be.
>
> 1. The "Browse Org News" menu item (Org > Documentation > Browse Org
> News) isn't adequate, because it takes you to orgmode.org.  The package
> description (C-h P org RET) has the same problem.  If you're working
> offline, orgmode.org is not going to be available.  Also, it shows the
> news for the latest release, which might not be what you have installed.
> (The news for older releases is available at the bottom of the page, but
> it could be confusing if you don't notice that the news that is first
> presented is for a different release.)
>
> 2. I don't see a reference to ORG-NEWS in the Org mode section of the
> Info pages, much less an easy way to get to it.

These two look like something that would be dealt with on Org's side.
This report has been reassigned there, so perhaps someone on the Org
list will have thoughts or decide to work on a patch.

> 3. The entry in NEWS for the Org mode update mentions ORG-NEWS, but it
> doesn't say how to get to it.  (Yes, I know how to get to ORG-NEWS from
> NEWS.  Do we expect random users to understand the layout of an
> installed Emacs at that level of detail?)

And I guess this one is for Emacs's side at the time of the sync.

I was looking through the NEWS* files in the Emacs repo for guidance
from other packages, but I see mostly the same thing ("GNUS-NEWS",
"MH-E-NEWS", "ERC-NEWS", ...).  I guess there is one that's a little
different, though I'm not sure how helpful tacking on "./" is: "See the
file ./MH-E-NEWS for details".

Do you have any suggestions for what would be more helpful to put there?

bug#52392: 29.0.50; org-priority 'SPC to remove' doesn't work

[Kyle Meyer]

forcemerge 52341 52392
quit

Bruce E. Robertson writes:

> 1. in init.el:
> (custom-set-variables
>  '(org-priority-default 32)
>  '(org-priority-highest 0)
>  '(org-priority-lowest 31)
> )
> 2. position to line in .org file:
[...]

This looks like a duplicate of https://debbugs.gnu.org/52341 (which has
already received comments), so I'm merging the reports.

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Dr. Arne Babenhauserheide]

Russell Adams  writes:

> Did Org break your Org editing experience in Emacs for your Org files,
> or did this change just break some of the finer formatting details of
> your exported Org file?

The change to electric indent broke my workflow badly (always having to
undo the indentation after every new headline), and it took long until I
found out how to avoid that.

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


signature.asc
Description: PGP signature

Re: Patch to align baseline of latex fragments and surrounding text

[Matt Huszagh]

Sébastien Miquel  writes:

> This looks great indeed but I've failed to reproduce in my
> environment.

Thanks for testing this Sébastien.

> I couldn't get ~org--match-text-baseline-ascent~ to compute the
> ascent : the ~xml-get-attribute~ call returns
>   : ("-16.945024" "12.153473" "16.148855" "8.064997")
> which gives an ascent < -100, and the code then defaults to 'center.

I'd need to know more about your setup for generating latex
fragments. Did you follow all the directions in
org--match-text-baseline-ascent? How is your org-format-latex-header
set? In particular, are you using \documentclass[preview]{standalone}?
If you can provide me with the TeX file used to generate the fragment,
as well as the SVG file you get as a result, that would be helpful too.

> The options described in your =my-dvisvgm= seem outdated, you can
> check the latest default value of =dvisvgm= : =use-xcolor= is
> deprecated and a =:image-size-adjust= property is provided for the
> images to be sized properly. Are the arguments =--no-fonts= and
> =--exact-bbox= necessary ?

Hm, I'm not actually sure why I put use-xcolor in there, but it isn't
necessary. I've removed it in the updated patch (attached).

:image-size-adjust isn't necessary, I just mentioned it to point out
that baseline alignment works regardless of the size of a latex fragment
(I have another open PR that allows setting the size of fragments in a
context dependent way, which can be used for instance, to keep fragments
size-aligned to the surrounding text). I expect using the scale
parameter in org-format-latex-options will work similarly, but I'll
investigate.

--no-fonts is the same as -n. The --exact-bbox flag is necessary to
avoid cropping in certain cases (see
https://github.com/mgieseki/dvisvgm/issues/8). You're free to use
--bbox=min, but your glyphs may be cut off in places and this may affect
the baseline location too, though I haven't tested it.

> If there are no drawbacks, perhaps this behaviour should be the
> default. Otherwise, it should at least be easier to toggle.

I didn't attempt to make this the default because it requires a specific
setup, which is also different from the current default setup in other
respects. Most importantly, it requires using the standalone document
class, though I believe article is used at the moment.

> Can something similar be done with =dvipng= ?

Unfortunately I don't think so. This code isn't doing anything fancy; it
has no way of computing the text baseline from some arbitrary image file
displaying text. Instead, it relies on some other tool providing this
information inside the image file. In this case, standalone encodes this
information in the viewbox of the SVG file.

Thanks
Matt

>From 2640b24d2cce8e2b61101125c348db35800570ff Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Sun, 10 Oct 2021 15:46:05 -0700
Subject: [PATCH] org--make-preview-overlay: Add ability to set vertical
 alignment of latex fragments

* lisp/org.el (org--match-text-baseline-ascent): Add function that
computes the value of :ascent to match the baseline of the fragment to
the surrounding text.
(org-latex-fragment-overlay-ascent): Add custom variable that allows a
function to be used to compute the value of :ascent.
(org--make-preview-overlay): Incorporate the custom variable.
---
 lisp/org.el | 88 +++--
 1 file changed, 79 insertions(+), 9 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 405f0f0f9..91a4d0bf5 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -320,6 +320,73 @@ identifier."
   :version "24.1"
   :group 'org-id)
 
+(defun org--match-text-baseline-ascent (imagefile imagetype)
+  "Set :ascent to match the text baseline of an image to the surrounding text.
+IMAGEFILE is the path of the image file and IMAGETYPE is the
+image file type.
+
+This function currently only works for SVG images (defaulting to
+'center otherwise).  It also requires that the SVG's viewbox is
+correctly set according to the text baseline position.
+Specifically, it computes
+
+ascent = 100 * -min-y / height
+
+where min-y and height are taken from the viewbox.  If this
+computation returns a non-sensical value (below 0 or above 100),
+it will return 'center instead.
+
+It's possible to include text baseline information in the viewbox
+by using \\documentclass[preview]{standalone} in the input LaTeX
+file, compiling first to DVI and then converting this to an SVG
+image with dvisvgm.
+
+For example,
+
+(setq my-dvisvgm
+  '(my-dvisvgm :programs (\"latex\" \"dvisvgm\")
+   :description \"dvi > svg\"
+   :message \"you need to install latex and dvisvgm.\"
+   :image-input-type \"dvi\"
+   :image-output-type \"svg\"
+   :latex-compiler (\"latex -output-directory=%o %f\")
+   :image-converter (\"dvisvgm --no-fonts --exact-bbox -c %S -o %O %f\")))
+
+(add-to-list 'org-preview-latex-process-alist 

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Juan Manuel Macías writes:

> Jumping into the "real world", how about these two examples of nested 
> emphasis?

By the way, what do you think about allowing the use of some kind of
aliases, so that the aspect is less verbose? Maybe something like "(i::"
instead of "(italic () ..."? I came up with this hasty sketch over your
latest code, *just* to see how it looks (I don't know if I prefer it to
stay verbose):

#+begin_src emacs-lisp :results silent
 (setq orgia-alias-alist '(("i" "italic")
   ("b" "bold")
   ("u" "underline")
   ("s" "strike-through")))

  (defun orgia-replace (before after)
(interactive)
(save-excursion
  (goto-char (point-min))
  (while (re-search-forward before nil t)
(replace-match after t nil

  (defun orgia--transform-path (path)
(with-temp-buffer
  (insert path)
  (mapc (lambda (el)
  (orgia-replace (concat "(" (car el) "::") (concat "(" (cadr el) " 
() ")))
orgia-alias-alist)
  (buffer-string)))

  (defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
  (let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
  (read (orgia--transform-path path)) ;; <
;;
 #+end_src

#+begin_src elisp
   (org-export-string-as "An word"
'odt t)
#+end_src

#+RESULTS:
: 
: An interword


#+begin_src org :results latex :results replace
  [[orgia:(i:: "The English versions of the " (b:: (i:: "Iliad")) " and the " 
(b:: (i::
  "Odyssey")))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the 
\textbf{\emph{Odyssey}}}
#+end_export


--
Juan Manuel Macías 

https://juanmanuelmacias.com/

Re: org-cite and export to ODT

[András Simonyi]

Dear All,

On Thu, 9 Dec 2021 at 10:54, Xianwen Chen (陈贤文)  wrote:

> Thinking about the new org-cite, which is orgmode's native citation solution, 
> I'm wondering if it would be easier to use org-cite within orgmode and export 
> to ODT? A small example with configuration suggestion will be highly 
> appreciated!
>
> Xianwen

org-cite contains two citation export processors which are able to
export citations to ODT: oc-basic and oc-csl. A minimal example using
oc-csl could be along the following lines:

[ cut here ]
#+bibliography: /path/to/my.bib
#+cite_export: csl

[cite:@smith1998]

* References
#+print_bibliography:
[ cut here ]

details can be found in the Org manual
(https://orgmode.org/manual/Citation-handling.html#Citation-handling).

best wishes,
András

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Samuel Wales]

i think the big change was v9.

On 12/9/21, Eric S Fraga  wrote:
> On Thursday,  9 Dec 2021 at 16:21, Russell Adams wrote:
>> Did Org break your Org editing experience in Emacs for your Org files,
>> or did this change just break some of the finer formatting details of
>> your exported Org file?
>
> It's been a while but, IIRC, the latter to a large extent; I should have
> been more clear.
>
> However, there have been changes in the past that affected the editing
> experience but I cannot remember if they were with v8 or v9 or somewhere
> in between, particularly dealing with locations of :LOGBOOK: and
> scheduling directives.  These happened when Nikolas cleaned up the
> parsing, to the benefit of org but at the cost of making some documents
> non-compliant.
>
> Nevertheless, as others have stated, given the stability provided by
> Emacs (parts of my .emacs date back to 1985!), and org being all text,
> even breaking changes are usually trivial to correct or adjust to.
>
> --
> : Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: Patch to align baseline of latex fragments and surrounding text

[Sébastien Miquel]

Hi,

Matt Huszagh writes:

I feel that maybe it would be useful to attach screenshots to show the
improvement from this patch? Anyway, I've attached two images: one with
the correct baseline alignment to surrounding text and the other with
the current, incorrect, baseline alignment.

I think a lot of people would like this functionality. It looks much
better than the current behavior.

This looks great indeed but I've failed to reproduce in my
environment.

I couldn't get ~org--match-text-baseline-ascent~ to compute the
ascent : the ~xml-get-attribute~ call returns
 : ("-16.945024" "12.153473" "16.148855" "8.064997")
which gives an ascent < -100, and the code then defaults to 'center.

The options described in your =my-dvisvgm= seem outdated, you can
check the latest default value of =dvisvgm= : =use-xcolor= is
deprecated and a =:image-size-adjust= property is provided for the
images to be sized properly. Are the arguments =--no-fonts= and
=--exact-bbox= necessary ?

If there are no drawbacks, perhaps this behaviour should be the
default. Otherwise, it should at least be easier to toggle.

Can something similar be done with =dvipng= ?

Regards,

--
Sébastien Miquel

[BUG] Eval src block does not redisplay inline image [9.5.1 (9.5.1-g36086a @ /Users/rob/.emacs.d/elpa/org-9.5.1/)]

[Robert Nikander]

I’m trying to use Org mode like a Jupyter notebook. I’ve got something working, 
but for graphic plots, I have to call `org-display-inline-images` after every 
call to `org-babel-execute-src-block`. I guess there is a work-around, 
described here:

https://stackoverflow.com/questions/54269390/how-to-always-show-inline-images 


But it seems like a bug. ?

My example block:

#+begin_src ess-julia :results output graphics file :file FILENAME.png :session 
*julia* :exports both
  using Plots
  x = 1:0.02:10; y = sin.(10x) 
  plot(x, y, label="test")
#+end_src

After running it inserts this:

#+RESULTS:
[[file:FILENAME.png]]

As described in the stackoverflow Q, I can then run 
`org-redisplay-inline-images` or other commands to show the image.

Rob



Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 
Version 10.14.6 (Build 18G95))
 of 2021-11-18
Package: Org mode version 9.5.1 (9.5.1-g36086a @ 
/Users/rob/.emacs.d/elpa/org-9.5.1/)

[BUG] Agenda display + blocked habits + org-agenda-dim-blocked-tasks set to 'invisible

[Ignacio Casso]

Hello,

I think I've found a bug in the agenda display when
'org-agenda-dim-blocked-tasks' is set to 'invisible', and there is a task
that is a habit (i.e., 'STYLE' property set to 'habit') and is blocked
(e.g., because 'org-enforce-todo-dependencies' is set to 't' or there is
an 'ORDERED' property). In this scenario, the task does not appear in the
agenda, but its consistency graph does appear, and not in a separate
line, but appended to the end of the previous line, be it the previous
task or the header line with the date.

To reproduce the bug, only this minimal configuration and generating the
agenda for this file is needed:

(require 'org-habit)
(customize-set-variable 'org-agenda-dim-blocked-tasks 'invisible)


* Some habit
:PROPERTIES:
:ORDERED:  t
:END:
** TODO Habit 1
SCHEDULED: <2021-12-09 jue .+1d>
:PROPERTIES:
:STYLE:    habit
:END:
** TODO Habit 2
SCHEDULED: <2021-12-09 jue .+1d>
:PROPERTIES:
:STYLE:    habit
:END:

Best regards,

Ignacio

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian
Package: Org mode version 9.5 (9.5-g0a86ad @ 
/home/ignacio/.emacs.d/elpa/org-9.5/)

[BUG] Inconsistent behaviour of TODO + COMMENT + TODO dependencies + agenda? [9.5 (9.5-g0a86ad @ /home/ignacio/.emacs.d/elpa/org-9.5/)]

[Ignacio Casso]

Hello,

I'm not sure what is the expected behaviour of the COMMENT keyword for
TODOs and the agenda, since I only found it in the "Exporting" section
of the manual, but I find the following behaviour inconsistent:

- Tasks with a COMMENT keyword or under a heading with a COMMENT keyword
  do not appear in the agenda. I'm not sure if this is a feature or just
  happens because there is a step involving exporting when the agenda is
  constructed, but it seems reasonable to me and I use the COMMENT
  keyword for this sometimes.

- Tasks with a COMMENT keyword or under a heading with a COMMENT keyword
  DO matter when computing dependencies between tasks, when
  org-enforce-todo-dependencies is 't' or there is a 'ORDERED'
  property.

These two points seem inconsistent to me, since the first leads me to
believe that tasks under commented subtrees are as if they did not
exist, but in the second we see that's not true. Am I interpreting the
COMMENT keyword wrong?

Best regards,

Ignacio

P.D: Just when I was going to send this I tried to investigate it a
little bit more to not waste anyone's time, and I found the variable
'org-agenda-skip-comment-trees', which defaults to 't'. So now I see that
if it is set to 'nil' it would not be inconsistent to me anymore, but I
still think that the default behaviour is inconsistent, or at least
unintituive for newcomers, and that maybe a corresponding variable like
'org-dependencies-skip-comment-trees' might be needed.

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian
Package: Org mode version 9.5 (9.5-g0a86ad @ 
/home/ignacio/.emacs.d/elpa/org-9.5/)

Re: org-tag-persistent-alist AND per-file dynamic tags

[Victor A. Stoichita]

Hi Chris,

Le 29 Nov 2021, chris  a écrit :

> I use footnote 53 from https://orgmode.org/manual/Setting-Tags.html[1].
> I put my tags in `tags-file.org`, using `#+TAGS:`.
> I've put the next two lines in `init.el`.
>
> (setq org-agenda-files (list "~/path-to/tags-file.org")
>  org-complete-tags-always-offer-all-agenda-tags t)
>
> And I have completion on both the tags in `tags-file.org` and tags in
> the current buffer. I don't use `org-tag-alist`, so the comments made
> in https://emacs.stackexchange.com/q/ 69369#comment111307_69369[2],
> would not apply.

That’s great! It’s exactly what I needed. I’ll just switch my persistent
tags from org-tag-alist to an agenda file. This is also neater as it
will get them out of my init files, where I didn’t feel that they
really belonged.

> I use a script to collect the tags, based on Kitchin's 
> https://stackoverflow.com/a/27527252[3], and help from `#emacs`.
> […]
> The tags are sorted by frequency, which is not necessary
> here, but it's really nice.
> […]

Thanks for this as well! It’s nice to have it. For the moment, I curate
manually these "persistent" tags, because i want to have them grouped
hierarchically. But knowing how to collect them automatically might be
useful for me as well in the future!

Cheers,
Victor

Hourly repeating tasks only shown once per day in org-agenda

[JG]

Hi, I'm using fresh git copies of emacs and orgmode on an Ubuntu 21.10
VM with the following commit levels from git log -1:

emacs:
commit 6ecb24f877242371a0dbc7938e9b408df2690dc7 (HEAD -> master, origin/master, 
origin/HEAD)

orgmode:
commit 14ed651db0ef822d1b5491a376b66283da9b9349 (HEAD -> main, origin/main, 
origin/HEAD)

I have set up a test org file with this hourly repeating event:

* TODO Checking twice a day
<2021-12-08 Wed 7:00 +12h>

In the org-agenda I would expect to see the event appear twice a day at
7:00 and 19:00 every day, but instead I see it appear once a day at the
time in the timestamp. If I mark the 7:00 event for a day as done, I
correctly see the time stamp update to

<2021-12-08 Wed 19:00 +12h>

and after rebuilding the agenda buffer I again see the event appear
exactly once per day every day, but now at the 19:00 time slot.

I have confirmed that org-agenda-show-future-repeats is set to "Show all
repeated entries".

Re: Org-cite stuck in Helm minibuffer [9.5.1 (9.5.1-g36086a @ /home/dan/.emacs.d/elpa/org-9.5.1/)]

[Eric S Fraga]

On Wednesday,  8 Dec 2021 at 17:33, Bruce D'Arcus wrote:
> If you like Selectrum (Vertico is another recent, similar,
> alternative), you might give citar a try.
>
> https://github.com/bdarcus/citar

+1

Works very well for me with selectrum.

-- 
: Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Eric S Fraga]

On Thursday,  9 Dec 2021 at 16:21, Russell Adams wrote:
> Did Org break your Org editing experience in Emacs for your Org files,
> or did this change just break some of the finer formatting details of
> your exported Org file?

It's been a while but, IIRC, the latter to a large extent; I should have
been more clear.

However, there have been changes in the past that affected the editing
experience but I cannot remember if they were with v8 or v9 or somewhere
in between, particularly dealing with locations of :LOGBOOK: and
scheduling directives.  These happened when Nikolas cleaned up the
parsing, to the benefit of org but at the cost of making some documents
non-compliant.

Nevertheless, as others have stated, given the stability provided by
Emacs (parts of my .emacs date back to 1985!), and org being all text,
even breaking changes are usually trivial to correct or adjust to.

-- 
: Eric S Fraga, with org release_9.5.1-243-gad53c5 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Raw Org AST snippets for "impossible" markup

[Juan Manuel Macías]

Max Nikulin writes:

> Looking into your code I have realized that it should be implemented 
> using filter, not through :export property of links. Maybe without 
> working proof of concept with link exporters, this session of 
> monkey-typing would not be successful.

Jumping into the "real world", how about these two examples of nested emphasis?

#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (italic () "Iliad") " and the 
" (italic () "Odyssey"))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \emph{Iliad} and the \emph{Odyssey}}
#+end_export

This one more complex:

#+begin_src org :results latex :results replace
[[orgia:(italic () "The English versions of the " (bold () (italic () "Iliad")) 
" and the " (bold () (italic () "Odyssey")))]]
#+end_src

#+RESULTS:
#+begin_export latex
\emph{The English versions of the \textbf{\emph{Iliad}} and the 
\textbf{\emph{Odyssey}}}
#+end_export

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Russell Adams]

On Thu, Dec 09, 2021 at 10:46:34AM +, Eric S Fraga wrote:
> Org v8 in particular was a major step forward but broke many of my
> org files.

I know we're beating a dead horse, but can you clarify.

Did Org break your Org editing experience in Emacs for your Org files,
or did this change just break some of the finer formatting details of
your exported Org file?

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: org-cite and export to ODT

[John Kitchin]

If you are trying to use org-ref for this see
https://www.youtube.com/watch?v=rRR-5NSpKyE and this example:
https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org#opendocument.
You need to use a preprocessing hook (org-ref-csl-preprocess-buffer) with
org-ref to get the citations and bibliography .
John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Thu, Dec 9, 2021 at 4:54 AM Xianwen Chen (陈贤文) 
wrote:

> I have been using org-ref and biblatex. They export well to PDF, through
> LaTeX. I am able to export to ODT as well. However, I'm not able to have
> the bibliography or the references in the produced ODT.
>
> I searched online and found this tutorial:
> https://kjambunathan.github.io/org-mode-ox-odt/Bibliography-and-Citations-in-ODT-export.html.
> However, when following through the tutorial, I wasn't able to find
> ox-jabref.
>
> Thinking about the new org-cite, which is orgmode's native citation
> solution, I'm wondering if it would be easier to use org-cite within
> orgmode and export to ODT? A small example with configuration suggestion
> will be highly appreciated!
>
> Xianwen
>

Re: Raw Org AST snippets for "impossible" markup

[Max Nikulin]

On 09/12/2021 14:01, Juan Manuel Macías wrote:

John Kitchin writes:


Have you seen
https://github.com/tj64/org-dp? It seems to do a lot with creating and
manipulating org elements. It might either be handy or lead to some
inspiration.


Interesting package. Thanks for sharing.


Either I missed something or its purpose is completely different. It 
maps Org markup to Org markup. I am experimenting with fragments that 
should allow to get something that is really tricky or even impossible 
with established syntax, so it has to run immediately before exporters.



It gave me an idea, also borrowing part of Maxim's code, but evaluating
in this case the path. To continue playing with links... The goal is
to obtain a link with this structure `[[quote-lang:lang][quote]]':

#+BEGIN_SRC emacs-lisp :results silent
   (org-link-set-parameters
"quote-lang"
:display 'full
:export (lambda (path desc bck)
 (let* ((bck org-export-current-backend)
(attr (list (format
 ":environment foreigndisplayquote :options 
{%s}"
 path)))
(info (org-export-get-environment
   bck nil nil)))
   (org-no-properties
(org-export-data-with-backend
 `(quote-block (:attr_latex ,attr)
   ,desc)
 bck info)
#+END_SRC


Looking into your code I have realized that it should be implemented 
using filter, not through :export property of links. Maybe without 
working proof of concept with link exporters, this session of 
monkey-typing would not be successful.


#+begin_src elisp :results silent
  (defun orgia-element-replace (current new destructive?)
(if (eq current new)
current
  (let* ((lst? (and (listp new) (not (symbolp (car new)
 (new-lst (if lst?
  (if destructive? (nconc new) (reverse new))
(list new
(dolist (element new-lst)
  (org-element-insert-before element current)))
  (org-element-extract-element current)
  new))

  (defun orgia--transform-link (data)
(if (not (string-equal "orgia" (org-element-property :type data)))
data
  (let* ((path (org-element-property :path data)))
(if (not (eq ?\( (aref path 0)))
(or path (org-element-contents data))
  (read path)

  (defun orgia-parse-tree-filter (data _backend info)
(org-element-map data 'link
  (lambda (data)
(orgia-element-replace data (orgia--transform-link data) t))
  info nil nil t)
data)
#+end_src

#+begin_src elisp :results silent
  (add-to-list 'org-export-filter-parse-tree-functions 
#'orgia-parse-tree-filter)


  (org-link-set-parameters "orgia")
#+end_src


#+begin_src elisp
  (org-export-string-as "An word" 
'html t)

#+end_src

#+RESULTS:
: 
: An interword

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Eric S Fraga]

On Wednesday,  8 Dec 2021 at 17:16, Dr. Arne Babenhauserheide wrote:
> If you have 1400 slides of lectures, all carefully laid out to convey

Been there, done that.  I've learned to not upgrade org (or Emacs) for
a few weeks before the start of term!

I am a big fan of backwards compatibility but not if it becomes a
stranglehold on significant improvements.  Org v8 in particular was a
major step forward but broke many of my org files.  I was happy with the
trade-off: immediate pain but much better basis for future developments.

-- 
: Eric S Fraga, with org release_9.5.1-254-g14ed65 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

org-cite and export to ODT

[陈贤文]

I have been using org-ref and biblatex. They export well to PDF, through
LaTeX. I am able to export to ODT as well. However, I'm not able to have
the bibliography or the references in the produced ODT.

I searched online and found this tutorial:
https://kjambunathan.github.io/org-mode-ox-odt/Bibliography-and-Citations-in-ODT-export.html.
However, when following through the tutorial, I wasn't able to find
ox-jabref.

Thinking about the new org-cite, which is orgmode's native citation
solution, I'm wondering if it would be easier to use org-cite within
orgmode and export to ODT? A small example with configuration suggestion
will be highly appreciated!

Xianwen

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Ihor Radchenko]

Timothy  writes:

> For the sake of staying vaguely on-track, I think it’s worth noting that 
> Ihor’s
> comments make no mention of changing the Org syntax, or creating an abstract
> definition (that has existed as a WIP for years).

I think Dr. Babenhauser referred to another ongoing thread "Raw Org AST
snippets for "impossible" markup".

> There’s been a bit too much speculation[1] in this thread methinks…

Yep, though it is still fairly relevant to some of the interpretations
of the thread title. So, let it be. The discussion is not useless even
though it is not the feedback I was counting on.

I plan to open a new, more technical thread to discuss the changes I
wanted to make.

Best,
Ihor

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Timothy]

Hi Arne,

> I am wording this so strongly because we currently have talk about
> creating more abstract org syntax.
>
> This is the situation in which the temptation to skip backwards
> compatibility is highest — as is the cost of that, because not updating
> will quickly not be an option (because dependencies will follow).
>
> In another situation I would be much more relaxed about this discussion,
> but when larger refactoring is on the table, it is important that
> backwards compatibility is high in the priorities.

For the sake of staying vaguely on-track, I think it’s worth noting that Ihor’s
comments make no mention of changing the Org syntax, or creating an abstract
definition (that has existed as a WIP for years).

There’s been a bit too much speculation[1] in this thread methinks…

All the best,
Timothy



Footnotes
─

[1] Don’t get me started on speculations
building on speculation.

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Dr. Arne Babenhauserheide]

Tim Cross  writes:



> Russell Adams  writes:
>> That Org can also be used to export to other formats is both a
>> blessing and a curse. Org can only do high level constructs in the
>> languages it exports to, and really should only be expected to do just
>> that. It's a paper thin macro or template over a much more complicated
>> document language.
…
>> The exporting is the difference in expectations. Org's lightweight
>> markup is quite simple, and the documents it produces should be as
>> well. This is much like the original HTML specification. Look how
>> complicated it is to write HTML now with CSS and Javascript emulating
>> mundane functions after decades of bolt on "standards".


Yes, the language-specific hacks are outside its scope. When I do
#+latex: …
or
@@html:…@@

I am in the export formats.

What should not happen is that 

>>> Please do not make org-mode volatile.¹
>> …
>> I think our maintainers have done an excellent job of minimizing the
>> impact of any changes.

Yes, they have. That’s why I wrote that it is a too rarely highlighted
strength, that Emacs is stable.

>> However I only export Org to be backwardly compatible with itself, not
>> the languages it makes exports to.

One of the big strengths of org-mode is in its integrations. When the
languages change that it exports to, it cannot do much. But where they
don’t, an update of org-mode should not break the export.

From the expectations-side, that’s the extended 80/20 rule: 80% of your
users only use 20% of the features¹, but they don’t all use the same
20%. So everytime you break something that’s not in the core 20%, you
lose some users until only a small core is left that actually did not
use anything outside those 20%.

¹: for org-mode it migh rather be 5% :-)

> As you point out, the big benefit of org mode is that the files are
> plain text. This means you will always be able to 'fix' any issues which
> arise from change. It might not be convenient and you may be frustrated
> by such change, but you will likely have a much better outcome than you
> would with any other document formatting system which is not based on
> plain text. 

Yes — that’s also one of the reasons why I’m using org-mode.

It’s awesome integrations and tooling are why I use org-mode instead of
markdown or asciidoc or similar. It binds all my work in Emacs together.

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


signature.asc
Description: PGP signature

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[Dr. Arne Babenhauserheide]

Tim Cross  writes:

> What really doesn't help is to immediately jump to extremes and start
> talking about making something volatile just because change is
> mentioned.

I am wording this so strongly because we currently have talk about
creating more abstract org syntax.

This is the situation in which the temptation to skip backwards
compatibility is highest — as is the cost of that, because not updating
will quickly not be an option (because dependencies will follow).

In another situation I would be much more relaxed about this discussion,
but when larger refactoring is on the table, it is important that
backwards compatibility is high in the priorities.

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


signature.asc
Description: PGP signature