Re: [O] BUG: swapped utf-8 symbols in org-entities

2016-07-01 Thread Nicolas Goaziou
Hello,

Konstantin Kliakhandler  writes:

> Attached is the patch, as requested.

Applied. Thank you.

> I'm not sure what were the conclusions of the side discussion, but
> I do want to point out that my change is in accordance with unicode
> symbol names and with the symbols that pdflatex prints on paper.

I think Rasmus (Cc'ed) discovered a bug in TeX input method. Rasmus,
would you feel like reporting it upstream?

Regards,

-- 
Nicolas Goaziou



Re: [O] [PATCH] Reschedule "++" repeaters on same day if in future

2016-07-01 Thread Nicolas Goaziou
Hello,

Don March  writes:

> You're right about both things.  I updated the patch, and also added an
> example to the manual.  If that's not what you had it mind, let me know
> or feel free to edit.

Thank you. 

I used (not (time-less-p (current-time) time)) as suggested instead, so
as to take into consideration the (granted, highly unlikely) case of
time equality, and pushed to master.

Would you mind providing a note about this change in ORG-NEWS?


Regards,

-- 
Nicolas Goaziou



[O] more than 2 indexes in org-mode -> latex

2016-07-01 Thread Sharon Kimble

How many indexes can you have in an org-mode document exported to latex?
My experience shows 2! So how can I have 3, or more please?

This is the relevant part, I think, of my preamble of my file -

--8<---cut here---start->8---
#+latex_header: \usepackage{imakeidx}
#+latex_header: \makeindex[title=Index,options=-s 
./index.ist,columnseprule,intoc]
#+latex_header: \makeindex[name=ps,title=Index of Symptoms,options=-s 
./index.ist,columnseprule,intoc]
# #+latex_header: \makeindex[name=se,title=Index of Side-effects,options=-s 
./index.ist,columnseprule,intoc]
--8<---cut here---end--->8---

I can have any choice of 2, but not 3 as I would like.

In a 'straight' latex file using the above commands I can have 3 or
more, so how do I get it to allow 3 or more in org-mode please?

Thanks
Sharon.
-- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
Debian 8.4, fluxbox 1.3.7, emacs 25.0.95


signature.asc
Description: PGP signature


[O] Meaningful & stable anchors in HTML export

2016-07-01 Thread Vladimir Alexiev
Consider e.g. http://vladimiralexiev.github.io/Multisensor/#sec-3-2-2, which
uses an anchor made from the section number.
I much prefer a readable/meaningful anchor like github does:
https://github.com/VladimirAlexiev/VladimirAlexiev.github.io/tree/master/Mul
tisensor#322-normalization-problems 
Numbered anchors are bad because they are not stable: if I move the section,
the anchor will change. 

Github makes anchors from the heading text, which in my experience are a lot
more stable.
In the above case it added the section number since I have
#+OPTIONS: num:t
in
https://raw.githubusercontent.com/VladimirAlexiev/VladimirAlexiev.github.io/
master/Multisensor/index.org.
But I'm willing to give up section numbering in favor of stable anchors.

