Re: Bug: LaTeX export does not handle .pgf/.tikz images [9.3 (9.3-elpaplus @ .emacs.d/elpa/org-plus-contrib-20191203/)]

[Fraga, Eric]

On Friday,  6 Dec 2019 at 17:47, Arthur wrote:
> Since my last org update (today or yesterday I would say) I have been
> having an issue with exporting .pgf or .tikz file to LaTeX.  The
> exporter always returns `nil`.

Your example works just fine for me with git up to date as of a few
minutes ago (and also with org from a week ago, give or take).  Maybe
something in your configuration?

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Re: Issues with nested begin..end blocks in inline math environments

[Fraga, Eric]

On Friday,  6 Dec 2019 at 11:42, Matt Huszagh wrote:
> I'm experiencing incorrect and seemingly inconsistent behavior when nesting
> `\begin` `\end` environments inside `\(\)` or `$$`. For example, the
> following is valid latex code:

The identification of LaTeX fragments is somewhat fragile (in my
experience).  I would suggest you enclose complex LaTeX code fragments
within an #+begin_export latex ... #+end_export environment.

Assuming your export target is LaTeX and/or PDF.

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

Include lines in setupfile are not evaluated: bug or feature?

[Jarmo Hurri]

Greetings.

I am (still) trying to figure out a SINGLE common setup/include file for
all settings for a large batch of files.

I found out recently that common #properties can be set in a setup file
(but not in an included file). However, now it seems that in a setup
file I can not include all common included files. Is this intended
behaviour?

Below is an example that demonstrates this. First the main (exported
file):

# --- file main-file.org 
#+setupfile: setup-file.org

src_elisp[:exports results :results raw]{(org-entry-get nil "MY_PROPERTY" t)}
# ---

Then the setup file:

# -- file setup-file.org 
#+property: MY_PROPERTY true
#+include: setup-included.org
# ---

Then the file that is supposed to be included in the setup file (and,
consequently, in the main file):

# -- file setup-included.org 
Some text to be included.
# ---

But the text is not included in the main file. Documentation of
#setupfile says that

"Org parses the contents of this document as if it was included in the
buffer."

https://orgmode.org/manual/In_002dbuffer-settings.html

But that does not seem to be the case.

Jarmo

Re: Bug: headlines escape blocks [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Nicolas Goaziou]

Hello,

Tom Gillespie  writes:

> * Description
> Headlines are not ignored inside of blocks when the headline is not indented.
>
> * Affected versions
> 9.1.9, 9.3
>
> * Observed behavior
> Lines starting with any headline pattern =*=, =**= etc. are treated as
> headlines inside all block types. Example and source blocks highlight
> as if the text is escaped, diverging from the behavior of org-mode.
> Verse blocks highlight as a headline, in agreement with the behavior.

This is the expected behaviour. See (info "(org) Literal Examples")

Regards,

-- 
Nicolas Goaziou

Re: Bug: LaTeX export does not handle .pgf/.tikz images [9.3 (9.3-elpaplus @ .emacs.d/elpa/org-plus-contrib-20191203/)]

[Nicolas Goaziou]

Hello,

Arthur  writes:

> Since my last org update (today or yesterday I would say) I have been
> having an issue with exporting .pgf or .tikz file to LaTeX.  The
> exporter always returns `nil`.
>
> I attached a patch that can fix this.  It is not thoroughly tested by my
> assumption is that the `progn` does not actually "set" variable
> `image-code`, hence the `nil`.
>
> Attached:
>  - org file to reproduce the error.
>  - tex file output by the org exporter.
>  - output of `org-submit-bug-report` (it is waaay too long)
>  - the patch I wrote which basically removes the `progn` block and
>replaces it by a single `setq`.

Fixed. Thank you for the report and the patch.

Regards,

-- 
Nicolas Goaziou

Bug: tangle failure of one block results in failure to set =:tangle-mode= of another [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Tom Gillespie]

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.


* Description
=#+HEADER: :tangle= arguments fail after other blocks tangle
=#+BEGIN_SRC lang :tangle= arguments fail before other blocks tangle

