Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]

2020-04-11 Thread Kyle Meyer
Kyle Meyer  writes:

> I've sat down to work on it a few times and wasn't able to get anywhere
> with the time I had available.  It's on my list to revisit.  However, as
> we have no proposed fix, in my view it'd make sense to revert the
> problematic commit, 39c656870.  While that recent commit may resolve a
> longstanding bug in the handling of one-time delays, it causes a
> regression in functionality that I suspect is much more widely used and
> relied on.
>
> I'll plan to revert the commit tomorrow.  Please chime in if you
> disagree with me doing so.

Reverted in 1de7eabf2.



Re: How to get all headings from current location up to the root

2020-04-11 Thread Ihor Radchenko
org-get-outline-path ;) 

George Mauer  writes:

> I feel silly that I can’t figure this out but how do I get the current
> heading, its parent, its parent parent, etc via elisp?

-- 
Ihor Radchenko,
PhD,
Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
University, Xi'an, China
Email: yanta...@gmail.com, ihor_radche...@alumni.sutd.edu.sg



Re: How to add new type of block to a derived back-end?

2020-04-11 Thread Salomon Turgman
Ok... just reporting back my progress in case it helps someone else. Bur
first, all the stuff that you can do with src blocks is stuff I never
imagined. Seems like the possibilities are endless. Here is what I did so
far:

#+NAME: simulation
#+HEADER: :var cap="DEFAULTCAPTION" :cache yes :eval no-export :var
altimage="1_image.svg#img1"
#+BEGIN_SRC emacs-lisp :var divid="defid" :var num=1 :results html :exports
results
(format
"Simulation %s: %s
  

  

  

  

  
  var app = Elm.%s.init({node:
document.getElementById(\"%s\")});"
num cap divid altimage (capitalize divid) divid)
#+END_SRC

That is my "definition"... I call it like this:

#+CALL: simulation(cap="Manual control of tank level", num=1,
divid="main1", altimage="1_manual_noscript.svg")

And it seems to work beautifully. Still need to figure out the counting of
the number of simulations per page... but that should be trivial at this
point. Thank you so much for all the pointers.

-s-

On Fri, Apr 10, 2020 at 1:14 PM Salomon Turgman  wrote:

> Thank you very much. I will explore what you suggest. I'm glad I emailed,
> seems like I was going down the wrong path.
>
> Salomon
>
> On Fri, Apr 10, 2020, 1:10 PM Berry, Charles 
> wrote:
>
>> Salomon, see inline comments below.
>>
>> HTH,
>>
>> Chuck
>>
>> > On Apr 10, 2020, at 7:56 AM, Salomon Turgman 
>> wrote:
>> >
>> > Hello all,
>> >
>> > Thanks in advance for any hints you can provide for this. I am trying
>> to create a derived back-end that handles a new type of block in org-mode.
>> I am trying to derive using the html export backend as a parent.
>> >
>> > Currently I am solving my problem like this:
>> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
>> level.
>> > #+BEGIN_EXPORT html
>> > Simulation 1: Manual control of the tank
>> level.
>> > 
>> > 
>> > 
>> > Some other cool stuff here.
>> > 
>> > 
>> > 
>> > var app = Main1.init({node:
>> document.getElementById("main1")});
>> > #+END_EXPORT
>> >
>> > This has a few downsides:
>> > 1. I have to specify the caption twice since export translator does not
>> handle captions.
>> > 2. I have to include substantial amounts of html.
>> > 3. I have keep track of references to simulations manually (simulation
>> 1, simulation 2, etc)
>> > 4. I have to include the identifier `main1` or `Main1` in several
>> locations in the snippet.
>> >
>> > I could solve some of this with an automated snippet insertion tool but
>> I thought that maybe I can get the export back-end to do most of the work
>> for me.
>> >
>> > So I am trying to derive as follows (in pseudo-elisp-code):
>> > (require 'ox)
>> > (require 'ox-html)
>> >
>> > (org-export-define-derived-backend 'textbook 'html
>> >   :menu-entry
>> >   '(?I "Export textbook section"
>> >((?b "To buffer" org-html-export-as-html)
>> >   (?I "To file" org-html-export-to-html)
>> >   (?o "As HTML file and open"
>> > (lambda (a s v b)
>> >   (if a (org-html-export-to-html t s v b)
>> >   (org-open-file (org-html-export-to-html nil s v
>> b)))
>> >   :translate-alist '((simulation . org-textbook-simulation)))
>>
>> From the `org-export-define-backend' docstring:
>>
>> "TRANSCODERS is an alist between object or element types and
>> functions handling them."
>>
>> But `simulation' is not such a type. So, this will not work.
>>
>> >
>> > (defun org-textbook-simulation (element contents info)
>> >   (let* ((simnum (extract simnum value))
>> >   (caption (org-export-get-caption element))
>> >  (divid (extrac divid value))
>> >   (modid (convert divid into modid))
>> >  )
>> > (format "Simulation %simnum%:
>> %Caption%.
>> >   
>> > 
>> > 
>> >   
>> > var app = %modid%.init({node:
>> document.getElementById(\"%divid%\")});"
>> >simnum caption divid modid divid)))
>> >
>> > With the hope that I can do something like this in my .org file:
>> >
>> > #+CAPTION[Manual control]: Simulation 1: Manual control of the tank
>> level.
>> > #+BEGIN_SIMULATION main1
>> > Some other cool stuff here
>> > #+END_SIMULATION
>>
>>
>> I think an easier approach is to write a babel src-block that formats the
>> inputs you need and creates a value that is your desired output.
>>
>> Use `:var' header arguments to define the inputs.
>>
>> Use `:wrap html' to prevent the exporter from changing the output.
>>
>> Subsequent calls can use the `#+CALL' idiom.
>>
>> You can use any scripting language that suits you - elisp, python, shell,
>> R, ... --- for this purpose.
>>
>> If you are skilled in emacs-lisp you might write an `eval' macro instead
>> of a src block.
>>
>> >
>> > Am I on the right track here? Can someone point me to an example on how
>> to:
>> > 1. Keep track of the number of simulations for referencing?
>>
>> Using the babel approach, you would need a `:session' with a persistent
>> variable that would hold the count. You would need to 

Re: patch for org-confluence.el to add menu entry

2020-04-11 Thread Richard Kim
How about this:

Add key binding for converting org mode to Confluence wiki, i.e.,
'C-x C-e f f' converts current org buffer to a temporary buffer
holding Confluence wiki markup.

This key binding takes effect only when org-confluence.el file
in contrib directory is loaded first.

---

As far as I now, there is no way to make this new key binding work
along with autoload so that it just works.  I think org-confluence.el
has to be loaded first for the key binding to take effect.  I just
need to do (load "org-confluence") in my startup file.


From: Nicolas Goaziou 
Sent: Saturday, April 11, 2020 2:04 PM
To: Richard Kim 
Cc: emacs-orgmode@gnu.org 
Subject: Re: patch for org-confluence.el to add menu entry

Hello,

Richard Kim  writes:

> I would like to suggest the following patch so that I can easily export
> to Confluence wiki format using the usual org-mode export mechanism.

Sure. Could you write a proper commit message and send it again?

Thank you.

Regards,

--
Nicolas Goaziou


Re: wip-cite status question and feedback

2020-04-11 Thread Bruce D'Arcus
On Sat, Apr 11, 2020 at 5:43 PM  wrote:
...

> Well, that depends on your target. If you aim for CSL than that's already 
> fairly complete. (Even it's more than complete since the current CSL 
> specification only knows normal citations. Suppressing authors is done by 
> calling applications, and AuthorInText is a pandoc-specific addition.)

Suppress author is not specific to pandoc; it's used in other CSL
applications like Zotero and Mendeley.

> If you aim for biblatex than there's still a long way to go.
> Concerning "cite", "(cite)", and "citep"
>
> 1. In CSL the basic citation depends on the class of the citation style. 
> Citations appear either as parenthetical citations or in notes.
> It's not a huge deal, but nevertheless...
>
> 2. "citep" is much better than "(cite)", but it is also inaccurate as long as 
> CSL is concerned.
>
> So, I'd rather suggest something along these lines:
>
> cite: => note citation or parenthetical citation => (Doe 2020)
> citet => narrative cite => Doe (2020)
>
> Of course, you might argue that this is too closely tied to CSL. You could 
> also adopt natbib's cite, citet, citep commands, or biblatex's many cite 
> commands...

My only suggestion is to retain the goal of being able to change
back-and-forth from in-text and note-based styles without needing to
modifying the document source.

The pandoc syntax meets that goal.

Biblatex (and likely bibtex) does not, where you have dedicated
citation commands for footcites and such, and so have to modify
document source to make those changes in output.

The downside to the suppress author approach is you have to explicitly
write the author name in the text when doing things like the citet
example above.

So the above would be "Doe [-doe2020]" in pandoc.

I've never found that a problem, but reasonable people disagree.

I'm not 100% sure, but I think citet meets that goal also, so Denis'
suggestion might work.

Bruce



Re: wip-cite status question and feedback

2020-04-11 Thread denis . maier . lists
Hi,

> Let's assume Org implements SuppressAuthor as "-@doe", so far it has:
> 
> | Syntax| Mode| Sample output 
> |
> |---+-+---|
> | @doe or [cite:@doe]   | AuthorInText| Doe (2020)
> |
> | -@doe or [cite:-@doe] | AuthorInText + SuppressAuthor   | (2020)
> |
> | [@doe] or [(cite):@doe]   | NormalCitation  | (Doe, 2020)   
> |
> | [-@doe] or [(cite):-@doe] | NormalCitation + SuppressAuthor | (2020)
> |
> 
> So, we could mix suppress author with some other style, although this
> seems useless for the time being.
> 
> Current syntax is not great because it is ad-hoc, and not very
> future-proof, if new modes appear. Also, the "(cite)" key is a bit
> mouthful, "citep" might have been prettier. Anyway, is it complete
> enough?

Well, that depends on your target. If you aim for CSL than that's already 
fairly complete. (Even it's more than complete since the current CSL 
specification only knows normal citations. Suppressing authors is done by 
calling applications, and AuthorInText is a pandoc-specific addition.)
If you aim for biblatex than there's still a long way to go.
Concerning "cite", "(cite)", and "citep"

1. In CSL the basic citation depends on the class of the citation style. 
Citations appear either as parenthetical citations or in notes. 
It's not a huge deal, but nevertheless...

2. "citep" is much better than "(cite)", but it is also inaccurate as long as 
CSL is concerned.

So, I'd rather suggest something along these lines:
 
cite: => note citation or parenthetical citation => (Doe 2020)
citet => narrative cite => Doe (2020)

Of course, you might argue that this is too closely tied to CSL. You could also 
adopt natbib's cite, citet, citep commands, or biblatex's many cite commands...
 
> Also, there is some ambiguity between modes applying reference-wise,
> i.e., "suppress author", and modes applying to the whole reference,
> i.e., NormalCitation and AuthorInText.
> 
> Therefore, I'm wondering: has the following any meaning?
> 
>   [cite: -@doe; @foo]
>   [(cite): -@doe; @foo]

Good question: I think "[(cite): -@doe; @foo]" is absolutely possible. That 
would be "(2019; Foo 2020)". But what about "[cite: -@doe; @foo]"? That is 
certainly more complicated. How do you render multiple narrative citations?

Best,
Denis



Re: patch for org-confluence.el to add menu entry

2020-04-11 Thread Nicolas Goaziou
Hello,

Richard Kim  writes:

> I would like to suggest the following patch so that I can easily export 
> to Confluence wiki format using the usual org-mode export mechanism.

Sure. Could you write a proper commit message and send it again?

Thank you.

Regards,

-- 
Nicolas Goaziou



How to get all headings from current location up to the root

2020-04-11 Thread George Mauer
I feel silly that I can’t figure this out but how do I get the current
heading, its parent, its parent parent, etc via elisp?


Re: [PATCH] Show hidden drawers when org-cycle on headlines

2020-04-11 Thread Nicolas Goaziou
Hello,

stardiviner  writes:

> I think the hidden drawers info is useful for users, this should be
> shown when org-cycle on headlines.

Doesn't this defeat the whole purpose of drawers? What problem do you
want to solve?

Regards,

-- 
Nicolas Goaziou



Re: wip-cite status question and feedback

2020-04-11 Thread Bruce D'Arcus
On Wed, Apr 8, 2020, 5:32 AM Nicolas Goaziou  wrote:

[snip]

> Sounds like a plan. Let me summarize it a bit :
>
> 1. [ ] Finalize Org citation syntax. It is mostly good, but we need to
>decide about the following points:
>
>- [ ] Should it include both "(cite):" and "cite:", i.e., does it
>  make sense to provide a (very limited) style specification piece
>  wise?

There are two questions here; right?

So (cite:) is the standard citation form (in the pandoc syntax
[@doe19]), and cite: is the bare variant @doe19?

On the latter, probably yes, depending on how ready citeproc.el/org is
to take over processing for more advanced needs.

>- [ ] Should it include /global/ prefix and suffix?

On further reflection, and discussion on the csl forum, I think yes.

The flat pandoc syntax works well, but does break down in one situation:

Where you have a multicite, and where the output processor resorts them.

Global affixes would fix that.

>- [ ] Should we keep the short specification, i.e., "[@key]"?

If you kept it, would it be possible to allow more than one key?

So something like [@doe17; @doe18]?

>- [ ] What kind of markup do we allow in a citation? At the moment
>  the exhaustive list is: bold, code, entity, italic, latex-fragment,
>  strike-through, subscript, superscript, underline, verbatim and
>  line breaks.

I don't see any downside to being liberal here. Do you?

Though most common by far, I think, would be just bold and italic.

> 2. [ ] Decide about API Org should provide for it to be useful. Here are
>some low hanging fruits:
>
>- [ ] List all ".bib" files associated to the document,
>
>- [ ] List all citations,
>
>- [ ] Return citation key at point, if any.
>
>- Anything else?
>
>Moreover, we need to decide about how external processors could plug
>into the export framework.
>
>- [ ] For example, it could be a simple variable bound to a list of
>  functions. Each function accepts three arguments: the export
>  back-end, as a symbol, the full citation, as a list of triplets
>  (key, prefix, suffix) along with global prefix/suffix, and the
>  usual INFO communication channel. Does it need more?
>
>- [ ] Also, the prefix/suffix may contain some Org markup, so this
>  needs to be also processed. Should it happen before, or after the
>  external processor does its job? I.e., should the function
>  translate into Org or target format?

Obviously on the above group of questions, would be really good to
hear from Andras, but the citeproc-el docs should be helpful?

https://github.com/andras-simonyi/citeproc-el#usage

> 3. [ ] Specify the kind of basic translation that be done out of the
>box? Ideally, every non-derived back-end should do something, even
>basic. Therefore, we need to propose some translation pattern for
>each of the following:
>
>- [ ] ASCII
>
>- [ ] HTML
>
>- [ ] LaTeX
>
>- [ ] ODT
>
>- [ ] Texinfo

So this would the default output for each format. This would be
assuming, to go back to earlier posts here, basic formatting built it,
and not integrating citeproc-el?

Bruce



Re: org-clock misleading description for a prompt option

2020-04-11 Thread Dmitrii Korobeinikov
Alright, I see. Thanks for the explanations!

сб, 11 апр. 2020 г. в 03:40, Kyle Meyer :
>
> Dmitrii Korobeinikov  writes:
>
> >> That seems confusing to me as well (at least being the not-advanced
> >> clocker that I am).  I suspect the confusion comes from the different
> >> perspective from which it's written.  You're talking about restarting
> >> Emacs and clocking in again; the description is, I think, written
> >> assuming the context of the prompt being triggered due to idle time.  In
> >> that scenario, hitting i/q or 'k => all' have the same effect; a new
> >> entry is not created.
> >
> > I am not sure I follow. Is idle time some sort of concept used by
> > org-clock for something more than the interface explanations?
>
> Yes, see
>
> (info "(org)Resolving idle time")
>
> Even if you don't customize org-clock-idle-time, the option mentioned in
> the second paragraph of that page, you can trigger that prompt manually
> to account for being idle by calling org-resolve-clocks (bound to 'C-c
> C-x C-z' by default).
>
> > Whether I restart emacs or purposefully insert (while no clocks are
> > running) `CLOCK: [2020-04-10 Fri 22:43]' into a logbook and do
> > org-clock-in, the behaviour is the same.
>
> Right.  I'd say that falls into the same category as the restart.  The
> key, as you mention, it that there is no clock running (versus a clock
> running with idle time to account for).
>
> > Also, 'k => all' is not an
> > option for me, it just asks for a number, defaulting to the elapsed
> > time. Perhaps it's because I am running an older version of org-mode
> > (9.3.6.)
>
> Sorry for the unclear shorthand.  I just meant "hit k, select the
> default value to keep all idle time".



[PATCH] Show hidden drawers when org-cycle on headlines

2020-04-11 Thread stardiviner

I think the hidden drawers info is useful for users, this should be
shown when org-cycle on headlines.

Here is the patch.

-- 
[ stardiviner ]
   I try to make every word tell the meaning what I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
  
From 98e3ece4d2bd6f7c7ccd0ecf70dc327a01bff8bd Mon Sep 17 00:00:00 2001
From: stardiviner 
Date: Sat, 11 Apr 2020 13:16:02 +0800
Subject: [PATCH] org.el: Rename org-cycle-hide-drawers to
 org-cycle-toggle-drawers

* lisp/org.el (org-cycle-toggle-drawers): Make function toggle
show/hide drawers.

* lisp/org-agenda.el (org-cycle-toggle-drawers): updated renamed
functions.

* etc/ORG-NEWS: mention incompatible changes.
---
 etc/ORG-NEWS   |  9 +
 lisp/org-agenda.el |  4 ++--
 lisp/org.el| 26 +-
 3 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index e90ac60e3..244c30be4 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -80,6 +80,11 @@ resulting  will be ~~.
 You may want to check whether your HTML files are rendered differently
 after this change.
 
+*** Renamed ~org-cycle-hide-drawers~ to ~org-cycle-toggle-drawers~
+
+Rename function after added a third optional argument changed function
+meaning. Now drawers will be expanded when ~org-cycle~ on headlines.
+
 ** New default settings for some options
 
 These options now defaults to =t=:
@@ -294,6 +299,10 @@ HTML.
 
 Functions in this hook are run after ~org-agenda-filter~ is called.
 
+*** New option ~org-show-drawer-on-cycle~
+
+Option to control whether expand hidden drawer when ~org-cycle~ on headlines.
+
 ** Removed or renamed functions and variables
 *** Removed  ~org-maybe-keyword-time-regexp~
 
diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index ffb892b0c..e3dca49af 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -9104,7 +9104,7 @@ (defun org-agenda-show-and-scroll-up ( arg)
 	  (ignore-errors (scroll-up)))
   (org-agenda-goto t)
   (org-show-entry)
-  (if arg (org-cycle-hide-drawers 'children)
+  (if arg (org-cycle-toggle-drawers 'children nil t)
 	(org-with-wide-buffer
 	 (narrow-to-region (org-entry-beginning-position)
 			   (org-entry-end-position))
@@ -9164,7 +9164,7 @@ (defun org-agenda-show-1 ( more)
   (outline-show-subtree)
   (save-excursion
 	(org-back-to-heading)
-	(org-cycle-hide-drawers 'subtree '("LOGBOOK")))
+	(org-cycle-toggle-drawers 'subtree '("LOGBOOK") t))
   (message "Remote: SUBTREE AND LOGBOOK"))
  ((> more 4)
   (outline-show-subtree)
diff --git a/lisp/org.el b/lisp/org.el
index 57682fd16..5d5e54574 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -6012,7 +6012,23 @@ (defun org-hide-block-all ()
 
  Drawers visibility
 
-(defun org-cycle-hide-drawers (state  exceptions)
+(defcustom org-show-drawer-on-cycle nil
+  "Whether auto expand hidden drawers when `org-cycle' headlines."
+  :type 'boolean
+  :safe #'booleanp
+  :group 'org)
+
+(defun org-cycle-expand-drawer (state)
+  "Show hidden drawer of headline."
+  (org-cycle-toggle-drawers 'children))
+
+(defun org-enable-cycle-expand-drawer ()
+  (when org-show-drawer-on-cycle
+(add-hook 'org-cycle-hook #'org-cycle-expand-drawer)))
+
+(add-hook 'org-mode-hook #'org-enable-cycle-expand-drawer)
+
+(defun org-cycle-toggle-drawers (state  exceptions flag)
   "Re-hide all drawers after a visibility state change.
 STATE should be one of the symbols listed in the docstring of
 `org-cycle-hook'.  When non-nil, optional argument EXCEPTIONS is
@@ -6031,7 +6047,7 @@ (defun org-cycle-hide-drawers (state  exceptions)
 	  (unless (member-ignore-case (match-string 1) exceptions)
 	(let ((drawer (org-element-at-point)))
 	  (when (memq (org-element-type drawer) '(drawer property-drawer))
-		(org-flag-drawer t drawer)
+		(org-flag-drawer flag drawer)
 		;; Make sure to skip drawer entirely or we might flag
 		;; it another time when matching its ending line with
 		;; `org-drawer-regexp'.
@@ -6427,7 +6443,7 @@ (defun org-set-startup-visibility ()
 (when org-hide-block-startup (org-hide-block-all))
 (org-set-visibility-according-to-property)
 (org-cycle-hide-archived-subtrees 'all)
-(org-cycle-hide-drawers 'all)
+(org-cycle-toggle-drawers 'all nil t)
 (org-cycle-show-empty-lines t)))
 
 (defun org-set-visibility-according-to-property ()
@@ -6532,7 +6548,7 @@ (defun org-clean-visibility-after-subtree-move ()
 	(when (and (not (org-invisible-p))
 		   (org-invisible-p (line-end-position)))
 	  (outline-hide-entry
-	(org-cycle-hide-drawers 'all)
+	(org-cycle-toggle-drawers 'all nil t)
 	(org-cycle-show-empty-lines 'overview)
 
 (defun org-cycle-show-empty-lines (state)
@@ -8076,7 +8092,7 @@ (defun org-sort-entries
 			  "(empty for default `sort-subr' predicate): ")
 		  'allow-empty
 	   ((member dcst '(?p ?t ?s ?d ?c ?k))