In the HTML exporter (ox-html.el) version org-plus-contrib-20150803, the
following are tried in succession to obtain a preferred-id:

  (list (org-element-property :CUSTOM_ID headline)
(concat "sec-" section-number)
(org-element-property :ID headline

The first is manually set CUSTOM_ID property, the second a numbered secton
(eg "sec-3-2-2") and the third an ID that's automatically inserted by
org-store-link.

The newest ox-html.el
(http://orgmode.org/w/?p=org-mode.git;a=blob_plain;f=lisp/ox-html.el;hb=HEAD
) uses this

  (list (org-element-property :CUSTOM_ID headline)
(org-export-get-reference headline info)
(org-element-property :ID headline

You see the second line is changed. It uses org-export-get-reference from
ox.el, 
which uses org-export-new-reference, which "Generates random 7 digits
hexadecimal numbers". 
I don't know if that is stored (which would make it stable), but it's
certainly not meaningful to any reader of the HTML file.

So my request is: the HTML export should have an option 
  org-export-anchors-use-title
to generate section anchors from the section title.

--

There is some code https://github.com/snosov1/toc-org that embeds a TOC
inside the org file,
which is very useful in github (github preview itself doesn't show a TOC).
toc-org generates meaningful (Github-like) links when
toc-org-hrefify-default is "gh".

But as described in https://github.com/snosov1/toc-org/issues/29,
Github keeps the section number, and doesn't strip the TODO and
statistics-cookies.
So a section headline like "3.2.2 TODO Normalization Problems [3/4]"
will get this anchor #322-todo-normalization-problems-34.

So it's best to include further options about which parts of a headline to
use:

- org-export-anchors-use-section-numbers
  "If org-export-with-section-numbers is also enabled, prepend the section
number (without any dashes).
This makes your anchors ugly and less stable, but you need to set this for
Github preview compatibility"
- org-export-anchors-use-todo
  "Prepend TODO/DONE keywords, in lowercase, to section anchors.
This makes your anchors ugly and less stable, but you need to set this for
Github preview compatibility"
-  org-export-anchors-use-title
  "Make section anchors from the words in the section title, converting to
lowercase and replacing punctuation with dash. 
This makes your anchors stable (title changes less frequently than
numbering) and readable. Set this for Github preview compatibility"
- org-export-anchors-use-statistics-cookies
  "Append statistic cookies (e.g. [33%] or [1/3]) to section anchor,
replacing punctuation with dash.
This makes your anchors ugly and less stable, but you need to set this for
Github preview compatibility"





[O] patch for custom help-echo on links

2016-07-01 Thread John Kitchin
I have attached a patch to allow org-link-display-parameters (introduced
in a previous patch for custom faces) to also provide a custom tooltip.
It can be a string or a function, and if neither the old behavior is
used.

WDYT?

-- 
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
diff --git a/lisp/org.el b/lisp/org.el
index 451a668..612a85e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1873,7 +1873,9 @@ The first element in each list is a string of the link
 type. Subsequent optional elements make up a p-list. :face can be
 used to change the face on the link (the default is
 `org-link'. If :display is 'full the full link will show in
-descriptive link mode."
+descriptive link mode. :help-echo can be either a string or a function
+that returns a string. That function should have args of (begin
+end type path) and it should return a string."
   :type '(alist :tag "Link display paramters"
 		:key-type 'string
 		:value-type '(plist))
@@ -5877,10 +5879,14 @@ prompted for."
   (when (and (re-search-forward org-plain-link-re limit t)
 	 (not (org-in-src-block-p)))
 
-(let ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
-   'face))
-	  (link (match-string-no-properties 0))
-	  (type (match-string-no-properties 1)))
+(let* ((face (get-text-property (max (1- (match-beginning 0)) (point-min))
+'face))
+	   (link (match-string-no-properties 0))
+	   (type (match-string-no-properties 1))
+	   (path (match-string-no-properties 2))
+	   (help-echo (plist-get
+		   (cdr (assoc type org-link-display-parameters))
+		   :help-echo)))
   (unless (if (consp face) (memq 'org-tag face) (eq 'org-tag face))
 	(org-remove-flyspell-overlays-in (match-beginning 0) (match-end 0))
 	(add-text-properties (match-beginning 0) (match-end 0)
@@ -5889,6 +5895,15 @@ prompted for."
 	  (cdr (assoc type org-link-display-parameters))
 	  :face)
 	 'org-link)
+   'help-echo (cond
+	   ((stringp help-echo)
+		help-echo)
+	   ((functionp help-echo)
+		(funcall help-echo
+			 (match-beginning 0)
+			 (match-end 0)
+			 type path))
+	   (t nil))
    'htmlize-link `(:uri ,link)
    'keymap org-mouse-map))
 	(org-rear-nonsticky-at (match-end 0))
@@ -6084,13 +6099,31 @@ by a #."
 	   (type (save-match-data
 		   (string-match "\\(.*?\\):" hl)
 		   (match-string 1 hl)))
-	   (help (concat "LINK: " (save-match-data (org-link-unescape hl
+	   (path (save-match-data
+		   (string-match ".*:\\(.*\\)" hl)
+		   (match-string 1 hl)))
+	   (help-echo (plist-get
+		   (cdr (assoc type org-link-display-parameters))
+		   :help-echo))
+	   (help (cond
+		  ((stringp help-echo)
+		   help-echo)
+		  ((functionp help-echo)
+		   (funcall help-echo
+			(match-beginning 0)
+			(match-end 0)
+			type path))
+		  (t
+		   (concat "LINK: "
+			   (save-match-data
+			 (org-link-unescape hl))
 	   (ip (list 'invisible (or (plist-get
  (cdr (assoc type org-link-display-parameters))
  :display)
 'org-link)
 		 'keymap org-mouse-map 'mouse-face 'highlight
-		 'font-lock-multiline t 'help-echo help
+		 'font-lock-multiline t
+		 'help-echo help
 		 'htmlize-link `(:uri ,hl)))
 	   (vp (list 'keymap org-mouse-map 'mouse-face 'highlight
 		 'font-lock-multiline t 'help-echo help


Re: [O] citations not incoprporated from bib file when exporting from .org to pdflatex

2016-07-01 Thread David Abernethy
I eventually stumbled on the solution to my problem:

I restructured my document removing the #+BIBLIOGRAPHY: bib-file style 
statement which no longer seems to work, placing the LateX commands to specify 
the bibliography at the end of the file:

#+LATEX_CLASS: article
#+LATEX_HEADER: \usepackage[margin=0.5in]{geometry}
#+LaTeX_CLASS_OPTIONS: [12pt]

* Objectives
* Stroke care guidelines

#+LATEX: \bibliographystyle{vancouver}
#+LATEX: \bibliography{stroke}

I have this in .emacs to ensure the triple compilation required:
(setq org-latex-pdf-process '("latexmk -pdflatex='pdflatex -interaction 
nonstopmode' -pdf -bibtex -f %f”))

I have not been able to find any guidance on how to deal with this change in 
behaviour by org-mode so post this for others to save them the many hours I 
wasted when I have a deadline to meet


> On 27/06/2016, at 23:20, David Abernethy  wrote:
> 
> 
> I am exporting a file stroke.org  using the bibliography 
> file stroke.bib in the same directory
> The citations are not being incorporated into the pdf file
> 
> An example from stroke.log: LaTeX Warning: Citation `Drummond:2014aa' on page 
> 2 undefined on input line 71.
> 
> The header for stroke.org  is:
> #+LATEX_CLASS: article
> #+BIBLIOGRAPHY: stroke vancouver option:-d
> 



Re: [O] Meaningful & stable anchors in HTML export

2016-07-01 Thread Nicolas Goaziou
Hello,

"Vladimir Alexiev"  writes:

> So my request is: the HTML export should have an option 
>   org-export-anchors-use-title
> to generate section anchors from the section title.

I disagree. Using headline is brittle since it is relatively common for
some headlines to share the same title, and Org internal anchor
mechanism should guarantee there are no duplicates.

You can use a CUSTOM_ID property to force the name of the section
anchor.

Regards,

-- 
Nicolas Goaziou



Re: [O] patch for custom colored links in org-mode

2016-07-01 Thread Nicolas Goaziou
Hello,

John Kitchin  writes:

> Indeed, I based this approach off a patch Rasmus posted some time ago for
> colored blocks ;)
>
> It is also similar to some other approaches in org-mode, e.g.
> the "org-%s-complete-link" functions.

This is yet another obscure part of Org, IMO. I really think we need to
normalize link customization, for an improved user experience.

> Would you consider expanding org-add-link-type like this to set those in
> the special variable?

I don't like much `org-add-link-type' because, it inherently only
operates on additional link types, so it is not sufficient to handle all
customization needs. I'd rather have a single way to control link
behaviour.

I think we could rename `org-link-display-parameters' into
`org-link-type-parameters' and control links from that location. More
explicitly, the value for a given link type (string) could be a plist
with the following properties
- :follow
- :export
- :face
- :display
- :completion
- :echo

The value would contain every link type, including internal ones. Its
value would probably be daunting at first (compared, e.g., with
a boolean) but it would give full control over links.

WDYT?


Regards,

-- 
Nicolas Goaziou



Re: [O] colored-links take 2

2016-07-01 Thread Nicolas Goaziou
John Kitchin  writes:

> I forgot a little piece in the last patch. This one is probably right.

Thank you. Some comments follow.

> +(defcustom org-link-display-parameters nil 
> +  "An alist of properties to display a link with.

An alist between link types and properties to ...

> +The first element in each list is a string of the link

first element -> key

> +type. Subsequent optional elements make up a p-list. :face can be

Double spaces are required between sentences.

> +used to change the face on the link (the default is
> +`org-link'. If :display is 'full the full link will show in

Ditto. Also 'full -> `full'.

There should probably be other allowed values for :display, e.g., `path'
and `description'.

> +descriptive link mode."
> +  :type '(alist :tag "Link display paramters"
> + :key-type 'string
> + :value-type '(plist))
> +  :group 'org-link)

:type is wrong, it should be string' not 'string and plist instead of
'(plist). Also, allowed keywords should probably be specified somewhere.

>(list 'mouse-face 'highlight
> -'face 'org-link
> +'face (or (plist-get
> +   (cdr (assoc type 
> org-link-display-parameters))
> +   :face)
> +  'org-link)

(plist-get ) is begging for a getter, e.g.
`org-link--parameter-value' (which is called with two arguments, the
type as a string and the property as a keyword).

> +(ip (list 'invisible (or (plist-get
> +  (cdr (assoc type 
> org-link-display-parameters))
> +  :display)
> + 'org-link)

See above.

Regards,



[O] Custom source block for concept map markdown

2016-07-01 Thread Ben Feldman
Hi,

my goal is to create a custom source block to create concept maps. The source 
block contains
my custom made pseudo code. When exporting the org-file to LaTeX and PDF this 
pseudo code
must be translated to DOT code. This DOT code is interpreted by the dot2texi 
package.

The reason for the pseudo code is that it is more easy human readable. The 
reason for dot2texi is
that vanilla DOT does not allow for labels on edges, i.e. labels that cross the 
edge.

Here is an example of a concept map:

https://upload.wikimedia.org/wikipedia/commons/c/c3/Electricity_Concept_Map.gif

This is an example of my pseudo code for a single connection between two 
concepts
and a label for that connection:

(Electricity) {is a form of} (Energy)

As you see it looks like a sentence.

The DOT code for this would look like this:

"Electricity" -> "Energy" [label="is a form of"];

Clearly, this doesn’t look like a proper sentence. Therefore I concocted the 
following
function that takes a region containing my pseudo code and translates it to DOT 
code:

(defun concept2dot (rStart rEnd)
  (interactive "r")
  (save-restriction
(narrow-to-region rStart rEnd)
(goto-char (point-min))
(while (re-search-forward "(\\([[:word:]].*\\)) +{\\([[:word:]].*\\)} 
+(\\([[:word:]].*\\))" nil t)
  (replace-match (concat "\"" (match-string 1) "\"" " -> " "\"" 
(match-string 3) "\"" " [label=\"" (match-string 2) "\"];") t nil))
)
  )


After translating my pseudo code to DOT code a LaTeX source block with that DOT 
code would look like this:


#+LATEX_HEADER: \usepackage{dot2texi}
#+LATEX_HEADER: \usepackage{tikz}
#+LATEX_HEADER: \usetikzlibrary{shapes, arrows}

#+BEGIN_LATEX
\begin{dot2tex}[tikz, tikzedgelabels, options={-t raw --nodeoptions='every 
node/.style={text width=2cm, text centered, rounded corners, fill=black!10}' 
--edgeoptions="every node/.style={fill=white, inner sep=1pt}"}]
digraph G {

  node [shape=box, fixedsize=true, width=1.2];

 "Electricity" -> "Energy" [label="is a form of"];

}
\end{dot2tex}
#+END_LATEX


However, I want to avoid firstly translating my pseudo code manually by 
selecting a region and applying my function to it. Secondly, I want to
get rid of all the LaTeX code. Ideally the end result should look like this:

#+BEGIN_SRC conceptmap

(Electricity) {is a form of} (Energy)
(Energy) {that can exist in the form} (Lightning)
(Energy) {that can exist in the form of} (Thunder)

#+END_SRC

When I export my org-file to LaTeX the translation into DOT code occurs 
automatically.

What would be the easiest way to achieve this result? 

Thanks, B.F.


















Re: [O] [PATCH] Reschedule "++" repeaters on same day if in future

2016-07-01 Thread Don March
Nicolas Goaziou  writes:

> Would you mind providing a note about this change in ORG-NEWS?

No problem.  Would you put that in "new features" or "miscellaneous"?



Re: [O] [PATCH] Reschedule "++" repeaters on same day if in future

2016-07-01 Thread Nicolas Goaziou
Don March  writes:

> No problem.  Would you put that in "new features" or "miscellaneous"?

I'd say "miscellaneous" since this is a minor change.

Regards,



Re: [O] patch for custom colored links in org-mode

2016-07-01 Thread John Kitchin
+1 for all this.

Nicolas Goaziou writes:

> Hello,
>
> John Kitchin  writes:
>
>> Indeed, I based this approach off a patch Rasmus posted some time ago for
>> colored blocks ;)
>>
>> It is also similar to some other approaches in org-mode, e.g.
>> the "org-%s-complete-link" functions.
>
> This is yet another obscure part of Org, IMO. I really think we need to
> normalize link customization, for an improved user experience.
>
>> Would you consider expanding org-add-link-type like this to set those in
>> the special variable?
>
> I don't like much `org-add-link-type' because, it inherently only
> operates on additional link types, so it is not sufficient to handle all
> customization needs. I'd rather have a single way to control link
> behaviour.

I agree, it doesn't make sense to use it for customization. OTOH, it
also adds the link type to org-link-types, rebuilds the regexp and the
org-link-protocols.

Do you think we would eliminate `org-link-types' and
`org-link-protocols' then? That would be fine with me.

I think we might still want an org-add-link-type function though, if
there are additional things that need to be done after adding to
`org-link-type-parameters', e.g. updating regexps. It might even be
feasible to keep backward compatibility for code that already uses this.

Presumably we would then eliminate the "org-%s-complete-link" functions?
There don't seem to be many (not including the auto-generated org-ref
related ones ;)

>
> I think we could rename `org-link-display-parameters' into
> `org-link-type-parameters' and control links from that location. More
> explicitly, the value for a given link type (string) could be a plist
> with the following properties
> - :follow
> - :export
> - :face
> - :display
> - :completion
> - :echo
>
> The value would contain every link type, including internal ones. Its
> value would probably be daunting at first (compared, e.g., with
> a boolean) but it would give full control over links.

I like it.

>
> WDYT?
>
>
> Regards,


-- 
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



Re: [O] patch for custom colored links in org-mode

2016-07-01 Thread Nicolas Goaziou
John Kitchin  writes:

> I agree, it doesn't make sense to use it for customization. OTOH, it
> also adds the link type to org-link-types, rebuilds the regexp and the
> org-link-protocols.

It is possible to rebuild regexps upon modifying a defcustom.

> Do you think we would eliminate `org-link-types' and
> `org-link-protocols' then? That would be fine with me.

They would contain duplicate data, so they can be removed.

> I think we might still want an org-add-link-type function though, if
> there are additional things that need to be done after adding to
> `org-link-type-parameters', e.g. updating regexps. It might even be
> feasible to keep backward compatibility for code that already uses
> this.

We already have `org-make-link-regexp'. We can make it call
`org-element-update-syntax' at its end, so as to become a replacement
for `org-add-link-type'.

Every customization of `org-link-parameters' would then call
`org-make-link-regexp'. Users setting the variable by hand, or libraries
defining new types, would be required to call it explicitly, though.

I'm not sure about `org-add-link-type'. It introduces yet another way to
configure link, but makes possible to eschew the `org-make-link-regexp'
call. In any case, it needs to be kept around for
backward-compatibility, but could also be marked as obsolete, pointing
to `org-link-parameters' instead.

WDYT?

> Presumably we would then eliminate the "org-%s-complete-link"
> functions?

Indeed.

I think it is possible to proceed in four steps.

1. First, we create the variable, with appropriate getter, setter and
   default values. At this point it is sufficient to
   support :follow, :export and :completion properties only.

2. Then we get all the code base to extract information about links
   through this variable instead of various existing ways, namely,
   `org-%s-complete-link', `org-link-protocols' and `org-link-types'.

3. Then we extend it with new properties, i.e., :display, :echo
   and :face.

4. Document the changes in the manual and ORG-NEWS file.

You have mostly worked out the third part of the process. Do you want to
take a stab at any of the other steps? Or do you prefer me to do some
parts?

Regards,



Re: [O] patch for custom colored links in org-mode

2016-07-01 Thread Nicolas Goaziou
Hello,

Rasmus  writes:

> Maybe a defcustom consisting of an alist of anonymous faces:
>
> '((R ((:background "red")))
>   (emacs-lisp ((:background "blue"

Sounds good, even if a string as the key might be better (languages are
stored as strings in the parse tree). Also why limit ourselves to
anonymous faces?

Regards,

-- 
Nicolas Goaziou



Re: [O] patch for custom colored links in org-mode

2016-07-01 Thread John Kitchin
If there is no urgency I will take a shot at it next week. I will look through 
the code and come up with a detailed plan that expands on your 4 steps below 
and be in touch about it. Thanks in advance for your patience 😉.

On July 1, 2016, at 7:20 PM, Nicolas Goaziou  wrote:

John Kitchin  writes:

> I agree, it doesn't make sense to use it for customization. OTOH, it
> also adds the link type to org-link-types, rebuilds the regexp and the
> org-link-protocols.

It is possible to rebuild regexps upon modifying a defcustom.

> Do you think we would eliminate `org-link-types' and
> `org-link-protocols' then? That would be fine with me.

They would contain duplicate data, so they can be removed.

> I think we might still want an org-add-link-type function though, if
> there are additional things that need to be done after adding to
> `org-link-type-parameters', e.g. updating regexps. It might even be
> feasible to keep backward compatibility for code that already uses
> this.

We already have `org-make-link-regexp'. We can make it call
`org-element-update-syntax' at its end, so as to become a replacement
for `org-add-link-type'.

Every customization of `org-link-parameters' would then call
`org-make-link-regexp'. Users setting the variable by hand, or libraries
defining new types, would be required to call it explicitly, though.

I'm not sure about `org-add-link-type'. It introduces yet another way to
configure link, but makes possible to eschew the `org-make-link-regexp'
call. In any case, it needs to be kept around for
backward-compatibility, but could also be marked as obsolete, pointing
to `org-link-parameters' instead.

WDYT?

> Presumably we would then eliminate the "org-%s-complete-link"
> functions?

Indeed.

I think it is possible to proceed in four steps.

1. First, we create the variable, with appropriate getter, setter and
   default values. At this point it is sufficient to
   support :follow, :export and :completion properties only.

2. Then we get all the code base to extract information about links
   through this variable instead of various existing ways, namely,
   `org-%s-complete-link', `org-link-protocols' and `org-link-types'.

3. Then we extend it with new properties, i.e., :display, :echo
   and :face.

4. Document the changes in the manual and ORG-NEWS file.

You have mostly worked out the third part of the process. Do you want to
take a stab at any of the other steps? Or do you prefer me to do some
parts?

Regards,


Re: [O] [PATCH] Reschedule "++" repeaters on same day if in future

2016-07-01 Thread Don March
Here is a patch with that addition to ORG-NEWS.
From 18d0d67f7f0efd635351056c185b46e2c2a54d5e Mon Sep 17 00:00:00 2001
From: Don March 
Date: Sat, 2 Jul 2016 02:39:58 -0400
Subject: [PATCH] ORG-NEWS: document last "++" repeater change

---
 etc/ORG-NEWS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ea9e4de..71f44f5 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -447,6 +447,15 @@ Thus the new behavior is to generate this HTML link instead:
 : http://www.gnu.org/software/emacs/manual/html_mono/emacs.html#List-Buffers";>emacs#List Buffers
 
 All emacs related info links are similarly translated plus few other =gnu.org= manuals.
+*** Repeaters with a "++" interval and a time can be shifted to later today
+Previously, if a recurring task had a timestamp of
+=<2016-01-01 Fri 20:00 ++1d>= and was completed on 2016-01-02 at
+08:00, the task would skip 2016-01-02 and would be rescheduled for
+2016-01-03.  Timestamps with "++" cookies and a specific time will now
+shift to the first possible future occurrence, even if the occurrence
+is later the same day the task is completed.  (Timestamps already in
+the future are still shifted one time further into the future.)
+
 * Version 8.3
 
 ** Incompatible changes
-- 
2.8.1