[O] Preserving links when using org-element-interpret-data

[Thibault Marin]

Hi all,

I am trying to use the org-element tools to modify an org file from elisp code
and I was wondering if the `org-element-parse-buffer' /
`org-element-interpret-data' combo should result in the same content as the
original buffer.  I am having issues with links where the target and the
description are both =file:= entries.

My original org looks like this:

#+NAME: org-data
#+begin_example
,#+TITLE: test

[[file:a.png][file:a.png]]
#+end_example

The elisp code parses the org file and outputs the result from
`org-element-interpret-data':

#+NAME: org-interpret
#+BEGIN_SRC emacs-lisp :var org-data=org-data :results verbatim

(let (org-tree)
  (with-temp-buffer
(insert org-data)
(setq org-tree (org-element-parse-buffer)))
  (org-element-interpret-data org-tree))

#+END_SRC

#+RESULTS: org-interpret
: "#+TITLE: test
: 
: [[file:a.png][[[file:a.png
: "

The input link is transformed from
#+begin_example
[[file:a.png][file:a.png]]
#+end_example
to
#+begin_example
[[file:a.png][[[file:a.png
#+end_example

Are the additional brackets in the description expected?  Is there any way to
achieve what I want: I am trying to get org-element-interpret-data to output the
same link syntax as the input (in my real application, I am changing the
filename).

Thanks in advance for the help.


P.S.: Here is my version information:
#+BEGIN_SRC emacs-lisp :results drawer
(concat (emacs-version) "\n"
(replace-regexp-in-string "@.*)" "@ ... )" (org-version nil t)))
#+END_SRC

#+RESULTS:
:RESULTS:
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.21.5)
 of 2016-09-05 on trouble, modified by Debian
Org-mode version 8.3.6 (release_8.3.6-1179-ga9ae0e @ ... )
:END:

Re: [O] [RFC] Change visibility for bracket links

[Clément Pit--Claudel]

On 2016-10-05 20:16, David A. Gershman wrote:
> On 10/05/2016 03:26 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> "David A. Gershman"  writes:
>>
>>> Not bad, but could it be customizable via variable giving the user the
>>> choice?
>> Thank you for your feedback.
>>
>> I guess we could introduce a variable to let users shoot them in the
>> foot, but is there any incentive to do so? I mean, the clutter is
>> minimal, and the current state can be very annoying at times (ever tried
>> to start a buffer with a bracket link?).
>>
>>
> Actually, no I haven't. :)
> 
> I have no problem with the brackets, I just think they "break up" the
> flow of reading we're familiar with.  Dare I say many people are use to
> a web-like experience when having hyper links in text.  From your
> description, the existence of the brackets are more for precise edits
> without having to fudge with point.  I have fallen victim to that, but
> admit, I prefer "clean" links.

What about having our cake and eating it too? :)  We could do just the same as 
what prettify-symbols-mode does with its prettify-symbols-unprettify-at-point 
variable.  Namely, we could show the brackets when point is at the edge of a 
link, and hide them otherwise.  The same trick could be applied to subscripts 
(I have working code for that for a different project, at 
https://github.com/cpitclaudel/company-coq/blob/master/company-coq.el#L4287).

Wouldn't this preserve the flow of reading, while allowing for easier editing?

Cheers,
Clément.



signature.asc
Description: OpenPGP digital signature

Re: [O] [RFC] Change visibility for bracket links

[David A. Gershman]

On 10/05/2016 03:26 PM, Nicolas Goaziou wrote:
> Hello,
>
> "David A. Gershman"  writes:
>
>> Not bad, but could it be customizable via variable giving the user the
>> choice?
> Thank you for your feedback.
>
> I guess we could introduce a variable to let users shoot them in the
> foot, but is there any incentive to do so? I mean, the clutter is
> minimal, and the current state can be very annoying at times (ever tried
> to start a buffer with a bracket link?).
>
>
Actually, no I haven't. :)

I have no problem with the brackets, I just think they "break up" the
flow of reading we're familiar with.  Dare I say many people are use to
a web-like experience when having hyper links in text.  From your
description, the existence of the brackets are more for precise edits
without having to fudge with point.  I have fallen victim to that, but
admit, I prefer "clean" links.

If you do add the variable, by all means, have the new [format] be the
default.  Let people like me do the additional work of changing their
config.  It gives us a chance of being the geniuses who know how to help
others if/when they ask on the list. *evil laugh*


--David

Re: [O] Bug: org-refile, org-archive-subtree and footnotes [8.3.6 (8.3.6-4-g4835be-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20160926/)]

[Jorge Morais Neto]

On 5 October 2016 at 19:24, Nicolas Goaziou  wrote:
> You gave a recipe to reproduce the example. I was being lazy and
> expected the complete (final) example. Anyway, I did my homework.
>
> This should be fixed: the message is slightly less frightening now.
>
> Regards,

Thank you!  Regards

-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: [O] [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

"David A. Gershman"  writes:

> Not bad, but could it be customizable via variable giving the user the
> choice?

Thank you for your feedback.

I guess we could introduce a variable to let users shoot them in the
foot, but is there any incentive to do so? I mean, the clutter is
minimal, and the current state can be very annoying at times (ever tried
to start a buffer with a bracket link?).


Regards,

-- 
Nicolas Goaziou0x80A93738

Re: [O] Bug: org-refile, org-archive-subtree and footnotes [8.3.6 (8.3.6-4-g4835be-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20160926/)]

[Nicolas Goaziou]

Jorge Morais Neto  writes:

> On 5 October 2016 at 06:44, Nicolas Goaziou  wrote:
>>
>> OOC, could you show the footnote section triggering this warning? Org
>> Lint ignores property drawers there (i.e., it shouldn't raise an error),
>> so I'm wondering how is inserted this timestamp.
>
> I don't understand.  Have I not already given an example in the
> original email?

You gave a recipe to reproduce the example. I was being lazy and
expected the complete (final) example. Anyway, I did my homework. 

This should be fixed: the message is slightly less frightening now.

Regards,

Re: [O] Bug: Archive to Datetree [8.3.6 (8.3.6-6-g194e51-elpa @ .emacs.d/elpa/org-20161003/)]

[Nicolas Goaziou]

Hello,

Klarre N  writes:

> When archiving to datetree:
> (setq org-archive-location "file.ext::datetree/")
>
> The following produces unexpected result on "Minimal Example":
> 1. Archive first TODO "A1".
>
> 2. Archive second TODO "A2".
>
>
> * Minimal Example
> ** DONE A1
>CLOSED: [2016-06-28 Tue 21:00]
>
> ** DONE A2
>CLOSED: [2016-06-14 Tue 21:00]
>
>
> Result (no day headline for 2016-06-14):
> * 2016
> ** 2016-06 June
>  DONE A2
>  CLOSED: [2016-06-14 Tue 21:00]
>
> *** 2016-06-28 Tuesday
>  DONE A1
>  CLOSED: [2016-06-28 Tue 21:00]
>
>
> Expected Result:
> * 2016
> ** 2016-06 June
> *** 2016-06-14 Tuesday
>  DONE A2
>  CLOSED: [2016-06-14 Tue 21:00]
>
> *** 2016-06-28 Tuesday
>  DONE A1
>  CLOSED: [2016-06-28 Tue 21:00]

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change visibility for bracket links

[David A. Gershman]

Not bad, but could it be customizable via variable giving the user the
choice?


>On October 5, 2016 8:40:08 AM PDT, Nicolas Goaziou
> wrote:
>>Hello,
>>
>>I'd like to make the following change to bracket links display (i.e.,
>>when `org-highlight-links' contains `bracket', which is the default).
>>
>>Basically, I want to leave a visible pair of brackets around the link,
>>i.e.,
>>
>>  [[uri][description]]
>>
>>is displayed as
>>
>>  [description]
>>
>>instead of
>>
>>  description
>>
>>and
>>
>>  [[uri]]
>>
>>is displayed as
>>
>>  [uri]
>>
>>instead of
>>
>>  uri
>>
>>The rationale behind this suggestion is that editing a mostly
>invisible
>>link is unintuitive when point is at the boundaries of its visible
>>part.
>>
>>More precisely, in the following visible part of a link
>>
>>  description
>>
>>if point hits "d" from the right, changes happen in the description of
>>the link, but if point comes from the left, changes happen before the
>>link. 
>>
>>I guess I could get used to it, but sometimes, the link happens to be
>>at
>>column 0. In this case, the only way to "come from the left" is to
>move
>>to the previous line and go past the newline character. This is, IMO,
>>very annoying, notwithstanding the fact that it is impossible to
>>realize
>>at the beginning of the buffer.
>>
>>Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
>>before the opening bracket makes changes before the link. Conversely,
>>editing after the former makes changes to the uri or the description,
>>whichever is displayed.
>>
>>The cost a little more visual clutter, but it seems very acceptable to
>>me. I attach a quick patch for testing.
>>
>>Feedback welcome.
>>
>>Regards,

-- 
David A. Gershman, CISSP
dagersh...@dagertech.net

Re: [O] [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Marco Wahl  writes:

> I think there is an issue with the coloring when writing text
> immediately to the right of a file link.  E.g.
>
> [[file:shot.png]]text

You are right. I didn't check the patch thoroughly. Here is an update,
which should be more robust.

Regards,

>From 518363a2b794fc21d28987dd59a65c0efa1d9ce4 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Wed, 5 Oct 2016 17:22:15 +0200
Subject: [PATCH] Change bracket links visibility

* lisp/org.el (org-activate-bracket-links): Leave a pair of brackets
  around bracket links so as to facilitate editing them.  Small
  refactoring.
(org-beginning-of-line):
(org-end-of-line): Remove workaround bug #14346, since the original
report cannot be reproduced.

* testing/lisp/test-org.el (test-org/beginning-of-line): Fix test.
---
 lisp/org.el  | 66 +---
 testing/lisp/test-org.el |  4 +--
 2 files changed, 31 insertions(+), 39 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6d5201b..fcc60d3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6163,7 +6163,6 @@ by a #."
 			(match-string-no-properties 2 hl
 	   (link-start (match-beginning 0))
 	   (link-end (match-end 0))
-	   (bracketp t)
 	   (help-echo (org-link-get-parameter type :help-echo))
 	   (help (cond
 		  ((stringp help-echo)
@@ -6199,44 +6198,43 @@ by a #."
 			  (t
 			   `(:uri ,(format "%s:%s" type path)
 	   (activate-func (org-link-get-parameter type :activate-func))
-	   ;; invisible part
-	   (ip (list 'invisible (or
- (org-link-get-parameter type :display)
- 'org-link)
-		 'face face
-		 'keymap keymap
-		 'mouse-face mouse-face
-		 'font-lock-multiline t
-		 'help-echo help
-		 'htmlize-link htmlize-link))
-	   ;; visible part
+	   ;; Visible part.
 	   (vp (list 'keymap keymap
 		 'face face
 		 'mouse-face mouse-face
 		 'font-lock-multiline t
 		 'help-echo help
-		 'htmlize-link htmlize-link)))
-  ;; We need to remove the invisible property here.  Table narrowing
-  ;; may have made some of this invisible.
+		 'htmlize-link htmlize-link))
+	   ;; Invisible part.
+	   (ip (append (list 'invisible
+			 (or (org-link-get-parameter type :display)
+ 'org-link))
+		   vp)))
+  ;; We need to remove the invisible property here.  Table
+  ;; narrowing may have made some of this invisible.
   (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
   (remove-text-properties (match-beginning 0) (match-end 0)
 			  '(invisible nil))
-  (if (match-end 3)
+  (if (match-end 2)
 	  (progn
-	(add-text-properties (match-beginning 0) (match-beginning 3) ip)
-	(org-rear-nonsticky-at (match-beginning 3))
-	(add-text-properties (match-beginning 3) (match-end 3) vp)
-	(org-rear-nonsticky-at (match-end 3))
-	(add-text-properties (match-end 3) (match-end 0) ip)
-	(org-rear-nonsticky-at (match-end 0)))
-	(add-text-properties (match-beginning 0) (match-beginning 1) ip)
-	(org-rear-nonsticky-at (match-beginning 1))
-	(add-text-properties (match-beginning 1) (match-end 1) vp)
-	(org-rear-nonsticky-at (match-end 1))
-	(add-text-properties (match-end 1) (match-end 0) ip)
-	(org-rear-nonsticky-at (match-end 0)))
+	(add-text-properties (match-beginning 0) (match-beginning 2) ip)
+	(add-text-properties (match-beginning 2) (match-end 2) vp)
+	(add-text-properties (match-end 2) (match-end 0) ip)
+	;; Make sure text after the visible closing bracket gets
+	;; past the whole link.
+	(add-text-properties (match-end 2) (match-end 0)
+ `(rear-nonsticky ,ip))
+	(add-text-properties (match-end 2) (match-end 0)
+ `(front-sticky ,ip)))
+	(add-text-properties (match-beginning 0) (1+ (match-beginning 0)) ip)
+	(add-text-properties (1+ (match-beginning 0)) (1+ (match-end 1)) vp)
+	(add-text-properties (1+ (match-end 1)) (match-end 0) ip)
+	;; Make sure text after the visible closing bracket gets past
+	;; the whole link.
+	(add-text-properties (match-end 1) (match-end 0) `(rear-nonsticky ,ip))
+	(add-text-properties (match-end 1) (match-end 0) `(front-sticky ,ip)))
   (when activate-func
-	(funcall activate-func link-start link-end path bracketp))
+(funcall activate-func link-start link-end path t))
   t)))
 
 (defun org-activate-dates (limit)
@@ -23762,10 +23760,7 @@ beyond the end of the headline."
 	;; point was already at beginning of line and command is
 	;; repeated.
 	(when (and (= (point) pos) (eq last-command this-command))
-	  (goto-char after-bullet
-  (setq disable-point-adjustment
-(or (not (invisible-p (point)))
-(not (invisible-p (max (point-min) (1- (point
+	  (goto-char after-bullet)
 
 (defun org-end-of-line ( arg)
   "Go to the end of the line.
@@ -23802,10 +23797,7 @@ the cursor is already beyond the end of the headline."
 	  ;; If 

[O] Bug: Archive to Datetree [8.3.6 (8.3.6-6-g194e51-elpa @ .emacs.d/elpa/org-20161003/)]

[Klarre N]

When archiving to datetree:
(setq org-archive-location "file.ext::datetree/")

The following produces unexpected result on "Minimal Example":
1. Archive first TODO "A1".

2. Archive second TODO "A2".


* Minimal Example
** DONE A1
   CLOSED: [2016-06-28 Tue 21:00]

** DONE A2
   CLOSED: [2016-06-14 Tue 21:00]


Result (no day headline for 2016-06-14):
* 2016
** 2016-06 June
 DONE A2
 CLOSED: [2016-06-14 Tue 21:00]

*** 2016-06-28 Tuesday
 DONE A1
 CLOSED: [2016-06-28 Tue 21:00]


Expected Result:
* 2016
** 2016-06 June
*** 2016-06-14 Tuesday
 DONE A2
 CLOSED: [2016-06-14 Tue 21:00]

*** 2016-06-28 Tuesday
 DONE A1
 CLOSED: [2016-06-28 Tue 21:00]


Emacs  : GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-22
Package: Org-mode version 8.3.6 (8.3.6-6-g194e51-elpa @
.emacs.d/elpa/org-20161003/)

current state:
==
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
org-babel-hide-result-toggle-maybe org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-show-block-all append
local] 5]
 #[nil "\300\301\302\303\304$\207"
   [org-add-hook change-major-mode-hook org-babel-show-result-all
append local] 5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-archive-location "archive.arc::datetree/"
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: [O] Best diagram, image software?

[Jeremie Juste]

Hello,

Lawrence Bottorff  writes:

> I know lots of you use Emacs and org mode to prepare scholarly books and 
> papers, either doing the HTML or, more probably, the Latex
> export. Question: Let's say I want to produce a math text with 
> Emacs/org-mode/Latex. What is the best way to make diagrams and
> images? I've seen things like Inkscape and LibreOffice Draw. But then there 
> is Gnuplot and Tikz. Yes, what Tikz does seems optimal,
> but the learning curve is a year's sabbatical. Just wondering what you people 
> are using to do your images.
>

I'm very impressed by tikz and gnuplot. I use both of them inefficiently
sometimes trying to understand some code here and there. There
documentation are very good though. It would be great for a sabatical in
my opinion.

Because I didn't take the time to learn tikz and gnuplot, these days I
mostly make graphics with R and ggplot2 though. The advantage is that in
addition of the good documentation there is a quite a number of people
using it so it more likely that some people have encountered your
problem before or has a solution to your problem. So you can find
solution more quickly I believe. Yet this is an easy
way out because I think taking the time to learn how the stuff really
works give you some perspective.

Best regards,
Jeremie

Re: [O] Repeating tasks with scheduled time

[Nicolas Goaziou]

Arkady Grudzinsky  writes:

> Thanks.  I have 8.2 installed.  Do you know when 9.0 will be
> released?

Within 2 weeks, probably.

Regards,

Re: [O] Repeating tasks with scheduled time

[Arkady Grudzinsky]

On Wed, Oct 05 2016, Nicolas Goaziou wrote:

> Hello,
>
> Arkady Grudzinsky  writes:
>
>> On Tue, Oct 04 2016, Arkady Grudzinsky wrote:
>>
>>> Say, I have this TODO item which needs to be repeated every
>>> evening after 20:00 and if it is not marked as DONE for several
>>> days, I want it to be moved to the NEAREST 20:00 in the future,
>>> i.e. to 20:00 TODAY if I mark it at noon.  I thought, this would
>>> accomplish the goal:
>>>
>>> * TODO Load and run the dishwasher
>>>   SCHEDULED: <2016-10-03 Mon 20:00 .+1d>
>>
>> Sorry, the correct syntax would be 
>>
>> * TODO Load and run the dishwasher
>>   SCHEDULED: <2016-10-03 Mon 20:00 ++1d>
>>
>> It still moves the scheduled time to the next day instead of
>> 20:00 today.
>>
>>
>>>
>>> Instead, marking this task as completed today at noon moves the
>>> schedule to 20:00 TOMORROW instead of 20:00 TODAY although the
>>> nearest 20:00 in the future is, technically, 20:00 TODAY.
>>>
>>> Is there a way to change this behavior?
>
> IIRC this was fixed in development version, i.e., Org 9.0.

Thanks.  I have 8.2 installed.  Do you know when 9.0 will be
released?

-- 
Arkady

Re: [O] [RFC] Change visibility for bracket links

[Detlef Steuer]

Am Wed, 05 Oct 2016 17:40:08 +0200
schrieb Nicolas Goaziou :

> Hello,
> 
> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
> 
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
> 
>   [[uri][description]]
> 
> is displayed as
> 
>   [description]
> 
> instead of
> 
>   description
> 
> and
> 
>   [[uri]]
> 
> is displayed as
> 
>   [uri]
> 
> instead of
> 
>   uri

+1

Detlef

> 
> The rationale behind this suggestion is that editing a mostly
> invisible link is unintuitive when point is at the boundaries of its
> visible part.
> 
> More precisely, in the following visible part of a link
> 
>   description
> 
> if point hits "d" from the right, changes happen in the description of
> the link, but if point comes from the left, changes happen before the
> link. 
> 
> I guess I could get used to it, but sometimes, the link happens to be
> at column 0. In this case, the only way to "come from the left" is to
> move to the previous line and go past the newline character. This is,
> IMO, very annoying, notwithstanding the fact that it is impossible to
> realize at the beginning of the buffer.
> 
> Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
> before the opening bracket makes changes before the link. Conversely,
> editing after the former makes changes to the uri or the description,
> whichever is displayed.
> 
> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
> 
> Feedback welcome.
> 
> Regards,
> 

Re: [O] Syntax highlighting for JSON/JavaScript/Java code examples

[Peter Davis]

On Wed, Oct 5, 2016, at 01:38 PM, Peter Davis wrote:
> I'm trying to include code examples in a doc. They're JSON, but 'js'
> doesn't seem to work, so I'm using 'java'. 
> 
> I just discovered that I don't have htmlize in my setup, so I added
> that. Now org is trying to do syntax highlighting, at least when
> exporting HTML, but I'm getting this:
> 
> org-babel-exp process dot at line 143...
> executing Dot code block...
> Wrote c:/Users/pdavis/AppData/Local/Temp/babel-8776xe_/ob-input-877621O
> Code block evaluation complete.
> face-attribute: Invalid face
> 
> 
> Any hints, or ideas for trouble-shooting this?

Nevermind. My bad.

I had copied the htmlize.el from an xemacs installation. Stupid.

I just installed htmlize via package manager and all seems good for now.
I'm even getting the syntax highlighting!

Thanks,
-pd


-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] Fwd: comment lines inside org tables

[Thomas S. Dye]

Rolf Sander (MPI) writes:

> I still think orgmode is great code and I would have loved to
> participate. However, given the way that you treat me here, I lost my
> motivation to work with you. Instead, I will have to modify my own *.el
> files.

Git makes this relatively painless.  My sense is that quite a few Org
mode users keep local git branches where they experiment with features
that haven't, for whatever reason, made their way to contrib or core.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

[O] Syntax highlighting for JSON/JavaScript/Java code examples

[Peter Davis]

I'm trying to include code examples in a doc. They're JSON, but 'js'
doesn't seem to work, so I'm using 'java'. 

I just discovered that I don't have htmlize in my setup, so I added
that. Now org is trying to do syntax highlighting, at least when
exporting HTML, but I'm getting this:

org-babel-exp process dot at line 143...
executing Dot code block...
Wrote c:/Users/pdavis/AppData/Local/Temp/babel-8776xe_/ob-input-877621O
Code block evaluation complete.
face-attribute: Invalid face


Any hints, or ideas for trouble-shooting this?

Thanks!
-pd


-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] Misc. questions

[Peter Davis]

On Tue, Oct 4, 2016, at 03:02 PM, Peter Davis wrote:
> 
> 3) Still trying to find a way to get to DocBook XML (4, it turns out). I
> know the export page says to output texi (see #2 above) and then convert
> with makeinfo, but I have my doubts.  Of course, once I get texi working
> I'll be able to see for myself what information, if any, is lost.
> 

I now have a working routine for this on Windows 10, though it's not
pretty:

 1. Edit file in emacs org-mode
 2. Export to TeXInfo (texi) format
 3. Open Ubuntu/Bash window:
a. cp ../../../mnt/c/Users/pdavis/org/filename.texi ./
b. makeinfo --docbook filename.texi
c. cp ./filename.xml ../../../mnt/c/Users/pdavis/org
 4. Open filename.xml in emacs and replace header with db-xml-hdr.xml
 5. Open edited filename.xml in ArborText

Tedious, but it works. I can probably find ways to automate some of it,
such as a bash shell script to copy the file, run makeinfo, substitute
the header, and copy it back.

Thanks,
-pd

-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] [RFC] Change visibility for bracket links

[Marco Wahl]

Nicolas Goaziou  writes:

> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
>
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
>
>   [[uri][description]]
>
> is displayed as
>
>   [description]

> [omission]

> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
>
> Feedback welcome.

+1

I think there is an issue with the coloring when writing text
immediately to the right of a file link.  E.g.

[[file:shot.png]]text


Regards,
-- 
Marco

Re: [O] Fwd: comment lines inside org tables

[Nicolas Goaziou]

Hello,

"Rolf Sander (MPI)"  writes:

> I'm sorry to say this but this email list has been the most
> disappointing experience for me. I asked a simple question and even
> provided the code for a possible solution. The answers I received
> included phrases like "can of worms", "little benefit" and "barely
> scratching the surface of the problem".

I think that blaming the whole list is uncalled for. You got helpful
answers from other persons than me, yet you only quote parts of my
answers.

> And now you even wrote:

[...]

>> I already answered to that question, but you discarded my answer.
>
> This is not true! You did not answer my question! Without testing, you
> just _speculated_ that you expect problems with formulas and export.

What makes you think I speculated anything? I tried to show you the weak
spots of your model.

> So I tested it myself. In my tests I did _not_ experience any problems
> with formulas and export. Why do you claim that I discarded your
> answer?

Exhibiting one example confirming a theory doesn't validate it.

Anyway, you can do the following with your patch:

 - Move point to your "comment row"
 - M-: (org-element-property :type (org-element-at-point))

If you get `rule', by all means, Org sees your row as a standard table
rule. This is not transparent; this is /not/ a comment. You just created
a degenerate syntax for table rules.

Note that this may be what you really want, but this is not equivalent
to the initial example you gave:

  |+---+|
  | animal | size  | number |
  |+---+|
  | gnus   | big   |  3 |
  # don't forget to add elephants here:
  | gnats  | small |   1000 |
  |+---+|

If such thing existed, the "gnus" and "gnats" rows wouldn't be separated
by a rule, e.g., in export, because Org removes such lines prior to
starting the export process. Another example is the following:

  |+---+|
  | animal | size  | number |
  |-/ whatever
  | gnus   | big   |  3 |
  | gnats  | small |   1000 |
  |+---+|

In this case, you are creating a table header, so this is not
transparent either. I could also add an example where an additional rule
has an impact on formulas (@I..@II could have a different meaning
depending on the presence or not of another rule).

All in all, I think your problem is ill-defined. You wanted comment
rows, but you didn't specify how it should behave in various situations
involving tables. I stand on my ground : generic comment rows are
difficult to implement and "a can of worms".

Allowing text within a table rule is easier to achieve, as you proved,
but it feels very hackish and limited in use. What if I want to
introduce comments without creating a visible rule in the table? Do
I need yet another syntax?

> I still think orgmode is great code and I would have loved to
> participate. However, given the way that you treat me here,

I don't treat you in any way. I just suggested your idea was wrong.
I understand this can be frustrating. I would be frustrated too.


Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Change visibility for bracket links

[Rainer M Krug]

Le mercredi 5 octobre 2016, Nicolas Goaziou  a
écrit :

> Hello,
>
> I'd like to make the following change to bracket links display (i.e.,
> when `org-highlight-links' contains `bracket', which is the default).
>
> Basically, I want to leave a visible pair of brackets around the link,
> i.e.,
>
>   [[uri][description]]
>
> is displayed as
>
>   [description]
>
> instead of
>
>   description
>
> and
>
>   [[uri]]
>
> is displayed as
>
>   [uri]
>
> instead of
>
>   uri
>
>
+1

Very good suggestion.

Rainer

The rationale behind this suggestion is that editing a mostly invisible
> link is unintuitive when point is at the boundaries of its visible part.
>
> More precisely, in the following visible part of a link
>
>   description
>
> if point hits "d" from the right, changes happen in the description of
> the link, but if point comes from the left, changes happen before the
> link.
>
> I guess I could get used to it, but sometimes, the link happens to be at
> column 0. In this case, the only way to "come from the left" is to move
> to the previous line and go past the newline character. This is, IMO,
> very annoying, notwithstanding the fact that it is impossible to realize
> at the beginning of the buffer.
>
> Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
> before the opening bracket makes changes before the link. Conversely,
> editing after the former makes changes to the uri or the description,
> whichever is displayed.
>
> The cost a little more visual clutter, but it seems very acceptable to
> me. I attach a quick patch for testing.
>
> Feedback welcome.
>
> Regards,
>
> --
> Nicolas Goaziou0x80A93738
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax (F):   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

[O] [RFC] Change visibility for bracket links

[Nicolas Goaziou]

Hello,

I'd like to make the following change to bracket links display (i.e.,
when `org-highlight-links' contains `bracket', which is the default).

Basically, I want to leave a visible pair of brackets around the link,
i.e.,

  [[uri][description]]

is displayed as

  [description]

instead of

  description

and

  [[uri]]

is displayed as

  [uri]

instead of

  uri

The rationale behind this suggestion is that editing a mostly invisible
link is unintuitive when point is at the boundaries of its visible part.

More precisely, in the following visible part of a link

  description

if point hits "d" from the right, changes happen in the description of
the link, but if point comes from the left, changes happen before the
link. 

I guess I could get used to it, but sometimes, the link happens to be at
column 0. In this case, the only way to "come from the left" is to move
to the previous line and go past the newline character. This is, IMO,
very annoying, notwithstanding the fact that it is impossible to realize
at the beginning of the buffer.

Leaving a pair of brackets, OTOH, disambiguates the situation. Editing
before the opening bracket makes changes before the link. Conversely,
editing after the former makes changes to the uri or the description,
whichever is displayed.

The cost a little more visual clutter, but it seems very acceptable to
me. I attach a quick patch for testing.

Feedback welcome.

Regards,

-- 
Nicolas Goaziou0x80A93738
>From 768d77be335e1e5e0a4afa9bf7dbd89f9c5ab65e Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Wed, 5 Oct 2016 17:22:15 +0200
Subject: [PATCH] Change bracket links visibility

* lisp/org.el (org-activate-bracket-links): Leave a pair of brackets
  around bracket links so as to facilitate editing them.
---
 lisp/org.el | 49 ++---
 1 file changed, 18 insertions(+), 31 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 6d5201b..25f48e3 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6199,41 +6199,34 @@ by a #."
 			  (t
 			   `(:uri ,(format "%s:%s" type path)
 	   (activate-func (org-link-get-parameter type :activate-func))
-	   ;; invisible part
-	   (ip (list 'invisible (or
- (org-link-get-parameter type :display)
- 'org-link)
-		 'face face
-		 'keymap keymap
-		 'mouse-face mouse-face
-		 'font-lock-multiline t
-		 'help-echo help
-		 'htmlize-link htmlize-link))
-	   ;; visible part
+	   ;; Visible part.
 	   (vp (list 'keymap keymap
 		 'face face
 		 'mouse-face mouse-face
 		 'font-lock-multiline t
 		 'help-echo help
-		 'htmlize-link htmlize-link)))
+		 'htmlize-link htmlize-link))
+	   ;; Invisible part.
+	   (ip (append (list 'invisible
+			 (or (org-link-get-parameter type :display)
+ 'org-link))
+		   vp)))
   ;; We need to remove the invisible property here.  Table narrowing
   ;; may have made some of this invisible.
   (org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
   (remove-text-properties (match-beginning 0) (match-end 0)
 			  '(invisible nil))
-  (if (match-end 3)
+  (if (match-end 2)
 	  (progn
-	(add-text-properties (match-beginning 0) (match-beginning 3) ip)
-	(org-rear-nonsticky-at (match-beginning 3))
-	(add-text-properties (match-beginning 3) (match-end 3) vp)
-	(org-rear-nonsticky-at (match-end 3))
-	(add-text-properties (match-end 3) (match-end 0) ip)
+	(add-text-properties (match-beginning 0) (match-beginning 2) ip)
+	(add-text-properties (match-beginning 2) (match-end 2) vp)
+	(add-text-properties (match-end 2) (match-end 0) ip)
+	;; The following is needed so as characters inserted after
+	;; the closing bracket do not enter the link.
 	(org-rear-nonsticky-at (match-end 0)))
-	(add-text-properties (match-beginning 0) (match-beginning 1) ip)
-	(org-rear-nonsticky-at (match-beginning 1))
-	(add-text-properties (match-beginning 1) (match-end 1) vp)
-	(org-rear-nonsticky-at (match-end 1))
-	(add-text-properties (match-end 1) (match-end 0) ip)
+	(add-text-properties (match-beginning 0) (1+ (match-beginning 0)) ip)
+	(add-text-properties (1+ (match-beginning 0)) (1+ (match-end 1)) vp)
+	(add-text-properties (1+ (match-end 1)) (match-end 0) ip)
 	(org-rear-nonsticky-at (match-end 0)))
   (when activate-func
 	(funcall activate-func link-start link-end path bracketp))
@@ -23762,10 +23755,7 @@ beyond the end of the headline."
 	;; point was already at beginning of line and command is
 	;; repeated.
 	(when (and (= (point) pos) (eq last-command this-command))
-	  (goto-char after-bullet
-  (setq disable-point-adjustment
-(or (not (invisible-p (point)))
-(not (invisible-p (max (point-min) (1- (point
+	  (goto-char after-bullet)
 
 (defun org-end-of-line ( arg)
   "Go to the end of the line.

Re: [O] Fwd: comment lines inside org tables

[Rolf Sander (MPI)]

Hello Nicolas and everyone else,

I'm sorry to say this but this email list has been the most
disappointing experience for me. I asked a simple question and even
provided the code for a possible solution. The answers I received
included phrases like "can of worms", "little benefit" and "barely
scratching the surface of the problem". And now you even wrote:


I am still waiting for an answer to my question if the solution with
"|-/" comments that I have proposed has any negative side effects...



I already answered to that question, but you discarded my answer.


This is not true! You did not answer my question! Without testing, you
just _speculated_ that you expect problems with formulas and export. So
I tested it myself. In my tests I did _not_ experience any problems with
formulas and export. Why do you claim that I discarded your answer?

I still think orgmode is great code and I would have loved to
participate. However, given the way that you treat me here, I lost my
motivation to work with you. Instead, I will have to modify my own *.el
files.

Good bye...
Rolf

--
---
  Rolf Sander  phone: [+49] 6131/305-4610
  Max-Planck Institute of Chemistryemail: rolf.san...@mpic.de
  PO Box 3060, 55020 Mainz, Germany homepage: www.rolf-sander.net
---
   www.atmospheric-chemistry-and-physics.net
www.geoscientific-model-development.net
---

Re: [O] Fwd: comment lines inside org tables

[Nicolas Goaziou]

Hello,

"Rolf Sander (MPI)"  writes:

> I am still waiting for an answer to my question if the solution with
> "|-/" comments that I have proposed has any negative side effects...

I already answered to that question, but you discarded my answer.

Again, you're hacking a new syntax that the parser doesn't know about.
Besides, the status of this new row type is undefined (wrt to export, to
formulas, to radio tables...). For these reasons, it is bound to have
negative side effects.

Regards,

-- 
Nicolas Goaziou

Re: [O] is there a way to make line numbers appear in ASCII output?

[Nicolas Goaziou]

Hello,

"Christopher W. Ryan"  writes:

> I'm exporting part of my org-mode document as plain text.  Is there
> a way to produce sequential line numbers in the output?

You can implement a post-process filter that adds them. See 

  (info "(org) Advanced configuration")

for examples, and `org-export-filter-final-output-functions'.

Regards,

-- 
Nicolas Goaziou

[O] is there a way to make line numbers appear in ASCII output?

[Christopher W. Ryan]

I'm exporting part of my org-mode document as plain text.  Is there a 
way to produce sequential line numbers in the output?


Thanks.

--Chris Ryan

Re: [O] Is it generally better practice to specify local variables at the first line for Org files?

[Marco Wahl]

> Local variables at the end of the buffer are, indeed, a bit painful to
> handle under Org. Org Footnote handles them reasonably well, I think,
> but that's about it.
>
> I would welcome a general solution to this, as long as it does not
> impede speed of most basic Org commands.
>
> Do you have an idea about it?

I think it's difficult to find a good way to keep something (e.g. the
local variables) at the bottom of an org file.  Up to now the bottommost
tree contains the rest of the file.  There is no bottom.  A certain
bottom would somehow disturb the tree structure as it is, AFAICS.

For the implementation you need to check for many operations if the
bottom is involved.

The header of an org file on the other side is a save place with regards
to operations in the tree.  Personally, if Emacs would allow to place
the local variables block at the beginning of a file, I'd do that.

> Maybe a start would be to have a dedicated
> Org version of `outline-next-heading' that moves before local variables
> when it reaches the end of the buffer.

This sounds like a good idea to me.  This step would keep the local
variables a bit saver, AFAICS.  I can imagine that the implementation of
this idea (and more ideas like this) could yield an almost pain free
local variable experience for org files.


Ciao,
-- 
Marco

Re: [O] [orgweb patch] Add mailinglist archive alternatives

[Takaaki Ishikawa]

Dear Marco,

I agree with your nice idea. Since I have a permission to commit orgweb/ja, so 
I applied your changes to ja branch. I hope Bastien or some other main 
committers will merge it soon.

Best,
Takaaki

> On Oct 5, 2016, at 6:50 PM, Marco Wahl  wrote:
> 
> Hi!
> 
>>> I propose to put the lists.gnu.org archive and The Mail Archive on the
>>> orgmode site, like in the patch below.  WDYT?
>> 
>> It sounds good.
> 
> Yeah, thanks.
> 
> Note that I can _not_ do the change by myself, since I'm not part of the
> respective group.
> 
> So committers to the orgweb, please consider to apply this patch!
> 
> 
> Thanks,
> --
> Marco
> 
> 

--
Takaaki ISHIKAWA 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [O] [DOCS] Re: Making DocBook xml books from org mode?

[Peter Davis]

On Fri, Sep 30, 2016, at 03:37 PM, Nick Dokos wrote:
> Peter Davis  writes:
> 
> > Hi, Tom,
> >
> > On Fri, Sep 30, 2016, at 11:33 AM, Thomas S. Dye wrote:
> >> ... stuff excised ...
> >> 
> >> This was part of the old exporter.  It hasn't been ported to the new one.
> >
> > Thanks, Tom. Christian's post made me wonder if this was hiding in the
> > background somewhere.
> >
> 
> There is a footnote in the (incomplete) page
> 
> http://orgmode.org/worg/exporters/ox-overview.html
> 
> that says:
> 
> ,
> | (1) DocBook export, available in previous Org-mode versions, has not
> | currently been ported to the new exporter, however the new ox-texinfo
> | backend can generate DocBook format. Once file.texi is created via
> | ox-texinfo, simply execute:
> | 
> | makeinfo --docbook file.texi
> `
> 
> I wonder if that will meet the OP's requirements.
> 

I've been trying this, but on Windows 10, makeinfo keeps generating info
files, even with the --docbook switch specified. I can not get it to
output xml.

Thanks,
-pd

-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] Misc. questions

[Peter Davis]

On Tue, Oct 4, 2016, at 04:21 PM, Stig Brautaset wrote:
> Peter Davis  writes:
> > 2) How does the export menu get set? 
> 
> I noticed there's a variable to control it, but whether that's the whole
> story I don't know. Anyway, try:
> 
> : M-x customize-variable RET org-export-backends
> 
> I'm afraid I can't help with the remaining questions.

Ah! The help (C-h v org-export-backends) for this variable says it must
be set before org.el is loaded. Otherwise, it can be modified with
customize, or with some code which is shown in the help.

It appears to have had the initial value (ascii html icalendar latex),
and also has md on my currently running emacs.

Thanks!

-pd

-- 
  Peter Davis
  www.techcurmudgeon.com

Re: [O] Fwd: comment lines inside org tables

[Rolf Sander (MPI)]

Hello Eric,


could you not simply use the / label and then have a comment in one of
the existing columns, a column that is width restricted so that a
large amount of text doesn't affect alignent? You can then use the
special edit mode (C-c `) for long entries to see the full comment.


Thanks for the suggestion. Yes, I could do this and see something like
this in emacs:

|---+--+---+|
|   | <12> |   ||
|   | animal   | size  | number |
|---+--+---+|
|   | gnus | big   |  3 |
| / | don't forg=> |   ||
|   | gnats| small |   1000 |
|---+--+---+|

The real contents of the file, however, would look very different:

|---+--+---+|
|   | <12> |   ||
|   | animal   | size  | number |
|---+--+---+|
|   | gnus | big   |  3 |
| / | don't forget to add elephants here: |   ||
|   | gnats| small |   1000 |
|---+--+---+|

Since I am sharing my table with several colleagues at work, it is
important that the columns are really aligned in the file (not only when
viewing the file in org-mode). Unfortunately, not all of my colleagues
are using emacs...

I am still waiting for an answer to my question if the solution with
"|-/" comments that I have proposed has any negative side effects...

 Best regards
Rolf

--
---
  Rolf Sander  phone: [+49] 6131/305-4610
  Max-Planck Institute of Chemistryemail: rolf.san...@mpic.de
  PO Box 3060, 55020 Mainz, Germany homepage: www.rolf-sander.net
---
   www.atmospheric-chemistry-and-physics.net
www.geoscientific-model-development.net
---

Re: [O] Misc. questions

[Colin Baxter]

On Tue, Oct 04 2016, John Hendy wrote:

> On Tue, Oct 4, 2016 at 2:02 PM, Peter Davis  wrote:
>> I apologize in advance for the flood of questions, but I'm using org in
>> new ways now for creating documentation, and running into a lot of
>> issues.
>>
>> 1) Is there a way to automatically say "yes" to all the "Evaluate code
>> block...?" questions when I export, so I don't have to keep typing "yes"
>> over and over again?
>
- Snip lots ---

I prefer to put nil evaluate as local variables at the very end of your org 
file:

# Local Variables:
# org-confirm-babel-evaluate: nil
# End:

Re: [O] Is it generally better practice to specify local variables at the first line for Org files?

[John Kitchin]

I usually just put a headline at the end, titled "end" or "local
variables", etc.., and tagged noexport,


John

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


On Wed, Oct 5, 2016 at 5:33 AM, Nicolas Goaziou 
wrote:

> Hello,
>
> Marco Wahl  writes:
>
> > I have the same issue.  Currently I try to have an extra eye on the
> > bottommost org tree.  I also use an extra tag to mark the org tree which
> > should be bottommost.  I also use the idea stated in
> > http://www.mail-archive.com/emacs-orgmode@gnu.org/msg106940.html which
> sorts
> > the wanted org tree to the bottom when sorting.
> >
> > For me this works reasonably well.
> >
> > When you put the local variables to the top of the file you are on the
> > save side AFAICT.
> >
> > I try to avoid too much information in the first line.  I prefer to have
> > the variables at the bottom.
>
> Local variables at the end of the buffer are, indeed, a bit painful to
> handle under Org. Org Footnote handles them reasonably well, I think,
> but that's about it.
>
> I would welcome a general solution to this, as long as it does not
> impede speed of most basic Org commands.
>
> Do you have an idea about it? Maybe a start would be to have a dedicated
> Org version of `outline-next-heading' that moves before local variables
> when it reaches the end of the buffer.
>
> Regards,
>
> --
> Nicolas Goaziou
>
>

Re: [O] Bug: org-refile, org-archive-subtree and footnotes [8.3.6 (8.3.6-4-g4835be-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20160926/)]

[Jorge Morais Neto]

On 5 October 2016 at 06:44, Nicolas Goaziou  wrote:
>
> OOC, could you show the footnote section triggering this warning? Org
> Lint ignores property drawers there (i.e., it shouldn't raise an error),
> so I'm wondering how is inserted this timestamp.

I don't understand.  Have I not already given an example in the original email?

-- 
• I am Brazilian.  I hope my English is correct and I welcome corrections.
• Please adopt free formats like PDF, ODF, Org, LaTeX, Opus, WebM and 7z.
• Free (as in free speech) software for Android: https://f-droid.org/

Re: [O] [RFC] Release Org 9.0 by the end of the next week?

[Bastien Guerry]

Hi Nicolas and Rasmus, 

> Rasmus  writes:
>
>> I have the following patches that I could realistically finish soon:
>
> [...]
>>   - ox-html: move title to preamble for more control over layout/final output
>>   - ox-beamer: more keywords (needs to incorporate Nicolas’ feedback)
>>   - ox-publish: more flexible sitemap

This looks great enhancements, thanks.

> Do you need more time, or can it wait for Org 9.1 ?
>
> If it can wait and there isn't anything blocking left, I think we can go
> ahead and release Org 9.0 very soon.

Agreed.

> Bastien, what date is the most appropriate for you?

The second half of october, I should be able to take half a day for
a quick review and for the release.

Thanks,

-- 
 Bastien

Re: [O] [orgweb patch] Add mailinglist archive alternatives

[Marco Wahl]

Hi!

>> I propose to put the lists.gnu.org archive and The Mail Archive on the
>> orgmode site, like in the patch below.  WDYT?
>
> It sounds good.

Yeah, thanks.

Note that I can _not_ do the change by myself, since I'm not part of the
respective group.

So committers to the orgweb, please consider to apply this patch!


Thanks,
-- 
Marco

Re: [O] Bug: org-refile, org-archive-subtree and footnotes [8.3.6 (8.3.6-4-g4835be-elpaplus @ /home/jorge/.emacs.d/elpa/org-plus-contrib-20160926/)]

[Nicolas Goaziou]

Hello,

Jorge  writes:

> On 4 October 2016 at 12:08, Nicolas Goaziou  wrote:
>> BTW, would you want to provide a patch?
> I'm sorry, but I am overloaded.  Besides, I know very little Elisp; for
> example, only in the last few weeks did I learn about backquote constructs.
> Furthermore, I am a very slow programmer even in C, C++ or Python, with which 
> I
> have more experience.

OK. I add it to my TODO list.

> The lint message can make an inexperienced user think there is something wrong
> (I did), and he could waste time investigating the issue or manually removing
> the extraneous elements (thinking they are prejudicial).  Perhaps the message
> could be reworded.  Maybe
>
>   Extraneous elements, which are ignored when exporting, in footnote
>   section.

OOC, could you show the footnote section triggering this warning? Org
Lint ignores property drawers there (i.e., it shouldn't raise an error),
so I'm wondering how is inserted this timestamp.

Regards,

-- 
Nicolas Goaziou

Re: [O] Is it generally better practice to specify local variables at the first line for Org files?

[Nicolas Goaziou]

Hello,

Marco Wahl  writes:

> I have the same issue.  Currently I try to have an extra eye on the
> bottommost org tree.  I also use an extra tag to mark the org tree which
> should be bottommost.  I also use the idea stated in
> http://www.mail-archive.com/emacs-orgmode@gnu.org/msg106940.html which sorts
> the wanted org tree to the bottom when sorting.
>
> For me this works reasonably well.
>
> When you put the local variables to the top of the file you are on the
> save side AFAICT.
>
> I try to avoid too much information in the first line.  I prefer to have
> the variables at the bottom.

Local variables at the end of the buffer are, indeed, a bit painful to
handle under Org. Org Footnote handles them reasonably well, I think,
but that's about it.

I would welcome a general solution to this, as long as it does not
impede speed of most basic Org commands.

Do you have an idea about it? Maybe a start would be to have a dedicated
Org version of `outline-next-heading' that moves before local variables
when it reaches the end of the buffer.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Release Org 9.0 by the end of the next week?

[Nicolas Goaziou]

Hello,

Rasmus  writes:

> I have the following patches that I could realistically finish soon:

[...]
>   - ox-html: move title to preamble for more control over layout/final output
>   - ox-beamer: more keywords (needs to incorporate Nicolas’ feedback)
>   - ox-publish: more flexible sitemap

Do you need more time, or can it wait for Org 9.1 ?

If it can wait and there isn't anything blocking left, I think we can go
ahead and release Org 9.0 very soon.

Bastien, what date is the most appropriate for you?

Regards,

-- 
Nicolas Goaziou

Re: [O] convert scheduled recurring entries into clocked data

[Bala Ramadurai]

Thanks Nicolas for your reply. I am using Org 8.3.4.

The clocking works fine for me and so do recurring state changes. Basic
functioning is OK for me.

Currently, I follow these steps:
1. I don't clock these recurring tasks
2. mark the recurring task as done
3. manually copy the clock data
4. and use M-S- to change the clock data to the current date

I was seeing if the above process can be automated or cleverly done thru
elisp code. I am not adept at elisp, so I was wondering if anyone else had
done this.

Thanks and have a great day!
Bala

http://balaramadurai.net

On Wed, Oct 5, 2016 at 12:13 PM, Nicolas Goaziou 
wrote:

> Hello,
>
> Bala Ramadurai  writes:
>
> > I use org-mode for scheduling and logging in tasks. I clock in
> > non-recurring tasks, however I find it strenuous to clock in recurring
> > tasks. Is there any way I can mark the recurring task done and the
> > scheduled time for the task is converted into clocked data as soon as I
> > mark it done?
> >
> > Example,
> >
> > * TODO Task 1
> > SCHEDULED: <2016-10-04 Tue 10:00-10:30 ++1d>
> >
> > After I mark it done, the task should read
> >
> > * TODO Task 1
> > SCHEDULED: <2016-10-05 Wed 10:00-10:30>
> > :LOGBOOK:
> > - State "DONE"   from "TODO"   [2016-10-04 Tue 11:42]
> > CLOCK: [2016-10-04 Tue 10:00]--[2016-10-04 Tue 10:30] => 0:30
> > :END:
>
> Could you expunge a bit? What happens instead? What is your
> configuration and the Org version you're using? In particular, did you
> try the latest one?
>
> Regards,
>
> --
> Nicolas Goaziou
>

Re: [O] [orgweb patch] Add mailinglist archive alternatives

[Nicolas Goaziou]

Hello,

Marco Wahl  writes:

> I propose to put the lists.gnu.org archive and The Mail Archive on the
> orgmode site, like in the patch below.  WDYT?

It sounds good.

Regards,

-- 
Nicolas Goaziou

[O] [orgweb patch] Add mailinglist archive alternatives

[Marco Wahl]

Hi orgweb people and all,

I propose to put the lists.gnu.org archive and The Mail Archive on the
orgmode site, like in the patch below.  WDYT?


Ciao,
-- 
Marco

>From 7e72e47e6de1146fad668d4577b0fe0fe85a033d Mon Sep 17 00:00:00 2001
From: Marco Wahl 
Date: Wed, 5 Oct 2016 08:08:50 +0200
Subject: [PATCH] Add links to alternative mailing list archives

* community.org: Add two links to alternative mailing list archives.
---
 community.org | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/community.org b/community.org
index 1def48e..605fef0 100644
--- a/community.org
+++ b/community.org
@@ -33,6 +33,9 @@ Browse it [[http://news.gmane.org/gmane.emacs.orgmode][through Gmane]].
 
 #+end_html
 
+Alternatively look at the archives of the mailing list at
+[[http://lists.gnu.org/archive/html/emacs-orgmode/][lists.gnu.org]] or [[http://www.mail-archive.com/emacs-orgmode@gnu.org/][The Mail Archive]].
+
 The mailing list is /the/ central place for anything related to Org: help
 users, report bugs, suggest new features, etc.  Don't hesitate!
 
-- 
2.10.0

Re: [O] convert scheduled recurring entries into clocked data

[Nicolas Goaziou]

Hello,

Bala Ramadurai  writes:

> I use org-mode for scheduling and logging in tasks. I clock in
> non-recurring tasks, however I find it strenuous to clock in recurring
> tasks. Is there any way I can mark the recurring task done and the
> scheduled time for the task is converted into clocked data as soon as I
> mark it done?
>
> Example,
>
> * TODO Task 1
> SCHEDULED: <2016-10-04 Tue 10:00-10:30 ++1d>
>
> After I mark it done, the task should read
>
> * TODO Task 1
> SCHEDULED: <2016-10-05 Wed 10:00-10:30>
> :LOGBOOK:
> - State "DONE"   from "TODO"   [2016-10-04 Tue 11:42]
> CLOCK: [2016-10-04 Tue 10:00]--[2016-10-04 Tue 10:30] => 0:30
> :END:

Could you expunge a bit? What happens instead? What is your
configuration and the Org version you're using? In particular, did you
try the latest one?

Regards,

-- 
Nicolas Goaziou

Re: [O] Is it generally better practice to specify local variables at the first line for Org files?

[Marco Wahl]

Hi Jorge!

> Hi.  In most of my Emacs files, I set any file local variables using a local
> variables list near the end of the file.  However I just realized a pitfall.
> Emacs, according to its manual, only recognizes this local variables list if
> its location fulfills two criteria:
> 1. It starts no more than 3000 characters from the end of the file.
> 2. It is on the last page if the file is divided into pages.

Yes.

> This means that if I refile some Org subtree to another Org file, and the
> refile target is below the local variables list (e. g. if I refile to the top
> level, so that Org chooses the end of the file) then the local variables list
> may start failing one of the criteria and thus silently stop working.  There
> may be other problematic scenarios.

Yes.

> Therefore it seems that, for Org files, it is good practice to avoid this
> pitfall by specifying any file local variables via the other method, i.e. on
> the first line.  I ask for confirmation that this is a general Org Mode good
> practice before I adopt it for all my existing Org files and any future ones.

I have the same issue.  Currently I try to have an extra eye on the
bottommost org tree.  I also use an extra tag to mark the org tree which
should be bottommost.  I also use the idea stated in
http://www.mail-archive.com/emacs-orgmode@gnu.org/msg106940.html which sorts
the wanted org tree to the bottom when sorting.

For me this works reasonably well.

When you put the local variables to the top of the file you are on the
save side AFAICT.

I try to avoid too much information in the first line.  I prefer to have
the variables at the bottom.


Best regards,
-- 
Marco

Re: [O] Repeating tasks with scheduled time

[Nicolas Goaziou]

Hello,

Arkady Grudzinsky  writes:

> On Tue, Oct 04 2016, Arkady Grudzinsky wrote:
>
>> Say, I have this TODO item which needs to be repeated every
>> evening after 20:00 and if it is not marked as DONE for several
>> days, I want it to be moved to the NEAREST 20:00 in the future,
>> i.e. to 20:00 TODAY if I mark it at noon.  I thought, this would
>> accomplish the goal:
>>
>> * TODO Load and run the dishwasher
>>   SCHEDULED: <2016-10-03 Mon 20:00 .+1d>
>
> Sorry, the correct syntax would be 
>
> * TODO Load and run the dishwasher
>   SCHEDULED: <2016-10-03 Mon 20:00 ++1d>
>
> It still moves the scheduled time to the next day instead of
> 20:00 today.
>
>
>>
>> Instead, marking this task as completed today at noon moves the
>> schedule to 20:00 TOMORROW instead of 20:00 TODAY although the
>> nearest 20:00 in the future is, technically, 20:00 TODAY.
>>
>> Is there a way to change this behavior?

IIRC this was fixed in development version, i.e., Org 9.0.

Regards,

-- 
Nicolas Goaziou