When tangling multiple blocks if a block fails during tangling after
some other block has already been tangled, the block that has already
been tangled will not have its =:tangle-mode= set. This can result in
a =:tangle-mode (identity #o0600)= header argument failing to be
applied after a file has been created resulting in a file that is
readable by anyone instead of secure.

* Affected versions
9.1.9, 9.3

* Observed behavior
An error occurs during tangling multiple blocks with =C-c C-v C-t=.
Files that are expected to have a mode set (e.g. =#o0755=, or =#o0600=)
by a =:tangle-mode= header retain the default mode =#o0644=.

It does not matter whether =:tangle-mode= is set on a =#+HEADER:= line
or on a =#+BEGIN_SRC= line.

* Expected behavior
It is not entirely clear what the best way to fix this is. Anything
that causes a failure
between the time that a file is tangled and tangle mode is set could
cause a similar issue.

One way to ensure that this cannot happen is the following:
1. Before a block is tangled check for the =:tangle-mode= header
2. If the =:tangle-mode= header exists, touch the file to be tangled
DO NOT WRITE THE CONTENTS YET
3. Set the mode specified by the =:tangle-mode= header
4. Now write the contents of the file
This will prevent a file from being written =#o0644= by default and
possibly left exposed.

* Reproduction
This is a contrived example. The secret file has to be tangled before
the other block fails
to tangle. To reproduce the issue I am using a missing folder to cause
an error after
tangling the secret file but before its =:tangle-mode= has been set. NOTE:
_any other failure that can occur after some other block has tangled
can cause the same problem_.

The examples also attached.

#+NAME: org-bug-0-0.org
#+BEGIN_EXAMPLE org

To reproduce =emacs -q --load org -- org-bug-0-0.org= and then =C-c C-v C-t=
#+HEADER: :tangle-mode (identity #o0600)
#+BEGIN_SRC bash :eval never :tangle ./some-secret-file.sh
export ALL_MY_ENVIRONMENT_VARS=secret
#+END_SRC

#+HEADER: :tangle ./this-folder-does-not-exist/some-other-file
#+BEGIN_SRC bash :eval never
echo will fail to tangle after some-secret-file.sh is written
echo BUT before its :tangle-mode is set
#+END_SRC

#+END_EXAMPLE

#+NAME: org-bug-0-1.org
#+BEGIN_EXAMPLE org

To reproduce =emacs -q --load org -- org-bug-0-1.org= and then =C-c C-v C-t=
#+BEGIN_SRC bash :eval never :tangle ./some-secret-file-2.sh
:tangle-mode (identity #o0600)
export ALL_MY_ENVIRONMENT_VARS=secret
#+END_SRC

#+BEGIN_SRC bash :eval never :tangle
./this-folder-does-not-exist/some-other-file
echo will fail to tangle after some-secret-file-2.sh is written
echo BUT before its :tangle-mode is set
#+END_SRC

#+END_EXAMPLE

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, X toolkit)
 of 2019-09-27
Package: Org mode version 9.3 (9.3-elpaplus @
/home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)


org-bug-0-0.org
Description: Lotus Organizer


org-bug-0-1.org
Description: Lotus Organizer

mathematica.el in org-plus-contrib outdated (i.e. command MathematicaScript became wolframscript in new version)

[dalanicolai]

As stated in the subject of this e-mail, the command MathematicaScript
became wolframscript in the newer versions of mathematica. To make
ob-mathematica.el work again with newer versions of mathematica simply
replace all occurences of MathematicaScript with wolframscript in that file.

An extra comment. Wolfram made it's Wolfram Engine freely available

for developers. And I guess it can be used to, for example, produce
Mathematica Plots (or graphics) in the jupyter notebooks using the Wolfram
Language kernel for jupyter
 (I am not
sure because I have a licensed Mathematica version and I guess my jupyter
is using that kernel to get the graphics). Would be great to have such
functionality working in org-mode (with-babel). Unfortunately I am not a
developer. But someone else might like the idea too.

Bug: headlines escape blocks [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Tom Gillespie]

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.


* Description
Headlines are not ignored inside of blocks when the headline is not indented.

* Affected versions
9.1.9, 9.3

* Observed behavior
Lines starting with any headline pattern =*=, =**= etc. are treated as
headlines inside all block types. Example and source blocks highlight
as if the text is escaped, diverging from the behavior of org-mode.
Verse blocks highlight as a headline, in agreement with the behavior.

* Expected behavior
I would expect the behavior implied by the highlighting in the example
and source blocks. Blocks should take precedence over the headline
behavior.

* Reproduction
See example below (attached as a standalone file as well).

---
To reproduce =emacs -q --load org -- org-bug-1.org=
#+BEGIN_EXAMPLE
* This should not be treated as a header
but for some reason it is
#+END_EXAMPLE

#+BEGIN_SRC
* Neither should this be treated as a header
but for some reason it is
** And so is this
#+END_SRC

#+BEGIN_VERSE
* Ode to a left aligned headline
this one colors correctly
#+END_VERSE

 #+BEGIN_SRC
* This one does not highlight correctly
hrm
 #+END_SRC
---

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, X toolkit)
 of 2019-09-27
Package: Org mode version 9.3 (9.3-elpaplus @
/home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/usr/share/emacs/26.3/lisp/org/)


org-bug-1.org
Description: Lotus Organizer

Re: Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Nicolas Goaziou]

