Bug: org-element does not recognize table.el tables [9.4 (release_9.4-53-g23f941 @ /home/nick/elisp/org-mode/lisp/)]

[Nick Dokos]

Consider an Org mode file with a table.el table (which I made by
first constructing an Org mode table and then usind `C-c ~' to convert it):


--8<---cut here---start->8---
* table.el table


  ++++
  |  a |  b |  c |
  ++++
  |  1 |  2 |  3 |
  ++++
  |  4 |  5 |  6 |
  ++++
  |  7 |  8 |  9 |
  ++++
  | 10 | 11 | 12 |
  ++++
--8<---cut here---end--->8---

Trying to export to LaTeX produces pretty mangled output.

It turns out that when in
 `org-latex-table', (org-element-property :type table) returns `org', so
 it thinks it's an Org mode table and calls `org-latex--org-table' to
 process it, producing output like this:

--8<---cut here---start->8---
\sout{}\sout{}
\begin{center}
\begin{tabular}{lll}
a & b & c\\
\end{tabular}
\end{center}
\sout{}\sout{}
\begin{center}
\begin{tabular}{rrr}
1 & 2 & 3\\
\end{tabular}
\end{center}
\sout{}\sout{}

...

\begin{center}
\begin{tabular}{rrr}
10 & 11 & 12\\
\end{tabular}
\end{center}
\sout{}\sout{}
--8<---cut here---end--->8---


Evaluating `(org-element-at-point)' returns `(paragraph ...)' all along
the top line and `(table ( :type org ))' when the cursor is at
the beginning of the `a b c' line.


Emacs  : GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.13, 
cairo version 1.16.0)
 of 2020-10-30
Package: Org mode version 9.4 (release_9.4-53-g23f941 @ 
/home/nick/elisp/org-mode/lisp/)

-- 
Nick

Re: [PATCH] Fix ODT output for scheduled items.

[Nick Dokos]

Same patch but fixes the typo in the Changelog:

>From 7dc4877469c5bed7580ff80e9534480e16972b93 Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Sat, 28 Nov 2020 10:01:02 -0500
Subject: [PATCH] org-odt-planning: Fix scheduled item output

* lisp/ox-odt.el (org-odt-planning): Use org-scheduled-string, not
  org-deadline-string, for scheduled items.

See <https://emacs.stackexchange.com/questions/61985/org-export-to-odt-incorrectly-use-deadline-for-scheduled> for an ECM.
---
 lisp/ox-odt.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 4619f9fcd..ef07acfed 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -2946,7 +2946,7 @@ channel."
 	 (when scheduled
 	   (concat
 		(format "%s"
-			"OrgScheduledKeyword" org-deadline-string)
+			"OrgScheduledKeyword" org-scheduled-string)
 		(org-odt-timestamp scheduled contents info)))
 
 
-- 
2.25.4


-- 
Nick

[PATCH] Fix ODT output for scheduled items.

[Nick Dokos]

The ODT exporter uses the org-deadline-string for scheduled items. This
apparently predates the introduction of the "new" exporter in 2013 -
time flies...

It was reported on Emacs SE:

 
https://emacs.stackexchange.com/questions/61985/org-export-to-odt-incorrectly-use-deadline-for-scheduled

Patch attached.

>From 429d3eb816d0673326969f50b478f4d622147432 Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Sat, 28 Nov 2020 10:01:02 -0500
Subject: [PATCH] org-odt-planning: Fix scheduled item output

* lis/ox-odt.el (org-odt-planning): Use org-scheduled-string, not
  org-deadline-string, for scheduled items.

See <https://emacs.stackexchange.com/questions/61985/org-export-to-odt-incorrectly-use-deadline-for-scheduled> for an ECM.
---
 lisp/ox-odt.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 4619f9fcd..ef07acfed 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -2946,7 +2946,7 @@ channel."
 	 (when scheduled
 	   (concat
 		(format "%s"
-			"OrgScheduledKeyword" org-deadline-string)
+			"OrgScheduledKeyword" org-scheduled-string)
 		(org-odt-timestamp scheduled contents info)))
 
 
-- 
2.25.4


-- 
Nick

Re: add linked files to agenda files

[Nick Dokos]

Alan Schmitt  writes:

> Hello,
>
> I'm experimenting with a setup where each project is its own org file,
> and where I have a master file linking to active projects. How can I
> configure org to add every linked file of that master file to the
> org-agenda-files?
>

You'll probably have to write a custom function to do that, but it
depends on how exactly your master file is set-up, so providing some
details on that would help.

Just guessing at this point, I would imagine you'd want something like
this:

--8<---cut here---start->8---
(defun path-from-link (link)
   (org-element-property :path link))

