Re: [O] "header-args :eval inline-only" not working

[Vikas Rawal]

>> 
>> I don’t see org-export-use-babel in available options. I cannot customise it.
>> 
>> '(org-export-use-babel (quote inline-only))
>> 
>> Seems to have no effect. Is that so because, as you say later, users are not 
>> supposed to touch this option?
> 
> No.  You must have an older version of org than
> 
> commit 3b5ce449c4b16291ad56e23d5be1e480e57d906f
> Author: Charles Berry >
> Date:   Sat Nov 12 18:54:20 2016 -0800
> 
>Replace `org-export-babel-evaluate' with `org-export-use-babel'
> 
> Did you try `C-h v org-export-use-babel RET', click `customize', etc?

I am on the latest version on org mode ELPA. It is dated August 18, 2017, so 
should include the commit you mention.

> C-h v org-export-use-babel RET’

Does not work (there is no such variable).

> Try
> 
> #+PROPERTY: header-args :eval never-export
> 
> and don't forget C-c C-c to update when you add this.

But this would prevent exporting all code blocks including inline blocks.

Isn’t it?

There seems no way of separately controlling inline and other blocks.

I guess I have to live with that.

Vikas

Re: [O] make compile fails

[Adam Porter]

Jarmo Hurri  writes:

> Running 'make cleanall' didn't help.
>
> However, a fresh clone followed by a reconfiguration of local.mk solved
> the issue. Most likely the result of a local.mk that is no longer
> consistent.

Just FYI, you can avoid having to re-clone the repo by running

git reset --hard && git clean -dfx

which resets the working tree completely and deletes all files that are
unknown to git.  Of course, you should probably add `--dry-run` first,
to make sure you don't delete anything you want.

Re: [O] [PATCH] org-agenda: Add 'none setting for org-agenda-overriding-header

[Adam Porter]

Nicolas Goaziou  writes:

> Let's adjust the patch, then. Thank you!

Hi Nicolas,

Here is the new patch.  I took the liberty of using a macro to replace
the code that was duplicated in the four agenda functions.  Please let
me know if you would like any further changes.

Thanks,
Adam>From 203bc583da0c482ab7092623383fe47c2d729420 Mon Sep 17 00:00:00 2001
From: Adam Porter 
Date: Sat, 19 Aug 2017 21:26:12 -0500
Subject: [PATCH] org-agenda: Refactor org-agenda-overriding-header code

Replace org-agenda-overriding-header tests in these four functions with
calls to a macro, eliminating the duplicate code.  Also, disable the
header when the variable is set to the empty string.

* lisp/org-agenda.el (org-agenda--insert-overriding-header): Add macro.
(org-agenda-list): Use macro.
(org-search-view): Use macro.
(org-todo-list): Use macro.
(org-tags-view): Use macro.
(org-agenda-overriding-header): Update docstring.

* etc/ORG-NEWS: Explain that header can be disabled with empty string.
---
 etc/ORG-NEWS   |   4 ++
 lisp/org-agenda.el | 153 +
 2 files changed, 89 insertions(+), 68 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 1901c29..e55d1e4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -135,6 +135,10 @@ See docstring for details.
 =org-agenda-tags-column= can now be set to =auto=, which will
 automatically align tags to the right edge of the window.  This is now
 the default setting.
+ Disable =org-agenda-overriding-header= by setting to empty string
+
+The =org-agenda-overriding-header= inserted into agenda views can now be
+disabled by setting it to an empty string.
 
 *** New value for ~org-publish-sitemap-sort-folders~
 
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index fe7c4f2..940bf7b 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -2065,6 +2065,22 @@ works you probably want to add it to `org-agenda-custom-commands' for good."
 	(setcdr ass (cdr entry))
   (push entry org-agenda-custom-commands
 
+(cl-defmacro org-agenda--insert-overriding-header ( default)
+  "Insert header into agenda view depending on value of `org-agenda-overriding-header'.
+If the empty string, don't insert a header.  If any other string,
+insert it as a header.  If nil, insert DEFAULT, which should
+evaluate to a string."
+  (declare (debug ( form)))
+  `(pcase org-agenda-overriding-header
+ ("" nil)  ; Don't insert a header if set to empty string
+ ;; Insert user-specified string
+ ((pred stringp) (insert
+		  (org-add-props (copy-sequence org-agenda-overriding-header)
+			  nil 'face 'org-agenda-structure)
+		  "\n"))
+ ;; When nil, make string automatically and insert it
+ ((pred null) (insert ,default
+
 ;;; Define the org-agenda-mode
 
 (defvar org-agenda-mode-map (make-sparse-keymap)
@@ -4160,17 +4176,15 @@ items if they have an hour specification like [h]h:mm."
 	   (w1 (org-days-to-iso-week d1))
 	   (w2 (org-days-to-iso-week d2)))
 	  (setq s (point))
-	  (if org-agenda-overriding-header
-	  (insert (org-add-props (copy-sequence org-agenda-overriding-header)
-			  nil 'face 'org-agenda-structure) "\n")
-	(insert (org-agenda-span-name span)
-		"-agenda"
-		(if (< (- d2 d1) 350)
-			(if (= w1 w2)
-			(format " (W%02d)" w1)
-			  (format " (W%02d-W%02d)" w1 w2))
-		  "")
-		":\n")))
+	  (org-agenda--insert-overriding-header
+	   :default (concat (org-agenda-span-name span)
+			"-agenda"
+			(if (< (- d2 d1) 350)
+(if (= w1 w2)
+(format " (W%02d)" w1)
+  (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))
@@ -4581,25 +4595,25 @@ in `org-agenda-text-search-extra-files'."
 			(goto-char (1- end))
 	(setq rtn (nreverse ee))
 	(setq rtnall (append rtnall rtn)))
-  (if org-agenda-overriding-header
-	  (insert (org-add-props (copy-sequence org-agenda-overriding-header)
-		  nil 'face 'org-agenda-structure) "\n")
-	(insert "Search words: ")
-	(add-text-properties (point-min) (1- (point))
-			 (list 'face 'org-agenda-structure))
-	(setq pos (point))
-	(insert string "\n")
-	(add-text-properties pos (1- (point)) (list 'face 'org-warning))
-	(setq pos (point))
-	(unless org-agenda-multi
-	  (insert (substitute-command-keys "\
+  (org-agenda--insert-overriding-header
+   :default (with-temp-buffer
+		  (insert "Search words: ")
+		  (add-text-properties (point-min) (1- (point))
+   (list 'face 'org-agenda-structure))
+		  (setq pos (point))
+		  (insert string "\n")
+		  (add-text-properties pos (1- (point)) (list 'face 'org-warning))
+		  (setq pos (point))
+		  (unless org-agenda-multi
+		(insert (substitute-command-keys "\
 Press `\\[org-agenda-manipulate-query-add]', \
 `\\[org-agenda-manipulate-query-subtract]' to 

Re: [O] "header-args :eval inline-only" not working

[Berry, Charles]

> On Aug 19, 2017, at 7:24 PM, Vikas Rawal  
> wrote:
> 
> 
>> 
>> There is a bug in the documentation  -- `org-export-babel-evaluate' is 
>> obsolete. It should say `org-export-use-babel’.
> 
> I don’t see org-export-use-babel in available options. I cannot customise it.
> 
> '(org-export-use-babel (quote inline-only))
> 
> Seems to have no effect. Is that so because, as you say later, users are not 
> supposed to touch this option?

No.  You must have an older version of org than

commit 3b5ce449c4b16291ad56e23d5be1e480e57d906f
Author: Charles Berry 
Date:   Sat Nov 12 18:54:20 2016 -0800

Replace `org-export-babel-evaluate' with `org-export-use-babel'

Did you try `C-h v org-export-use-babel RET', click `customize', etc?

> 
>> But that part of the manual is irrelevant to what the `:eval' header does.  
>> There is no `inline-only' value in either the documentation or in the lisp 
>> code.  So, `inline-only' acts like `yes' for the reason I stated earlier.
>> 
>> 
>>> With current org, I get this behaviour only if I globally set the option. 
>>> But that somehow disables ":results”.
>>> 
>> 
>> Right. `:results' is a babel header.  When babel is off, the babel headers 
>> are not acted upon.
>> 
>> Setting `org-export-use-babel' to `nil' or `inline-only' turns off babel for 
>> src blocks.
>> 
>> 
>> The behavior was purposely changed. With `inline-only' none of the babel 
>> operations will be executed for src blocks  -- i.e. the src blocks and 
>> existing results (if any) will be exported as is.  
>> 
>> Users should avoid touching `org-export-use-babel' for almost all purposes.  
>> It does not do the equivalent of setting `:eval' globally.
>> 
> 
> 
> I just saw this thread: 
> https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00443.html
> 
> I certainly feel that the current behaviour is a regression. The user should 
> have the possibility of controlling globally or buffer-wide whether the 
> source codes are evaluated at the time of export or not. org-export-use-babel 
> does not do that. It turns off babel completely, exporting codes and existing 
> results as is.
> 

Try

#+PROPERTY: header-args :eval never-export

and don't forget C-c C-c to update when you add this.

> This is clearly a regression as far as my use case is concerned.
> 

It seems like `:eval never-export' set globally handles the uses most folks had 
for the old behavior, and I think a bug was fixed by Nicolas in changing it, so 
reverting is probably not going to happen.

Chuck

Re: [O] "header-args :eval inline-only" not working

[Vikas Rawal]

> 
> There is a bug in the documentation  -- `org-export-babel-evaluate' is 
> obsolete. It should say `org-export-use-babel’.

I don’t see org-export-use-babel in available options. I cannot customise it.

'(org-export-use-babel (quote inline-only))

Seems to have no effect. Is that so because, as you say later, users are not 
supposed to touch this option?

> But that part of the manual is irrelevant to what the `:eval' header does.  
> There is no `inline-only' value in either the documentation or in the lisp 
> code.  So, `inline-only' acts like `yes' for the reason I stated earlier.
> 
> 
>> With current org, I get this behaviour only if I globally set the option. 
>> But that somehow disables ":results”.
>> 
> 
> Right. `:results' is a babel header.  When babel is off, the babel headers 
> are not acted upon.
> 
> Setting `org-export-use-babel' to `nil' or `inline-only' turns off babel for 
> src blocks.
> 
> 
> The behavior was purposely changed. With `inline-only' none of the babel 
> operations will be executed for src blocks  -- i.e. the src blocks and 
> existing results (if any) will be exported as is.  
> 
> Users should avoid touching `org-export-use-babel' for almost all purposes.  
> It does not do the equivalent of setting `:eval' globally.
> 


I just saw this thread: 
https://lists.gnu.org/archive/html/emacs-orgmode/2017-02/msg00443.html 


I certainly feel that the current behaviour is a regression. The user should 
have the possibility of controlling globally or buffer-wide whether the source 
codes are evaluated at the time of export or not. org-export-use-babel does not 
do that. It turns off babel completely, exporting codes and existing results as 
is.

This is clearly a regression as far as my use case is concerned.

Vikas

Re: [O] "header-args :eval inline-only" not working

[Berry, Charles]

> On Aug 19, 2017, at 6:10 PM, Vikas Rawal  
> wrote:
> 
>> 
>> 
>> The first problem is that you have babel code *inside* a macro.  Since 
>> macros are run after babel executes, nothing will happen.
> 
> From the manual: "Org expands macros at the very beginning of the export 
> process.”
> 
> These macros run fine if I allow code evaluation. Macro replacement happens 
> first, and then the code evaluation. That is not the problem.

You are correct. Sorry.


> 
>> 
>> Next, there is no `:eval inline-only'.  That seem to work only because only 
>> the negative cases are checked. i.e. it is the same as `:eval yes' or even  
>> `:eval yes-please-and-thank-you’.
> 
> Again, from the manual:

> 
> "To evaluate just the inline code blocks, set org-export-babel-evaluate to 
> inline-only. Isolating the option to allow inline evaluations separate from 
> ‘src’ code block evaluations during exports is not for security but for 
> avoiding any delays due to recalculations, such as calls to a remote 
> database.”
> 

There is a bug in the documentation  -- `org-export-babel-evaluate' is 
obsolete. It should say `org-export-use-babel'.  

But that part of the manual is irrelevant to what the `:eval' header does.  
There is no `inline-only' value in either the documentation or in the lisp 
code.  So, `inline-only' acts like `yes' for the reason I stated earlier.


> With current org, I get this behaviour only if I globally set the option. But 
> that somehow disables ":results”.
> 

Right. `:results' is a babel header.  When babel is off, the babel headers are 
not acted upon.

Setting `org-export-use-babel' to `nil' or `inline-only' turns off babel for 
src blocks.


> With older org, everything works as it should.

Older than this:

---
commit ec615b192d703a0201ceefd46897e4636ff00a38
Author: Nicolas Goaziou 
Date:   Thu Apr 28 17:25:31 2016 +0200

Fix `org-export-babel-evaluate' handling 
---


The behavior was purposely changed. With `inline-only' none of the babel 
operations will be executed for src blocks  -- i.e. the src blocks and existing 
results (if any) will be exported as is.  

Users should avoid touching `org-export-use-babel' for almost all purposes.  It 
does not do the equivalent of setting `:eval' globally.

Chuck 

Re: [O] "header-args :eval inline-only" not working

[Vikas Rawal]

> 
> 
> The first problem is that you have babel code *inside* a macro.  Since macros 
> are run after babel executes, nothing will happen.

From the manual: "Org expands macros at the very beginning of the export 
process.”

These macros run fine if I allow code evaluation. Macro replacement happens 
first, and then the code evaluation. That is not the problem.

> 
> Next, there is no `:eval inline-only'.  That seem to work only because only 
> the negative cases are checked. i.e. it is the same as `:eval yes' or even  
> `:eval yes-please-and-thank-you’.

Again, from the manual:

"To evaluate just the inline code blocks, set org-export-babel-evaluate to 
inline-only. Isolating the option to allow inline evaluations separate from 
‘src’ code block evaluations during exports is not for security but for 
avoiding any delays due to recalculations, such as calls to a remote database.”

With current org, I get this behaviour only if I globally set the option. But 
that somehow disables ":results”.

With older org, everything works as it should.

Vikas

Re: [O] make compile fails

[Adrian Bradd]

Looks like htmlize was removed from contrib a few days ago
(commit d0ced9894) which is probably the cause of your issue. You can get
it from https://github.com/hniksic/emacs-htmlize

You can generate a new local.mk by running 'make local.mk'. You may have to
remove or rename the existing local.mk for this to work.

On 19 August 2017 at 04:30, Jarmo Hurri  wrote:

> Colin Baxter  writes:
>
> > > 
> 
> > > jarmo@localhost org-mode]$ diff local.mk local.mk~ 31c31 <
> > > ORG_ADD_CONTRIB = htmlize ---
> > >> #ORG_ADD_CONTRIB = ox-* # e.g. the contributed exporter
> > > 
> 
> >
> > > Maybe the issue is somehow related to this? Anyway, I was still
> > > able to compile on August 11th, so something has changed since
> > > then.
> >
> > I don't know of any issues surrounding local.mk. All I can suggest is
> > that you try a 'make distclean' first. Failing that, why not just
> > delete (or rename) your org-mode git directory and git clone a fresh
> > source? That way, you'd be certain you don't have any old "corrupting"
> > files in your git tree.
>
> Running 'make cleanall' didn't help.
>
> However, a fresh clone followed by a reconfiguration of local.mk solved
> the issue. Most likely the result of a local.mk that is no longer
> consistent.
>
> Up and running again. Thanks!
>
> Jarmo
>
>
>

Re: [O] [Feature request] LaTeX blocks preview

[edgar]

On 2017-08-19 08:57, Nicolas Goaziou wrote:

It is not possible in the general case. The export block is not
guaranteed to contain a complete environment; it isn't necessarily
displayable either.


Thank you for your kind attention, anyway :) .


I think this is an acceptable workaround. I think AucTeX has its own
previewing mechanism, so step 2 may not be required.


I think that is the sole purpose of org-edit-latex-mode. It seems that 
AucTeX does not work in the org-edit-special buffer. Thanks again.


-

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Re: [O] named anchors in HTML export

[Adam Spiers]

On 19 August 2017 at 09:50, Nicolas Goaziou  wrote:
> Adam Spiers  writes:
>> I was also expecting to be able to use #+NAME: foo in front of a
>> headline
>
> You cannot use a NAME keyword to a headline (or an inlinetask).
> CUSTOM_ID is morally equivalent, though.
>
>> or even other elements like paragraphs, but this doesn't
>> work. Is this a bug, or am I misreading the manual?
>
> Currently, "ox-html" doesn't create an anchor for named paragraphs,
> unless the paragraph consists of an image only.
>
> However, you can put targets anywhere in a paragraph using <>
> syntax.
>
>>  Is there any way of creating an anchor for an arbitrary element,
>> short of some ugly "+HTML" hack?
>
> Note that internal references are... internal. You can use them across
> documents only when using Org publishing mechanism. IOW, <>
> doesn't create  anchor, but something like  id="org1234567">.

Thanks Nicolas, that's super helpful!

Re: [O] TIMEZONE property for ical export

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> Subject: [PATCH 2/2] Inherit TIMEZONE and LOCATION properties in iCalendar
>  export
>
> * lisp/ox-icalendar.el (org-icalendar-entry): Both properties now
>   optionally inherit, depending on value of
>   `org-use-property-inheritance'.
> * doc/org.texi: Mention change.

Applied.

> Subject: [PATCH 1/2] Add per-entry timezone support for icalendar export
>
> * lisp/ox-icalendar.el (org-icalendar-entry): Look for an
>   "ICALENDAR_TZ" property.
>   (org-icalendar--vevent, org-icalendar--vtodo): Accept additional
>   timezone argument.
>   (org-icalendar-convert-timestamp): Change
>   paramenter name to "tz", and accept a wider variety of values.
> * doc/org.texi: Mention in manual.

Applied.

Thank you!

Regards,

Re: [O] "header-args :eval inline-only" not working

[Berry, Charles]

> On Aug 19, 2017, at 1:36 PM, Vikas Rawal  
> wrote:
> 
> 
>> On 20-Aug-2017, at 12:57 AM, Nicolas Goaziou  wrote:
>> 
>> Hello,
>> 
>> Vikas Rawal  writes:
>> 
>>> My org-version (latest on org ELPA) is: Org mode version 9.0.9 
>>> (9.0.9-82-gb862c2-elpa @ /Users/vikas/.emacs.d/elpa/org-20170814/)
>>> 
>>> The following is not working: 
>>> 
>>> #+PROPERTY: header-args :eval inline-only
>>> 
>>> ":eval never-export” works; but ":eval inline-only" does not.
>> 
>> What is "not working”?
> 
> ":eval inline-only" has no effect. It still tries to evaluate all code blocks.
> 
> 
>>> I can deal with this by globally changing the option using:
>>> 
>>> (org-export-babel-evaluate (quote inline-only))
>>> 
>>> But this creates another problem. After this, org does not respect 
>>> “:exports results” and exports both the code and results.
>> 
>> Could you provide an ECM?
> 
> Please see the attached file.

Which contains:

#+PROPERTY: header-args :session nss70 :eval inline-only
#+macro: getcell src_emacs-lisp[:results value raw]{(org-table-get-remote-range 
"$1" "$2")}
#+macro: roundnum src_emacs-lisp[:results value raw]{(round (string-to-number 
(org-table-get-remote-range "$1" "$2")))}


> 
> When I export this, it still tries to evaluate the code block 
> ind1_t2_hhd_code. If I use (org-export-babel-evaluate (quote inline-only)), 
> it does not evaluate  ind1_t2_hhd_code code block but it exports both the 
> code and the output.
> 



The first problem is that you have babel code *inside* a macro.  Since macros 
are run after babel executes, nothing will happen.

Next, there is no `:eval inline-only'.  That seem to work only because only the 
negative cases are checked. i.e. it is the same as `:eval yes' or even  `:eval 
yes-please-and-thank-you'.

Instead of a macro containing babel, you can use `call_whatnot(a,b)' statements 
for inline execution, where a src block named `whatnot' handles the desired 
computations.  You can execute these in advance of exporting and specify `:eval 
never-export'.

HTH,

Chuck

p.s. I did not see a bug.  

Re: [O] TIMEZONE property for ical export

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Eric Abrahamsen  writes:
>
>> It's a little strange, because the manual section for this specifically
>> mentions the inheritance of the LOCATION property, but the code doesn't
>> do it. Shall I add it in? It makes sense for LOCATION and TIMEZONE to be
>> inheritable, but not SUMMARY and DESCRIPTION, of course.
>>
>> If I add inheritance, that will look like this, right?
>>
>> (tz (org-export-get-node-property :LOCATION entry
>>   (org-property-inherit-p :LOCATION)))
>
> It should be:
>
>   (org-property-inherit-p "LOCATION")
>
>> That could also be a separate, second commit.
>
> I think that would be better.
>
>> I've added an ORG-NEWS entry. The patch in my last message was done with
>> git format-patch, isn't that commit message okay?
>
> It is. I just need to read better.

Okay, hopefully this is it!

Eric

>From edecd8c97961b759c3aa608d6e05daeb09989c3d Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sat, 19 Aug 2017 14:51:44 -0700
Subject: [PATCH 2/2] Inherit TIMEZONE and LOCATION properties in iCalendar
 export

* lisp/ox-icalendar.el (org-icalendar-entry): Both properties now
  optionally inherit, depending on value of
  `org-use-property-inheritance'.
* doc/org.texi: Mention change.
* etc/ORG-NEWS: Mention change.
---
 doc/org.texi | 2 +-
 etc/ORG-NEWS | 3 +++
 lisp/ox-icalendar.el | 8 ++--
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index d8a8a8e81..8bb6fa7f4 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14162,7 +14162,7 @@ and write it to @code{org-icalendar-combined-agenda-file} file name.
 @cindex property, TIMEZONE
 The iCalendar export back-end includes SUMMARY, DESCRIPTION, LOCATION and
 TIMEZONE properties from the Org entries when exporting.  To force the
-back-end to inherit the LOCATION property, configure the
+back-end to inherit the LOCATION and TIMEZONE properties, configure the
 @code{org-use-property-inheritance} variable.
 
 When Org entries do not have SUMMARY, DESCRIPTION and LOCATION properties,
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index f53a70837..cf7502ace 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -99,6 +99,9 @@ Use "/!" markup when filtering TODO keywords to get only not-done TODO
 keywords.
 
 ** New features
+*** iCalendar export uses inheritance for TIMEZONE and LOCATION properties
+Both these properties can be inherited during iCalendar export,
+depending on the value of ~org-use-property-inheritance~.
 *** iCalendar export respects a TIMEZONE property
 Set the TIMEZONE property on an entry to specify a time zone for that
 entry only during iCalendar export.  The property value should be
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index d445c7b8d..b27c30c31 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -537,7 +537,9 @@ inlinetask within the section."
 			   (org-export-data
 			(org-element-property :title entry) info
 	 (loc (org-icalendar-cleanup-string
-		   (org-element-property :LOCATION entry)))
+		   (org-export-get-node-property
+		:LOCATION entry
+		(org-property-inherit-p "LOCATION"
 	 ;; Build description of the entry from associated section
 	 ;; (headline) or contents (inlinetask).
 	 (desc
@@ -553,7 +555,9 @@ inlinetask within the section."
 	  org-icalendar-include-body
 		  (org-icalendar-include-body (org-trim contents)))
 	 (cat (org-icalendar-get-categories entry info))
-	 (tz (org-element-property :TIMEZONE entry)))
+	 (tz (org-export-get-node-property
+		  :TIMEZONE entry
+		  (org-property-inherit-p "TIMEZONE"
 	 (concat
 	  ;; Events: Delegate to `org-icalendar--vevent' to generate
 	  ;; "VEVENT" component from scheduled, deadline, or any
-- 
2.14.1

>From d237d0460eb504fc560459b9039b57a70677b90b Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sat, 19 Aug 2017 10:09:00 -0700
Subject: [PATCH 1/2] Add per-entry timezone support for icalendar export

* lisp/ox-icalendar.el (org-icalendar-entry): Look for an
  "ICALENDAR_TZ" property.
  (org-icalendar--vevent, org-icalendar--vtodo): Accept additional
  timezone argument.
  (org-icalendar-convert-timestamp): Change
  paramenter name to "tz", and accept a wider variety of values.
* doc/org.texi: Mention in manual.
* etc/ORG-NEWS: Mention in NEWS.
---
 doc/org.texi | 13 ++---
 etc/ORG-NEWS |  5 -
 lisp/ox-icalendar.el | 44 +++-
 3 files changed, 41 insertions(+), 21 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 032087fc2..d8a8a8e81 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14159,9 +14159,10 @@ and write it to @code{org-icalendar-combined-agenda-file} file name.
 @cindex property, SUMMARY
 @cindex property, DESCRIPTION
 @cindex property, LOCATION
-The iCalendar export 

Re: [O] TIMEZONE property for ical export

[Nicolas Goaziou]

Eric Abrahamsen  writes:

> It's a little strange, because the manual section for this specifically
> mentions the inheritance of the LOCATION property, but the code doesn't
> do it. Shall I add it in? It makes sense for LOCATION and TIMEZONE to be
> inheritable, but not SUMMARY and DESCRIPTION, of course.
>
> If I add inheritance, that will look like this, right?
>
> (tz (org-export-get-node-property :LOCATION entry
>   (org-property-inherit-p :LOCATION)))

It should be:

  (org-property-inherit-p "LOCATION")

> That could also be a separate, second commit.

I think that would be better.

> I've added an ORG-NEWS entry. The patch in my last message was done with
> git format-patch, isn't that commit message okay?

It is. I just need to read better.

Regards,

Re: [O] "header-args :eval inline-only" not working

[Vikas Rawal]

> On 20-Aug-2017, at 12:57 AM, Nicolas Goaziou  wrote:
> 
> Hello,
> 
> Vikas Rawal  writes:
> 
>> My org-version (latest on org ELPA) is: Org mode version 9.0.9 
>> (9.0.9-82-gb862c2-elpa @ /Users/vikas/.emacs.d/elpa/org-20170814/)
>> 
>> The following is not working: 
>> 
>> #+PROPERTY: header-args :eval inline-only
>> 
>> ":eval never-export” works; but ":eval inline-only" does not.
> 
> What is "not working”?

":eval inline-only" has no effect. It still tries to evaluate all code blocks.


>> I can deal with this by globally changing the option using:
>> 
>> (org-export-babel-evaluate (quote inline-only))
>> 
>> But this creates another problem. After this, org does not respect “:exports 
>> results” and exports both the code and results.
> 
> Could you provide an ECM?

Please see the attached file.

When I export this, it still tries to evaluate the code block ind1_t2_hhd_code. 
If I use (org-export-babel-evaluate (quote inline-only)), it does not evaluate  
ind1_t2_hhd_code code block but it exports both the code and the output.

Vikas



testecm.org
Description: Binary data

Re: [O] TIMEZONE property for ical export

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Eric Abrahamsen  writes:
>
>>> BTW, as long as Org doesn't support time zones, the "ox-icalendar"
>>> property may be prefixed with "ICALENDAR_" (e.g., ICALENDAR_TZ).
>>
>> Done!
>
> I realize this is not a great idea since other properties do not have
> "ICALENDAR_" prefix. Sorry about that. I suggest to go back to TIMEZONE.

No problem.

>> How does the attached patch look?
>
>> - (cat (org-icalendar-get-categories entry info)))
>> + (cat (org-icalendar-get-categories entry info))
>> + (tz (org-element-property :ICALENDAR_TZ entry)))
>
> Note that "ICALENDAR_TZ" is not inherited in this case. Neither are
> LOCATION and so on, tho. You would need to use
> `org-export-get-node-property' in conjunction with
> `org-property-inherit-p'.

It's a little strange, because the manual section for this specifically
mentions the inheritance of the LOCATION property, but the code doesn't
do it. Shall I add it in? It makes sense for LOCATION and TIMEZONE to be
inheritable, but not SUMMARY and DESCRIPTION, of course.

If I add inheritance, that will look like this, right?

(tz (org-export-get-node-property :LOCATION entry
  (org-property-inherit-p :LOCATION)))

That could also be a separate, second commit.

>> -event belongs to.
>> +event belongs to. TIMEZONE specifies a time zone for this event
>> +only.
>
> Missing space.
>
> Could you add a commit message and an ORG-NEWS entry?

I've added an ORG-NEWS entry. The patch in my last message was done with
git format-patch, isn't that commit message okay?

Eric

Re: [O] Table columns not aligning when width set

[Kaushal Modi]

On Sat, Aug 19, 2017 at 6:19 AM Nicolas Goaziou 
wrote:

> Fixed. Thank you.
>

Thanks! I confirm the fix.
-- 

Kaushal Modi

Re: [O] "header-args :eval inline-only" not working

[Nicolas Goaziou]

Hello,

Vikas Rawal  writes:

> My org-version (latest on org ELPA) is: Org mode version 9.0.9 
> (9.0.9-82-gb862c2-elpa @ /Users/vikas/.emacs.d/elpa/org-20170814/)
>
> The following is not working: 
>
> #+PROPERTY: header-args :eval inline-only
>
> ":eval never-export” works; but ":eval inline-only" does not.

What is "not working"?

> I can deal with this by globally changing the option using:
>
> (org-export-babel-evaluate (quote inline-only))
>
> But this creates another problem. After this, org does not respect “:exports 
> results” and exports both the code and results.

Could you provide an ECM?

Regards,

-- 
Nicolas Goaziou

Re: [O] TIMEZONE property for ical export

[Nicolas Goaziou]

Eric Abrahamsen  writes:

>> BTW, as long as Org doesn't support time zones, the "ox-icalendar"
>> property may be prefixed with "ICALENDAR_" (e.g., ICALENDAR_TZ).
>
> Done!

I realize this is not a great idea since other properties do not have
"ICALENDAR_" prefix. Sorry about that. I suggest to go back to TIMEZONE.

> How does the attached patch look?

> -  (cat (org-icalendar-get-categories entry info)))
> +  (cat (org-icalendar-get-categories entry info))
> +  (tz (org-element-property :ICALENDAR_TZ entry)))

Note that "ICALENDAR_TZ" is not inherited in this case. Neither are
LOCATION and so on, tho. You would need to use
`org-export-get-node-property' in conjunction with
`org-property-inherit-p'.

> -event belongs to.
> +event belongs to. TIMEZONE specifies a time zone for this event
> +only.

Missing space.

Could you add a commit message and an ORG-NEWS entry?

Regards,

Re: [O] TIMEZONE property for ical export

[Eric Abrahamsen]

Nicolas Goaziou  writes:

> Hello,
>
> Eric Abrahamsen  writes:
>
>> Out of curiosity, what's your stance on supporting time zones in Org's
>> timestamps? It would be an enormous amount of work, obviously, but in
>> principle?
>
> In principle I agree this would be a very good thing, if possible at
> all.
>
>> That's pretty much what it was before I messed with it, and I was a
>> little confused because no callers of `org-icalendar-convert-timestamp'
>> ever used the optional fourth argument at all. My thinking was that
>> users might want to explicitly set the timezone to "UTC". To be honest
>> I'm not sure why they would, but I also don't know why we'd accept t
>> when nothing uses it. I found the whole handling of utc-or-not a bit
>> confusing. What do you think?
>
> I have no strong opinion about this. I was merely concerned about
> consistency. E.g., when using `format-time-string', I never think about
> "UTC" for the last optional argument.

As it is now, a program can call `org-icalendar-convert-timestamp' and
pass in t for the "tz" argument, and that will go to
`format-time-string' correctly. If a user sets the property to "UTC",
that will also get converted to t. Again, I'm not sure this is actually
useful, but the call to `format-time-string' should be consistent.

> BTW, as long as Org doesn't support time zones, the "ox-icalendar"
> property may be prefixed with "ICALENDAR_" (e.g., ICALENDAR_TZ).

Done! How does the attached patch look?

Eric

>From 16e86dbdde1e0accfa7d882adfc173d60df15fe4 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen 
Date: Sat, 19 Aug 2017 10:09:00 -0700
Subject: [PATCH] Add per-entry timezone support for icalendar export

* lisp/ox-icalendar.el (org-icalendar-entry): Look for an
  "ICALENDAR_TZ" property.
  (org-icalendar--vevent, org-icalendar--vtodo): Accept additional
  timezone argument.
  (org-icalendar-convert-timestamp): Change
  paramenter name to "tz", and accept a wider variety of values.
---
 doc/org.texi | 13 ++---
 lisp/ox-icalendar.el | 44 +++-
 2 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index 032087fc2..88c979982 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -14159,9 +14159,10 @@ and write it to @code{org-icalendar-combined-agenda-file} file name.
 @cindex property, SUMMARY
 @cindex property, DESCRIPTION
 @cindex property, LOCATION
-The iCalendar export back-end includes SUMMARY, DESCRIPTION and LOCATION
-properties from the Org entries when exporting.  To force the back-end to
-inherit the LOCATION property, configure the
+@cindex property, ICALENDAR_TZ
+The iCalendar export back-end includes SUMMARY, DESCRIPTION, LOCATION and
+ICALENDAR_TZ properties from the Org entries when exporting.  To force the
+back-end to inherit the LOCATION property, configure the
 @code{org-use-property-inheritance} variable.
 
 When Org entries do not have SUMMARY, DESCRIPTION and LOCATION properties,
@@ -14170,6 +14171,12 @@ derives the description from the body of the Org item.  The
 @code{org-icalendar-include-body} variable limits the maximum number of
 characters of the content are turned into its description.
 
+The ICALENDAR_TZ property can be used to specify a per-entry time zone, and
+will be applied to any entry with timestamp information.  Time zones should
+be specified as per the IANA time zone database format, e.g.@:
+``Asia/Almaty''.  Alternately, the property value can be ``UTC'', to force
+UTC time for this entry only.
+
 Exporting to iCalendar format depends in large part on the capabilities of
 the destination application.  Some are more lenient than others.  Consult the
 Org mode FAQ for advice on specific applications.
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index ba7a62f8b..eb8491f7e 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -341,7 +341,7 @@ A headline is blocked when either
 		   (1- (length org-icalendar-date-time-format))) ?Z))
 
 (defvar org-agenda-default-appointment-duration) ; From org-agenda.el.
-(defun org-icalendar-convert-timestamp (timestamp keyword  end utc)
+(defun org-icalendar-convert-timestamp (timestamp keyword  end tz)
   "Convert TIMESTAMP to iCalendar format.
 
 TIMESTAMP is a timestamp object.  KEYWORD is added in front of
@@ -352,8 +352,11 @@ Also increase the hour by two (if time string contains a time),
 or the day by one (if it does not contain a time) when no
 explicit ending time is specified.
 
-When optional argument UTC is non-nil, time will be expressed in
-Universal Time, ignoring `org-icalendar-date-time-format'."
+When optional argument TZ is non-nil, timezone data time will be
+added to the timestamp.  It can be the string \"UTC\", to use UTC
+time, or a string in the IANA TZ database
+format (e.g. \"Europe/London\").  In either case, the value of
+`org-icalendar-date-time-format' will be ignored."
   

Re: [O] org-table.el

[Kaushal Modi]

On Sat, Aug 19, 2017 at 7:06 AM Vikas Rawal 
wrote:

> Is it by choice that org-table.el is part of both org and org-plus-contrib?


org-plus-contrib = org + the stuff in contrib/ dir

So yes, *everything* in org is in org-plus-contrib too.


> Does it have to be explicitly loaded?
>

org-table should get auto-loaded. Is there a specific usage that made you
wonder if org-table should have been loaded, but is not?

-- 

Kaushal Modi

Re: [O] [RFC] Shrink columns dynamically

[Nicolas Goaziou]

Completing myself,

Nicolas Goaziou  writes:

> `org-table-toggle-column-width' is now bound to "C-c TAB". I removed
> "noshrink" STARTUP keyword, which wasn't useful. I also introduced an
> honest test coverage.
>
> Still no documentation, though.

I made some final changes to "hide-table-column" branch:

  - Now C-u C-c TAB shrink columns with a width cookie and expands the
others;

  - When point is before the first column or after the last one, C-c TAB
asks for columns ranges;

  - I added documentation.

If there is no objection or major bug (including usability ones), I will
merge this branch into master in a couple of days.

Regards,

[O] "header-args :eval inline-only" not working

[Vikas Rawal]

My org-version (latest on org ELPA) is: Org mode version 9.0.9 
(9.0.9-82-gb862c2-elpa @ /Users/vikas/.emacs.d/elpa/org-20170814/)

The following is not working: 

#+PROPERTY: header-args :eval inline-only

":eval never-export” works; but ":eval inline-only" does not.

I can deal with this by globally changing the option using:

(org-export-babel-evaluate (quote inline-only))


But this creates another problem. After this, org does not respect “:exports 
results” and exports both the code and results.

Has anyone else faced this?

If I start my emacs with a -q, emacs picks up the org version that came with my 
version of emacs (25.2.1):

Org-mode version 8.2.10 (release_8.2.10 @ 
/usr/local/Cellar/emacs-mac/emacs-25.2-z-mac-6.5/share/emacs/25.2/lisp/org/)

With this, everything works!  “:eval inline-only” is respected and so is 
“:exports results”.

Have I stumbled on a bug in the current version?

Vikas

Re: [O] ox-odt: List items contain body paragraphs, confusing styles

[Nicolas Goaziou]

James Harkins  writes:

>   On Sat, 19 Aug 2017 04:36:58 -0400 Nicolas Goaziou 
>  wrote  
>> Adding a special style to every paragraph contained in a plain list is 
>> very easy to do. Just let me know if it happens to be the way to solve 
>> the issue at hand. 
>
> I think that is the correct solution. (Again, only one paragraph style for 
> all list levels.)
>
> I realized just now, I couldn't reproduce the problem because I was still 
> using the filter! I just disabled the filter, regenerated the stylesheet, and 
> the problem reappeared.
>
> So here are steps to reproduce:
>
> 1. According to the org-manual[1], create an empty org odt document to export 
> to ODT (creating org-specific styles). C-e o O to export and open.
>
> 2. In this document, edit "Text body" to add 0.5" of first-line indent.
>
> 3. Save the document.
>
> 4. Create a new org document including ~#+ODT_STYLES_FILE: 
> "./ox-odt-generate-stylesheet.odt"~ (replacing with your path) and some list 
> items.
>
> 5. C-e o O, and you'll see incorrect indentation for the list items.

OK. So could you tell me what should be the style name?

Do we need to add it to some style file somewhere? If so, what would be
its definition?

Regards,

[O] org-table.el

[Vikas Rawal]

Is it by choice that org-table.el is part of both org and org-plus-contrib? 
Does it have to be explicitly loaded?

Vikas

Re: [O] ox-odt: List items contain body paragraphs, confusing styles

[James Harkins]

  On Sat, 19 Aug 2017 04:36:58 -0400 Nicolas Goaziou 
 wrote  
> Adding a special style to every paragraph contained in a plain list is 
> very easy to do. Just let me know if it happens to be the way to solve 
> the issue at hand. 

I think that is the correct solution. (Again, only one paragraph style for all 
list levels.)

I realized just now, I couldn't reproduce the problem because I was still using 
the filter! I just disabled the filter, regenerated the stylesheet, and the 
problem reappeared.

So here are steps to reproduce:

1. According to the org-manual[1], create an empty org odt document to export 
to ODT (creating org-specific styles). C-e o O to export and open.

2. In this document, edit "Text body" to add 0.5" of first-line indent.

3. Save the document.

4. Create a new org document including ~#+ODT_STYLES_FILE: 
"./ox-odt-generate-stylesheet.odt"~ (replacing with your path) and some list 
items.

5. C-e o O, and you'll see incorrect indentation for the list items.

hjh

[1] http://orgmode.org/manual/Applying-custom-styles.html#Applying-custom-styles

Re: [O] Table columns not aligning when width set

[Nicolas Goaziou]

Hello,

William Denton  writes:

> I noticed this last week, but I'm on vacation.  I'm compiling and running Org 
> and Emacs from source, and have been keeping up to date, but the problem's 
> been 
> there for a while.  For Org, I'm on the master branch, not tables, and 
> running 
> "make update" to update.
>
> In the example below, the <40> and <10> widths are not respected.  If you hit 
> C-c C-C on the STARTUP line, first one things goes wrong and then another, 
> and 
> you can toggle back and forth.
>
> Bill
>
> # --
>
> #+TITLE: Table column problem
> #+STARTUP: align
>
> | Forty| Ten  |
> | <40> | <10> |
> |--+--|
> | This cell has more than forty characters in it, but it won't align | Under. 
>   |
> | This cell has under forty characters.| More than ten over here. |
>
> # --

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] Bug: Explicit <6> table column width [9.0.9 (release_9.0.9-754-g940c90)]

[Nicolas Goaziou]

Hello,

Paul Stansell  writes:

> I think there might be a something wrong when explicitly setting a width
> of a table column.
>
> For example, for this table
>
>   |---+--|
>   |   | <6>  |
>   | 1 | one  |
>   | 2 | This is a long chunk of text |
>   | 3 | three|
>   |---+--|
>
> when I press  in the table the view changes to
>
>   |---+--|
>   |   | <6>  |
>   | 1 | one  |
>   | 2 | This i |
>   | 3 | three|
>   |---+--|
>
> and when I press C-c the view toggles between
>
>   |---+|
>   |   | <6>|
>   | 1 | one|
>   | 2 | This is a long chunk of text |
>   | 3 | three  |
>   |---+|
>
> and
>
>   |---+--|
>   |   | <6>  |
>   | 1 | one  |
>   | 2 | This is a long chunk of text |
>   | 3 | three|
>   |---+--|

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] make compile fails

[Colin Baxter]

Dear Jarmo,
> Jarmo Hurri  writes:

> Hi Colin.

> Colin Baxter  writes:

>> Works for me using 'make clean' followed by 'make all'.

> For some reason I still get the same error even with that sequence
> of commands.

> Make reports that the error is coming from addcontrib. Isn't there
> some file that controls local contrib config? Was it local.mk?
> It's been years, but I remember having to make a change in that
> file. If I run a diff against what was probably the original, I
> get the following:

> 
> jarmo@localhost org-mode]$ diff local.mk local.mk~ 31c31 <
> ORG_ADD_CONTRIB = htmlize ---
>> #ORG_ADD_CONTRIB = ox-* # e.g. the contributed exporter
> 

> Maybe the issue is somehow related to this? Anyway, I was still
> able to compile on August 11th, so something has changed since
> then.

I don't know of any issues surrounding local.mk. All I can suggest is
that you try a 'make distclean' first. Failing that, why not just delete
(or rename) your org-mode git directory and git clone a fresh source? That
way, you'd be certain you don't have any old "corrupting" files in your
git tree.

Best wishes,

Colin.


-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]

[Nicolas Goaziou]

Hello,

Sam Halliday  writes:

> Regression in org-plus-contrib from http://orgmode.org/elpa/ vs version
> distributed with Emacs 25.2.1
>
> Running
>
>   M-x md-org-export-to-markdown
>
> on a simple org file such as the following
>
> ==
>
> #+TITLE: Functional Programming in Scala for Mortals
>
> /Functional Programming in Scala for Mortals/ is a book aimed at Scala
> developers with an Object Oriented background who wish to learn the
> *Functional Programming* paradigm.
> ==
>
> Causes the following backtrace:
>
> Debugger entered--Lisp error: (wrong-type-argument listp #("Functional 
> Programming in Scala for Mortals" 0 43 (:parent (#1

This usually mean that you have a mixed installation. You should check
that the Org shipped with Emacs is not used.

Regards,

-- 
Nicolas Goaziou

[O] Bug: markdown export errors on headers [9.0.9 (9.0.9-82-gb862c2-elpaplus @ /home/fommil/.emacs.d/elpa/org-plus-contrib-20170814/)]

[Sam Halliday]

Regression in org-plus-contrib from http://orgmode.org/elpa/ vs version
distributed with Emacs 25.2.1

Running

  M-x md-org-export-to-markdown

on a simple org file such as the following

==
#+TITLE: Functional Programming in Scala for Mortals

/Functional Programming in Scala for Mortals/ is a book aimed at Scala
developers with an Object Oriented background who wish to learn the
*Functional Programming* paradigm.
==

Causes the following backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp #("Functional 
Programming in Scala for Mortals" 0 43 (:parent (#1
  org-element-set-contents(#("Functional Programming in Scala for Mortals" 0 43 
(:parent (#0
  apply(org-element-set-contents #("Functional Programming in Scala for 
Mortals" 0 43 (:parent (#0))) nil)
  #[257 
"\211\305\306\307#\310\311\211:\204\312\202\"\n@9\203!\nAA\202\"\n)\"\210\313\314
\211:\2043\312\202@\n@9\203?\nAA\202@\n)#\210\315\211 
\n;\203V\316\317\n#\202\\\320\nA@\"*\211;\203n\321\n\312\f$\202z\nA\322\nA@\f#\240\210\n+\210
 AA@\240\210@\240*\207" [new old element property value 
replace-regexp-in-string "\n" " " mapc #[(blob) "\305 
\211;\203\306\f\307\n$\202 \fA\310\fA@\n#\240\210\f+\207" [blob old value 
property element :parent org-add-props nil plist-put] 6] nil apply 
org-element-set-contents :parent get-text-property 0 plist-get org-add-props 
plist-put] 7 "\n\n(fn S)"](#("Functional Programming in Scala for Mortals" 0 43 
(:parent (#0
  #[257 
"\211\211:\204\211;\205\311\262\202\211@9\205\211@\262
?\206\251\301\203-
\312\301\313\">\206\251\211\2049\314\310\242\"\202\251\211\315=\203]\314\310\242\211:\204N\316\262\202Y\211@9\203Y\211AA\262\"\202\251\211\304>\203~\300!\211\203}\302\203v\317\320\"\210\202}\307\307\242B\240\210\210\306\321=\203\271
;\204\271\211\236A\211\203\270\211@\310\242\211;\203\247\322\323#\266\202\202\257\312A@\"\266\202!\210A\266\202\202\216\210\303\203Q\306\321=\203Q\324!\325=\203Q\211\203P\211@\211@A\211;\203\347\322\323#\266\202\202\357\312A@\"\266\202\211\203G
\235\2030
\235\203!\326!\211\203
\211@\310\242A!\210\310\242@!\210A\266\202\202
\210\202G\310\242A!\210\310\242@!\210\202G
\235\203B\314\310\242\326!\"\210\202G\310\242!\210\266
A\266\202\202\315\210\211\305>\206\251
\211:\204c\316\262\202n\211@9\203n\211AA\262?\206\251\306\327=\203\200\211>?\206\251\306\330=\203\216\324!\331=\206\251\314\310\242\211:\204\235\316\262\202\250\211@9\203\250\211AA\262\"\207"
 [#[257 
"\211\305\306\307#\310\311\211:\204\312\202\"\n@9\203!\nAA\202\"\n)\"\210\313\314
   \211:\2043\312\202@\n@9\203?\nAA\202@\n)#\210\315\211 
\n;\203V\316\317\n#\202\\\320\nA@\"*\211;\203n\321\n\312\f$\202z\nA\322\nA@\f#\240\210\n+\210
 AA@\240\210@\240*\207" [new old element property value 
replace-regexp-in-string "\n" " " mapc #[(blob) "\305 
\211;\203\306\f\307\n$\202 \fA\310\fA@\n#\240\210\f+\207" [blob old value 
property element :parent org-add-props nil plist-put] 6] nil apply 
org-element-set-contents :parent get-text-property 0 plist-get org-add-props 
plist-put] 7 "\n\n(fn S)"] nil nil nil (plain-text) nil objects (nil) (#0) 
plain-text plist-get :ignore-list mapc org-data nil throw :--map-first-match 
objects get-text-property 0 org-element-class element reverse greater-elements 
elements object org-element-secondary-value-alist 
org-element--parsed-properties-alist org-element-dual-keywords 
org-element-multiple-keywords org-element-greater-elements] 11 "\n\n(fn 
--DATA)"](#("Functional Programming in Scala for Mortals" 0 43 (:parent (#0
  mapc(#[257 
"\211\211:\204\211;\205\311\262\202\211@9\205\211@\262
?\206\251\301\203-
\312\301\313\">\206\251\211\2049\314\310\242\"\202\251\211\315=\203]\314\310\242\211:\204N\316\262\202Y\211@9\203Y\211AA\262\"\202\251\211\304>\203~\300!\211\203}\302\203v\317\320\"\210\202}\307\307\242B\240\210\210\306\321=\203\271
;\204\271\211\236A\211\203\270\211@\310\242\211;\203\247\322\323#\266\202\202\257\312A@\"\266\202!\210A\266\202\202\216\210\303\203Q\306\321=\203Q\324!\325=\203Q\211\203P\211@\211@A\211;\203\347\322\323#\266\202\202\357\312A@\"\266\202\211\203G
\235\2030
\235\203!\326!\211\203
\211@\310\242A!\210\310\242@!\210A\266\202\202
\210\202G\310\242A!\210\310\242@!\210\202G
\235\203B\314\310\242\326!\"\210\202G\310\242!\210\266
A\266\202\202\315\210\211\305>\206\251
\211:\204c\316\262\202n\211@9\203n\211AA\262?\206\251\306\327=\203\200\211>?\206\251\306\330=\203\216\324!\331=\206\251\314\310\242\211:\204\235\316\262\202\250\211@9\203\250\211AA\262\"\207"
 [#[257 
"\211\305\306\307#\310\311\211:\204\312\202\"\n@9\203!\nAA\202\"\n)\"\210\313\314
  \211:\2043\312\202@\n@9\203?\nAA\202@\n)#\210\315\211 
\n;\203V\316\317\n#\202\\\320\nA@\"*\211;\203n\321\n\312\f$\202z\nA\322\nA@\f#\240\210\n+\210
 AA@\240\210@\240*\207" [new old element property value 

Re: [O] Escaping links

[Nicolas Goaziou]

Hello,

Fabrice Popineau  writes:

> You could also prefix the link by a string holding (in ascii) the number of
> bytes of the unencoded link.
>
> But that makes raw/manual editing of an org file much harder.

I'd rather have something simple.

Here are some suggestions.

1. Replace "\\[\\[\\([^][]+\\)\\]\\(\\[\\([^][]+\\)\\]\\)?\\]"
   (`org-bracket-link-regexp') with
   "\\[\\[\\([^\000]+?\\)\\]\\(\\[\\([^\000]+?\\)\\]\\)?\\]". This gives
   more possibilities. We will just live with the unsupported cases
   (e.g. square brackets at the end of the path or the description).

2. Use good ole backslash character to escape ambiguous characters (even
   though any character can be escaped). `org-link-unescape' would take
   care of them instead of url-encoded characters.

3. A mix of both. `org-bracket-link-regexp' could become more
   complicated though.

I'm open to other suggestions, as long as they do not massively impede
manual editing.

Regards,

-- 
Nicolas Goaziou

Re: [O] Suggestion for tiniest of manual changes

[Nicolas Goaziou]

Hello,

Peter Tomhas  writes:

> Perhaps that could become something like (apologies for poorly
> formatted texinfo):
>
> %\1 @dots{} %\N @r{Insert the text entered at the Nth
> %^@{@var{prompt}@}, where @code{N} is}
> @r{a number, starting from 1.@footnote{As is standard in elisp,
> to insert a backslash character within a string, as is required here, it is
> necessary to escape it with another backslash. So to insert %\1, %\2 and so
> on, one should actually insert %\\1, %\\2, etc.}}

I added a footnote about it. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [Feature request] LaTeX blocks preview

[Nicolas Goaziou]

Hello,

ed...@openmail.cc writes:

> I would like to ask if it is possible to preview latex blocks. Something 
> like this (replace EXPORT with SRC, if you wish):
>
>  #+BEGIN_EXPORT latex
>  \begin{align}
>I_{0}
>& > \max{(\lambda_{f}^{2})}
>\\
>& > 2^{2}
>\\
>I_{0} & > 4
>  \end{align}
>  #+END_EXPORT
>
> to be previewed in the same way as
>
>  \begin{align}
>I_{0}
>& > \max{(\lambda_{f}^{2})}
>\\
>& > 2^{2}
>\\
>I_{0} & > 4
>  \end{align}

It is not possible in the general case. The export block is not
guaranteed to contain a complete environment; it isn't necessarily
displayable either.

> - Related ::
>- org-edit-latex-mode
>  There is org-edit-latex-mode, but it requires  some extra work:
>  1. org-edit-special (C-')
>  2. org-edit-latex-preview-at-point (C-c C-p C-p)
>  3. org-edit-src-exit (C-')
>
>  Besides, the preview does not stay in the original Org-mode buffer, 
> but it's lost with step 3.

I think this is an acceptable workaround. I think AucTeX has its own
previewing mechanism, so step 2 may not be required.

Regards,

-- 
Nicolas Goaziou

Re: [O] named anchors in HTML export

[Nicolas Goaziou]

Hello,

Adam Spiers  writes:

> I was also expecting to be able to use #+NAME: foo in front of a
> headline

You cannot use a NAME keyword to a headline (or an inlinetask).
CUSTOM_ID is morally equivalent, though.

> or even other elements like paragraphs, but this doesn't
> work. Is this a bug, or am I misreading the manual?

Currently, "ox-html" doesn't create an anchor for named paragraphs,
unless the paragraph consists of an image only.

However, you can put targets anywhere in a paragraph using <>
syntax.

>  Is there any way of creating an anchor for an arbitrary element,
> short of some ugly "+HTML" hack?

Note that internal references are... internal. You can use them across
documents only when using Org publishing mechanism. IOW, <>
doesn't create  anchor, but something like .

Regards,

-- 
Nicolas Goaziou

Re: [O] ox-odt: List items contain body paragraphs, confusing styles

[Nicolas Goaziou]

Hello,

James Harkins  writes:

> So I would say, postpone this issue unless I can gather more evidence.

OK.

> A short answer to your questions is that every list item does consist
> of paragraphs, and each paragraph must have a paragraph style, but --
> the paragraph style can be the same one, even at different list
> levels. There is no need for a different paragraph style for each list
> level, and you don't have to do anything special for multiple
> paragraphs within a list item.

Adding a special style to every paragraph contained in a plain list is
very easy to do. Just let me know if it happens to be the way to solve
the issue at hand.


Regards,

-- 
Nicolas Goaziou

Re: [O] TIMEZONE property for ical export

[Nicolas Goaziou]

Hello,

Eric Abrahamsen  writes:

> Out of curiosity, what's your stance on supporting time zones in Org's
> timestamps? It would be an enormous amount of work, obviously, but in
> principle?

In principle I agree this would be a very good thing, if possible at
all.

> That's pretty much what it was before I messed with it, and I was a
> little confused because no callers of `org-icalendar-convert-timestamp'
> ever used the optional fourth argument at all. My thinking was that
> users might want to explicitly set the timezone to "UTC". To be honest
> I'm not sure why they would, but I also don't know why we'd accept t
> when nothing uses it. I found the whole handling of utc-or-not a bit
> confusing. What do you think?

I have no strong opinion about this. I was merely concerned about
consistency. E.g., when using `format-time-string', I never think about
"UTC" for the last optional argument.

BTW, as long as Org doesn't support time zones, the "ox-icalendar"
property may be prefixed with "ICALENDAR_" (e.g., ICALENDAR_TZ).

Regards,

-- 
Nicolas Goaziou

Re: [O] make compile fails

[Jarmo Hurri]

Colin Baxter  writes:

> > 
> > jarmo@localhost org-mode]$ diff local.mk local.mk~ 31c31 <
> > ORG_ADD_CONTRIB = htmlize ---
> >> #ORG_ADD_CONTRIB = ox-* # e.g. the contributed exporter
> > 
>
> > Maybe the issue is somehow related to this? Anyway, I was still
> > able to compile on August 11th, so something has changed since
> > then.
>
> I don't know of any issues surrounding local.mk. All I can suggest is
> that you try a 'make distclean' first. Failing that, why not just
> delete (or rename) your org-mode git directory and git clone a fresh
> source? That way, you'd be certain you don't have any old "corrupting"
> files in your git tree.

Running 'make cleanall' didn't help.

However, a fresh clone followed by a reconfiguration of local.mk solved
the issue. Most likely the result of a local.mk that is no longer
consistent.

Up and running again. Thanks!

Jarmo

Re: [O] make compile fails

[Colin Baxter]

Dear Jarmo,

> Jarmo Hurri  writes:

> Greetings.

> Just pulled the latest version and tried to compile it. I get the
> following error:

> --
> [jarmo@localhost org-mode]$ make compile make -C doc clean; make
> -C lisp clean; make[1]: Entering directory
> '/home/jarmo/src/org-mode/doc' rm -f org *.pdf *.html *_letter.tex
> org-version.inc org-version.tex \ *.aux *.cp *.cps *.dvi *.fn
> *.fns *.ky *.kys *.pg *.pgs \ *.toc *.tp *.tps *.vr *.vrs *.log
> *.html *.ps make[1]: Leaving directory
> '/home/jarmo/src/org-mode/doc' make[1]: Entering directory
> '/home/jarmo/src/org-mode/lisp' rm -f org-version.el
> org-loaddefs.el org-version.elc org-loaddefs.elc org-install.elc
> rm -f *.elc make[1]: Leaving directory
> '/home/jarmo/src/org-mode/lisp' make -C lisp compile make[1]:
> Entering directory '/home/jarmo/src/org-mode/lisp' rm -f
> org-version.el org-loaddefs.el org-version.elc org-loaddefs.elc
> org-install.elc install -m 644 -p .  install: missing destination
> file operand after '.'  Try 'install --help' for more information.
> make[1]: *** [Makefile:64: addcontrib] Error 1 make[1]: Leaving
> directory '/home/jarmo/src/org-mode/lisp' make: ***
> [mk/targets.mk:95: compile] Error
> 2 --

> System specs:
> --
> [jarmo@localhost org-mode]$ uname -a Linux localhost.localdomain
> 4.12.5-300.fc26.x86_64 #1 SMP Mon Aug 7 15:27:25 UTC 2017 x86_64
> x86_64 x86_64 GNU/Linux [jarmo@localhost org-mode]$ dnf list
> installed emacs Installed Packages emacs.x86_64 1:25.2-3.fc26
> @updates 
--


Works for me using 'make clean' followed by 'make all'.

Colin.

-- 
--
Colin Baxter
m43...@yandex.com
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8

Re: [O] make compile fails

[Jarmo Hurri]

Hi Colin.

Colin Baxter  writes:

> Works for me using 'make clean' followed by 'make all'.

For some reason I still get the same error even with that sequence of
commands.

Make reports that the error is coming from addcontrib. Isn't there some
file that controls local contrib config? Was it local.mk? It's been
years, but I remember having to make a change in that file. If I run a
diff against what was probably the original, I get the following:


jarmo@localhost org-mode]$ diff local.mk local.mk~
31c31
< ORG_ADD_CONTRIB = htmlize
---
> #ORG_ADD_CONTRIB = ox-* # e.g. the contributed exporter


Maybe the issue is somehow related to this? Anyway, I was still able to
compile on August 11th, so something has changed since then.

Jarmo