Hello,

'Ihor Radchenko'  writes:

> I have one scheduled item like the following:
>
> * test
> <2019-12-05 Thu 23:00-29:00>
>
> This kind of item fails to be parsed by agenda because of incorrect
> treatment of 23:00-29:00 time interval

What makes you think the time interval above is correct? I would also
expect an error from that time specification.

Regards,

-- 
Nicolas Goaziou

Re: Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

[Resending without a link since your mail server classified my previous message 
as spam]

> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.

I also thought that it is incorrect (and posted a bug report since it is 
what is produced by typing 11pm+6 in org-read-date). 
However, I got a reply that 23:00-29:00 is a valid time interval
format (see "Bug: Incorrect behaviour of org-schedule when defining a
time in"). 

Best,
Ihor

Nicolas Goaziou  writes:

> Hello,
>
> 'Ihor Radchenko'  writes:
>
>> I have one scheduled item like the following:
>>
>> * test
>> <2019-12-05 Thu 23:00-29:00>
>>
>> This kind of item fails to be parsed by agenda because of incorrect
>> treatment of 23:00-29:00 time interval
>
> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.
>
> Regards,
>
> -- 
> Nicolas Goaziou

Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Andy Moreton]

On Fri 06 Dec 2019, Nicolas Goaziou wrote:

> Hello,
>
> Andy Moreton  writes:
>
>> This is still a regression.
>>
>> The old behaviour allowed display of fixed width columns, even if that
>> is wider than the content of cells in that column. This is useful for
>> display of several related tables with aligned column dividers.
>>
>> How do I get the old behaviour back, rather than the new breakage ?
>
> I will try to ignore the sarcasm, or whatever you may call it, from your
> answer.

No sarcasm intended, merely a re-statement that this change is a
regression of user visible behaviour.

> AFAICT, you still can have cells wider than their contents, e.g., try
> `C-c TAB` on the table below.
>
> | <30> |
> | foo  |

That still does not match the old behaviour though, as the table still
shows the `org-table-shrunk-column-indicator' overlay which is
undesireable.

Dynamic shrink/expand is a fine feature to add, but why was it done in a
way that broke the documented existing behaviour ?

AndyM

Re: Issues with nested begin..end blocks in inline math environments

[Matt Huszagh]

"Fraga, Eric"  writes:
> The identification of LaTeX fragments is somewhat fragile (in my
> experience).  I would suggest you enclose complex LaTeX code fragments
> within an #+begin_export latex ... #+end_export environment.
>
> Assuming your export target is LaTeX and/or PDF.

Thanks for the suggestion. Unfortunately these are mostly just used as
latex previews in the org buffer. I'm going to try to improve support
for this when I get the time since I use this capability extensively. If
you have any thoughts/suggestions on best ways to improve this I'd be
happy to hear them.

Re: Custom time stamps in column view

[Fraga, Eric]

On Sunday,  1 Dec 2019 at 19:57, Fraga, Eric wrote:
> I guess I'm making a feature request: to be able to use custom time
> display in column views.  Would this be possible?  (or, knowing me, it
> might already be possible so would somebody tell me how?)

I found some time today to explore and have managed to answer my own
question.  Unsurprisingly, org has what I need!

Using the answer given to a related question on StackExchange [1], I
came up with this simple function:

#+begin_src emacs-lisp
  (defun esf/todo-column-display-filter (column-title value)
(when (and value (not (string= value ""))
   (or (string= column-title "SCHEDULED")
   (string= column-title "DEADLINE")))
  (format-time-string "%e %b %A" (org-time-string-to-time value
  (setq-local org-columns-modify-value-for-display-function
  #'esf/todo-column-display-filter)
#+end_src

Makes my column view much easier to read for seeing my todo list!

Thank you,
eric

Footnotes:
[1]  
https://emacs.stackexchange.com/questions/54027/org-column-view-with-date-calculations

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.3-34-g2eee3c

PATCH: Re: Recurring TODO with hours not scheduled correctly

[Justin Vallon]

On 12/3/19 1:03 AM, Justin Vallon wrote:
> Newbie org-mode user.  Wondering about some odd recurrence behavior.
...
> My understanding of .+TERM is that the new scheduled time should be now
> + term.  However, from this instance and testing with other terms, it
> seems to be "current date + scheduled-time" + HOURS.  Completing again
> advances the time by one hour, leaving the date as today.
> 
> For ".+2d", the new scheduled date/time is 2d away (at the same time),
> and re-completing does not change the new schedule time.

Following up with a patch to make .+1h work "like" .+1d:

- When computing the new scheduled date, the repeater-type "." would
shift the scheduled date to today, then adjust by the interval.
Shifting the date would leave the time unchanged
- When shifting by hours, the old time would remain, and then be shifted
by the interval
- With the patch, ".+1h" will shift schedule-date to now (vs today),
then add "1h" as before.  ".+1d" will have the old behavior (shift date,
but leave time alone).
- That is:
  - ".+1d" is tomorrow at same scheduled time
  - ".+1h" is in one hour
  - ".+24h" is 24h from now.

I would argue that the old behavior is broken (".+1h" advances the
schedule time by an hour), so retaining the old behavior is not useful
(ie: no option is required).

Changes:

- org-timestamp-change: Add a 'now tag to set the current time to now
- org-auto-repeat-maybe: if interval is '.+Nh', relative time is "now"
(instead of today)

"now" might be usable when the interval is days, but I am not sure about
the difference between (org-today) and (current-time) (ie: they seem
different), so the patch only applies for intervals of hours.

Patch is relative to org 9.3.

-- 
-Justin
justinval...@gmail.com
--- org.el  2019/12/07 15:36:31 1.1
+++ org.el  2019/12/07 15:37:15
@@ -10824,9 +10824,14 @@
(repeater-type (match-string 1 ts)))
(cond
 ((equal "." repeater-type)
- ;; Shift starting date to today.
- (org-timestamp-change (- (org-today) (time-to-days time))
-   'day))
+ (cond
+  ((equal what "h")
+   ;; adjust timestamp to now
+   (org-timestamp-change 0 'now))
+  (t
+   ;; Shift starting date to today.
+   (org-timestamp-change (- (org-today) (time-to-days 
time))
+ 'day
 ((equal "+" repeater-type)
  (let ((nshiftmax 10)
(nshift 0))
@@ -15349,6 +15354,8 @@
  (setcar (nthcdr 1 time0) (or (nth 1 time0) 0))
  (setcar (nthcdr 2 time0) (or (nth 2 time0) 0))
  (setq time (apply 'encode-time time0
+  (when (eq what 'now)
+   (setq time (current-time)))
   ;; Insert the new time-stamp, and ensure point stays in the same
   ;; category as before (i.e. not after the last position in that
   ;; category).

Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Nicolas Goaziou]

Hello,

Andy Moreton  writes:

> That still does not match the old behaviour though, as the table still
> shows the `org-table-shrunk-column-indicator' overlay which is
> undesireable.

Why is it undesirable?

> Dynamic shrink/expand is a fine feature to add, but why was it done in a
> way that broke the documented existing behaviour ?

I think the current state is better. However, I initially explained the
motivation behind this change (see links in this thread).

Feel free to suggest, and possibly implement, if users agree, a better
way. Or, please point where the documented behaviour does not match the
current state.

Regards,

-- 
Nicolas Goaziou

Re: Bug: Agenda fails to parse time interval like 23:00-29:00 [9.1.9 (release_9.1.9-65-g5e4542 @ /home/yantar92/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.

I also thought that it is incorrect (and posted a bug report since it is 
what is produced by typing 11pm+6 in org-read-date). 
However, I got a reply that 23:00-29:00 is a valid time interval
format [1].

Best,
Ihor

[1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00039.html 


Nicolas Goaziou  writes:

> Hello,
>
> 'Ihor Radchenko'  writes:
>
>> I have one scheduled item like the following:
>>
>> * test
>> <2019-12-05 Thu 23:00-29:00>
>>
>> This kind of item fails to be parsed by agenda because of incorrect
>> treatment of 23:00-29:00 time interval
>
> What makes you think the time interval above is correct? I would also
> expect an error from that time specification.
>
> Regards,
>
> -- 
> Nicolas Goaziou

Re: Displaying remote images

[Jack Kamm]

After test-driving this patch for a bit, the main issue I foresee is
that this can potentially hang Emacs if loading a lot of images over a
slow SSH connection. This was also discussed in the previous thread from
2014.

I plan to mitigate this with an option to enable/disable/cache the
remote images. For the cache'ing, visiting the remote files in their own
Emacs buffers seems to work pretty well.

I'm in the process of updating my copyright papers for my current
employer, and will send an updated patch when I've got that sorted out.

--Jack

Re: Include lines in setupfile are not evaluated: bug or feature?

[Nicolas Goaziou]

Jarmo Hurri  writes:

> Greetings.
>
> I am (still) trying to figure out a SINGLE common setup/include file for
> all settings for a large batch of files.
>
> I found out recently that common #properties can be set in a setup file
> (but not in an included file). However, now it seems that in a setup
> file I can not include all common included files. Is this intended
> behaviour?
>
> Below is an example that demonstrates this. First the main (exported
> file):
>
> # --- file main-file.org 
>
> #+setupfile: setup-file.org
>
> src_elisp[:exports results :results raw]{(org-entry-get nil "MY_PROPERTY" t)}
> # ---
>
> Then the setup file:
>
> # -- file setup-file.org 
>
> #+property: MY_PROPERTY true
> #+include: setup-included.org
>
> # ---
>
> Then the file that is supposed to be included in the setup file (and,
> consequently, in the main file):
>
> # -- file setup-included.org 
> Some text to be included.
> # ---
>
> But the text is not included in the main file. Documentation of
> #setupfile says that
>
> "Org parses the contents of this document as if it was included in the
> buffer."
>
> https://orgmode.org/manual/In_002dbuffer-settings.html
>
> But that does not seem to be the case.

SETUPFILE and INCLUDE are orthogonal. There is no point in mixing them.

SETUPFILE keyword recursively loads configuration from other files,
without inserting anything. INCLUDE keyword recursively inserts contents
from other files in the current document, but there is no guarantee that
configuration from these files will be inherited.

As a rule of thumb, if you want to access to metadata (i.e., keywords),
use SETUPFILE, if you are interested in contents, use INCLUDE. Note that
you can have both for a single file.

Regards,

-- 
Nicolas Goaziou

Re: 'org-dynamic-block-define' is a void-function?

[Nicolas Goaziou]

Hello,

Sharon Kimble  writes:

> On loading the most recent version of org-mode (yesterdays, being
> 2019-12-03) I am consistently getting this occurring in debugger.
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (void-function org-dynamic-block-define)
>   (org-dynamic-block-define "clocktable" (quote org-clock-report))

This looks like a FrankenOrg. Your installation is suspicious. I don't
know what is "paradox", but you may want to check if all loaded
libraries are correct (e.g., by looking at `load-path').

Regards,

-- 
Nicolas Goaziou

Re: Include lines in setupfile are not evaluated: bug or feature?

[Jarmo Hurri]

Hello Nicolas!

Nicolas Goaziou  writes:

> SETUPFILE and INCLUDE are orthogonal. There is no point in mixing
> them.

Ok. As a programmer I was hoping to mix them, because it would be
logical to have _one_ header file that defines all the common things for
a set of related files.

But perhaps I can get away with using SETUPFILEs only. I will see.

> Jarmo Hurri  writes:
>> Documentation of #setupfile says that
>>
>> "Org parses the contents of this document as if it was included in the
>> buffer."
>>
>> https://orgmode.org/manual/In_002dbuffer-settings.html
>>
>> But that does not seem to be the case.
>
> SETUPFILE keyword recursively loads configuration from other files,
> without inserting anything. INCLUDE keyword recursively inserts
> contents from other files in the current document, but there is no
> guarantee that configuration from these files will be inherited.

Do I understand correctly: the description in the documentation is not
correct in the sense that not all contents from SETUPFILE is evaluated
as if it were included in the buffer?

I am just trying to think about how this limitation, if it exists,
should be expressed in documentation. Shall I give it a try?

Thanks for the clarifying response!

Jarmo

Re: Issues with nested begin..end blocks in inline math environments

[Matt Huszagh]

"Fraga, Eric"  writes:
> The identification of LaTeX fragments is somewhat fragile (in my
> experience).  I would suggest you enclose complex LaTeX code fragments
> within an #+begin_export latex ... #+end_export environment.
>
> Assuming your export target is LaTeX and/or PDF.

Changing the beginning and end regexes to the following seems to work
well (I've just added a non-capturing group for \(\) or $$ so that
begin-end blocks can be nested inside inline math environments).

(setq org-element--latex-begin-environment "^[ 
\t]*\\(?:(\\|\\$\\)?begin{\\([A-Za-z0-9*]+\\)}")
(setq org-element--latex-end-environment "end{%s}[ 
\t]*\\(?:)\\|\\$\\)?$")

I'm going to test this a bit before submitting it as a patch to make
sure it doesn't cause any issues. If you have any tricky fragments you
want to test it on please let me how it works!

#+INCLUDE causes error when it attmepts to expand a LaTeX macro in source block

[Charles Millar]

Greetings,

In my init file I have

(setq org-confirm-babel-evaluate nil)

File "A" is attached as an org file. I evaluate the source blocks (C-c 
C-v s), the table is generated and then I export it to PDF. The source 
blocks do not evaluate during export.


In file B I have

#+INCLUDE: "/path/to/FileA::*SCHEDULE A1112"

When I attempt to export File B to PDF/LaTeX the following error occurs

Debugger entered--Lisp error: (error "Undefined Org macro: cmhfill; 
aborting")

  signal(error ("Undefined Org macro: cmhfill; aborting"))
  error("Undefined Org macro: %s; aborting" "cmhfill")

If I place a "#+HEADER: :eval no" in the source blocks in File A (after 
generating the table) File B will export the table to PDF. Also, please 
note that the cmhfill macro is in the table headings.


Is this an error, i.e. the #+INCLUDE does not honor the setting in my 
init file?


Is there a header or property setting for File B to prevent the exporter 
from evaluating the source blocks when executing through an #+INCLUDE, 
more particularly to prevent the attempted macro expansion within the 
source blocks?


Both File A and File B had identical LaTeX settings, i.e. the macro was 
defined in both files.


GNU Emacs 27.0.50 (build 8, x86_64-pc-linux-gnu, GTK+ Version 3.24.13) 
of 2019-12-07


Org mode version 9.3 (release_9.3-36-gbe7434 @ 
/usr/local/share/org-mode/lisp/)


Charlie Millar
* SCHEDULE A1112
#+NAME: SCHEDAP
#+begin_src rec :data somefile.rec :type Finance :fields 
AccountDate,Shares,Description,AccountAmount :sort AccountDate,Description 
:results silent
 (File = 'Estate' && AccountSchedule = 'A')
#+end_src
#+RESULTS: SCHEDAP
#+NAME: SCHEDA
#+begin_src emacs-lisp :var table=SCHEDAP :exports results
  (setq table (cons 'hline table))
  (setq table (cons '("Date" "{{{cmhfill}}} Shares" " Description " 
"{{{cmhfill}}} Inventory{{{cm1space}}}Value") table))
  (setq table (append table '(("| |Total Schedule A"
  (setq table (append table '(("\n#+TBLFM: @>$>=vsum(@I$>..@>>$>);%.2f::"
  table
#+end_src
#+ATTR_LATEX: :mode table :environment longtable :align  
p{60pt}N{5}{3}p{275pt}N{8}{2}
#+RESULTS: SCHEDA
| Date   | {{{cmhfill}}} Shares | Description  | {{{cmhfill}}} 
Inventory{{{cm1space}}}Value |
|+--+--+|
| 2018-03-18 |  | Something|
   49645.59 |
| etc|  | etc  |
4878.51 |
||  | Total Schedule A |
   54524.10 |
#+TBLFM: @>$>=vsum(@I$>..@>>$>);%.2f:: |

filling every item in a list

[Samuel Wales]

sometimes i will get long lines pasted in from someplace.
all in a long set of lines
like this
except with longer lines

then i make it into a list.

but i want each item of the list to be filled.

so i make a region and fill and the items do not get filled.

sometimes filladapt works, but not always.

is this a problem anybody has?  due to a bug i can't upgrade from
9.1.14 so i'm hoping maybe it;s been addressed.

thanks.

bug logging the TODO tracking state with brackets in the header

[pinmacs]

Hi,

I reached a strange bug, I hope you can reproduce it too

I want to track changes on TODO and I have in the beginning of my buffer:

#+TODO: TODO(t!) PLANNED(p!) DOING(d!) VERIFY(v) EXPLAIN(e) | DONE(d!)

which means that TODO, PLANEED, DOING and DONE will have a report of
change in the same header [0]

If I have the number of TODOs like [6/45] (6 DONE, 45 in TODO) is not
working (see [1] for my example)

If I quit that expression, it works, that could be the case when I do a
subheader from a header without that brackets [2]

I hope this example is illustrative [1].

The header that says "this fails" if I change the state, it reports
tracking state in the parent header with wrong information "state TODO
from TODO". It fails because the parent has the bracket thing. If the
parent of the parent has bracket thing it reports to "the parent of the
parent", so it is weird :/

The header that says "this works" changes from states correctly because
parent does not have the brackets

I hope you can reproduce the bug on your own

I'm using orgmode version 9.3

let me if I can help with the bug reporting

Cheers,
pinmacs

[0]
https://www.gnu.org/software/emacs/manual/html_node/org/Tracking-TODO-state-changes.html

[1]

*** TODO <2019-12-07 Sat>  [6/45]
:today:
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:58]
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:58]
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:57]
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:57]
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:57]
- State "TODO"   from "TODO"   [2019-12-07 Sat 22:57]
 DONE this fails
* DONE this works OK
- State "DONE"   from "EXPLAIN"    [2019-12-07 Sat 22:58]
- State "DOING"  from "PLANNED"    [2019-12-07 Sat 22:58]
- State "PLANNED"    from "TODO"   [2019-12-07 Sat 22:58]
- State "TODO"   from  [2019-12-07 Sat 22:58]

[2]

as you can see in the following 2 links:

- https://orgmode.org/manual/Breaking-down-tasks.html#Breaking-down-tasks
- https://orgmode.org/manual/Checkboxes.html#Checkboxes

Re: Bug: Org 9.3 table columnwidth directive not working [9.3 (release_9.3 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]

[Andy Moreton]

On Sat 07 Dec 2019, Nicolas Goaziou wrote:

> Hello,
>
> Andy Moreton  writes:
>
>> That still does not match the old behaviour though, as the table still
>> shows the `org-table-shrunk-column-indicator' overlay which is
>> undesireable.
>
> Why is it undesirable?

It also always shows the shrink/expend overlay, even if that is not
desired. I find it visually intrusive, and the extra character
introduces a new misalignment.

>> Dynamic shrink/expand is a fine feature to add, but why was it done in a
>> way that broke the documented existing behaviour ?
>
> I think the current state is better. However, I initially explained the
> motivation behind this change (see links in this thread).

While everyone has their own preferences, developers should not impose
their preferences on users, who may decide to make different choices.

The dynamic shrink feature added a new capability that many will find
useful, but it also removed the ability to do things the older and
simpler way. It should have been added as an option, so either static
or dynamic behaviour can be selected by the user.

AndyM

Re: Bug: headlines escape blocks [9.3 (9.3-elpaplus @ /home/tom/.emacs.d/elpa/org-plus-contrib-20191203/)]

[Tom Gillespie]

Hi Nicolas,
Thanks for the reply and pointer to the docs. Given that the
headlines are working as expected, is there the possibility to
change how the syntax highlighting for source and example
blocks works so that it matches the behavior for the verse blocks?
Best,
Tom


On Sat, Dec 7, 2019 at 3:12 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Tom Gillespie  writes:
>
> > * Description
> > Headlines are not ignored inside of blocks when the headline is not 
> > indented.
> >
> > * Affected versions
> > 9.1.9, 9.3
> >
> > * Observed behavior
> > Lines starting with any headline pattern =*=, =**= etc. are treated as
> > headlines inside all block types. Example and source blocks highlight
> > as if the text is escaped, diverging from the behavior of org-mode.
> > Verse blocks highlight as a headline, in agreement with the behavior.
>
> This is the expected behaviour. See (info "(org) Literal Examples")
>
> Regards,
>
> --
> Nicolas Goaziou