(setq org-agenda-files (with-current-buffer
 (find-file-noselect "master.org")
 (org-element-map (org-element-parse-buffer)
  '(link)
  #'path-from-link)))
--8<---cut here---end--->8---

but the details might make a difference.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: New website - back to the old unicorn!

[Nick Dokos]

Sounds good to me.

And thanks for all the work to update the site!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: New website - back to the old unicorn!

[Nick Dokos]

One thing that I have done in the past (and I'm probably not the onlye
one) on the Emacs SE is refer people to the mailing list through the
old link: https://orgmode.ord/community.html which does not exist any
more, so we have a whole lot of broken links on Emacs SE at the moment:
can something be done to restore the functionality of those links?

Thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: recursive checkbox counting

[Nick Dokos]

Alan Schmitt  writes:

> On 2020-10-01 14:24, torys.ander...@gmail.com (Tory S. Anderson) writes:
>
>> The way I've made this work is with the following property:
>>
>>:COOKIE_DATA: ALL
>>
>> But I suppose I haven't tried if that's fully recursive.
>
> Thank you for the suggestion. I gave it a try, and unfortunately it does
> not work.
>

Not sure whether this will work (or whether it will help in your case):

   
https://emacs.stackexchange.com/questions/60710/is-there-any-way-of-getting-overview-statistics-for-all-checkboxes-in-a-given-or/60747#60747

There are some links to other questions on Emacs SE that might (or
might not) be helpful.

> Best,
>
> Alan
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: Infinite loop caused by org-agenda-property-list [9.4 (9.4-elpa @ /home/dsmasterson/.emacs.d/elpa/org-9.4/)]

[Nick Dokos]

David Masterson  writes:

> Nick Dokos  writes:
>
>> From what I can gather, this does not have much to do with Org mode
>> proper, which has no org-agenda-property-list at all. I presume that
>> you have
>>
>> https://github.com/Malabarba/org-agenda-property/blob/master/org-agenda-property.el
>>
>> installed, which does provide such a variable, but all that one can
>> say atm is that that library has a bug *or* is incompatible with
>> (current?) Org mode.  In either case, I think you should report it as
>> an issue to the above site.  Once they have figured out what is wrong,
>> then maybe an RFE against Org mode *might* be indicated.
>
> Ah!  That makes sense.  I'll look into it.
>

You might be able to work around the problem by having org-agenda-property put 
the
property on the same line:

   (setq org-agenda-property-position 'same-line)

and adjusting the position on the line with

   (setq org-agenda-property-column 100)

if necessary.

If the infinite loop goes away in that case, then you have some confirmation of 
your
theory about two-line agenda entries.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-tempo question

[Nick Dokos]

I can't say anything about indentation (I encounter problems that I
have not reported because of lack of time to investigate combined with
laziness - but I suspect they are, partly at least, of my own making).

But when I do `8---
#+NAME: third
#+begin_src org

- an item
  - subitem

  ,#+begin_example

  ,#+end_example

#+end_src

#+begin_example

#+end_example


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

The commas are important: are you not getting them?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: The Website Revamp: The final stretch

[Nick Dokos]

"collapsable" should be "collapsible".

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: The Website Revamp: The final stretch

[Nick Dokos]

Nix on variant C from me.

Slight lean towards B, but I personally would be happy with either A or B.

Thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: Infinite loop caused by org-agenda-property-list [9.4 (9.4-elpa @ /home/dsmasterson/.emacs.d/elpa/org-9.4/)]

[Nick Dokos]

>From what I can gather, this does not have much to do with Org mode
proper, which has no org-agenda-property-list at all. I presume that
you have

https://github.com/Malabarba/org-agenda-property/blob/master/org-agenda-property.el

installed, which does provide such a variable, but all that one can
say atm is that that library has a bug *or* is incompatible with
(current?) Org mode.  In either case, I think you should report it as
an issue to the above site.  Once they have figured out what is wrong,
then maybe an RFE against Org mode *might* be indicated.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-tables with monetary amounts

[Nick Dokos]

For fixed precision, you can either use an explicit format as Russell Adams 
points out,
or you can modify (globally or per file) the variable org-calc-default-modes. 
That's a
complicated variable and you only need to change one part of it for this:

(plist-put org-calc-default-modes 'calc-float-format '(fix 2))

See e.g. https://emacs.stackexchange.com/a/59181/14825 for some discussion.
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Infinite recursion ?

[Nick Dokos]

Nick Dokos  writes:

> What's the error message? Did you try setting `debug-on-eror'? Does that give
> a more useful backtrace?

Backtrace: no variable named `debug-on-eror' - maybe you made an eror :-)

Sigh - should be `debug-on-error'.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Infinite recursion ?

[Nick Dokos]

David Masterson  writes:

> Haven't figured this out yet, but I seem to be hitting an "infinite
> recursion" bug that eventually dies when it runs out of memory.
>
> The scenario (so far) is trying to change an Org tag in the agenda
> (':'). The command gives me the tags that I then edit and save whereupon
> it sits in an infinite recursion until it hits a limit in Emacs. If I
> quit, the files seem to have been updated, but the Agenda isn't.  I'm
> still trying to figure out how to debug this.  Setting debug-on-quit was
> not consistent and didn't seem to have a large list of function calls
> (ie. the recursion).  Any ideas?
>
> This is Emacs 26.3 with Orgmode 9.4.  I'm also using Org-Super-Agenda
> from Melpa (20200310.1337).
>
> Side question that might be related: org-agenda started positioning
> itself at the end of the agenda rather than the beginning after building
> the agenda.  I don't think I changed something for this.  What could
> cause this?

What's the error message? Did you try setting `debug-on-eror'? Does that give
a more useful backtrace?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: creating png images in emails with org-mode

[Nick Dokos]

Eric S Fraga  writes:

> On Thursday, 17 Sep 2020 at 00:57, Nick Dokos wrote:
>> Apparently, recent versions of ImageMagick (version 7 seems to be one)
>> on (perhaps) some distros ship with a
>> /etc/ImageMagick-/policy.xml file that imposes restrictions
>> on what can be done. Here's an SE question with some information:
>
> Thank you.  Interesting.
>
> For the OP, it might be worth noting that the solution on the
> StackExchange page you linked to refers to the generation of PDF files
> from the LaTeX snippet; I would imagine that the fix noted will need to
> be adjusted for PNG files but cannot verify as I'm still on ImageMagick
> version 6 and don't have these issues.

Actually, it refers to the generation of PNG files from PDF files using
`convert' (I think). The `imagemagick' process of LaTeX preview uses
`pdflatex'to go from TeX to PDF and `convert' to go from PDF to PNG.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: creating png images in emails with org-mode

[Nick Dokos]

Joseph Vidal-Rosset  writes:

> Hello,
>
> One more time, my setup to create png image via LaTeX in email in org-mode is 
> broken.
>
> I get this error message:
>
> Creating LaTeX preview...
> org-compile-file: File "/tmp/orgtex2wp50c.png" wasn’t produced.  Please 
> adjust ‘imagemagick’ part of ‘org-preview-latex-process-alist’.
>
> Your help is welcome, because I do not understand what I have to do, how I 
> have to "adjust" imagemagick.
>
> Best wishes,
>
> Jo.
>

Apparently, recent versions of ImageMagick (version 7 seems to be one)
on (perhaps) some distros ship with a
/etc/ImageMagick-/policy.xml file that imposes restrictions
on what can be done. Here's an SE question with some information:


https://emacs.stackexchange.com/questions/31408/error-message-when-previewing-latex-snippet-in-org-file

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: basic org questions

[Nick Dokos]

Emanuel Berg via "General discussions about Org-mode."  
writes:

> Matt Huszagh wrote:
>
>> Were you referring to the tables being centered
>> after export (I see from another part of this chain
>> that that's what you were referring to in the 3rd
>> question) when you wanted them left-aligned?
>> If that is the case, it would really help if you
>> specify that in your original question.
>> Appearance in an org-mode buffer and appearance in
>> the PDF, HTML, etc. after export are very different
>> things with very different configuration.
>
> Yes, after export to PDF, they are centered. they =
> the whole table items.

(setq org-latex-tables-centered nil)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

#+ATTR_HTML examples uses old syntax

[Nick Dokos]

The attached patch fixes an example in the "Tables in HTML export"
section of the manual that uses the old `border="3"' syntax instead
of `:border 3' etc.

>From 52be0b5b1fe492b3ff44e6ccd6dbfaed1eb88537 Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Sat, 12 Sep 2020 17:47:29 -0400
Subject: [PATCH] Fix syntax of #+ATTR_HTML

The example in the "Tables in HTML export" section of the manual
uses the old syntax: `border="2"' etc.

Change it to use `:border 2' etc.
---
 doc/org-manual.org | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 46498bd22..be60d99f6 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12817,7 +12817,7 @@ following lines before the table in the Org file:
 #+cindex: @samp{ATTR_HTML}, keyword
 #+begin_example
 ,#+CAPTION: This is a table with lines around and between cells
-,#+ATTR_HTML: border="2" rules="all" frame="border"
+,#+ATTR_HTML: :border 2 :rules all :frame border
 #+end_example
 
 The HTML export back-end preserves column groupings in Org tables (see
-- 
2.25.4


-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: latex fragments compilation error when exporting to html

[Nick Dokos]

Jeremie Juste  writes:

> Hello 
>
> When I export test.org to html, the latex fragment fail to compile. 
> The reason is a star get added to the tabular environment. {tabular*}
> (see tmpfile.tex). 
>
> I don't know why the function insists in using the tabular* environment.
>
> From this point I would have two questions:
>
> How can I remove the star from the tabular environment ?
> How can I can I find the culprit?
> - I was hoping to provide a patch by finding the culprit but I got lost.
>   - I tried to debug-on-entry org-format-latex.
>   
>
> Best regards,
> Jeremie
>
>> test.org 
>
> #+OPTIONS:   H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t 
> tex:imagemagick title:nil author:nil date:nil
> #+LATEX_HEADER: \usepackage{booktabs}
>
>  \begin{tabular}{lll}
>  \toprule
>   1 & 2 & 3 \\
>   5 & 6 & 8 \\
>  \bottomrule
>  \end{tabular}
>   
>> tmpfile.tex
>
> ...
>
> {\color{fg}
> \begin{tabular*}{lll}
> \toprule
>  1 & 2 & 3 \\
>  5 & 6 & 8 \\
> \hline
> \end{tabular*}
> %
> }
>
>

I cannot reproduce it with Org mode version 9.3.7 (release_9.3.7-705-gea9463 @ 
/home/nick/src/emacs/org/org-mode/lisp/).
What version are you using?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: convert a org table to plain text

[Nick Dokos]

Uwe Brauer  writes:

>> Uwe Brauer  writes:
>
>> Does this:
>
>> 
>> https://stackoverflow.com/questions/17717483/howto-convert-org-mode-table-to-original-tabbed-format/17726489#17726489
>
>
> Yes, very much so. It would be great to have that code included in
> orgmode. Did anybody try to contact the author?
>

You mean orgtbl-to-tsv and related? All of that *is* part of Org mode. All you 
have to do is write a code block calling it
to convert.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: convert a org table to plain text

[Nick Dokos]

Uwe Brauer  writes:

> Hi 
>
> What is the inverse function to 
> org-table-convert-region?
>
> I am unable to find anything in the documentation or google.
>
> Regards
>
> We Brauer 
>
>
>

Does this:


https://stackoverflow.com/questions/17717483/howto-convert-org-mode-table-to-original-tabbed-format/17726489#17726489

help?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [BUG] babel runs bash instead of zsh when sessions are used

[Nick Dokos]

Kyle Meyer  writes:

> Rudi C writes:
>
>> #+BEGIN_SRC zsh :session z1
>> echo $HOME $0
>> #+END_SRC
>>
>> #+RESULTS:
>> : /Users/evar /bin/bash
>
> What version of Org are you using?
>
> I tried with both the latest release (9.3.7) and the current master
> branch (220f2b0d9), using default configuration aside from
>
> (org-babel-do-load-languages
>  'org-babel-load-languages
>  '((shell . t)))
>
> I see "/usr/bin/zsh" in both cases.
>
>

I was able to reproduce it (with ksh, rather than zsh) on Org mode version 
9.3.7 (release_9.3.7-705-gea9463 @ /home/nick/elisp/org-mode/lisp/).

--8<---cut here---start->8---
#+BEGIN_SRC ksh :session z1
echo $HOME $0 $(which $0)
#+END_SRC

#+RESULTS:
: /home/nick /bin/bash /bin/bash

#+BEGIN_SRC ksh
echo $HOME $0 $(which $0)
#+END_SRC

#+RESULTS:
: /home/nick ksh /usr/bin/ksh

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

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: configure separator in org-table-insert-hline

[Nick Dokos]

Vladimir Alexiev  writes:

> How can I use radio tables for that?
>

By writing a translation function, similar to 
orgtbl-to-{csv,latex,html,texinfon,unicode,orgtbl}.
See

  (info "(org) Tables in Arbitrary Syntax")

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: :results raw replace header args for a code block don't replace [9.3.7 (9.3.7-18-g093b47-elpaplus @ /Users/skoshelev/.emacs.d/elpa/26.2/develop/org-plus-contrib-20200810/)]

[Nick Dokos]

TEC  writes:

> Julius Dittmar  writes:  
>> as far as I know this is no bug. Reason: How could org tell where
>> the old results end? There's no end marker. Thus instead of removing
>> everything that follows, it refrains from removing anything. 
>
> This is my understanding. It's also why I tend to use
>
> :results raw drawer
>

You mean `:results drawer'? There is no reason to include `raw'.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Bug: inserting capture template [9.3.7 (release_9.3.7-705-gea9463 @ /home/nick/elisp/org-mode/lisp/)]

[Nick Dokos]

This was reported in 
https://emacs.stackexchange.com/questions/59928/org-capture-at-point-as-sibling-of-heading

I was able to reproduce it starting from emacs -q with the following ECM:

   emacs -q -l min.el foo.org

where min.el  looks like this (adjust load-path to taste):
--8<---cut here---start->8---

(add-to-list 'load-path "~/src/org-mode/org-mode/lisp")

(require 'org-loaddefs)

(add-to-list 'auto-mode-alist '("\\.org\\'" . org-mode))

(global-set-key "\C-cl" 'org-store-link)
(global-set-key "\C-cc" 'org-capture)
(global-set-key "\C-ca" 'org-agenda)


(setq org-capture-templates
  '(("a" "Appointment or call" entry (file+headline "~/todo.org" "Tasks")
 "* APPT %?\n %u")))
--8<---cut here---end--->8---

and foo.org looks like this (| is the position of the cursor):


--8<---cut here---start->8---
* foo

** one

*** two

 three
|
 four
--8<---cut here---end--->8---

In current Org mode, doing `C-0 M-x org-capture RET a' (where "a"
gets me an APPT template - see below), I get:
--8<---cut here---start->8---
* foo
** one

*** two

 three
* APPT 
  [2020-08-04 Tue 12:58]
 four
--8<---cut here---end--->8---

with the template at top level.

In 9.2, the same operation inserted a template as a sibling of the headline:

--8<---cut here---start->8---
* foo
** one
   
*** two

 three
 APPT 
 [2020-08-04 Tue 12:58]
 four
--8<---cut here---end--->8---

The current behavior looks like a bug to me, so I bisected it to the following 
commit:

--8<---cut here---start->8---
0201d1c0cc367fea0e561ba113f02f263b0ed501 is the first bad commit
commit 0201d1c0cc367fea0e561ba113f02f263b0ed501
Author: Nicolas Goaziou 
Date:   Sat Jul 6 15:59:12 2019 +0200

Fix inserting capture templates at point

* lisp/org-capture.el (org-capture):
(org-capture-set-target-location):
(org-capture-place-entry):
(org-capture-place-item):
(org-capture-place-table-line): Fix inserting capture templates at
point.  Insert a new internal property for capture
template: :insert-here.
(org-capture-insert-template-here): Remove function.

* testing/lisp/test-org-capture.el (test-org-caputre/entry):
(test-org-capture/item):
(test-org-capture/table-line): Add tests.

Reported-by: Dominic Surano 


 etc/ORG-NEWS |   4 +-
 lisp/org-capture.el  | 126 +++
 testing/lisp/test-org-capture.el |  58 +-
 3 files changed, 104 insertions(+), 84 deletions(-)
--8<---cut here---end--->8---

HTH


---

Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32, 
cairo version 1.16.0)
 of 2020-06-15
Package: Org mode version 9.3.7 (release_9.3.7-705-gea9463 @ 
/home/nick/elisp/org-mode/lisp/)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: File local setting for export directory?

[Nick Dokos]

Russell Adams  writes:

> On Mon, Aug 03, 2020 at 04:15:22PM +0200, Loris Bennett wrote:
>> I want to export an org file to a pdf and have the pdf created in
>> subdirectory relative to the org file.
>>
>> What's the simplest way to set the export directory in a file local way?
>
> Can you just set your EXPORT_FILE_NAME  to include that directory?
>
> #+EXPORT_FILE_NAME: subdir/Thing.html
>
> You might need a FQPN. You'll have to test.
>

Unfortunately, this produces the tex file in the subdir, but the
xelatex/pdflatex process is still run in the current directory, with
`subdir/file.tex' as input file, so it produces the PDF in the current
directory.

I was wondering why Eric A. suggested a patch, but I guess this
is the reason (N.B. I haven't tried his patch).

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Search for an entry expands parent

[Nick Dokos]

Gt Uit  writes:

>  
>  
> 18.07.2020, 18:48, "Kyle Meyer" :
>
> Gt Uit writes:
>  
>
>  Updates since my last email:
>  - Sometimes the first C-s yields intended result (minimal), with
>  subsequent C-s searches expanding all entries.
>  - I tried on Emacs 28.0.50 and am getting the same results.
>  - I tried with emacs -Q and isearch minimal behaves properly!
>  - I tried a live distribution (Linux Mint 20 Ulyana, same
>  distribution I am currently using) and isearch minimal behaves
>  properly.
>  - I tried the following without any success:
>  + Remove all emacs related packages and reinstall emacs (via apt)
>  + Install emacs from snap.
>   
>  Now that I have narrowed down the bug to be something local to my
>  current installation please advise on how to debug/resolve.
>
> Something that might give you a clue about what's going on is stepping
> through org-show-set-visibility, comparing what happens when it works as
> expected and what happens when it doesn't. If you haven't used Edebug
> before, take a look at its node in the Elisp manual:
> (info "(elisp)Edebug")
>
> Thanks for pointing me to Edebug, a tremendously useful tool.
>  
> I got the following:
>  - Executed:
>    + M-x find-function org-show-set-visibility
>    + C-u C-M-x (edebug-defun)
>  - The first time I launch emacs, the function org-show-set-visibility is
>    called and I can step through the code via Edebug

Typing "d" at this point should give you a stack trace, so you can figure out
who called it.

> - Subsequent calls do not invoke org-show-set-visibility
>  
> I didn't mention earlier that I got this bug after upgrading from Linux
> Mint 19.3 to Linux Mint 20.
>  
> Can you please point me to what to further debug, in particular function
> that is called before org-show-set-visibility.
>  
> Gt Uit
>  
>  
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Wring case when using org-insert-structure-template

[Nick Dokos]

Nicolas Goaziou  writes:

>> Second question: I couldn't find any configuration variable or
>> function to change the default behaviour. Is there a way to do so?
>
> You can customize `org-structure-template-alist'. I don't remember if
> that's possible in Org 9.1.9, tho.
>
But you cannot change the case of the begin/end that way, so it would be entered
in mixed case:

#+begin_SRC ...
..
#+end_SRC

(I think - but I have not tested.)
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] agenda: Fold case when retrieving user-configured effort values

[Nick Dokos]

Kyle Meyer  writes:

> Nick Dokos writes:
>
>> BTW, I just thought of a possible problem: the manual says that property
>> keys are case-insensitive (although all the examples I can find spell
>> "_ALL" in upper case, but if I write
>>
>>   :PROPERTIES:
>>   :foo_all: bar baz
>>   :END:
>>
>> I don't think that the code is going to handle it correctly. There
>> are other places that also use "_ALL" without a let of case-fold-search
>> (at least AFAICT).
>>
>> Am I paranoid or is this a problem?
>
> case-fold-search is let-bound to t at the beginning of
> org-buffer-property-keys, so the added string-match is covered.
>

Wow - not only paranoid but blind as well.

> When collecting keys, there's no attempt to normalize to upper or lower,
> so the delete-dups call won't take care of any keys that are present in
> various case styles.  I don't think that's something worth worrying
> about (and perhaps it's even preferable, since we can't know which
> variant the caller would want to complete).
>
> As for other spots in the code base: looking through grep hits for
> "_ALL", it seems like most should be okay because they go through
> org-entry-get.  Two places in org-agenda are case-sensitive, though.
>
> -- >8 --
> Subject: [PATCH] agenda: Fold case when retrieving user-configured effort
>  values
>
> * lisp/org-agenda.el (org-agenda-filter-by-effort):
> (org-agenda-filter-completion-function): Ignore case when querying
> effort property key in org-global-properties since property keys are
> documented as case-insensitive.
> ---
>  lisp/org-agenda.el | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
> index 90129b23e..5c2933b0a 100644
> --- a/lisp/org-agenda.el
> +++ b/lisp/org-agenda.el
> @@ -7611,8 +7611,9 @@ (defun org-agenda-filter-by-effort (strip-or-accumulate)
>  consistency with the other filter commands."
>(interactive "P")
>(let* ((efforts (split-string
> -(or (cdr (assoc (concat org-effort-property "_ALL")
> -org-global-properties))
> +(or (cdr (assoc-string (concat org-effort-property "_ALL")
> +   org-global-properties
> +   t))
>  "0 0:10 0:30 1:00 2:00 3:00 4:00 5:00 6:00 7:00")))
>;; XXX: the following handles only up to 10 different
>;; effort values.
> @@ -,8 +7778,9 @@ (defun org-agenda-filter-completion-function (string 
> _predicate  flag)
> (org-agenda-get-represented-tags
>   ((member operator '("<" ">" "="))
>(setq table (split-string
> -(or (cdr (assoc (concat org-effort-property "_ALL")
> -org-global-properties))
> +(or (cdr (assoc-string (concat org-effort-property "_ALL")
> +   org-global-properties
> +   t))
>  "0 0:10 0:30 1:00 2:00 3:00 4:00 5:00 6:00 7:00")
>  " +")))
>   (t (setq table nil)))
>
> base-commit: eac255d911e0793513b2e2f14b06b94194a04daf

Thanks! LGTM.

-- 
Nick

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Kyle Meyer  writes:

> Nick Dokos writes:
>
>> Here's the amended patch: it includes the fixes from Kyle's review, the 
>> modification
>> he suggested that adds the plain property for each _ALL property to the list
>> and a few test cases to the test/org-buffer-property-keys test.
>
> Thank you for the updates.  Applied (bc4fa8a00).
>
>> -nil)))
>> +;; Get property names from #+PROPERTY keywords as well
>> +(mapcar (lambda (s)
>> +  (nth 0 (split-string s)))
>> +(cdar (org-collect-keywords '("PROPERTY"
>> +nil))
>
> I didn't spot it earlier, but this nil (not added by your patch) is
> unnecessary.  Since the patch is touching the line anyway, I've dropped
> it on apply.
>
>> +bare-props)
>>  (org-with-wide-buffer
>>   (goto-char (point-min))
>>   (while (re-search-forward org-property-start-re nil t)
>> @@ -13132,7 +13137,15 @@ COLUMN formats in the current buffer."
>>   (let ((p (match-string-no-properties 1 value)))
>> (unless (member-ignore-case p org-special-properties)
>>   (push p props))
>> -(sort (delete-dups props) (lambda (a b) (string< (upcase a) (upcase 
>> b))
>> +(sort (delete-dups (append props
>> +   ;; for each xxx_ALL property, make sure
>> +   ;; the bare xxx property is also
>> +   ;; included
>> +   (dolist (x props bare-props)
>> + (if (string-match "_ALL\\b" x)
>> + (setq bare-props (cons (substring x 0 -4)
>> +bare-props))
>
> I did a cosmetic rewrite here to use mapcar, which I hope you won't
> mind.
>

BTW, I just thought of a possible problem: the manual says that property
keys are case-insensitive (although all the examples I can find spell
"_ALL" in upper case, but if I write

  :PROPERTIES:
  :foo_all: bar baz
  :END:

I don't think that the code is going to handle it correctly. There
are other places that also use "_ALL" without a let of case-fold-search
(at least AFAICT).

Am I paranoid or is this a problem?

-- 
Nick

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Kyle Meyer  writes:

> Nick Dokos writes:
>
>> Here's the amended patch: it includes the fixes from Kyle's review, the 
>> modification
>> he suggested that adds the plain property for each _ALL property to the list
>> and a few test cases to the test/org-buffer-property-keys test.
>
> Thank you for the updates.  Applied (bc4fa8a00).
>
>> -nil)))
>> +;; Get property names from #+PROPERTY keywords as well
>> +(mapcar (lambda (s)
>> +  (nth 0 (split-string s)))
>> +(cdar (org-collect-keywords '("PROPERTY"
>> +nil))
>
> I didn't spot it earlier, but this nil (not added by your patch) is
> unnecessary.  Since the patch is touching the line anyway, I've dropped
> it on apply.
>
>> +bare-props)
>>  (org-with-wide-buffer
>>   (goto-char (point-min))
>>   (while (re-search-forward org-property-start-re nil t)
>> @@ -13132,7 +13137,15 @@ COLUMN formats in the current buffer."
>>   (let ((p (match-string-no-properties 1 value)))
>> (unless (member-ignore-case p org-special-properties)
>>   (push p props))
>> -(sort (delete-dups props) (lambda (a b) (string< (upcase a) (upcase 
>> b))
>> +(sort (delete-dups (append props
>> +   ;; for each xxx_ALL property, make sure
>> +   ;; the bare xxx property is also
>> +   ;; included
>> +   (dolist (x props bare-props)
>> + (if (string-match "_ALL\\b" x)
>> + (setq bare-props (cons (substring x 0 -4)
>> +bare-props))
>
> I did a cosmetic rewrite here to use mapcar, which I hope you won't
> mind.

Not at all - thanks!

>
> Thanks again.
>
>

-- 
Nick

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Here's the amended patch: it includes the fixes from Kyle's review, the 
modification
he suggested that adds the plain property for each _ALL property to the list
and a few test cases to the test/org-buffer-property-keys test.

--8<---cut here---start->8---
>From 60b9ababe42c91ec6fcd2c53f6923d75daa12454 Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Mon, 6 Jul 2020 21:49:41 -0400
Subject: [PATCH] org: add property names from #+PROPERTY keywords to
 completion list

* lisp/org.el (org-buffer-property-keys): Enhance the completion list
with property names from #+PROPERTY keywords, not just property
drawers. Also, for each xxx_ALL property, make sure that the bare xxx
property is added too.

* testing/lisp/test-org.el (test-org/buffer-property-keys): Add test
cases for #+PROPERTY keywords and also for xxx_ALL --> xxx properties.

See https://emacs.stackexchange.com/questions/59448/ for details.
---
 lisp/org.el  | 17 +++--
 testing/lisp/test-org.el | 21 +
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 4a1a83d0f..ccdb0dd5c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13084,7 +13084,12 @@ COLUMN formats in the current buffer."
(props (append
(and specials org-special-properties)
(and defaults (cons org-effort-property org-default-properties))
-   nil)))
+   ;; Get property names from #+PROPERTY keywords as well
+   (mapcar (lambda (s)
+ (nth 0 (split-string s)))
+   (cdar (org-collect-keywords '("PROPERTY"
+   nil))
+   bare-props)
 (org-with-wide-buffer
  (goto-char (point-min))
  (while (re-search-forward org-property-start-re nil t)
@@ -13132,7 +13137,15 @@ COLUMN formats in the current buffer."
 (let ((p (match-string-no-properties 1 value)))
   (unless (member-ignore-case p org-special-properties)
 (push p props))
-(sort (delete-dups props) (lambda (a b) (string< (upcase a) (upcase b))
+(sort (delete-dups (append props
+  ;; for each xxx_ALL property, make sure
+  ;; the bare xxx property is also
+  ;; included
+  (dolist (x props bare-props)
+(if (string-match "_ALL\\b" x)
+(setq bare-props (cons (substring x 0 -4)
+   bare-props))
+ (lambda (a b) (string< (upcase a) (upcase b))
 
 (defun org-property-values (key)
   "List all non-nil values of property KEY in current buffer."
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 30a8067db..61e642d4f 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5409,6 +5409,27 @@ Paragraph"
(equal '("A")
  (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:A+: 2\n:END:"
(org-buffer-property-keys
+  ;; Add bare property if xxx_ALL property is there
+  (should
+   (equal '("A" "B" "B_ALL")
+ (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:A+: 2\n:B_ALL: 
foo bar\n:END:"
+   (org-buffer-property-keys
+  ;; Add bare property if xxx_ALL property is there - check dupes
+  (should
+   (equal '("A" "B" "B_ALL")
+ (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:B: 2\n:B_ALL: 
foo bar\n:END:"
+   (org-buffer-property-keys
+  ;; Retrieve properties from #+PROPERTY keyword lines
+  (should
+   (equal '("A" "C")
+ (org-test-with-temp-text "#+PROPERTY: C foo\n* H\n:PROPERTIES:\n:A: 
1\n:A+: 2\n:END:"
+   (org-buffer-property-keys
+  ;; Retrieve properties from #+PROPERTY keyword lines - make sure an _ALL 
property also
+  ;; adds the bare property
+  (should
+   (equal '("A" "C" "C_ALL")
+ (org-test-with-temp-text "#+PROPERTY: C_ALL foo bar\n* 
H\n:PROPERTIES:\n:A: 1\n:A+: 2\n:END:"
+   (org-buffer-property-keys
   ;; With non-nil COLUMNS, extract property names from columns.
   (should
(equal '("A" "B")
-- 
2.25.1

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

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Kyle Meyer  writes:

> ,,,
> I think this patch is a clear improvement as is, but in the context of
> completion (and the stack exchange post you link to), isn't the handling
> around *_ALL keywords still a bit off?  It seems a caller would want to
> complete without the _ALL; to use the example from that post, with
> "#+PROPERTY: GENRE_ALL ...", the caller would want to complete "GENRE".
> Is it worth providing special handling here?
>

With a bit of caffeine in my system, I now see what you wrote and I
think you are right: if the _ALL property is present, then the bare
property should be added to the completion list if not already there.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Hi Kyle,

thanks for the review.

Kyle Meyer  writes:

> Nick Dokos writes:
>
>> Here's a patch to enhance the property name completion list with names from
>> #+PROPERTY keyword lines: at the moment, only property names found in 
>> property
>> drawers are used to populate the completion list.
>
> Thanks for the patch.
>
>> org: add property names from #+PROPERTY keywords to completion list
>>
>> * lisp/org.el (org-buffer-property-keys): ehhance the completion list
>
> Typo: enhance.  And as a convention nit, it should be capitalized.
>
Fixed.

>> with property names from #+PROPERTY keywords, not just property
>> drawers.
>>
>> ... 
>> +(mapcar (lambda (s)
>> +  (let ((split (split-string s)))
>> +(nth 0 split)))
>> +(cdar (org-collect-keywords '("PROPERTY"
>>  nil)))
>
> IMO the let-binding doesn't add any clarity over
>
>   (nth 0 (split-string s))
>
Fixed.
>
> I wondered about possible duplicates, but it looks like
> org-buffer-property-keys already takes care of that at the end.
>
> I think this patch is a clear improvement as is, but in the context of
> completion (and the stack exchange post you link to), isn't the handling
> around *_ALL keywords still a bit off?  It seems a caller would want to
> complete without the _ALL; to use the example from that post, with
> "#+PROPERTY: GENRE_ALL ...", the caller would want to complete "GENRE".
> Is it worth providing special handling here?
>
>
My assumption was that one could put in two properties (that's what
the OP was doing in his setup file): a GENRE_ALL one already properly
set-up and the corresponding bare GENRE property as a placeholder with
an empty value, just to get the completion. It seems to me like a
reasonable way to do it, without making org-buffer-property-keys too
opinionated.

I could see stripping all the _ALL suffixes from the property names
at the end, but personally it just makes me a bit queasy :) But if
there is consensus one way or the other, I'd be happy to implement it.

Here's the updated patch:

--8<---cut here---start->8---
>From 50c625f935d5581952d37801943550ff44c473ff Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Mon, 6 Jul 2020 21:49:41 -0400
Subject: [PATCH] org: add property names from #+PROPERTY keywords to
 completion list

* lisp/org.el (org-buffer-property-keys): Enhance the completion list
with property names from #+PROPERTY keywords, not just property
drawers.

See https://emacs.stackexchange.com/questions/59448/ for details.
---
 lisp/org.el | 4 
 1 file changed, 4 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 4a1a83d0f..8deaa1ed9 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13084,6 +13084,10 @@ COLUMN formats in the current buffer."
(props (append
(and specials org-special-properties)
(and defaults (cons org-effort-property org-default-properties))
+   ;; Get property names from #+PROPERTY keywords as well
+   (mapcar (lambda (s)
+ (nth 0 (split-string s)))
+   (cdar (org-collect-keywords '("PROPERTY"
nil)))
 (org-with-wide-buffer
  (goto-char (point-min))
-- 
2.25.1

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

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Adding a simple test to the previous patch:

--8<---cut here---start->8---
>From cae6b5596f69968003c053f53cb45ffb4139a5ad Mon Sep 17 00:00:00 2001
From: Nick Dokos 
Date: Mon, 6 Jul 2020 21:07:01 -0400
Subject: [PATCH] org: add property names from #+PROPERTY keywords to
 completion list

* lisp/org.el (org-buffer-property-keys): ehhance the completion list
with property names from #+PROPERTY keywords, not just property
drawers.

See https://emacs.stackexchange.com/questions/59448/ for details.
---
 lisp/org.el  | 5 +
 testing/lisp/test-org.el | 5 +
 2 files changed, 10 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 748c058ca..0e83162e8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13084,6 +13084,11 @@ COLUMN formats in the current buffer."
(props (append
(and specials org-special-properties)
(and defaults (cons org-effort-property org-default-properties))
+   ;; Get property names from #+PROPERTY keywords as well
+   (mapcar (lambda (s)
+ (let ((split (split-string s)))
+   (nth 0 split)))
+   (cdar (org-collect-keywords '("PROPERTY"
nil)))
 (org-with-wide-buffer
  (goto-char (point-min))
diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el
index 3c563f344..ddda96105 100644
--- a/testing/lisp/test-org.el
+++ b/testing/lisp/test-org.el
@@ -5352,6 +5352,11 @@ Paragraph"
(equal '("A")
  (org-test-with-temp-text "* H\n:PROPERTIES:\n:A: 1\n:A+: 2\n:END:"
(org-buffer-property-keys
+  ;; Retrieve properties from #+PROPERTY keyword lines
+  (should
+   (equal '("A" "C")
+ (org-test-with-temp-text "#+PROPERTY: C foo\n* H\n:PROPERTIES:\n:A: 
1\n:A+: 2\n:END:"
+(org-buffer-property-keys
   ;; With non-nil COLUMNS, extract property names from columns.
   (should
(equal '("A" "B")
-- 
2.25.4
--8<---cut here---end--->8---


-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

[PATCH] org: add property names from #+PROPERTY keywords to completion list

[Nick Dokos]

Here's a patch to enhance the property name completion list with names from
#+PROPERTY keyword lines: at the moment, only property names found in property
drawers are used to populate the completion list.

Keith Pinson posted the question on Emacs SE:

https://emacs.stackexchange.com/questions/59448/

Please let me know if the patch looks reasonable. If it does, I should
probably add a test.

Thanks!

--8<---cut here---start->8---
org: add property names from #+PROPERTY keywords to completion list

* lisp/org.el (org-buffer-property-keys): ehhance the completion list
with property names from #+PROPERTY keywords, not just property
drawers.

See https://emacs.stackexchange.com/questions/59448/ for details.
---
 lisp/org.el | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lisp/org.el b/lisp/org.el
index 748c058ca..0e83162e8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13084,6 +13084,11 @@ COLUMN formats in the current buffer."
(props (append
(and specials org-special-properties)
(and defaults (cons org-effort-property org-default-properties))
+   ;; Get property names from #+PROPERTY keywords as well
+   (mapcar (lambda (s)
+ (let ((split (split-string s)))
+   (nth 0 split)))
+   (cdar (org-collect-keywords '("PROPERTY"
nil)))
 (org-with-wide-buffer
  (goto-char (point-min))
-- 
2.25.1
--8<---cut here---end--->8---

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Bug: Clock table documentation [9.3.7 (release_9.3.7-644-ge3a724 @ /home/nick/elisp/org-mode/lisp/)]

[Nick Dokos]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


There is a sentence in the section "The clock table" of doc/org-manual.org
that seems to have been clipped. It's part of the paragraph that begins
on line 6600 of that file:

,
| The =#+BEGIN= line and specify a number of options to define the
| scope, structure, and formatting of the report.  Defaults for all
| these options can be configured in the variable
| ~org-clocktable-defaults~.
`

There's obviously something garbled there, but I'm not sure how it should go.


Emacs  : GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32, 
cairo version 1.16.0)
 of 2020-06-15
Package: Org mode version 9.3.7 (release_9.3.7-644-ge3a724 @ 
/home/nick/elisp/org-mode/lisp/)
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: multiple EXPORT_LATEX_HEADER lines

[Nick Dokos]

Dominik Schrempf  writes:

> Hello,
>
> are you looking for, e.g.,
>
> #+latex_header: \addbibresource{bibliography.bib}
> #+latex_header_extra: do some stuff
> #+latex_header_extra: and even more
>
> I don't use the EXPORT keyword at the beginning, I am not sure if it is 
> needed.
>
> Best,
> Dominik

Just as a clarification: the "_extra" here does not mean "append to previous 
value".

The only difference between "#+latex_header: " and #+latex_header_extra: " is
that anything specified in the former is *also* used when constructing the 
header
for the LaTeX file for previewing LaTeX fragments, whereas anything specified 
in the
latter is only used when exporting: it is not used when previewing.

See

(info "(org) LaTeX header and sectioning")

which says:

,
|The LaTeX export back-end appends values from ‘LATEX_HEADER’ and
| ‘LATEX_HEADER_EXTRA’ keywords to the LaTeX header.  The docstring for
| ‘org-latex-classes’ explains in more detail.  Also note that LaTeX
| export back-end does not append ‘LATEX_HEADER_EXTRA’ to the header when
| previewing LaTeX snippets (see *note Previewing LaTeX fragments::).
`

and the code in ox-latex.el:org-latex-make-preamble.

>
> Alan Schmitt  writes:
>
>> Hello,
>>
>> I would like to have a multi-line export header when exporting a
>> subtree. I tried this:
>>
>> :EXPORT_LATEX_HEADER: \makeatletter
>> :EXPORT_LATEX_HEADER+: \@setplength{refvpos}{\useplength{toaddrvpos}}
>> :EXPORT_LATEX_HEADER+: \makeatother
>>
>> The problem is that it's exported on a single line, and as such it does
>> not work. Is there a way to have the multiple properties exported as
>> multiple lines, or to specify in the property there is a line break?
>>
>> Thanks,
>>
>> Alan
>
>
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-babel :colnames yes

[Nick Dokos]

Would this work for you?

--8<---cut here---start->8---
#+BEGIN_SRC elisp :colnames yes
 '((one two) hline (1 3) (1 6))
#+END_SRC

#+RESULTS:
| one | two |
|-+-|
|   1 |   3 |
|   1 |   6 |

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

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: issue in orgmode manual

[Nick Dokos]

Bastien  writes:

> Hi Nick and John,
>
> this issue should be fixed now, thanks for reporting it.

It is fixed AFAICT - thanks!

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: issue tracker?

[Nick Dokos]

Anthony Carrico  writes:

> Does org-mode have an issue tracker, to keep track of which issues are 
> active, or is it just this mailing list?

Just this mailing list.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: Asterisk inside example is incorrectly parsed [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]

[Nick Dokos]

You need to quote the asterisk with a comma:

#+begin_example
,* I am not supposed to be a section
#+end_example

See

 (info "(Org) Literal Examples")


-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: issue in orgmode manual

[Nick Dokos]

John Hendy  writes:

> I ran into this as well and did not see a response back from the list
> yet. Emailed about just this issue last week.
>
> https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127933.html
>
> John
>
>
> On Sat, May 16, 2020 at 10:21 AM Max Mustermann
>  wrote:
>>
>> Hey,
>> On https://orgmode.org/manual/LaTeX-Export.html#Tables-in-LaTeX-export,
>> 13.10.5 -13.10.11 refer back to its parent 13.10
>> same with 13.9.6-13.9.11 and probably others.
>>
>> Sorry if this is already known or intended.
>>
>> Have a nice weekend.
>
>

Yes, it has been reported a couple more times, but nothing has been
done about it. My hunch is that Bastien takes care of orgmode.org,
but with the current Covid-19 crisis, he is extremely busy and he
may not be reading the list at all.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug - all org files open as if visibilty is set to "showeverything"

[Nick Dokos]

Charles Millar  writes:

> Hi,
>
> In the last two or three days, all my org files open as if I have set 
> the visibility in every file to
>
> #+STARTUP: showeverything
>
> Org mode version 9.3.6 (release_9.3.6-619-g434940 @ 
> /usr/local/share/org-mode/lisp/)
> GNU Emacs 28.0.50 (build 123, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, 
> cairo version 1.16.0) of 2020-05-13
>
> As far as I recall, I have not changed any settings in my init or elsewhere.
>
> Charlie Millar
>
>

That is correct. It's been discussed in the list and Nicolas announced that it's
been merged into master on Tuesday. Look for the thread entitled

   [RFC] Change default value for `org-startup-folded'?

It can also be found at 


C-h v org-startup-folded RET

You can get the previous default by setting it to t in your init file.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Section about latex export is broken in the html manual?

[Nick Dokos]

Niclas Borlin  writes:

> Hi,
>
> As far as I can tell, several links of section 10.13 LaTeX Export
> (https://orgmode.org/manual/LaTeX-Export.html) are broken (last
> checked 2020-04-28 19:15 UTC).
>
> The first four links on the page point to useful pages, i.e., clicking
> on "Quoting LaTeX code:" will get you to 
> https://orgmode.org/manual/Quoting-LaTeX-code.html#Quoting-LaTeX-code,
> that contains section 13.10.4 Quoting LaTeX code.
>
> However, from the link "Tables in LaTeX export" downwards, you are
> linked back to the same page. For instance, clicking on "Tables in
> LaTeX export" will get you to 
> https://orgmode.org/manual/LaTeX-Export.html#Tables-in-LaTeX-export. (I
> suspect the content of the page should be an updated version of 
> https://www.gnu.org/software/emacs/manual/html_node/org/Tables-in-LaTeX-export.html.)
>
> I suspect this is a link naming issue in the .org version of the
> manual. Can anyone fix this?
>
I can confirm your findings, but I don't see anything wrong in the
.org version of the manual: I exported it to .html locally and that
works fine. But I'm not sure what happens on the way from one's local
system to the site.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-rss feed title is concatenation of all post titles? (ECM included)

[Nick Dokos]

Stig Brautaset  writes:

> ...
> PS: Can we pretend this whole thread didn't happen? :-)
>

What thread?

-- 
Nick:-)

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Org-babel-lilypond always renders full pages

[Nick Dokos]

stardiviner  writes:

>
> Can report this bug to ob-lilypond.el maintainer. I have not found any contact
> info like email in source code file. Does anyone can get in touch with the
> maintainer?
>

Isn't ob-lilypond.el part of Org mode proper (i.e. not contrib)? If
so, this is the place to report bugs for it. The maintainer is the
usual suspects :-) (but I'm sure they would appreciate any help anybody
can offer).

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Org mode for meeting minutes

[Nick Dokos]

Pankaj Jangid  writes:


> I have an off-topic query though: How do you right align tags?
>
>
>

,
| org-tags-column is a variable defined in ‘org.el’.
| Its value is -120
| Original value was -77
| 
|   You can customize this variable.
| 
| Documentation:
| The column to which tags should be indented in a headline.
| If this number is positive, it specifies the column.  If it is negative,
| it means that the tags should be flushright to that column.  For example,
| -80 works well for a normal 80 character screen.
| When 0, place tags directly after headline text, with only one space in
| between.
`

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: bi-monthly steps.

[Nick Dokos]

"Bi-monthly" is ambiguous: it can mean twice a month or it can mean
once every two months and there is no convincing anybody that their
use of it is wrong :-)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: results block doesn't get replaced when doing :results raw

[Nick Dokos]

George Mauer  writes:

> I've seen this happening a lot in a variety of modes. When I do `:results 
> raw`, on subsequent 
> evaluations, rather than replacing the results block, it gets appended to.
>
> This is almost never what I want. I remember seeing some use of `:results raw 
> replace` in some manual
> or another but that never really seems to work for me.
>
> Is there a property or something that can be set to always replace?
>

That's expected: with `:results raw', org-babel does not know where
the results end, since there is no marker, so it cannot clear them
before producing the new results  - it just puts them right after the
`#+RESULTS:' line.

Why are you using `raw'? Can you use some other format (e.g. `drawer'
or `example') instead?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Typo in Org Manual

[Nick Dokos]

Sebastian Miele  writes:

> Sebastian Miele  writes:
>>
>> But how about instead changing the first sentence of the "Range
>> references" section from
>>
>>   You may reference a rectangular range of fields by specifying two
>>   field references connected by two dots ‘..’.
>>
>> to
>>
>>   You may reference a rectangular range of fields, including the ends,
>>   by specifying two field references connected by two dots ‘..’.
>>
>> ?
>
> I think even better would be to just add the following after the
> sentence mentioned above:
>
>   The ends are included in the range.
>
>

Yes, a general statement (outside of this particular example) seems
like a good idea. Then changing the "six" to "nine" does not need any
further elaboration.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug or not a bug? dot expansion in ob-shell

[Nick Dokos]

Hi Tim,

Tim Cross  writes:

> It seems to me that two separate issues have been mixed up and causing
> some confusion here. However, I think it is actually quite simple once
> we consider the issues separately.
>
> Issue 1: Defining the meaning of :result value and :result output
> Issue 2: Specifying what the default :result setting would be i.e.
> :result without a value/output specifier.
>
> Issue 1 seems the most straight-forward to me
> - output :: Whatever goes to stdout/stderr
> - value :: whatever would be returned by the execution of the code. This
> might be a return value (i.e. for some shell commands) or the value
> returned by a function (including shell functions i.e. bash function) or
> the last command executed etc. Essentially, anything returned (including
> nil) by the block. STDOUT/STDERR is never a return value (though some
> languages may send output to STDOUT/STDERR as well as returning it, in
> which case it would also be in :return value).
>
> Note that I don't agree that the only 'useful' result from shell blocks
> is output. You might have a complex shell script which uses source
> blocks to define shell functions
> that return values which you use via oweb expansion to include in other
> blocks etc.s
>
> With this definition, essentially :result value is essentially anything
> except whatever is sent to stdout/stderr.
>
> Issue 2 is a little more difficult. It is likely that a 'standard'
> default for :result that is the same for all languages is not
> possible/desired. The default will likely be a combination of what seems
> most natural for that language and what is most common usage for the
> majority of users. It could be that for some languages, the default for
> :result should be :result output and for others it should be :result
> value.
>
> Personally, I care less about issue 2 than issue 1. In the worst case, I
> will need to change my header arguments for some blocks and that would
> be easily automated. Far more critical is that :result value and :result
> output are clear, unambiguous and consistent. Any proposal to change
> these meanings because of different uses cases in languages is a bad
> idea. Instead, changing the 'default' would be preferable. Having shell
> source blocks return STDOUT/STDERR output for :result value is IMO a bad
> idea. Having shell blocks default to :result output when only specifying
> :result while having other languages, like python or clojure default to
> :result value seems far more preferable (provided differences are
> clearly documented of course).
> ...

Thanks for the (very clear) write-up. I can only nod my head
in violent agreement :-)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bibliography entry in the menu-bar

[Nick Dokos]

Sharon Kimble  writes:

> Simon Butler  writes:
>
>> Hi Sharon
>>
>> the menu is part of BibTeX-mode (https://www.emacswiki.org/emacs/BibTeX)
>
> Thanks Simon, I've now been able to provide a key-sequence for 'Online
> Resource' like so -
>
> (global-set-key "\C-c C-e C-o" 'bibtex-Online)
>
>
> however, it is shown in the drop-down-menu of bibtex commands as
>
> Online Resource   C-c SPC C-e SPC C-o
>
> How can I lose the 'SPC' in the drop-down list of commands please, so it
> looks very similar to all the others?
>

IIUC, you want to say

   (global-set-key (kbd "C-c C-e C-o") 'bibtex-Online)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug or not a bug? dot expansion in ob-shell

[Nick Dokos]

Hi Bastien,

I think all this is reasonable. I have some inline comments and
a suggestion at the end.

Bastien  writes:

> Hi Nick,
>
> I didn't conduct the survey in 2013, you can find the results here:
> https://orgmode.org/worg/org-configs/org-customization-survey.html
>
> I understand why you (and Tim and Derek) think an option is too much.
>
> But let's separate two problems: one is that Org have many options,
> some perhaps unneeded (or only here because of bad design decisions we
> made in the past), causing a technical debt, another one being "How to
> handle shell's notion of "return value" in ob-shell.el?
>
> The first problem is real: patches are always welcome in this area but
> this is the kind of problem that requires a big picture and a strong
> push, incremental fixes are difficult here.
>

But if we can avoid making the problem worse, we should do that. Messes
like this are created, not born.

> The second problem is real too, and while being cautious about not
> making the first problem worse, the solution should be independant.
>
> That said, we have three solutions:
>
> 1. Stick to a strict reading of Org and bash manuals: the absence of a
>:results header means "return the value, i.e. the exit status".
>
> 2. Deviate from this strict reading, introduce an exception for *all*
>shell blocks: no :results header means "return output" and you need
>to use :results value to get the exit status (your proposal).
>
> 3. Deviate from this strict reading and introduce an option that says:
>"Don't deviate from the Org's and bash manuals for all src blocks".
>
> Obviously, nobody wants the first solution.

I'm not convinced of that: personally, I would be happy with the first
solution and maybe others would be too. I would add a :results output
header explicitly where needed and be on my way. Of course, it would
break workflows where the output is expected and that might be a
problem for some. I agree that the option takes care of this problem.

>
> Part of me agrees with your second solution: after all, we had to wait
> until Vladimir's "echo ." trick to find out there was a problem.
>
> Part of me think that (1) deviation from the normal behavior should be
> carefully advertized and (2) by design, the normal behavior should not
> require tweaking options manually for each block.  An option fulfills
> both these needs: allowing to get the normal behavior by default and
> advertizing the "deviation".

I somewhat object to the use of the word "normal" in this paragraph: I
think you mean "current" in the first and last instances.  I disagree
with (2): see my suggestion below. And IMO, the option makes it so
that most users don't have to change anything. That is a good think in
general (it is the reason that the option exists), but it hides the
deviation rather than advertising it, because unless somebody follows
this discussion, they don't know that there *is* a deviation.

>
> Right now I'm not convinced we should get rid of this option.
>
> But I'm convinced we should take the decision we no consideration of
> the first (biggest) problem of Org having *perhaps* too many options.
>
> Case still open.

My longer term suggestion (which, I realize, does not help to close
*this* case any time soon):

I think that the global default setting `:results value' is wrong: it
works fine for "functional" code blocks (ones where a function is
defined and then called with some parameters to make sure it produces
the correct value - the function can be written in any language: I
don't mean to restrict it to functional languages); it does not work
well for the "scripting" cases (ones where the code block is a
sequence of calls, each of which might or might not produce output -
but it's the whole output that matters, not the individual calls).

In the longer run, I think the possibility of *forcing* users to choose
which one they want, should be entertained.

Thanks and regards!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug or not a bug? dot expansion in ob-shell

[Nick Dokos]

Hi Bastien,

Bastien  writes:

> Hi Diego,
>
> Diego Zamboni  writes:
>
>> I'm late to the discussion so I apologize in advance, but this fix
>> seems counterintuitive to me. In my mind, for any shell code:
>>
>> - Return value: exit code of the last command
>> - Output: whatever the commands print
>
> Yes, that's what is *now* possible if you set
> ob-shell-return-value-is-exit-status to t.
>
> Unless I miss something, it was not possible before today.
>
> #+begin_src shell
> echo Hello!
> #+end_src
>
> would simply return "Hello!" as a return.
>
> No exit code was *never* output.
>
>> So to me, it's intuitive that =:exports value= would return the exit
>> code of the last command, and =:exports output= would produce the
>> output of the commands. I don't understand why a new option is
>> needed.
>
> ... because it was not the case before.  Or maybe *I* miss something.
>
> Can you show me something that was working before and that is not
> anymore?
>
> Thanks,

I welcome the fix but not the option: the option situation in Org mode
was pretty horrible, then ca 2010, you did a survey and some options
were eliminated (not sure about the year or whether it *was* you who
did the survey, but I'm pretty sure there was one): that was the right
direction to go, but it wasn't enough. Org mode needs to be put into
an option diet, so adding another one here (and a rather gratuitous
one in my view) is not the way to go.

`:results value' should *always* produce the value of the last expression,
which for shell programs is the exit status of the last command.

`:results output' should *always* produce all of the output of the program.

An argument can be made that `:results value' is the default, but it
is the less useful option for shell programs. So maybe for shell
blocks, make the default to be `:results output' instead: people get
what they always got before the fix without lifting a finger, the exit status
is now available with `:results value', and the option can go away
quietly and quickly, before it becomes another contributor to the Org
mode technical debt.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: LaTeX export failure

[Nick Dokos]

"Thomas S. Dye"  writes:

> Thanks Eric,
>
> Good to know.  I'll try to track down the issue when I find time.
>
> All the best,
> Tom
>
> Fraga, Eric writes:
>
>> On Wednesday, 29 Jan 2020 at 15:22, Thomas S. Dye wrote:
>>> Here is the offending bit, which worked fine last November but
>>> fails today:
>>>
>>>  #+caption: Compare figure\nbsp{}[[fig:mqs3_op]].
>>
>> This works fine for me.  Sorry; that probably doesn't help you
>> much... :-(
>
>
> --
> Thomas S. Dye
> https://tsdye.online/tsdye
>
>

If you have not tried it already, M-x toggle-debug-on-error and
retrying the export should give a backtrace, which should help guide
further investigation. It should work even if you do the export in
batch mode (the backtrace should appear on stderr, I think), but if
you can do it interactively and with uncompiled code (C-u M-x
org-reload IIRC), that would be best.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: debugging why a latex preview fails

[Nick Dokos]

Alan Schmitt  writes:

> Hello Fabrice and Eric,
>
> Thanks a lot for your suggestions. I ended up edebugging
> 'org-create-formula-image' to have a look at the created tex file (that
> is indeed cleaned up after the generation). The file was fine, but
> dvipng failed on it (with errors like "raw PostScriptdvipng warning:
> PostScript environment contains DVI commands dvipng warning: No image
> output from inclusion of raw PostScript"). I switched to imagemagick to
> do the conversion and everything now works.
>
> The warnings were in the *Org Preview Latex Output* buffer, which
> I realized afterwards. However it's still tricky to debug because
> intermediate files are erased, so I could not initially run the command
> by hand to try to tweak it.
>

I've resorted occasionally to hacking the code and getting rid of the
cleanup just so I would have the intermediate .tex file to look at, but
it's probably not the best way to go :-). It would be nice to have the
ability to inhibit the cleanup more easily: it would make preview almost
as easy to debug as export.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: code.orgmode.org

[Nick Dokos]

Robert Klein  writes:

> Hi,
>
> Gogs config does the trace automatically due to a configuration
> inheritance issue (cf. https://github.com/gogs/gogs/issues/5007).
>
> I added the following lines to the custom/conf/app.ini file and
> restarted gogs:
>
>
> [log.file]
> LEVEL = Info
>
>
> Btw. the trace was afaik on all the time.  Dunno why it started to show
> up in the web interface only now.
>

I was seeing all sorts of problems last night, but it seems to work
now.

The problems sometimes manifested themselves with TRACE output that complained
about "pipe2: too many file descriptors open" (this is from memory, so take it
with the appropriate grain of salt) and sometimes by getting a 500 page.

Thanks for fixing it!

>
> On Wed, 22 Jan 2020 18:37:38 -0500
> Nick Dokos  wrote:
>
>> Somebody seems to be playing with stuff on code.orgmode.org: every
>> once in a while when I look at the repo (e.g by visiting
>> https://code.orgmode.org/bzg/org-mode), I get a literal HTML page,
>> instead of a rendered one. That seems to be caused by some extra text
>> at the beginning:
>> 
>> ,
>> | 2020/01/22 23:14:06 [TRACE] Session ID: 6961d7733328363f
>> | 2020/01/22 23:14:06 [TRACE] CSRF Token:
>> CMr9jiGTHiieFuGUEVds1J-EeOg6MTU3OTcyODI2MzgzMDMwMzA3OA== | HTTP/1.0
>> 200 OK | Content-Type: text/html; charset=UTF-8
>> | Date: Wed, 22 Jan 2020 23:14:07 GMT
>> | 
>> | 
>> | 
>> | ...
>> | 
>> `
>> 
>> The TRACE lines seem to indicate that somebody is trying to debug
>> something, but it's killing the website. Has anybody seen that? Does
>> anybody know what is going on?
>> 
>> Thanks!
>
>
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: noweb

[Nick Dokos]

"Fraga, Eric"  writes:

> My approach to this is to create three blocks that are tangled and a
> separate block (or more than one if you have different tests you want to
> perform) for evaluation that references those three blocks (via noweb)
> but is not tangled.

That works, but shouldn't Nuno's approach with :noweb eval work? What use
is it to include unexpanded noweb markers in the tangled output?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

code.orgmode.org

[Nick Dokos]

Somebody seems to be playing with stuff on code.orgmode.org: every
once in a while when I look at the repo (e.g by visiting
https://code.orgmode.org/bzg/org-mode), I get a literal HTML page,
instead of a rendered one. That seems to be caused by some extra text
at the beginning:

,
| 2020/01/22 23:14:06 [TRACE] Session ID: 6961d7733328363f
| 2020/01/22 23:14:06 [TRACE] CSRF Token: 
CMr9jiGTHiieFuGUEVds1J-EeOg6MTU3OTcyODI2MzgzMDMwMzA3OA==
| HTTP/1.0 200 OK
| Content-Type: text/html; charset=UTF-8
| Date: Wed, 22 Jan 2020 23:14:07 GMT
| 
| 
| 
| ...
| 
`

The TRACE lines seem to indicate that somebody is trying to debug something,
but it's killing the website. Has anybody seen that? Does anybody know what
is going on?

Thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Recommended global keybindings in the guide vs the manual

[Nick Dokos]

org-guide.org:Introduction/Activation says:

--8<---cut here---start->8---
Add the following lines to your Emacs init file.  The last four lines
define /global/ keys for some commands---please choose suitable keys
yourself.

#+begin_src emacs-lisp
;; The following lines are always needed.  Choose your own keys.
(global-set-key (kbd "C-l") 'org-store-link)
(global-set-key (kbd "C-a") 'org-agenda)
(global-set-key (kbd "C-c") 'org-capture)
(global-set-key (kbd "C-b") 'org-switchb)
#+end_src
--8<---cut here---end--->8---

I realize that it says to "choose suitable keys yourself", but
surely, these should be identical to what the full manual recommends?

--8<---cut here---start->8---
#+begin_src emacs-lisp
(global-set-key (kbd "C-c l") 'org-store-link)
(global-set-key (kbd "C-c a") 'org-agenda)
(global-set-key (kbd "C-c c") 'org-capture)
#+end_src
--8<---cut here---end--->8---

Right?
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-deadline-warning-days per file

[Nick Dokos]

Colin Baxter  writes:

> I have my org-deadline-warning-days set to 60 via
>
> #+begin_src elisp
> (setq org-deadline-warning-days 60)
> #+end_src
>
> in my ~/.emacs. How can I set it individually for each deadline in an
> org-mode file?
>

The manual says:

,
|  You can specify a different lead time for warnings for a specific
|  deadlines[sic] using the following syntax.  Here is an example with a
|  warning period of 5 days ‘DEADLINE: <2004-02-29 Sun -5d>’.  This
|  warning is deactivated if the task gets scheduled and you set
|  ‘org-agenda-skip-deadline-prewarning-if-scheduled’ to ‘t’.
`

HTH.
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Bug: xxx [9.3 (9.3-8-geab7c4-elpa @ c:/Users/Scott/.emacs.d/elpa/org-20191209/)]

[Nick Dokos]

Scott Otterson  writes:

> A function I wrote a few months ago is now failing because it's
> unable to find the org function "org-at-target-p".  I think this was
> originally in org.el but I can't find it there now.
>
> If this function was removed intentionally could someone suggest a
> new function that can do the same thing?  org-at-target-p used to
> return true if the cursor is on a dedicated target.
>

This happened with commit

,
| commit a486d9cbd7491741554944a116f81b02f6b35e4b (HEAD, refs/bisect/bad)
| Author: Nicolas Goaziou 
| Date:   Tue Nov 27 00:04:41 2018 +0100
| 
| Move link-related core functions out of "org.el"
`

The fact that the function disappears with no mention in the commit
message (where about 60 other functions are mentioned) leads me to
believe that it was unintentional, but of course, Nicolas will have
to confirm one way or the other.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Displaying remote images

[Nick Dokos]

Jack Kamm  writes:

> I've attached a patch which implements displaying remote images.
>
>> This is a longstanding problem, and there was an attempt to patch it in
>> 2014, but the patch was never accepted:
>> https://lists.gnu.org/archive/html/emacs-orgmode/2014-11/msg00583.html
>
> Compared to the previous attempt from 2014, I think my patch is simpler
> -- it doesn't require creating any temp files.
>
>> The fault might be with image.el rather than with org-mode itself --
>> for example, when I execute the following elisp, I get the same blank
>> box:
>
> After doing some reading, I learned that image.el doesn't really create
> the image. Instead, create-image simply creates a blank string with a
> text property pointing to the image file location, and the rendering of
> the image gets handled later by the C code (for example, png_load_body()
> in image.c), which doesn't know how to read remote image files.
>
> Since I wasn't comfortable trying to get the C code to read the remote
> file, I instead took the approach used by image-mode.el, which reads the
> remote image file and passes its contents directly to create-image,
> instead of just passing the filename.
>
> From 47120666dad6eb0b6ca716325d7de86924e1d28e Mon Sep 17 00:00:00 2001
> From: Jack Kamm 
> Date: Thu, 28 Nov 2019 17:45:56 -0800
> Subject: [PATCH] org: display remote images
>
> ---
>  lisp/org.el | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/lisp/org.el b/lisp/org.el
> index 90f222c8b..dc7bcc7aa 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -16754,13 +16754,20 @@ buffer boundaries with possible narrowing."
>   (t nil)))
> (old (get-char-property-and-overlay
>   (org-element-property :begin link)
> - 'org-image-overlay)))
> + 'org-image-overlay))
> +   (remote-p (file-remote-p file)))
> (if (and (car-safe old) refresh)
> (image-refresh (overlay-get (cdr old) 'display))
> - (let ((image (create-image file
> + (let ((image (create-image (if (not remote-p)
> +file
> +  (with-temp-buffer
> +(insert-file-contents 
> file)
> +(string-make-unibyte
> + 
> (buffer-substring-no-properties
> +  (point-min) 
> (point-max)
>  (and (image-type-available-p 
> 'imagemagick)
>   width 'imagemagick)
> -nil
> +remote-p
>  :width width)))
> (when image
>   (let ((ov (make-overlay

FWIW, looks good to me, but I've only (carefully) read the patch: I have not 
actually ran it.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: is this a known issue in clocktable output?

[Nick Dokos]

Marco Wahl  writes:

> Soubzriquet  writes:
>>> [...]
>
>>> > odd issue with using "day" steps where the date is getting offset
>>> > sometimes.
>>> >
>>> > I saw the issue with 26.1, was not fixed by updating  to current
>>> > environment with an empty init.el on OS X:
>>> > ...
>>> > Daily report: [2019-11-03 Sun]
>>> > | Headline | Time   |
>>> > |--+|
>>> > | *Total time* | *3:00* |
>>> > |--+|
>>> > | Day 3| 3:00   |
>>> >
>>> > Daily report: [2019-11-03 Sun]
>>> > | Headline | Time   |
>>> > |--+|
>>> > | *Total time* | *4:00* |
>>> > |--+|
>>> > | Day 4| 4:00   |
>>> >

>>> I can not reproduce this behavior.
>
>> Hi, sorry I was not more clear - the issue occurs also with emacs -Q  or
>> with empty init.el on my system.
>
> Okay, thanks.  I think I'm at the end of my abilities to investigate the
> issue further.
>
> I suggest you dig a little deeper for better understanding.  E.g.:
>
> - Try make the example of failure as small as you can.
>
> - Check with a newer version of Org.
>
> - Debug the issue.
>
>
> Possibly someone else can confirm the issue.
>  
>

I can reproduce the issue with 9.1.9, but it goes away with 9.2 or later.
Marco's suggestion to use a newer version is the right thing to do.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org 9.2.6 and org 9.1.9

[Nick Dokos]

Jean-Christophe Helary  writes:

> org 9.1.9 is a built-in
>
> but org 9.2.6 comes as a dependency to some packages and having both 
> installed creates conflicts.
>

What conflicts are you seeing? I have the built-in 9.1.9 org that
comes with emacs but I run (close to) latest master and I see no
problems: the only thing I do is to set my load-path to point to the
right place (and make sure that that setting precedes the
/usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):

(add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))

Although that has been enough for me, it's probably safer to delete
from load-path all other org entries, thereby making the built-in
version invisible to emacs - in my case, I just have the one:

   (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)

That way, if you happen to do something like `(require 'old-org-req)'
with a requirement that is not satisfied by current org, but is
satisfied by the built-in org, you'd get an error, rather than getting
a mixed installation.

> Why does that happen ?
>
> Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> with that situation and that's extremely confusing. What is the best
> way to solve that ?
>

I think the above should be enough (and IME it is), but maybe someone can
think of other things that might trip one up.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org-enable-table-editor is removed since 9.1

[Nick Dokos]

Tomasz Piotrowski  writes:

> If I try to edit a table in org-mode, e.g., add a row to it, I get a
> message
>
> "eval: Symbol’s value as variable is void: org-enable-table-editor".
>
> This is in line with changes made in version 9.1:
> https://orgmode.org/Changes_old.html#org8981857
>
> This makes the manual for editing tables:
> https://orgmode.org/manual/Built_002din-table-editor.html
>
> unusable for me. Indeed, I get the same message:
>
> "eval: Symbol’s value as variable is void: org-enable-table-editor"
>
> when I tried to submit the bug using:
>
> M-x org-submit-bug-report 
>
> I am on version 9.2.6, but I think all versions since 9.1 are affected.
>

Turn on debug-on-error and try again - a stack trace should be produced which 
should help
to identify the place where the symbol is used:

   M-x toggle-debug-on-error RET
   M-x org-submit-bug-report RET

You either have a mixed installation (i.e. you are using a mixture of 9.2.6
and a 9.1-or-earlier version), or you are using this symbol in one of
your initialization files and/or in your customizations.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Org 9.2 not inhibiting electric-pair-mode in the beginning of lines?

[Nick Dokos]

"Fraga, Eric"  writes:

> On Tuesday, 29 Oct 2019 at 16:50, Vladimir Nikishkin wrote:
>> I think, these are two different mechanisms. C-c C-, works as expected.
>> The "<" mechanism comes from org-tempo, and is faster, because you
>> don't have to choose anything.
>
> I don't know anything about org-tempo but, just to be clear, the old <
> at beginning of line mechanism that was available, by default, in org
> 8.x is no longer available.  It was replaced by C-c C-,.

Not quite: there is still an emulation of the old mechanism if you

(require 'org-tempo)

which Vladimir probably does. That modifies the following hook:

,
| org-tab-before-tab-emulation-hook is a variable defined in ‘org.el’.
| Its value is (org-tempo-complete-tag)
`

The hook is run close to the end of org-cycle (which is bound to TAB). So
when you type

Re: [O] Bug Report: Broken Link in Worg

[Nick Dokos]

Joshua Meyers  writes:

> In this page (https://orgmode.org/worg/org-gtd-etc.html) the link to
> the "very instructive post by Pete Phillips" now directs to the
> defunct gmane.org.  I think I tracked down the post it is supposed
> to link to, so I don't want others to have to do this work again:
> https://lists.gnu.org/archive/html/emacs-orgmode/2007-12/msg00281.html
>

You can go one step further and actually fix it in the worg page -
worg is user-editable: https://orgmode.org/worg/index.html#org218100b

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] export, excluding everything marked with special tags

[Nick Dokos]

John Kitchin  writes:

> One way is to put a list of tags (separated by spaces) in a file property 
> like this:
>
> #+EXCLUDE_TAGS: one two
>

... or if you want to do it globally, set the variable org-export-exclude-tags 
in your
init file:

(setq org-export-exclude-tags '("one" "two"))

> On Fri, Sep 20, 2019 at 7:06 AM Julius Dittmar  wrote:
>
> Hi,
>
> I know it's possible to define one tag's name to block org from
> including any heading tagged like that from exports. Is it possible to
> have more than one such tag defined? If so, how can that be done?
>
> Thanks in advance,
>
> Julius
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] lisp: scoping vars in repetitive defuns

[Nick Dokos]

Matt Price  writes:

> I have a number of convenience functions define to help me with grading 
> assignments. As I go through the semester, i update all of these functions 
> modestly so that they'rehelpful for grading the current
> assignment. 
>
> I big chunk of these simple functions is taken up just declaring variables 
> with (let (())) forms.  Each function uses some ofhte same variables, e.g:
>
> (defun dh-find-files ()
>   (interactive)
>   (let* ((base (org-entry-get (point) "ORG_LMS_ASSIGNMENT_DIRECTORY"))
>          (gh (org-entry-get (point) "GITHUB"))
>         (f2o `( ,(concat "Reflection/" gh ".md") ,(concat "students/" gh 
> ".json"  "01/index.html" "02/index.html" "03/style.css" "04/style.css"
>     (message "%s" f2o)
>     ;; make more flexible for resubmits
>     (shell-command (concat "cd " base " && git checkout " gh "-master"))
>     (dolist (x f2o)
>       (if (file-exists-p (concat base "/" x))
>           (find-file-other-window (concat base "/" x) )
>         (message "File %s does not exist, not opening." x)
>
> (defun dh-tests ()
>   (interactive)
>   (let* ((base (org-entry-get (point) "ORG_LMS_ASSIGNMENT_DIRECTORY" ))
>          (gh (org-entry-get (point) "GITHUB")))
>     (with-temp-buffer (shell-command (concat "cd " base " && npm test") t)) 
> ;; the "t" lets us suppress buffer
>     (browse-url-of-file (concat base "/TestResults/testresults.html"))
>     ;; (dh-mocha-run)
>    
>     ))
>
> --
>
> This semester I changed some elements of my workflow and I had to update all 
> the (org-entry-get) calls to new values.  It makes me think the code is less 
> maintainable than it could be.  I would like to do
> something like this:
>
> (lexical-let ((base `(org-entry-get (point) "ORG_LMS_ASSIGNMENT_DIRECTORY")
>    (gh `(org-entry-get (point) "GITHUB")) )
>     (defun dh-find-files ()
> (with-temp-buffer (shell-command (concat "cd " base " && npm test") t)) ;; 
> the "t" lets us suppress buffer
>     (browse-url-of-file (concat base "/TestResults/testresults.html")
>
> Obviously it doesn't work this way. But is there any way to set macros like 
> this to be expanded later inside a function definition? I feel certain there 
> must be...

Are you overthinking this perhaps? Wouldn't variables work? Like e.g.:

(defvar org-lms-assignment-dir-prop "ORG_LMS_ASSIGNMENT_DIRECTORY")

(defun dh-find-files()
  ...
  (let ((base (org-entry-get (point) org-lms-assignment-dir)
  ...

and then you only have one place to change it?

It's quite possible of course that I'm misunderstanding what you are looking 
for.

>
> Thanks,
>
> Matt
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] R-generated images not showing

[Nick Dokos]

William Denton  writes:

> This problem started for me a little while ago:  images generated from R 
> source 
> blocks no longer appear even though I have images display turned on.
>
> For example, this file:
>
> # -
>
> #+begin_src R :results graphics file :file /tmp/src.png
> x <- seq(-4, 4, length=200)
> y <- dnorm(x, mean=0, sd=1)
> plot(x,y, type = "l", lwd = 2, xlim = c(-3.5,3.5))
> #+end_src
>
> #+RESULTS:
> [[file:/tmp/src.png]]
> # -
>
> I don't see the image, I just see the text "file:/tmp/src.png".  When 
> image-display is off (C-c C-x C-v) it becomes a link, and when I toggle it 
> back 
> on it's just plain text.
>
> The file on disk really is there and is a valid image.
>
> If I run the three R lines in an ESS window (M-x R) then the image pops up in 
> its own window, as normal.
>
> I ran "emacs -Q" and loaded up Org and enough Babel stuff to the source block 
> to 
> work, and the image appeared inline as it should!  So it's something to do 
> with 
> my config [1] but I can't figure out what.
>
> Has anyone ever had this happen, or noticed it recently?  I'm compiling Emacs 
> and Org from source and both are current.  I'm not sure what the easiest way 
> to 
> identify the problem is.

The usual method is to bisect your setup-orgmode.el file: comment out
the bottom half and if that makes it work, then you know that the
problem is in the part that you commented out. Recursively, bisect
further.

I downloaded your setup-org.el and tried it out. There are two things
that I commend out: the (use-package org-bullets ...) stuff - the
`emacs -Q -l setup-orgmode.el' complained about use-package and I was
too lazy to add whatever is necessary to get it and the (add-hook
'org-mode-hook wrap-region-mode) stuff because I don't have
wrap-region-mode installed. With those two deletions, I see no
problem.  I doubt that the problem is with org-bullets, so try getting
rid of wrap-region-mode and see if that does the trick. Of course, it
may be that there is some interaction between your Org mode setup and
all the *other* setup that you do, but bisecting is still the way to
go.

>
> Bill
>
> [1] https://github.com/wdenton/.emacs.d/blob/master/setup/setup-orgmode.el
>
> --
> William Denton :: Toronto, Canada   ---   Listening to Art: 
> https://listeningtoart.org/
> https://www.miskatonic.org/ ---   GHG.EARTH: http://ghg.earth/
> Caveat lector.  ---   STAPLR: http://staplr.org/
>
>

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] minimal testing setup for pdf export?

[Nick Dokos]

Jude DaShiell  writes:

> It would be helpful if when pdf get exported from orgmode they have
> speech enabled by default.
>

Not sure that org mode can do anything about, since it's LaTeX that produces
the PDF. That said, I'm not sure what needs to be done: what's the difference
between a speech-enabled PDF and a non-speech-enabled one?

-- 
Nick

Re: [O] org-megaup

[Nick Dokos]

Jean-Christophe Helary  writes:

> When I use org-megaup I get a "Invalid function:
> org-preserve-local-variables" is there a way to fix that ?
>

org-megaup is not defined AFAICT - do you mean `org-metaup'?

If not, disregard the rest of this message.

If yes, I don't see any problems, so you might want to provide the
context (e.g. are trying to move subtrees up, move table rows up or
move items in a list up?) Check also the value of `org-metaup-hook' to
see if something weird crept in there.

If it happens regardless of context, I would edebug the org-metaup
function and see where the error message comes from - BTW,
org-preserve-local-variables is a macro, not a function (so that might
have something to do with it), defined in org-macs.el. If your setup
is curdled, that might not be loaded, so try `(load-library org-macs)`
and see if that resolves if: if it does, then you have to figure out
whether there is something wrong with your setup (if it doesn't load
that file automatically) or how it got curdled (if it does).

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Bug: Description of org agenda columns format in manual not correct/misleading

[Nick Dokos]

"Fraga, Eric"  writes:

> I have this setting in my Emacs initialization:
>
> (setq org-agenda-overriding-columns-format "%5TODO %TIMESTAMP %40ITEM 
> %LOCATION %TAGS")
>
> HTH,
> eric

Shouldn't you be using org-columns-default-format instead?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] defconst: Symbol’s value as variable is void: css-syntax-propertize-function

[Nick Dokos]

"Charles R (Charlie) Martin"  writes:

> I'm getting this error when trying to export HTML from org-mode. Is this a 
> known issue? I haven't found
> any solutions via google.
>

When I do `C-h v css-syntax-propertize-function RET' I get:

,
| css-syntax-propertize-function is a variable defined in ‘css-mode.el’.
| Its value is #f(compiled-function (start end) #)
| 
|   This variable may be risky if used as a file-local variable.
| 
| Documentation:
| Not documented as a variable.
`

Maybe try `M-x load-library RET css-mode RET' and try the export again?
A backtrace would be useful for identifying what is going awry. Try

M-x toggle-debug-on-error RET

and try the export againg; then post the backtrace.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Issue with internal links

[Nick Dokos]

"Doyley, Marvin M."  writes:

>
> * Testing
> * One
> * Two
>[[*Testing]].   (I also tried [[Testing]] and I got the same error)
>
> Debugger entered--Lisp error: (void-function org-pass-link-to-system)
>   org-pass-link-to-system("*Testing")
>   run-hook-with-args-until-success(org-pass-link-to-system "*Testing")
>   (if (run-hook-with-args-until-success 'org-open-link-functions path) 

org-pass-link-to-system is not a function defined by org mode, AFAICT.
The fact that it's the value of the org-open-link-functions hook reinforces
my belief that at some point in the past, you had defined this function
somewhere and you had included it in the hook; perhaps you lost the function
after an upgrade or a disk failure or ... who knows?

The value of org-open-link-functions is nil in my case, so I'd recommend
you try setting it to that:

 (setq org-open-link-functions nil)

and try following the link. If that works to your satisfaction, then
find the place in your init file or customizations file where
org-pass-link-to-system is added to org-open-link-functions and get
rid of it. Then restart emacs.

HTH.
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Move Currently clocked in task to left on modeline

[Nick Dokos]

Nathan Neff  writes:

> Hello all,
>
> How can I move the currently clocked task to be on the left side
> of my modeline in emacs?
>

The way the information ends up in the mode line is a bit convoluted:

- The main variable is `mode-line-format': you should read its doc
  string carefully.

- `mode-line-format' includes the variable `mode-line-misc-info'
  towards the end.

- `mode-line-misc-info' includes the variable `global-mode-string'
  (in a somewhat peculiar way that I don't quite understand).

- `org-clock-in', `org-clock-out' and `org-clock-cancel' affect the
  mode line by modifying the `global-mode-string' variable to append
  or delete `org-mode-line-string' to/from it and then forcing a
  mode-line update with (drum roll) `force-mode-line-update'.

- The rest of the org mode code mucks around with `org-mode-line-string'
  exclusively.

In short, there is no way to change the position of the currently
clocked task without rewriting code. You might be able to move
*all* of the org information by modifying an earlier mode-line
component (rather than `global-mode-string' which is part of the
final component). But it would not be trivial.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Exporting in html with numeric references to headlines

[Nick Dokos]

Shérab  writes:

> Dear all,
>
> Assume the following document:
>
> ===
>
> #+title: test1
>
> * Introduction
>
> Monads will be explained in chapter [[#monads]]
>
> * Monads
>   :PROPERTIES:
>   :CUSTOM_ID: monads
>   :END:
>
> Welcome to the monads chapter.
>
> ===
>
> When I export this to html, the paragraph in the introduction says:
>
> Monads will be explained in chapter 2
>
> with "2" being a link, which is what I am expecting. However the link
> does not work and it seems the "#monads" anchor is actually not created.
> I can also observe that the links in the table of contents do not seem
> to work either.
> Am I doing something wrong? I also tried different variations with
> <> but was not able to make anything work.

As Bruno Barbier points out, you are probably OK: you just have to add
more stuff in the first chapter, so that when you click the link, the change
is visible.

Another way to see it is to look at the HTML file that is
produced: if that contains what you expect, then you should be
OK. That is a technique that is often useful in debugging export
problems, e.g. I often export to PDF (via LaTeX) and I look at the
produced LaTeX file (and sometimes tinker with it and process it
until I figure out what's wrong).

In this case, the HTML looks like this:

,
| ...
| 
| 1 Introduction
| 
| 
| Monads will be explained in chapter 2
| 
| 
| 
| 
| 2 Monads
| 
| 
| Welcome to the monads chapter.
| 
| 
| 
| ...
`
which looks correct: the #monads href links the  tag.
To test Bruno's hypothesis, I even added a bunch of

,
| Lorem ipsum 
`

lines between the chapters right in the HTML file to make the second
chapter move down "below the fold" and see whether clicking the link
works: it did.

HTH.
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

[O] Bug: org-agenda-list attempts to add text properties to agenda header even if org-agenda-overriding-header is set to "" [9.2.4 (release_9.2.4-386-gb855ac @ /home/nick/elisp/org-mode/lisp/)]

[Nick Dokos]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Evaluate the following form:

 (let ((org-agenda-overriding-header "")) (org-agenda-list))

It fails with

 org-agenda-list: Args out of range: 0, 1

It seems that the following code in org-agenda-list:

--8<---cut here---start->8---
 ...
  (unless org-agenda-compact-blocks
(let* ((d1 (car day-numbers))
   (d2 (org-last day-numbers))
   (w1 (org-days-to-iso-week d1))
   (w2 (org-days-to-iso-week d2)))
  (setq s (point))
  (org-agenda--insert-overriding-header
(concat (org-agenda-span-name span)
"-agenda"
(cond ((<= 350 (- d2 d1)) "")
  ((= w1 w2) (format " (W%02d)" w1))
  (t (format " (W%02d-W%02d)" w1 w2)))
":\n")))
(add-text-properties s (1- (point)) (list 'face 'org-agenda-structure
  'org-date-line t))
(org-agenda-mark-header-line s))
--8<---cut here---end--->8---

tries to add text properties to the string even though it has been set to the
empty string.

I was able to reproduce this after it was reported on the Emacs SE:


https://emacs.stackexchange.com/questions/51354/is-there-any-way-to-hide-agenda-date-header

Emacs  : GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32)
 of 2019-05-01
Package: Org mode version 9.2.4 (release_9.2.4-386-gb855ac @ 
/home/nick/elisp/org-mode/lisp/)
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] export to latex, make-backup-files, vc-make-backup-files

[Nick Dokos]

Uwe Brauer  writes:

>> Uwe Brauer  writes:
>
>> FWIW, I tried a set-up with git (I don't have mercurial available) and I 
> cannot
>> reproduce this.
>
>> I'm not using numbered backups but the two variables you mention are set 
> the
>> same way for me. Here's what I did:
>
> Do you have really 
>  make-backup-files t, 
>  vc-make-backup-files nil
>

Those are the setting I have.

>
> The only way I can stop the backup nightmare, is set it to nil,
> globally, which is not what I want.
>

Why not? If it's under VC, why do you need emacs to make backups for you?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] export to latex, make-backup-files, vc-make-backup-files

[Nick Dokos]

Uwe Brauer  writes:

> Hi 
>
> The following kills me.
>
> I have set
>
> make-backup-files t, 
> vc-make-backup-files nil
>
> I am in a directory which is under version control (mercurial).
>
> The file test.org and test.tex are *both* under VC control.
>
> However when I export test.org to test.tex say twice
> the files 
>
> test.tex
> and 
>
> test.tex.~1~
>
> are generated and if I export once again I will have another backup
> file.
>
> ...
>
> But it does not help
>
> Is this a bug?
>

FWIW, I tried a set-up with git (I don't have mercurial available) and I cannot
reproduce this.

I'm not using numbered backups but the two variables you mention are set the
same way for me. Here's what I did:

- created a directory "foo" and cd'ed to it.
- `git init'
- create "test.org" and export to create "test.tex".
- `git add test.org test.tex'
- `git status' to check that everything looks good.
- modify test.org and export a few times.
- at every export, do `ls -la'. I always get this:

,
| $ ls -la
| total 12
| drwxrwxr-x.  4 nick nick   62 Jun 21 13:04 .
| drwxrwxr-x. 14 nick nick 4096 Jun 21 13:03 ..
| drwxrwxr-x.  2 nick nick   21 Jun 21 13:04 auto
| drwxrwxr-x.  7 nick nick  132 Jun 21 13:04 .git
| -rw-rw-r--.  1 nick nick   67 Jun 21 13:04 test.org
| -rw-rw-r--.  1 nick nick  788 Jun 21 13:04 test.tex
`

with no trace of backups.

Maybe try with git and see if you can reproduce the problem?
If not, I'd suspect either that the tex file is not under VC
or there is some incompatibility between mercurial and the
emacs vc package.

Also, there are two ways to make a backup (renaming and copying -
I use copying) and maybe the method you use is incompatible with
mercurial. Maybe you can try the other method: check the setting
of `make-backup-by-copying'.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] org-mode table element selection WITH blanks elements

[Nick Dokos]

This was posted on the Emacs SE and I replied there:

   
https://emacs.stackexchange.com/questions/51141/org-mode-table-element-selection-with-blanks
   
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Coloured source code examples in --batch exports?

[Nick Dokos]

Stig Brautaset  writes:

> ...
> Adding a ~--batch~ flag to the command makes the command run on
> CircleCI, but I get a less colourful (and less pleasing) result. The
> markup appears to only use /italic/ and *bold* styles now.
>

--batch skips your initialization file. You will have to provide a minimal
load file that does the initializations you need and then use -l to load it:

--8<---cut here---start->8---
emacs --batch -l my-init-file.el --file foo.org \
  --eval '(progn (package-initialize) (org-html-export-to-html nil nil nil 
t) (kill-emacs))'
--8<---cut here---end--->8---

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] change tables to matrix when importing, including expressions.

[Nick Dokos]

Uwe Brauer  writes:

> However I would like 
>
> #+begin_src 
> #+attr_latex: :mode math :environment matrix
> D=
> | 0 | -5 |
> | 5 |  0 |
> #+end_src
>
>
> To be exported as 
>
> #+begin_src 
> \[
> D=
> \begin{matrix}
>  0 & -5 \\
>  5 & 0 \\
> \end{matrix}
> \]
> #+end_src
>

#+attr_latex: :mode math :environment matrix :math-prefix D=

perhaps?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] strange output when executing matlab using babel, strange ,

[Nick Dokos]

Uwe Brauer  writes:

> Hi 
>
> I am running Ubuntu 16.06, matlab 2018b and  I am using the python
> kernel to use matlab from within org mode
>
> 
>
> * The problem
>
> When I run 
>
> #+begin_src matlab :results output latex :exports results  :eval never-export 
> disp('*Step 3:*')
> disp('*Step 3:*  Calculate this')
> #+end_src
>
> On obtain 
> #+RESULTS:
>
> #+begin_export latex
> ,*Step 3:*
> ,*Step 3:*  Calculate this
> #+end_export
>
> Instead of 
>
> #+begin_export latex
> *Step 3:*
> *Step 3:*  Calculate this
> #+end_export
>

> Does anybody have an idea what is wrong there?
>

I don't think anything is wrong: org quotes lines that look like
headlines in the babel output by prepending the comma.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Fwd: Questions about org-element

[Nick Dokos]

Ngor  writes:

> Hi Org community.
>
> I am re-posting my questions here according to Nicolas' recommendation.
>
> I am working on a standalone parser implementation for Org which is basically 
> a translation of elisp program to Rust
> https://github.com/org-rs/org-rs
>
> There are couple of things I wanted to ask about:
>
> 1) I have discovered several inconsistencies and errors in the Syntax/API 
> documentation
> https://orgmode.org/worg/dev/org-element-api.html vs 
> https://orgmode.org/worg/dev/org-syntax.html vs elisp source
> And I don't know the right way to report them.
>
> 2) I think I have found a bug in the algorithm (org-element-collect 
> affiliated keywords does not take granularity into accound and seems to be 
> always parsing objects in Caption
> keyword)
>
> 3) I have a question regarding the elisp source source (specifically about 
> the :parent of the parsed objects of the keyword)
>
> I can elaborate on each point but I don't want to overwhelm everybody with 
> details right from the start. I guess the meta-question is where and how
> should I discuss these points? - I never used mailing lists before (If I did 
> something incorrectly or do not follow the established rituals/traditions 
> please do not judge me harshly.
> )
>

No need for metaquestions: ask away.

You might want to report related problems together, but if the
connection is tenuous or non-existent, then separate posts to the
mailing list will probably work better. Asking your question in a
separate post is probably best, so it doesn't get lost in the forest
of detail when reporting problems.

If you suspect a bug, then use 'M-x org-submit-bug-report`: the bug
report will end up here and will contain a lot of information about
your set-up which might be helpful.

Finally, be patient: do not expect answers (particularly when the
questions are complicated, as it seems yours will be). It takes
a while for people to get around to even reading the posts, let
alone coming up with answers (or, as is likely, more quesions for
you).

And welcome to mailing lists in general and this mailing list in
particular!

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] suppress leading ":" in org-babel output

[Nick Dokos]

"Berry, Charles"  writes:

>> On May 27, 2019, at 7:17 PM, Nick Dokos  wrote:
>> 
>> Jeremie Juste  writes:
>> 
>>> Hello,
>>> 
>>> I recall seeing this thread on the mailing list but I cannot find it
>>> back.
>>> 
>>> I would like to suppress the first line leading ":" in the following output
>>> 
>>> 
>>> #+NAME:mean_purchase_per_shopping_trip
>>> 
>>> #+BEGIN_SRC R :var x=6 :results output :session *R*
>>> a <-sprintf("%.2f",12.234324)
>>> cat(a,sep="\n")
>>> #+END_SRC
>>> 
>>> #+RESULTS: mean_purchase_per_shopping_trip
>>> : 
>>> 
>>> : 12.23
>>> 
>> 
>> FWIW, I just get the last line:
>> 
>> #+NAME:mean_purchase_per_shopping_trip
>> 
>> #+BEGIN_SRC R :var x=6 :results output :session *R*
>> a <-sprintf("%.2f",12.234324)
>> cat(a,sep="\n")
>> #+END_SRC
>> 
>> #+RESULTS:
>> : 12.23
>> 
>> This is with 
>> 
>>   GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 
>> 2019-05-01
>>   Org mode version 9.2.3 (release_9.2.3-367-gd79e80 @ 
>> /home/nick/elisp/org-mode/lisp/)
>>   R version 3.5.3 (2019-03-11) -- "Great Truth"
>> 
>> on Fedora 29.
>> 
>
> I get what Jeremie reports (but he has a blank line inserted after the first 
> line, IIUC)
>
> This is with:
>
> GNU Emacs 26.1 
> Org 9.2.3
> ess-version: 18.10.3
> R version 3.6.0 (2019-04-26)
>
> I believe this is new-ish behavior. I see some older files without the
> extra line. Also, I think there are recent changes in ESS that pertain
> to comint sessions.
>
> FWIW, here is a clip from my session:
>
>> x <- 6L
> a <-sprintf("%.2f",12.234324)
> cat(a,sep="\n")
> 'org_babel_R_eoe'
>> > 
> 12.23
>> 
> [1] "org_babel_R_eoe"
>
>
> If Nick sees something different maybe a change in ESS is the culprit.
>

Here's what I see in the session buffer:

,
| > > if (identical(getOption('pager'), file.path(R.home('bin'), 'pager'))) 
options(pager='cat') # rather take the ESS one 
| > options(STERM='iESS', str.dendrogram.last="'", editor='emacsclient', 
show.error.locations=TRUE)
| > x <- 6L
| a <-sprintf("%.2f",12.234324)
| cat(a,sep="\n")
| 'org_babel_R_eoe'
| x <- 6L
| > a <-sprintf("%.2f",12.234324)
| > cat(a,sep="\n")
| 12.23
| > 'org_babel_R_eoe'
| [1] "org_babel_R_eoe"
| > 
`

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] suppress leading ":" in org-babel output

[Nick Dokos]

Jeremie Juste  writes:

> Hello,
>
> I recall seeing this thread on the mailing list but I cannot find it
> back.
>
> I would like to suppress the first line leading ":" in the following output
>
>
> #+NAME:mean_purchase_per_shopping_trip
>
> #+BEGIN_SRC R :var x=6 :results output :session *R*
> a <-sprintf("%.2f",12.234324)
> cat(a,sep="\n")
> #+END_SRC
>
> #+RESULTS: mean_purchase_per_shopping_trip
> : 
>
> : 12.23
>

FWIW, I just get the last line:

#+NAME:mean_purchase_per_shopping_trip

#+BEGIN_SRC R :var x=6 :results output :session *R*
a <-sprintf("%.2f",12.234324)
cat(a,sep="\n")
#+END_SRC

#+RESULTS:
: 12.23

This is with 

   GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 2.24.32) of 
2019-05-01
   Org mode version 9.2.3 (release_9.2.3-367-gd79e80 @ 
/home/nick/elisp/org-mode/lisp/)
   R version 3.5.3 (2019-03-11) -- "Great Truth"

on Fedora 29.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Advance notice of birthdays in org-mode via org-contacts

[Nick Dokos]

Daryl Manning  writes:

> I'm trying to come up with a better way to give myself advanced notice on 
> some peoples' birthdays coming up. 
>
> Right now, I use the following in a `cal.org` file to give me notice in 
> agenda that birthdays are coming up:
>
> ```
> * BDays                                                                       
>   :bday:
> %%(org-contacts-anniversaries "BIRTHDAY")
> ```
>
> The generally feeds off a `contacts.org` entry of the nature:
>
> ```
> *** John Wick                                                  
> :PROPERTIES:
> :EMAIL: therealj...@notthepuppy.com
> :BIRTHDAY: 1975-06-06
> :END:
> ```
>
> What I'd like is to get, on virtually all birthdays , a week's notice through 
> due soon (which I'll sort out in org-super-agenda in the view). 
> Alternatively, is there a nicer way to tag or
> otherwise note some birthdays in the `contacts.org` so that I could note 
> special people (close friends, family, etc) where I could set a specific 
> advanced notice period so that I have time
> to do something special for them etc?
>
> Would love to hear peoples' approaches to this. In general, if I'm not 
> looking out 2 weeks ahead (I spend most time in the day view), I can get 
> surprised.
>

I use bbdb, not org-contacts, and I have this in one of my agenda files:

* Anniversaries
   :PROPERTIES:
   :CATEGORY: Anniv
   :ID:   409062f6-6cb1-467f-b192-2dfcb7b384ca
   :END:
%%(org-bbdb-anniversaries-future)

That gives me the default 7 days of warning, but you can pass an
argument to it to specify the number of days of warning.

The function is fairly generic, so it should be possible to adapt it
to org-contacts with some modifications.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] switch off validate - how?

[Nick Dokos]

Amin Bandali  writes:

> Hello,
>
> Nick Dokos  writes:
>
> [...]
>
>>
>> C-h v org-html-validation-link RET
>>
>> Set it to "", but there are still validation remnants left in the HTML
>> file, which is probably a bug:
>>
>> ,
>> | 
>> | Author: Nick Dokos
>> | Created: 2019-05-20 Mon 12:43
>> | <<<<<<<<<<< this should disappear.
>> | 
>> `
>
> Indeed, it would be nice if setting `org-html-validation-link' to "" or
> nil didn’t insert the wrapping paragraph.  In the meantime, you can
> customize C-h v org-html-postamble-format RET and get rid of the
> validation paragraph entirely.
>

You can't [fn:1]  set `org-html-validation-link' to nil because the defcustom
specifies a string.

Redefining the postamble format  is indeed a good solution, probably the
best solution currently available. `org-html-validation-link' should probably
only be used to point to a different validation engine, not to get rid of
validation altogether.

* Footnotes

[fn:1] At least through `customize' or `set-variable' - `setq' will of course
   let you do anything you want.

-- 
Nick

Re: [O] switch off validate - how?

[Nick Dokos]

Colin Baxter  writes:

> Hello,
>
> In exporting to html, how do I switch off the `validate' link at the
> bottom of the html file? I can't seem to find any appropriate variable.
>  

C-h v org-html-validation-link RET

Set it to "", but there are still validation remnants left in the HTML
file, which is probably a bug:

,----
| 
| Author: Nick Dokos
| Created: 2019-05-20 Mon 12:43
| <<<<<<<<<<< this should disappear.
| 
`

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Show weekday in daily agenda view

[Nick Dokos]

db...@attentigroup.com (J. David Boyd) writes:

> Nick Dokos  writes:
>
>> johanna@th-koeln.de writes:
>>
>>> maybe I did not search the right way in google alias startpage. But I
>>> could not figure out how to write next to the date e.g. 2000-04-01 the
>>> weekday, i.e. the specific day of the week. It would come very handy to
>>> have the date displayed as 2019-05-14 Tu and 2019-05-15 We and so on. Or
>>> even have it spelled out as 2019-05-14 Tuesday.
>>>
>>
>> How do you generate that view?
>>
>> Doesn't your agenda view already show the day of the week?  With the
>> recommended keybinding, I get a daily agenda with C-c a a d.
>>
>> Mine starts like this:
>>
>> ,
>> | Day-agenda (W20):
>> | Tuesday14 May 2019
>> |8:00.. 
>> |   appts:  10:00-11:30 Tools Meeting
>> |   10:00.. 
>> |   12:00.. 
>> |   14:00.. 
>> |   16:00.. 
>> |   18:00.. 
>> |   20:00.. 
>> |   work:   Sched.Xx:  TODO Review PR
>> |   work:   Sched.2x:  TODO Add issue
>> |   Weather:OpenWeatherMap: light rain, 3-8°C, 1010hpa, 90%, 3m/s
>> `
>>
>> so it definitely shows the weekday, but perhaps you are doing something
>> different?
>
>
> How do you generate *that* view?  How do you have it creating sub-groups?  All
> I get is a straight-forward list of days and times, with all items in chrono
> order
>

Not sure what you mean by "sub-groups". And I'm pretty sure I don't do
anything special to get this. The grid is the standard grid - I
believe that comes "free" with the default settings of
org-agenda-time-grid and org-agenda-use-time-grid.

The appts:, work: and Weather: thingies are "categories" - the first
two come from the name of the agenda file where the item originated:
I have a work.org file for work items and an appts.org file which contains just
reminders. It actually contains a bit more: there are top-level headlines
for Anniversaries, Weather and Appointments like this:

,
| * Anniversaries
|:PROPERTIES:
|:CATEGORY: Anniv
|:ID:   409062f6-6cb1-467f-b192-2dfcb7b384ca
|:END:
| %%(org-bbdb-anniversaries)
| 
| * Weather
|   :PROPERTIES:
|   :CATEGORY: Weather
|   :END:
| %%(org-weather)
| 
| * Appointments
| ** APPT Doctor appt 
| 
`

Items in the Appoinments section don't have a defined Category
so they are labeled with the fill name ("appts"). Anniversaries
and Weather items have a CATEGORY property so they are labeled
by  the explicit category.

I don't remember whether I do anything special to sort the items
(e.g. why the Weather item is always last). If you are interested
in that, I can dig a little more into my configuration.

Does that answer your question?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Show weekday in daily agenda view

[Nick Dokos]

johanna@th-koeln.de writes:

> maybe I did not search the right way in google alias startpage. But I
> could not figure out how to write next to the date e.g. 2000-04-01 the
> weekday, i.e. the specific day of the week. It would come very handy to
> have the date displayed as 2019-05-14 Tu and 2019-05-15 We and so on. Or
> even have it spelled out as 2019-05-14 Tuesday.
>

How do you generate that view?

Doesn't your agenda view already show the day of the week?  With the
recommended keybinding, I get a daily agenda with C-c a a d.

Mine starts like this:

,
| Day-agenda (W20):
| Tuesday14 May 2019
|8:00.. 
|   appts:  10:00-11:30 Tools Meeting
|   10:00.. 
|   12:00.. 
|   14:00.. 
|   16:00.. 
|   18:00.. 
|   20:00.. 
|   work:   Sched.Xx:  TODO Review PR
|   work:   Sched.2x:  TODO Add issue
|   Weather:OpenWeatherMap: light rain, 3-8°C, 1010hpa, 90%, 3m/s
`

so it definitely shows the weekday, but perhaps you are doing something
different?

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Column width cookies stopped working in 9.2.3?

[Nick Dokos]

Neil Jerram  writes:

>> As Eric says, things have changed in this area. It's always a good
>> idea to check the /etc/ORG-NEWS file for such things.  In this
>> particular case, read the section entitled "Dynamically narrow table
>> columns" in the Version 9.2 "New features" section of etc/ORG-NEWS.
>
> Thanks Nick.  I did check the manual before writing, and noticed that it 
> still says:
>
>      To set the width of a column, one field anywhere in the column may
>   contain just the string ‘’ where N specifies the width as a number of
>   characters.

Just to clarify: my intention was to advertise etc/ORG-NEWS more
widely and point out that it's probably the best place to learn about
things that are likely to break one's workflows (and if you read it
before you update, you just might avoid unpleasant surprises - and
this is not a specific "you", but a general "you" that includes
everybody, including me: I often forget to do this and suffer the
consequences).

>
> I think the crux of the matter is that my use case is apparently
> different from everyone else's.  Now that I've reread the whole
> section, it seems that the main target use case is _shrinking_ a
> column to be narrower than what is needed for its content.  My use
> case is the opposite: I want a column to be a fixed width that is
> always _larger_ than its content.    (FWIW, this is in order to
> avoid spurious Git diffs for column width changes, as I change the
> content in those tables.)
>
> For example, after deploying 'C-u C-c TAB', one of my tables now looks like 
> this:
>
> | Programme        ...| Sang? ...| Notes                             ...|
> |--...+---...+---...|
> | Audition         ...|       ...| January 2019                      ...|
> |--...+---...+---...|
> | <16>             ...| <6>   ...| <64>                              ...|
> | 2019             ...|       ...|                                   ...|
> | B minor mass     ...| Yes   ...| 1 planned absence (6 Mar)         ...|
> |                  ...|       ...| 6 Mar Present when not expected   ...|
> | Songs Summer Eve ...| No    ...|                                   ...|
> | French Choral    ...| Yes   ...| "I'm intending to sing in [this]" ...|
>
> which is IMO uglier than what it used to be, and what I'd like, like this:
>
> | Programme        | Sang?  | Notes                                           
>                  |
> |--++--|
> | Audition         |        | January 2019                                    
>                  |
> |--++--|
> | <16>             | <6>    | <64>                                            
>                  |
> | 2019             |        |                                                 
>                  |
> | B minor mass     | Yes    | 1 planned absence (6 Mar)                       
>                  |
> |                  |        | 6 Mar Present when not expected                 
>                  |
> | Songs Summer Eve | No     |                                                 
>                  |
> | French Choral    | Yes    | "I'm intending to sing in [this]"               
>                  |
>
> Am I right about my use case being different, and therefore perhaps
> having been caught up unintentionally in this change?
>

That may well be true: personally, I always thought of these cookies as minimum 
width specifiers, not
maximum width.

But I think you could do what you want by having a row that contains fixed 
width strings, instead of
width cookies. To make it as unobtrusive as possible, I'd use non-breaking 
spaces as the character:

|  |    |   
   |
|  ||   
   |

There may be better solutions, but this is what sprang to my mind after reading 
your use case.

HTH
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Column width cookies stopped working in 9.2.3?

[Nick Dokos]

Neil Jerram  writes:

> Hi,
>
> I have tables with width cookies like this:
>
> | <16> | <6>   | <64>  |
>
> I just added new information to one of those tables, and the table
> shrank down to match the size of the content, i.e. as though Org is
> now ignoring the width cookies.
>
> I believe I've also upgraded in the last few days, and now have:
> Org mode version 9.2.3 (9.2.3-13-g727c3f-elpa @
> /home/neil/.emacs.d/elpa/org-20190506/)
>
> Is this a known thing?  Do I need something else now to make those
> width cookies work?
>

As Eric says, things have changed in this area. It's always a good
idea to check the /etc/ORG-NEWS file for such things.  In this
particular case, read the section entitled "Dynamically narrow table
columns" in the Version 9.2 "New features" section of etc/ORG-NEWS.

-- 
Nick

"There are only two hard problems in computer science: cache
pinvalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] [latex export/babel] pass arguments to \includegraphics from code blocks

[Nick Dokos]

Jakob Schöttl  writes:

> Hi, I want to use code blocks to generate and include images of sheet music:
>
> #+BEGIN_SRC lilypond :file test.png :exports results
> \header{tagline=""}
> { a b c }
> #+END_SRC
>
>
> When doing a latex export the result is:
>
> \begin{center}
> \includegraphics[width=.9\linewidth]{test.png}
> \end{center}
>
> Is there a way to specify the arguments for \includegraphics? For 
> example I want to change the display width.
>
> Putting these lines above the code block have no effect:
>
> #+ATTR_LATEX: :width 4cm
>
> #+CAPTION: xxx
>
> Maybe this requires a change in ob-lilypond.el to introduce new header 
> arguments for the source block?
>

What I do in such cases is evaluate the block and then add the caption and
attribute line above the #+RESULTS line:

--8<---cut here---start->8---
#+BEGIN_SRC lilypond :file test.png :exports results
\header{tagline=""}
{ a b c }
#+END_SRC


#+ATTR_LATEX: :width 4cm
#+CAPTION: xxx
#+RESULTS:
[[file:test.png]]
--8<---cut here---end--->8---

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Manual does not mention LEVEL special property

[Nick Dokos]

Nicolas Goaziou  writes:

> Hello,
>
> Omari Norman  writes:
>
>> The Org mode manual does not mention the LEVEL special property; can you
>> please add it?
>>
>> https://orgmode.org/manual/Special-properties.html
>
> I don't think LEVEL is a special property. Why do you think it should be
> one?
>

The "Matching tags and properties" section seems to imply that:

,
| You may also test for properties (see Properties and Columns) at the
| same time as matching tags. The properties may be real properties, or
| special properties that represent other metadata (see Special
| Properties). For example, the property ‘TODO’ represents the TODO
| keyword of the entry. Or, the property ‘LEVEL’ represents the level of
| an entry. So searching ‘+LEVEL=3+boss-TODO​="DONE"’ lists all level
| three headlines that have the tag ‘boss’ and are not marked with the
| TODO keyword ‘DONE’. In buffers with org-odd-levels-only set, ‘LEVEL’
| does not count the number of stars, but ‘LEVEL=2’ corresponds to 3
| stars etc.
`

AFAIU, special properties are properties of a headline, even though
the user has not defined them (indeed, *should not* define them) in a
properties drawer. If that's so, I think LEVEL qualifies as a special
property.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [O] Shrinking columns after formula recalculation

[Nick Dokos]

Nicolas Goaziou  writes:

> Hello,
>
> Nick Dokos  writes:
>
>> But since no good deed shall go unpunished, here's another related
>> problem I ran into: with shrunk columns, I add a few more rows to the
>> table with S-RET on the first column, recalculate to populate the
>> added rows and then do an undo. That undoes the results of the
>> recalculation but it also unshrinks the column.
>
> Yes, undo unshrinks. This is a good thing as one might not notice undone
> changes within a shrunk column.
>
> Also, AFAIK, there is no elegant way (i.e., not writing `org-undo') to
> circumvent the issue, if it is considered as such.
>

OK - thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler