Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

And yet another update fixing a typo in previous patch. Sorry

>From 89a60d654663b68f1c149fb3341a50191027f45e Mon Sep 17 00:00:00 2001
Message-Id: <89a60d654663b68f1c149fb3341a50191027f45e.1625983004.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sat, 10 Jul 2021 21:43:44 +0800
Subject: [PATCH] Fix duplicate logbook entry for repeated tasks

* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'.  Otherwise, there is no way to know if a note was
requested for `this-command'.  Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].

* lisp/org-agenda.el (org-agenda-todo): Avoid reintroducing the bug
fixed in c670379adf.

* testing/lisp/test-org.el: Add test checking the reported bug.

[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=vjqmjgtzy8uc1sypar...@mail.gmail.com
---
 lisp/org-agenda.el   |  6 +-
 lisp/org.el  |  4 +---
 testing/lisp/test-org.el | 23 ++-
 3 files changed, 28 insertions(+), 5 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..4cd527e5b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9433,7 +9433,11 @@ (defun org-agenda-todo ( arg)
 	 (goto-char pos)
 	 (org-show-context 'agenda)
 	 (let ((current-prefix-arg arg))
-	   (call-interactively 'org-todo))
+	   (call-interactively 'org-todo)
+   ;; Make sure that log is recorded in current undo.
+   (when (and org-log-setup
+  (not (eq org-log-note-how 'note)))
+ (org-add-log-note)))
 	 (and (bolp) (forward-char 1))
 	 (setq newhead (org-get-heading))
 	 (when (and org-agenda-headline-snapshot-before-repeat
diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..3d15771a2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10939,9 +10939,7 @@ (defun org-add-log-setup ( purpose state prev-state how extra)
 	org-log-note-extra extra
 	org-log-note-effective-time (org-current-effective-time)
 org-log-setup t)
-  (if (eq how 'note)
-  (add-hook 'post-command-hook 'org-add-log-note 'append)
-(org-add-log-note purpose)))
+  (add-hook 'post-command-hook 'org-add-log-note 'append))
 
 (defun org-skip-over-state-notes ()
   "Skip past the list of State notes in an entry."
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index de3c6f3c9..c2267c32d 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -7396,7 +7396,28 @@ (ert-deftest test-org/auto-repeat-maybe ()
 SCHEDULED: <2012-03-29 Thu +2y>
 CLOCK: [2012-03-29 Thu 10:00]--[2012-03-29 Thu 16:40] =>  6:40"
 	(org-todo "DONE")
-	(buffer-string))
+	(buffer-string)
+  ;; Make sure that logbook state change record does not get
+  ;; duplicated when `org-log-repeat' `org-log-done' are non-nil.
+  (should
+   (string-match-p
+(rx "* TODO Read book
+SCHEDULED: <2021-06-16 Wed +1d>
+:PROPERTIES:
+:LAST_REPEAT:" (1+ nonl) "
+:END:
+- State \"DONE\"   from \"TODO\"" (1+ nonl) buffer-end)
+(let ((org-log-repeat 'time)
+	  (org-todo-keywords '((sequence "TODO" "|" "DONE(d!)")))
+  (org-log-into-drawer nil))
+  (org-test-with-temp-text
+  "* TODO Read book
+SCHEDULED: <2021-06-15 Tue +1d>"
+(org-todo "DONE")
+(when (memq 'org-add-log-note post-command-hook)
+  (org-add-log-note))
+(buffer-string))
+
 
 
 ;;; Timestamps API
-- 
2.31.1

Re: Feature request: in org html export, option to disable id & class properties.

[Zachary Kanfer]

That is an interesting exporter. Is it actually part of orgmode? I don't
see it in the org repository. I don't want to rely on downloading something
from an archived repository that won't get bugfixes.

On Sat, Jul 10, 2021 at 3:41 AM András Simonyi 
wrote:

> Hello,
> I'm not really familiar with the internals of the built-in html
> exporter but the slimhtml exporter
> [https://github.com/balddotcat/ox-slimhtml]  might be closer to what
> you're looking for.
>
> best regards,
> András
>
> On Sat, 10 Jul 2021 at 09:08, Zachary Kanfer  wrote:
> >
> > When I export this sample org file:
> >
> > * top-level header
> > ** and here we have #2
> >
> > The body of the generated html has this content:
> >
> > 
> >   top-level header
> >   
> > and here we have #2
> >   
> > 
> >
> > I would prefer the html to not have these id or class properties;
> something like this:
> >
> > 
> >   top-level header
> >   
> > and here we have #2
> >   
> > 
> >
> > Actually, I'd rather skip the divs entirely, but that is a separate
> issue. Could there be a configurable way to disable the creation of these
> properties? I have searched the mailing list, and have not found anything.
> Perhaps I've missed something; there are a lot of results for "html class
> id" or similar searches. Thanks.
>

Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

Updating the patch with relevant new test

>From 5b89c95318a38df9f0a6706b6eb5320baafbd4d8 Mon Sep 17 00:00:00 2001
Message-Id: <5b89c95318a38df9f0a6706b6eb5320baafbd4d8.1625981997.git.yanta...@gmail.com>
From: Ihor Radchenko 
Date: Sat, 10 Jul 2021 21:43:44 +0800
Subject: [PATCH] Fix duplicate logbook entry for repeated tasks

* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'.  Otherwise, there is no way to know if a note was
requested for `this-command'.  Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].

* lisp/org-agenda.el (org-agenda-todo): Avoid reintroducing the bug
fixed in c670379adf.

* testing/lisp/test-org.el: Add test checking the reported bug.

[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=vjqmjgtzy8uc1sypar...@mail.gmail.com
---
 lisp/org-agenda.el   |  6 +-
 lisp/org.el  |  4 +---
 testing/lisp/test-org.el | 21 +
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..4cd527e5b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9433,7 +9433,11 @@ (defun org-agenda-todo ( arg)
 	 (goto-char pos)
 	 (org-show-context 'agenda)
 	 (let ((current-prefix-arg arg))
-	   (call-interactively 'org-todo))
+	   (call-interactively 'org-todo)
+   ;; Make sure that log is recorded in current undo.
+   (when (and org-log-setup
+  (not (eq org-log-note-how 'note)))
+ (org-add-log-note)))
 	 (and (bolp) (forward-char 1))
 	 (setq newhead (org-get-heading))
 	 (when (and org-agenda-headline-snapshot-before-repeat
diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..3d15771a2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10939,9 +10939,7 @@ (defun org-add-log-setup ( purpose state prev-state how extra)
 	org-log-note-extra extra
 	org-log-note-effective-time (org-current-effective-time)
 org-log-setup t)
-  (if (eq how 'note)
-  (add-hook 'post-command-hook 'org-add-log-note 'append)
-(org-add-log-note purpose)))
+  (add-hook 'post-command-hook 'org-add-log-note 'append))
 
 (defun org-skip-over-state-notes ()
   "Skip past the list of State notes in an entry."
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index de3c6f3c9..0634ba608 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -7397,6 +7397,27 @@ (ert-deftest test-org/auto-repeat-maybe ()
 CLOCK: [2012-03-29 Thu 10:00]--[2012-03-29 Thu 16:40] =>  6:40"
 	(org-todo "DONE")
 	(buffer-string))
+  ;; Make sure that logbook state change record does not get
+  ;; duplicated when `org-log-repeat' `org-log-done' are non-nil.
+  (should
+   (string-match-p
+(rx "* TODO Read book
+SCHEDULED: <2021-06-16 Wed +1d>
+:PROPERTIES:
+:LAST_REPEAT:" (1+ nonl) "
+:END:
+- State \"DONE\"   from \"TODO\"" (1+ nonl) buffer-end)
+(let ((org-log-repeat 'time)
+	  (org-todo-keywords '((sequence "TODO" "|" "DONE(d!)")))
+  (org-log-into-drawer nil))
+  (org-test-with-temp-text
+  "* TODO Read book
+SCHEDULED: <2021-06-15 Tue +1d>"
+(org-todo "DONE")
+(when (memq 'org-add-log-note post-command-hook)
+  (org-add-log-note))
+(buffer-string))
+
 
 
 ;;; Timestamps API
-- 
2.31.1

org-mode linter for BNF? (was Re: Concerns about community contributor support)

[trx2358-gitter]

Hi there,

I'm new to this mailing list and I'm sure I'm not caught up on discussions on 
using a BNF for org-mode.
I have seen Gustav Wilkstroem's warning about the difficulties involved.  I 
wonder if I might propose
(what seems to me) a novel approach.  Maybe instead of using the BNF inside 
org-mode, the BNF can be used
for a companion piece of software which runs alongside org-mode.  As a sort of 
"linter" for org-mode.

Taking code editors as an example.  During editing the code need not conform to 
the spec, but once saved
and handed to a compiler, it must or else the code will break.  Tools such as 
[[https://emacs-lsp.github.io/lsp-mode/][lsp]]
run a companion process alongside the editor which continuously check for 
conformity to the spec (and more!)
and report back any issues they've found.

If we had an lsp server for org-mode, then third party tools could be written 
to what *that* accepts rather than
what ~org-element.el~ accepts.  Tools could specify that only files which pass 
"linting" can be expected to work
100%.  Of course other editing tools could also incorporate the lsp server to 
have linting available to them.

In this way the specification of what's "pure org-mode grammar" is separate 
from "what's possible in emacs with
org-mode".  Obviously we wouldn't want the two to stray too far apart, but the 
added flexibility seems like it might
be a boon to the community.  It would be good though if such a tool were "part 
of the org-mode family" rather than
developed independently.

What do people think of the idea?

-Doug

FWIW, on a somewhat related note, I've started a github repository of org-mode 
snippets with the thought that these
could be used as examples to discuss what should and should not be part of 
"pure org-mode grammar".
([[https://github.com/gitonthescene/org-mode-samples][org-mode-samples]])

As such I'm actively seeking input since discussions with myself seem to mostly 
go in circles.  :-)

Also, I've laid out this same argument with slightly different wording in that 
project
[[https://github.com/gitonthescene/org-mode-samples/discussions/2][here]].

Tom Gillespie  writes:

>/Hi Tim, David, and Gustav,/

Hi

>/I am fairly certain that with only a few exceptions it is possible/
>/to specify a context free grammar for org syntax, followed by a second/
>/pass that deals specifically with markup and a few other forms,/
>/notably the reassembly of things like plain lists. The fact that this/
>/is possible because most org constructs are line oriented./

What do you think about having multiple Org grammars that parse specific
parts of an Org file and treat the rest as text blobs?  The idea is that
small tools (on smartphones) could concentrate on (say) gathering and
using the info related to one of:
+ task management
+ tangled code
+ Org file options
+ etc.

>/Just a note that the linked parser.rkt [0] is indeed a BNF describing org/
>/syntax in the same style as a bison/yacc grammar. One of the reasons/
>/why I set out to work on this was precisely so that there could be a/
>/reference that could be consulted by the community when questions/
>/about extended org come up./

How complete do you feel this grammar is?

>/In all my work on the grammar I have found maybe 2 or 3 places where/
>/the grammar could be "extended" but it isn't so much extended as it is/
>/regularized, where some parts of org already parse a more complex/
>/grammar while other very similar parts choose not to. Overall the cost/
>/of not parsing certain forms in certain situations adds complexity/
>/rather than reducing it./

Hmm.

>/Overcoming this is why I started working on the grammar, because/
>/in the absence of a formal spec for what org should do, it is very hard/
>/to make changes to what it is currently doing without having nasty/
>/side effects./

Thanks for the effort! This could lead to Org developments on non-Enacs
platforms (smartphones & tablets)

>/0. https://github.com/tgbugs/laundry/blob/next/laundry/parser.rkt
 note/
>/the upcoming path change (which I will note in the original thread when/
>/it happens)./

I'll see if I can look at this -- it's been decades since I played with
grammars. 

-- 
David Masterson

Re: [PATCH] ob-R output file with graphics parameter

[Berry, Charles]

Jack,

I will be going offline for a week or so, so I will have to defer more 
discussion.

I know that `silent' silences an unwanted file link. 

And there are a few other ways to do this.  

So, if it is determined to proceed, adding an implicit `file' will not prohibit 
uses in which it was not actually wanted.

Best,
Chuck

> On Jul 10, 2021, at 2:00 PM, Jack Kamm  wrote:
> 
> Hi Chuck,
> 
>> If you modify the ECM to change `:exports results' to `:exports
>> none' and clean older fig[12].png's from the directory, the export
>> fails.
> 
> Thanks for this example. I had mistakenly thought that code blocks
> with ":exports none" would be evaluated for side effects, but you are
> right, these blocks are skipped altogether during export.
> 
> Instead, I think this use case could be handled by the ":results silent"
> header. Blocks with that header are evaluated during export, but the
> result is not inserted into the org buffer or the exported document. It
> seems like a more general way to evaluate code blocks for side effects
> only.
> 
> To test this out, you could replace the header arguments in your
> example with:
> 
> ":exports results :results graphics file silent :file fig1.png"
> 
>> So if everyone else is determined to make this change I can live
>> with it.
> 
> I do hope someone submits an RFC, so we can discuss this more
> concretely. I still think it would be nice if we could go back to just
> ":results graphics" to insert a figure. Unfortunately, I'm not currently
> able to propose the patch, as I'm still in limbo w.r.t. my employer
> agreement.

Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

Bhavin Gandhi  writes:

> Thank you! I tried the patch, but the original bug[1] which the commit
> `c67037' tried to fix, gets introduced again. Basically,
> `org-agenda-undo' just removes the logbook entry and the scheduled date
> remains new.

You are right. I believe that I fixed the breakage in the attached
patch. Also, I noticed that c67037 did not fix the original bug when
state change requests interactive note.

Best,
Ihor

>From f012648b350013e33ef0e88afc85b4fcf048734b Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sat, 10 Jul 2021 21:43:44 +0800
Subject: [PATCH] Fix duplicate logbook entry for repeated tasks

* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'.  Otherwise, there is no way to know if a note was
requested for `this-command'.  Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].

* lisp/org-agenda.el (org-agenda-todo): Avoid reintroducing the bug
fixed in c670379adf.

[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=vjqmjgtzy8uc1sypar...@mail.gmail.com
---
 lisp/org-agenda.el | 6 +-
 lisp/org.el| 4 +---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 44acd035a..4cd527e5b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9433,7 +9433,11 @@ (defun org-agenda-todo ( arg)
 	 (goto-char pos)
 	 (org-show-context 'agenda)
 	 (let ((current-prefix-arg arg))
-	   (call-interactively 'org-todo))
+	   (call-interactively 'org-todo)
+   ;; Make sure that log is recorded in current undo.
+   (when (and org-log-setup
+  (not (eq org-log-note-how 'note)))
+ (org-add-log-note)))
 	 (and (bolp) (forward-char 1))
 	 (setq newhead (org-get-heading))
 	 (when (and org-agenda-headline-snapshot-before-repeat
diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..3d15771a2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10939,9 +10939,7 @@ (defun org-add-log-setup ( purpose state prev-state how extra)
 	org-log-note-extra extra
 	org-log-note-effective-time (org-current-effective-time)
 org-log-setup t)
-  (if (eq how 'note)
-  (add-hook 'post-command-hook 'org-add-log-note 'append)
-(org-add-log-note purpose)))
+  (add-hook 'post-command-hook 'org-add-log-note 'append))
 
 (defun org-skip-over-state-notes ()
   "Skip past the list of State notes in an entry."
-- 
2.31.1

Re: [PATCH] ob-R output file with graphics parameter

[Jack Kamm]

Hi Chuck,

> If you modify the ECM to change `:exports results' to `:exports
> none' and clean older fig[12].png's from the directory, the export
> fails.

Thanks for this example. I had mistakenly thought that code blocks
with ":exports none" would be evaluated for side effects, but you are
right, these blocks are skipped altogether during export.

Instead, I think this use case could be handled by the ":results silent"
header. Blocks with that header are evaluated during export, but the
result is not inserted into the org buffer or the exported document. It
seems like a more general way to evaluate code blocks for side effects
only.

To test this out, you could replace the header arguments in your
example with:

":exports results :results graphics file silent :file fig1.png"

> So if everyone else is determined to make this change I can live
> with it.

I do hope someone submits an RFC, so we can discuss this more
concretely. I still think it would be nice if we could go back to just
":results graphics" to insert a figure. Unfortunately, I'm not currently
able to propose the patch, as I'm still in limbo w.r.t. my employer
agreement.

[oc] use-package config question

[Bruce D'Arcus]

As I'm trying to put together a PR for the doom module for adding
org-cite support [1], I'm realizing I really don't understand
use-package very well.

Could someone with some expertise in this area recommend how I do the following?

Load org-cite and it's associated packages (oc-basic, oc-natbib,
etc.), and set some associated variables, if org-cite is available.

Bruce

[1] https://github.com/hlissner/doom-emacs/pull/5212

Re: org-mode export to (latex) PDF

[Juan Manuel Macías]

Hi Jonathan,

Jonathan McHugh writes:

> I recall there was momentum re exporting to Context from Orgmode, hopefully a 
> solid implementation is available.

It seems that a member of this mailing list, Jason Ross, is working on a
ConTeXt backend for org: https://github.com/Jason-S-Ross/ox-context/

ConTeXt is a TeX format that uses the LuaTeX engine, but the same
results can be achieved using LaTeX format with the LuaLaTeX version.

Of course, LuaTeX, the TeX engine that runs behind ConTeXt and LuaLaTeX,
was born with a clear multilingual "vocation", and it is the natural
evolution of pdfTeX.

Another option for multilingual documents is to use xeTeX engine and
xeLaTeX format.

ConTeXt is very interesting (a more modular approach, and it is not extended by
macro packages like LaTeX, so that the user already has everything inside
almost out of the box). The problem is that it's not as documented as LaTeX.

Best regards,

Juan Manuel

Re: org-mode export to (latex) PDF

[Jonathan McHugh]

Hi Jean-Christophe,

I have heard positive things with regards to the document management system, 
Context, for handling non Latin characters.

It may be worth considering as an alternative to Latex.

I recall there was momentum re exporting to Context from Orgmode, hopefully a 
solid implementation is available.

Kind regards,


Jonathan McHugh

indieterminacy@libre.brussels

July 10, 2021 3:43 PM, "Jean-Christophe Helary"  
wrote:

> I was busy last year going back to school and I wrote a research paper for my 
> first year of master
> almost entirely in org-mode.
> 
> My workflow was trivial:
> 
> - write in org-mode
> - enter the bibliography with Zotero
> - export to ODT and open in NeoOffice
> - modify in NeoOffice
> - deliver
> 
> At first, I tried to export the document to PDF but all the Japanese quotes I 
> had were removed from
> the document, which led me to prefer ODT export because it handled them 
> properly.
> 
> I guess it is an issue with the Latex backend and could have been solved with 
> the proper Latex
> settings, but it seems weird that the default settings do not allow for 
> out-of-the-box multilingual
> support.
> 
> Is there an easy way to have that as the default behavior?
> 
> -- 
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book

Re: [bug] Setting org-id-link-to-org-use-id to t creates IDs properties when tangling

[Jonathan McHugh]

Hi Rodrigo,

Regarding the problem of large content volumes and unique identifiers I thought 
Id CC Jean Marc Louis.

He has been building an Emacs approach to Hyperscope and has been considering 
this facet (and others). 
=> https://hyperscope.link/

Perhaps he may have some input?


Jonathan McHugh

indieterminacy@libre.brussels

July 10, 2021 12:36 PM, "Rodrigo Morales"  wrote:

> * The issue
> 
> When setting org-id-link-to-org-use-id to t, an :ID: property is created
> for each headline that contain at least one code block that is
> tangled.
> 
> * Reproducing this issue
> 
> 1. Start emacs -Q
> 
> 2. Open a "*.org" file at a location where you have write permissions
> (this is because, apparently, tangling only works when the file is
> correctly saved so this way we get rid of this possible issue)
> 
> 3. Insert the following minimal working example into the buffer (you can
> find the Org Mode file attached to this mail)
> 
> #+BEGIN_SRC org
> ,* foo
> 
> ,#+HEADER: :tangle ~/Downloads/main.txt
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> 
> ,* bar
> 
> ,#+HEADER: :tangle ~/Downloads/main.txt
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> 
> ,* fizz
> 
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> #+END_SRC
> 
> 4. Execute the following commands
> 
> #+BEGIN_SRC emacs-lisp
> (require 'org-id)
> (setq org-id-link-to-org-use-id t)
> #+END_SRC
> 
> 5. Now, execute org-babel-tangle (C-c C-v C-t).
> 
> At this point, a id property is created for the "foo" and "bar"
> headlines because those are the only headlines that contain a code
> block. This is what I got in emacs -Q
> 
> #+BEGIN_SRC org
> ,* foo
> :PROPERTIES:
> :ID: 358560b4-2426-4d42-a498-ae16195daf3a
> :END:
> 
> ,#+HEADER: :tangle ~/Downloads/main.txt
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> 
> ,* bar
> :PROPERTIES:
> :ID: 02217461-a744-42b2-b582-1a836568d686
> :END:
> 
> ,#+HEADER: :tangle ~/Downloads/main.txt
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> 
> ,* fizz
> 
> ,#+BEGIN_SRC text
> a
> ,#+END_SRC
> #+END_SRC
> 
> * Personal thoughts
> 
> In my opinion, this is undesired behavior because the goal of
> org-id-link-to-org-use-id isn't creating an ID property for each
> headline when performing tangling.
> 
> * Major undesired consequences
> 
> The following is an scenario in which this issue causes major undesired
> consequences: Consider the following scenario
> 
> + you have 1000 headlines in an Org Mode file
> 
> + all of those headlines don't have an ID property (because you are not
> interested in uniquely identifying all of those headlines through an ID)
> 
> + all of those headlines contain at least one code block that is tangled
> 
> Because of this issue, the following would be added for each headline
> 
> #+BEGIN_SRC org
> ,* my headline
> :PROPERTIES:
> :ID: <>
> :END:
> #+END_SRC
> 
> and this have the following undesired consequences
> 
> + You would end up with 3000 lines in your Org Mode file because of the
> id properties even when you weren't interested in creating an ID for
> each of those headlines.
> 
> + You would have 1000 more entries in org-id-locations-file (again, even
> where you weren't interested in creating an ID for each of those
> headlines)
> 
> -- 
> La información contenida en este e-mail y sus anexos es confidencial, 
> privilegiada y está dirigida exclusivamente a su destinatario, en 
> consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
> destinatario original, no deberá examinar, usar, copiar o distribuir este 
> mensaje o la información que contiene. Si lo recibe por error, por favor 
> reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
> uso total o parcial no autorizada de este mensaje está estrictamente 
> prohibida y sancionada por ley.
> 
> -- 
> [[[ If you see a signature in spanish below/above this message, please
> omit it. It is automatically inserted in all my messages due to the
> internal privacy policies of the organization that owns the domain of my
> email address. ]]]

Re: org-mode export to (latex) PDF

[Juan Manuel Macías]

Tim Cross writes:

> Just FYI for those who don't know, you can use the org-latex-classes
> variable to define your own pseudo document classes, possibly using the
> DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
> settings. So for example, you can add the babel or other packages you
> want and either make that the 'default' class or specify which class you
> want with the #+LATEX_CLASS header. I use this quite a bit because then
> I don't have to remember which LATEX_HEADER lines to include in the
> document, the specific option settings etc. I don't need support for
> multilingual documents, but I do have a number of 'special' documents
> (such as one with colours, logos and specific fonts for an employer to
> match their 'style guide'. I also have ones for generating project
> documents, letters, meeting minutes etc. They all use various different
> Latex extensions (particularly ones which don't mix well and cannot be
> included with other packages).

I agree. `Org-latex-classes' is a very good option for create LaTeX
templates, and I have a few classes defined as well. The problem is when
you need really long and complex preambles (it is not a problem that
most users may have, though). In a recent project (a book) my preamble
had about 2000 lines (including macros and environments defined by me,
some functions in Lua for LuaTeX, etc.). With long or complex preambles
it's a bit awkward to do it in Elisp and org-latex-classes. In that
case, I usually write the preamble to an Org document and generate a
*.tex file using org-babel-tangle. Then I include that file at the very
beginning of my document with an \input macro. On the LaTeX side, there
is also the option to create your own sty file:
https://tex.stackexchange.com/questions/77/how-to-make-a-standard-preamble-into-a-package

As an alternative to #+LaTeX_Header you can also include the
preamble in the Org document itself using a LaTeX block:

#+NAME: preamble
#+begin_src latex :exports none
... a lot of latex code
#+end_src

and then, in another block with the keyword `:noweb':

#+begin_src latex :noweb yes :results raw
,#+LaTeX_Header: <>
#+end_src

(This useful trick came from Charles Berry in this thread:
https://orgmode.org/list/225a3d45-0f47-4ffe-8bba-f023cb8c9...@health.ucsd.edu/#r)

Best regards,

Juan Manuel

Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Bhavin Gandhi]

Hello Ihor,

On Sat, 10 Jul 2021 at 19:18, Ihor Radchenko  wrote:
> The breakage was introduced in commit c67037:
>
> [c670379adfbdc4883d3cfa230289fd2829993265] Fix `org-agenda-todo' undo 
> behavior when logging (not adding note)
>
> The fix is attached.

Thank you! I tried the patch, but the original bug[1] which the commit
`c67037' tried to fix, gets introduced again. Basically,
`org-agenda-undo' just removes the logbook entry and the scheduled date
remains new.

[1] https://orgmode.org/list/87v98a8mes@gnu.org/

Re: [PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Gustavo Barros]

Hi Ihor,

On Sat, 10 Jul 2021 at 10:48, Ihor Radchenko  wrote:


The breakage was introduced in commit c67037:

[c670379adfbdc4883d3cfa230289fd2829993265] Fix `org-agenda-todo' undo 
behavior when logging (not adding note)


The fix is attached.


Thank you very much!

Best,
Gustavo.

Re: org-mode export to (latex) PDF

[Stefan Nobis]

Maxim Nikulin  writes:

> (add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))

Do not do this. Both, utf8x and ucs, are obsolete and deprecated for
quite some time.

For proper unicode support, switch from pdflatex to lualatex or
xelatex. With these newer backends (and proper adjustments for the
LaTeX preamble generated by Org) Unicode should work out of the box
(if the font supports the requested Unicode characters).

My current packages setup to support all three engines looks like
this (should work for normal documents and beamer):

--8<---cut here---start->8---

(setq org-latex-default-packages-alist
'(("AUTO" "inputenc" t ("pdflatex"))
  ("T1" "fontenc" t ("pdflatex"))
  ("" "fontspec" t ("lualatex" "xelatex"))
  ("AUTO" "babel" t ("pdflatex" "lualatex"))
  ("AUTO" "polyglossia" t ("xelatex"))
  ("" "graphicx" t)
  ("" "grffile" t)
  ("" "longtable" nil)
  ("" "wrapfig" nil)
  ("" "rotating" nil)
  ("normalem" "ulem" t)
  ("" "mathtools" t)
  ("" "amssymb" t)
  ("" "textcomp" t ("pdflatex"))
  ("warnings-off={mathtools-colon,mathtools-overbracket}" 
"unicode-math" t ("lualatex" "xelatex"))
  ("" "caption" nil)
  ("" "booktabs" t)
  ("" "hyperref" nil)
  "\\tolerance=1000"))

--8<---cut here---end--->8---

To switch e.g. to lualatex (and e.g. use latexmk for compiling), I
use:

--8<---cut here---start->8---

(setq org-latex-compiler "lualatex")
(setq org-latex-bib-compiler "biber")
(setq org-latex-pdf-process '("latexmk -f -pdf -%latex -outdir=%o %f"))

--8<---cut here---end--->8---

--
Until the next mail...,
Stefan.

Re: org-mode export to (latex) PDF

[Maxim Nikulin]

On 10/07/2021 20:52, Juan Manuel Macías wrote:


I agree with you that Org should have multilingual support. A few months
ago I started this thread here, with some proposals:
https://orgmode.org/list/87o8d95pvo@posteo.net/


I tried to draw more attention to support of locale-aware formatting of 
numbers on emacs-devel mail list. Certainly a question concerning 
mixed-language buffers were raised. Result of attempts to discuss text 
properties to mark regions having alternative languages was just "Which 
property will help here? we don't have such properties" from Eli Zaretskii.



 > Jean-Christophe Helary writes:


I guess it is an issue with the Latex backend and could have been
solved with the proper Latex settings, but it seems weird that the
default settings do not allow for out-of-the-box multilingual
support.


(add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))

might help. I am not an active LaTeX user last years, so I am unaware 
whether \usepackage[utf8x]{inputenc} has any drawbacks.

[BUG] org-goto slows down org-set-property

[Maxim Nikulin]

It is rather annoying that C-c C-x p `org-set-property' may be quite 
slow if a file is large enough. (I do not consider it huge however.) 
There is noticeable delay before the prompt for property name appears in 
minibuffer. Accidentally I have noticed that sometimes it is fast.


Problem appears after first jump using C-u C-c C-j `org-goto'. Actually 
a jump is not required, it is enough to get jump (refile) targets.


I hope, the following numbers are convincing enough. Second attempt to 
get list of properties is much slower than the first one.


#+begin_src elisp
  (require 'org-refile)
  (let ((org-refile-targets '((nil :maxlevel . 6)))
(org-refile-use-outline-path 'file)
(org-refile-use-cache t)
(iters 10))
(cons
 (list (org-version))
 (mapcar (lambda (f)
   (append (list f) (benchmark-run iters (funcall f
 (list #'org-buffer-property-keys
   #'org-refile-get-targets
   #'org-buffer-property-keys
#+end_src

git master:

#+RESULTS:
| 9.4.6|  || |
| org-buffer-property-keys | 0.065695 |  0 | 0.0 |
| org-refile-get-targets   | 1.836473 | 12 | 0.3949867119985 |
| org-buffer-property-keys | 0.563227 |  0 | 0.0 |

elpa-org system package for Ubuntu-20.04 is even more slower:

#+RESULTS:
| 9.3.1| || |
| org-buffer-property-keys | 0.242574778 |  0 | 0.0 |
| org-refile-get-targets   | 2.669112479 | 13 | 0.285175928 |
| org-buffer-property-keys | 1.231223427 |  0 | 0.0 |

The effect is noticeable for the doc/org-manual.org file from org 
sources though absolute numbers are well below delay that makes 
interaction incomfortable.


In the configuration above effect of `org-refile-use-cache' is crucial, 
contribution of `org-refile-use-outline-path' is noticeable but not so 
important.


My expectation is that neither `org-refile-use-cache' nor `org-goto' 
command should make adding property slower.

Re: org-mode export to (latex) PDF

[Tim Cross]

Juan Manuel Macías  writes:

> Hi Jean-Christophe,
>
> Jean-Christophe Helary writes:
>
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
>
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf
>
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
>
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
>
> #+LaTeX_Header: \usepackage[several langs]{babel}
>
> @@latex:\begin{otherlanguage*}{german}@@
>
> ... some text in german ...
>
> @@latex:\end{otherlanguage*}@@
>
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
>
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}

Just FYI for those who don't know, you can use the org-latex-classes
variable to define your own pseudo document classes, possibly using the
DEFAULT_PACKAGES, PACKAGES, EXTRA_PACKAGES macros and other latex
settings. So for example, you can add the babel or other packages you
want and either make that the 'default' class or specify which class you
want with the #+LATEX_CLASS header. I use this quite a bit because then
I don't have to remember which LATEX_HEADER lines to include in the
document, the specific option settings etc. I don't need support for
multilingual documents, but I do have a number of 'special' documents
(such as one with colours, logos and specific fonts for an employer to
match their 'style guide'. I also have ones for generating project
documents, letters, meeting minutes etc. They all use various different
Latex extensions (particularly ones which don't mix well and cannot be
included with other packages).

The LATEX_HEADER: options are useful for 'one off' documents, but become
a real pain to include all the time. however, I see this quite a lot and
just wanted to highlight that when you need to customise the latex
process, you do have these other options which can be very useful and I
suspect would be good for things like setting up support for
multilingual environments. I also use luatex rather than the default
plain 'latex' (mainly because of better/more flexible font support). 

I could be wrong as I've not looked at this in a long time, but one of
the problems with multilingual support in Latex was that it was somewhat
'fragile'. There were a number of packages which did not work well when
combined with certain fonts required for multilingual support and (from
memory) issues with hyphenation and packages which extended some
environments. While it was generally possible to tweak things to get
them to work, it was somewhat challenging to get them to work 'across
the board'. I don't know if this is still the case as it has been some
years incde I've needed to dig into Latex (mainly because now I do
almost everything just in org mode and don't need to!). This, combined
with a smaller user base for multilingual documents, may partly explain
the difficulty in gaining traction in this area. I do recall that
getting a stable general latex environment working for org exports was
somewhat challenging originally.

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 10, 2021, at 23:38, Juan Manuel Macías  wrote:
> 
> Hi Jean-Christophe,
> 
> Jean-Christophe Helary writes:
> 
>> I had given up on Latex because mixing languages sounded like a huge
>> pain in the butt but I see that without some org-level infrastructure
>> it is not possible to achieve much when exporting to Latex/PDF (unless
>> I missed something).
> 
> Well, LaTeX has excellent (typographic and orthotypographic)
> multilingual support, using the babel or polyglossia packages. I
> especially recommend babel:
> http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf

Thank you very much Juan.

I understand that Latex has excellent support for multilingual files. I use it 
sometimes for very complex multilingual texts (ancient Japanese and French for 
ex).

But with UTF-8 being ubiquitous on computers nowadays, I really can't be 
bothered to have to type all those sequences to have org-mode properly export 
to PDF something that it exports perfectly well to ODT without requiring 
anything extra.

Which is the reason why I was wondering about a "generic" default setting where 
the conversion engine behind org could just use a default multilingual package 
and a default "wide enough" generic font. I really mean a "good enough" export 
where all the characters are visible, nothing fancy.

Jean-Christophe 

> 
> And LaTeX also has very good support for oriental languages or languages
> with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
> also use opentype fonts and opentype features.
> 
> The problem is how to translate that from Org --in an org-centric way--
> to LaTeX. Currently, you can apply LaTeX commands for multilingual
> management directly in your Org document. For example:
> 
> #+LaTeX_Header: \usepackage[several langs]{babel}
> 
> @@latex:\begin{otherlanguage*}{german}@@
> 
> ... some text in german ...
> 
> @@latex:\end{otherlanguage*}@@
> 
> Recently, I submitted a patch here that allows adding LaTeX attributes
> to `quote' blocks. Then, you could do something like this:
> 
> #+LaTeX_Header:\usepackage[german,english]{babel}
> #+LaTeX_Header:\usepackage{quoting}
> #+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
> #+LaTeX_Header:\SetBlockEnvironment{quoting}
> 
> #+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
> #+begin_quote
> Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
> Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
> sich in ihr vorgesetzt, sowie über die Veranlassungen und das
> Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
> Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
> einer philosophischen Schrift nicht nur überflüssig, sondern um der
> Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
> #+end_quote
> 
> Best regards,
> 
> Juan Manuel 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Juan Manuel Macías]

Hi Jean-Christophe,

Jean-Christophe Helary writes:

> I had given up on Latex because mixing languages sounded like a huge
> pain in the butt but I see that without some org-level infrastructure
> it is not possible to achieve much when exporting to Latex/PDF (unless
> I missed something).

Well, LaTeX has excellent (typographic and orthotypographic)
multilingual support, using the babel or polyglossia packages. I
especially recommend babel:
http://mirrors.ctan.org/macros/latex/required/babel/base/babel.pdf

And LaTeX also has very good support for oriental languages or languages
with complex writing, especially in LuaTeX. In LuaTeX and XeTeX you can
also use opentype fonts and opentype features.

The problem is how to translate that from Org --in an org-centric way--
to LaTeX. Currently, you can apply LaTeX commands for multilingual
management directly in your Org document. For example:

#+LaTeX_Header: \usepackage[several langs]{babel}

@@latex:\begin{otherlanguage*}{german}@@

... some text in german ...

@@latex:\end{otherlanguage*}@@

Recently, I submitted a patch here that allows adding LaTeX attributes
to `quote' blocks. Then, you could do something like this:

#+LaTeX_Header:\usepackage[german,english]{babel}
#+LaTeX_Header:\usepackage{quoting}
#+LaTeX_Header:\usepackage[babel=true,autostyle=true,german=quotes]{csquotes}
#+LaTeX_Header:\SetBlockEnvironment{quoting}

#+ATTR_LaTeX: :environment foreigndisplayquote :options {german}
#+begin_quote
Eine Erklärung, wie sie einer Schrift in einer Vorrede nach der
Gewohnheit vorausgeschickt wird ---über den Zweck, den der Verfasser
sich in ihr vorgesetzt, sowie über die Veranlassungen und das
Verhältnis, worin er sie zu andern frühern oder gleichzeitigen
Behandlungen desselben Gegenstandes zu stehen glaubt--- scheint bei
einer philosophischen Schrift nicht nur überflüssig, sondern um der
Natur der Sache willen sogar unpassend und zweckwidrig zu sein (Hegel).
#+end_quote

Best regards,

Juan Manuel 

Re: [PATCH] extra space at the end of lines in source

[Greg Minshall]

hi.  i don't know who might merge Sébastien Miquel's fix into the source
code, but i'd be a promoter of this happening whenever it's convenient.

cheers, Greg

Sébastien Miquel  wrote:

> Greg Minshall writes:
> > thanks.  my trivial test shows this works*except*  in the particular
> > case where, when closing the Org Src buffer, `point` is on an empty
> > line.  in this case, that one empty line is given extra spaces.
> Yes, I was aware of this, but didn't think we could do better in this
> case. I've
> thought about it some more, and came up with a solution.
> 
> Here's a new patch that's smarter about indenting the current line,
> and resolves
> this remaining issue.
> 
> Regards,
> 
> -- 
> Sébastien Miquel
> 

Re: org-mode export to (latex) PDF

[Jean-Christophe Helary]

> On Jul 10, 2021, at 22:52, Juan Manuel Macías  wrote:
> 
> Hi Jean-Christophe,
> 
> Jean-Christophe Helary writes:
> 
>> I guess it is an issue with the Latex backend and could have been solved 
>> with the proper Latex settings, but it seems weird that the default settings 
>> do not allow for out-of-the-box multilingual support.
> 
> I agree with you that Org should have multilingual support. A few months
> ago I started this thread here, with some proposals:
> https://orgmode.org/list/87o8d95pvo@posteo.net/

Juan,

That's a very interesting proposal. Thank you for the reference.

I had given up on Latex because mixing languages sounded like a huge pain in 
the butt but I see that without some org-level infrastructure it is not 
possible to achieve much when exporting to Latex/PDF (unless I missed 
something).

So I guess I'll just keep my current workflow for now, with ODT as my "pivot" 
format.

Thank you again, Juan.


-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: org-mode export to (latex) PDF

[Juan Manuel Macías]

Hi Jean-Christophe,

Jean-Christophe Helary writes:

> I guess it is an issue with the Latex backend and could have been solved with 
> the proper Latex settings, but it seems weird that the default settings do 
> not allow for out-of-the-box multilingual support.

I agree with you that Org should have multilingual support. A few months
ago I started this thread here, with some proposals:
https://orgmode.org/list/87o8d95pvo@posteo.net/

Best regards,

Juan Manuel 

[PATCH] Re: Bug: Duplicate logbook entry for repeated tasks [9.4.6 (9.4.6-gab9f2a @ /home/gustavo/.emacs.d/elpa/org-9.4.6/)]

[Ihor Radchenko]

Bhavin Gandhi  writes:

> I was able to reproduce this, and here are my findings as well as a
> reproducible configuration with only a few settings.

The breakage was introduced in commit c67037:

[c670379adfbdc4883d3cfa230289fd2829993265] Fix `org-agenda-todo' undo behavior 
when logging (not adding note)

The fix is attached.

Best,
Ihor

>From ff3c0f6524d4165518ec0c53b49a58162ff7b2a9 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sat, 10 Jul 2021 21:43:44 +0800
Subject: [PATCH] Fix duplicate logbook entry for repeated tasks

* lisp/org.el (org-add-log-setup): Always run `org-add-log-note' via
`post-command-hook'.  Otherwise, there is no way to know if a note was
requested for `this-command'.  Running `org-add-log-note' directly
would, for example, break `org-auto-repeat-maybe' as reported in [1].

[1] https://orgmode.org/list/CAOn=hbcaW1R6vtun-E2r4LS=j3dp=vjqmjgtzy8uc1sypar...@mail.gmail.com
---
 lisp/org.el | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..3d15771a2 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10939,9 +10939,7 @@ (defun org-add-log-setup ( purpose state prev-state how extra)
 	org-log-note-extra extra
 	org-log-note-effective-time (org-current-effective-time)
 org-log-setup t)
-  (if (eq how 'note)
-  (add-hook 'post-command-hook 'org-add-log-note 'append)
-(org-add-log-note purpose)))
+  (add-hook 'post-command-hook 'org-add-log-note 'append))
 
 (defun org-skip-over-state-notes ()
   "Skip past the list of State notes in an entry."
-- 
2.31.1

org-mode export to (latex) PDF

[Jean-Christophe Helary]

I was busy last year going back to school and I wrote a research paper for my 
first year of master almost entirely in org-mode.

My workflow was trivial:

- write in org-mode
- enter the bibliography with Zotero
- export to ODT and open in NeoOffice
- modify in NeoOffice
- deliver

At first, I tried to export the document to PDF but all the Japanese quotes I 
had were removed from the document, which led me to prefer ODT export because 
it handled them properly.

I guess it is an issue with the Latex backend and could have been solved with 
the proper Latex settings, but it seems weird that the default settings do not 
allow for out-of-the-box multilingual support.

Is there an easy way to have that as the default behavior?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: [WDYT] org-attach-sync better remove an empty attachment directory?

[Colin Baxter]

> Marco Wahl  writes:

> Colin Baxter  writes:
>>> Tim Cross  writes:
>> 
> We could introduce multiple possibilities to choose from.
>> >>>
>> >>> 1. Ask in case of an empty directory if it should be deleted.
>> >>> 2. Don't ask.  Don't touch an empty directory.  (The state
>> now.)  >>> 3. Don't ask.  Delete empty directory.
>> >>>
>> >>> We could also make 3. the default setting.
>> >>
>> >> I made a mistake here.
>> >>
>> >> If we do this I vote for option 1. (not 3.) as default
>> (following >> the suggestion by Colin) since it is the most
>> interactive >> variant.  If the question gets annoying the user
>> can switch to >> one of the other options.
>> >>
>> 
>> > That seems quite resonable to me.
>> 
>> And me.

> Thanks!

> I pushed respective code.  Critique is always welcome.

For me, this works really well. Thank you for a great addition.

Best wishes,

Colin Baxter.

Re: [PATCH] [BUG] Bad fontification in full displayed links

[Juan Manuel Macías]

Hi Ihor,

Ihor Radchenko writes:

> Why not just (add-face-text-property start end face-property)?

You are right, I think that solution is much simpler. I attach a
new patch and I have included your name in the commit message, for the
suggestion. Thanks!

Best regards,

Juan Manuel 

>From 0e31ba4ce76e436712285b163b8595b0a973da94 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sat, 10 Jul 2021 13:53:44 +0200
Subject: [PATCH] org.el: prevent partial fontification when a link is
 displayed full

* lisp/org.el (org-activate-links): apply `face-property' variable in
other cases when handle invisible parts in bracket
links: `(add-face-text-property start end face-property)' suggestion
from Ihor Radchenko
---
 lisp/org.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org.el b/lisp/org.el
index ffcc5945d..eca12a5e7 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5228,7 +5228,7 @@ This includes angle, plain, and bracket links."
 'org-link))
 			 properties)))
 		(add-text-properties start visible-start hidden)
-(add-face-text-property visible-start visible-end face-property)
+(add-face-text-property start end face-property)
 		(add-text-properties visible-start visible-end properties)
 		(add-text-properties visible-end end hidden)
 		(org-rear-nonsticky-at visible-start)
-- 
2.32.0

[a very different solution] (was: convert subtree or nested list to table)

[Uwe Brauer]

>>> "MP" == Matt Price  writes:

> I have to write a number of text-heavy documents which need to be delivered
> as tables with wrapped paragraphs in most cells. Working directly in table
> format is pretty arduous and uncomfortable.  Has anyone ever written a
> function to accept a list or subtree as input and process it into a table?

> If anyone has done something similar, I'd love some tips!

I am facing currently a similar problem. The best solution, at least for
me, is described here:

https://emacsnotes.wordpress.com/2020/04/26/create-tables-with-paragraph-like-content-in-org-mode-with-the-least-amount-of-hassle/


smime.p7s
Description: S/MIME cryptographic signature

[bug] Setting org-id-link-to-org-use-id to t creates IDs properties when tangling

[Rodrigo Morales]

* The issue

When setting org-id-link-to-org-use-id to t, an :ID: property is created
for each headline that contain at least one code block that is
tangled.

* Reproducing this issue

1. Start emacs -Q

2. Open a "*.org" file at a location where you have write permissions
(this is because, apparently, tangling only works when the file is
correctly saved so this way we get rid of this possible issue)

3. Insert the following minimal working example into the buffer (you can
find the Org Mode file attached to this mail)

#+BEGIN_SRC org
,* foo

,#+HEADER: :tangle ~/Downloads/main.txt
,#+BEGIN_SRC text
a
,#+END_SRC

,* bar

,#+HEADER: :tangle ~/Downloads/main.txt
,#+BEGIN_SRC text
a
,#+END_SRC

,* fizz

,#+BEGIN_SRC text
a
,#+END_SRC
#+END_SRC

4. Execute the following commands

#+BEGIN_SRC emacs-lisp
(require 'org-id)
(setq org-id-link-to-org-use-id t)
#+END_SRC

5. Now, execute org-babel-tangle (C-c C-v C-t).

At this point, a id property is created for the "foo" and "bar"
headlines because those are the only headlines that contain a code
block. This is what I got in emacs -Q

#+BEGIN_SRC org
,* foo
  :PROPERTIES:
  :ID:   358560b4-2426-4d42-a498-ae16195daf3a
  :END:

,#+HEADER: :tangle ~/Downloads/main.txt
,#+BEGIN_SRC text
a
,#+END_SRC

,* bar
  :PROPERTIES:
  :ID:   02217461-a744-42b2-b582-1a836568d686
  :END:

,#+HEADER: :tangle ~/Downloads/main.txt
,#+BEGIN_SRC text
a
,#+END_SRC

,* fizz

,#+BEGIN_SRC text
a
,#+END_SRC
#+END_SRC

* Personal thoughts

In my opinion, this is undesired behavior because the goal of
org-id-link-to-org-use-id isn't creating an ID property for each
headline when performing tangling.

* Major undesired consequences

The following is an scenario in which this issue causes major undesired
consequences: Consider the following scenario

+ you have 1000 headlines in an Org Mode file

+ all of those headlines don't have an ID property (because you are not
  interested in uniquely identifying all of those headlines through an ID)
  
+ all of those headlines contain at least one code block that is tangled

Because of this issue, the following would be added for each headline

#+BEGIN_SRC org
,* my headline
:PROPERTIES:
:ID: <>
:END:
#+END_SRC

and this have the following undesired consequences

+ You would end up with 3000 lines in your Org Mode file because of the
  id properties even when you weren't interested in creating an ID for
  each of those headlines.
  
+ You would have 1000 more entries in org-id-locations-file (again, even
  where you weren't interested in creating an ID for each of those
  headlines)


-- 
La información contenida en este e-mail y sus anexos es confidencial, 
privilegiada y está dirigida exclusivamente a su destinatario, en 
consecuencia, solo puede ser utilizada por aquel. Si usted no es el 
destinatario original, no deberá examinar, usar, copiar o distribuir este 
mensaje o la información que contiene. Si lo recibe por error, por favor 
reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o 
uso total o parcial no autorizada de este mensaje está estrictamente 
prohibida y sancionada por ley.
* foo

#+HEADER: :tangle ~/Downloads/main.txt
#+BEGIN_SRC text
a
#+END_SRC

* bar

#+HEADER: :tangle ~/Downloads/main.txt
#+BEGIN_SRC text
a
#+END_SRC

* fizz

#+BEGIN_SRC text
a
#+END_SRC


-- 
[[[ If you see a signature in spanish below/above this message, please
omit it. It is automatically inserted in all my messages due to the
internal privacy policies of the organization that owns the domain of my
email address. ]]]

Re: [PATCH] ob-R output file with graphics parameter

[Jeremie Juste]

Re: Feature request: in org html export, option to disable id & class properties.

[András Simonyi]

Hello,
I'm not really familiar with the internals of the built-in html
exporter but the slimhtml exporter
[https://github.com/balddotcat/ox-slimhtml]  might be closer to what
you're looking for.

best regards,
András

On Sat, 10 Jul 2021 at 09:08, Zachary Kanfer  wrote:
>
> When I export this sample org file:
>
> * top-level header
> ** and here we have #2
>
> The body of the generated html has this content:
>
> 
>   top-level header
>   
> and here we have #2
>   
> 
>
> I would prefer the html to not have these id or class properties; something 
> like this:
>
> 
>   top-level header
>   
> and here we have #2
>   
> 
>
> Actually, I'd rather skip the divs entirely, but that is a separate issue. 
> Could there be a configurable way to disable the creation of these 
> properties? I have searched the mailing list, and have not found anything. 
> Perhaps I've missed something; there are a lot of results for "html class id" 
> or similar searches. Thanks.

Feature request: in org html export, option to disable id & class properties.

[Zachary Kanfer]

When I export this sample org file:

* top-level header
** and here we have #2

The body of the generated html has this content:


  top-level header
  
and here we have #2
  


I would prefer the html to not have these id or class properties; something
like this:


  top-level header
  
and here we have #2
  


Actually, I'd rather skip the divs entirely, but that is a separate issue.
Could there be a configurable way to disable the creation of these
properties? I have searched the mailing list, and have not found anything.
Perhaps I've missed something; there are a lot of results for "html class
id" or similar searches. Thanks.