[QUESTION] How to use `make-thread` to run org-babel-execute-src-block?

[Christopher Miles]

<#secure method=pgpmime mode=sign>

I have following code snippet config:

(defun org-property-eval-on-cycle-expand (&optional state)
  "Evaluate Org inline source block in property value on headline cycle expand."
  (when (memq state '(children subtree))
(if-let ((inline-src-block (org-entry-get nil "EVAL" nil)))
(with-temp-buffer
  (insert inline-src-block)
  (goto-char (point-min))
  (require 'ob-async nil t)
  (setq-local org-babel-default-inline-header-args
  '((:results . "silent") (:async . t)))
  (let* ((context (org-element-context))
 (src-block-info (org-babel-get-src-block-info nil context))
 (type (org-element-type context)))
(when (eq type 'inline-src-block)
  ;; TODO use `make-thread'
  ;; ob-async: advice `org-babel-execute-src-block:async' on 
‘org-babel-execute-src-block’
  (org-babel-execute-src-block nil src-block-info)))

(add-hook 'org-cycle-hook #'org-property-eval-on-cycle-expand)


I use upper config in bellowing case to auto play video when I expand headline.

* eval inline src code block
  :PROPERTIES:
  :EVAL: src_sh{mpv "video.mp4"}
  :END:



As upper code snippet marked TODO comment. Because I'm using ob-async. So the 
org-babel-execute-src-block is async by default with ob-async's advice. I want 
to get rip of it. Using make-thread, I tried to use (make-thread FUNCTION) (the 
FUNCTION is a wrapper of org-babel-execute-src-block) but it will block current 
Emacs instance. How to make it async without blocking current Emacs?

Hope someone can help me. Thank you in advance.
-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

[PATCH] org-clock.el: clocktable ':formula %' now includes per-file time pct

[Alan D. Salewski]

* lisp/org-clock.el (org-clocktable-write-default): When ':formula %'
  is in-effect, show the per-file time percentage in the '%' column.

This change only has an effect when multiple files are contributing
to a given clocktable (such as when ':scope agenda' has been
specified).  The existing behavior is that such tables have an extra
'File' column, and each individual file that contributes has its own
summary line with the headline value '*File time*'.  Those summary
rows also produce a rollup time value for the file in the 'Time'
column.

Prior to this change, the built-in '%' formula does not produce a
calculation for those per-file times in the '%' column (the relevant
cells in the '%' column were blank).  With this change, the
percentage contribution of each individual file time to the total
time is shown.

The more agenda files you have, the more useful this behavior
becomes.

TINYCHANGE

Signed-off-by: Alan D. Salewski 
---
 lisp/org-clock.el | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index cfd112ec3..8e91609c2 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -2697,7 +2697,18 @@ from the dynamic block definition."
 (format (concat "| %s %s | %s%s%s"
 (format org-clock-file-time-cell-format
 (org-clock--translate "File time" lang))
-" | *%s*|\n")
+
+;; The file-time rollup value goes in the first 
time
+;; column (of which there is always at least 
one)...
+" | *%s*|"
+;; ...and the remaining file time cols (if any) 
are blank.
+(make-string (max 0 (1- time-columns)) ?|)
+
+;; Optionally show the percentage contribution of 
"this"
+;; file time to the total time.
+(if (eq formula '%) " %s |" "")
+"\n")
+
 (file-name-nondirectory file-name)
 (if level?"| " "") ;level column, maybe
 (if timestamp "| " "") ;timestamp column, maybe
@@ -2705,7 +2716,12 @@ from the dynamic block definition."
 (if properties ;properties columns, maybe
 (make-string (length properties) ?|)
   "")
-(org-duration-from-minutes file-time ;time
+(org-duration-from-minutes file-time) ;time
+
+(cond ((not (eq formula '%)) "")  ;time percentage, 
maybe
+  ((or (not total-time) (= total-time 0)) "0.0")
+  (t
+   (format "%.1f" (* 100 (/ file-time (float 
total-time)
 
  ;; Get the list of node entries and iterate over it
  (when (> maxlevel 0)
-- 
a l a n   d.   s a l e w s k i
ads@salewski.email
salew...@att.net
https://github.com/salewski

Re: [bug] Exporting results in "Wrong type argument" when "+CALL" is used

[General discussions about Org-mode.]

> On Jan 30, 2021, at 3:10 PM, Rodrigo Morales  
> wrote:
> 
> 
> As the subject states, executing some exporting commands (see list in
> step 2 below) results in an error when there is at least one "#+CALL"
> statement.
> 
> The backtrace is shown below.
> 
> #+begin_example
> Debugger entered--Lisp error: (wrong-type-argument consp nil)
>  org-babel-exp-code(nil lob)

[snip]

There is a malformed line:

#+CALL: foo

and M-x org-lint fails to find it. See (info "(org) Evaluating Code Blocks")

Using  

#+CALL: foo()

works.

Curiously enough, placing that line at the very end of file (i.e. with no 
trailing newline) works.

HTH,

Chuck

Re: [PATCH] ox-md.el export code blocks using grave accents

[Rodrigo Morales]

Please, omit this duplicated thread. It has already been discussed.

This thread was created due to an error of mine.

On Thu, 28 Jan 2021 at 22:51, Rodrigo Morales 
wrote:

>
> Sorry for not attaching the files. Here they are.
>
>
> --
> Greetings,
> Rodrigo Morales.
>

[patch] to allow org-attach-git to handle individual repositories

[Juan Manuel Macías]

Hi,

I would like to propose and discuss this patch for org-attach-git,
following a series of comments and suggestions from Ihor Radchenko in
this thread:
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00483.html

This patch would allow org-attach-git to handle individual repositories,
that is, any repository initialized in a directory attached to a node.
A custom variable is provided, that admits two values:

1. default: the default value, which is equivalent to the old behavior

2. individual-repository: which activates the 'new' feature.

Best regards,

Juan Manuel

diff --git a/lisp/org-attach-git.el b/lisp/org-attach-git.el
index 2091cbc61..54df5b9ba 100644
--- a/lisp/org-attach-git.el
+++ b/lisp/org-attach-git.el
@@ -52,9 +52,26 @@ If \\='ask, prompt using `y-or-n-p'.  If t, always get.  If nil, never get."
 	  (const :tag "always get from annex if necessary" t)
 	  (const :tag "never get from annex" nil)))
 
+(defcustom org-attach-git-dir 'default
+  "The attachment directory where a Git repository must be
+handled. The default value is `default', which is equivalent to
+`org-attach-id-dir'. If the value is `individual-repository', it
+means that the directory attached to the current node should be
+handled as a individual repository, as long as it has been
+conveniently initialized."
+  :group 'org-attach
+  :package-version '(Org . "9.0")
+  :version "26.1"
+  :type '(choice
+  (const :tag "Default" default)
+  (const :tag "Individual repository" individual-repository)))
+
 (defun org-attach-git-use-annex ()
   "Return non-nil if git annex can be used."
-  (let ((git-dir (vc-git-root (expand-file-name org-attach-id-dir
+  (let ((git-dir (vc-git-root (cond ((eq org-attach-git-dir 'default)
+   (expand-file-name org-attach-id-dir))
+  ((eq org-attach-git-dir 'individual-repository)
+   (org-attach-dir))
 (and org-attach-git-annex-cutoff
  (or (file-exists-p (expand-file-name "annex" git-dir))
  (file-exists-p (expand-file-name ".git/annex" git-dir))
@@ -62,7 +79,10 @@ If \\='ask, prompt using `y-or-n-p'.  If t, always get.  If nil, never get."
 (defun org-attach-git-annex-get-maybe (path)
   "Call git annex get PATH (via shell) if using git annex.
 Signals an error if the file content is not available and it was not retrieved."
-  (let* ((default-directory (expand-file-name org-attach-id-dir))
+  (let* ((default-directory (cond ((eq org-attach-git-dir 'default)
+   (expand-file-name org-attach-id-dir))
+  ((eq org-attach-git-dir 'individual-repository)
+   (org-attach-dir
 	 (path-relative (file-relative-name path)))
 (when (and (org-attach-git-use-annex)
 	   (not
@@ -86,7 +106,10 @@ This checks for the existence of a \".git\" directory in that directory.
 
 Takes an unused optional argument for the sake of being compatible
 with hook `org-attach-after-change-hook'."
-  (let* ((dir (expand-file-name org-attach-id-dir))
+  (let* ((dir (cond ((eq org-attach-git-dir 'default)
+   (expand-file-name org-attach-id-dir))
+  ((eq org-attach-git-dir 'individual-repository)
+   (org-attach-dir
 	 (git-dir (vc-git-root dir))
 	 (use-annex (org-attach-git-use-annex))
 	 (changes 0))

[PATCH] document org-html-meta-tags

[TEC]

Hi Kyle, All,

As requested, here's a small documentation entry for the new setting :)

>From 636330422eef59f448a60b933be9a5581af9 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Mon, 1 Feb 2021 03:01:12 +0800
Subject: [PATCH] manual, news: Document org-html-meta-tags

* docs/org-manual.org, etc/ORG-NEWS: Document and announce the new
setting `org-html-meta-tags'.
---
 doc/org-manual.org | 3 +++
 etc/ORG-NEWS   | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 20a0d1d7a..a82b0f9a4 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -12624,6 +12624,9 @@ settings described in [[*Export Settings]].
   multiple =DESCRIPTION= lines.  The exporter takes care of wrapping
   the lines properly.
 
+  The exporter includes a number of other meta tags, which can be customised
+  by modifying ~org-html-meta-tags~.
+
 - =HTML_DOCTYPE= ::
 
   #+cindex: @samp{HTML_DOCTYPE}, keyword
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index ba769224f..a2f1667b2 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -81,6 +81,13 @@ block. ~org-babel-latex-preamble~, ~org-babel-latex-begin-env~ and
 the user to specify the preamble and code that preceedes and proceeds
 the contents of the source block.
 
+*** New option ~org-html-meta-tags~  allows for HTML meta tags customisation
+
+New variable ~org-html-meta-tags~ makes it possible to customise the
+== tags used in an HTML export. Accepts either a static list of
+values, or a function that generates such a list (see
+~org-html-meta-tags-default~ as an example of the latter).
+
 ** New features
 *** =ob-python= improvements to =:return= header argument 
 
-- 
2.30.0


Oh, by the way --- regarding your commits on commit/code conventions.
With (what seem like to me) quite a few "best practices" to keep in
mind, has anyone created a patch lint tool to make sure they're being
adhered to? I imagine it wouldn't be hard to check for blank lines in
functions or commits without a sentence case commit message.

For someone who isn't aware of all the nits that may be picked :P this
would be rather useful, and far better than a list of guidelines (I'm
not actually any such list though).

Oh dear, I sense myself diverging but I'm now considering the
possibility of setting up CI for the org-mode repo to check for as many
such concerns as we can to try to make the code base more consistent
(from my experience, every time I'm told to check for a specific issue
in a patch I wrote, I find many other matches in the file).

Perhaps it could be possible to hook up the ML to a process that runs
the CI script on a copy of Org with the patch(es) applied and replies
with any errors that may come up?

I should really stop here, before I really get going and start
explaining why I think it could be good to migrate to Gitea and other
ideas :P

Feel free to disregard my ramble, I've just been accumulating thoughts
on the state of Org development, and a few are liable to spill out.

All the best,

Timothy

Re: Microsoft Excel getting features we have had for a long time in org :-)

[Eric S Fraga]

On Sunday, 31 Jan 2021 at 19:38, to...@tuxteam.de wrote:
> At least you can keep your APL programs in an VCS and the diffs might
> make sense. Try that with excel.

Very true, and the same applies to org tables (i. e. being able to use
version control).

And, as an aside, I love APL!  I just recognise the challenges of
sharing APL codes.  But, to be fair, it's been decades since I last used
APL (or J).

Also, I do use org tables quite extensively as spreadsheets but I'm also
careful to avoid making them inscrutable to all (including me).  As soon
as a table starts getting too complex, I move the coding to a src block
with the table as input (and maybe another table as output).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-199-gbc511b

Re: Microsoft Excel getting features we have had for a long time in org :-)

[TEC]

Eric S Fraga  writes:

> I actually tell (warn?) my students that spreadsheets are an example of
> a "write-only programming language", the other being APL (for those with
> long memories).

I may not be of the right generation to remember APL, but I used to love
spreadsheets ... until I had to look at the same spreadsheet later
[shudder].

Using Org tables for small things and an actual program (python, R,
julia, etc.) for anything medium-large I've found vastly superior to
spreadsheets.

Good for Excel, but as far as I'm concerned it's a bit like making a
pitcher plant smell nicer 🙃. The trap is more enticing, but you still
end up in the same mess.

--
Timothy

Re: Microsoft Excel getting features we have had for a long time in org :-)

[Gyro Funch]

In one of the simulation classes I teach, I try to convey the same
message.  :-)

In a past life, I had to extend applications that used Excel as a
front-end with a combination of interlinked functions in spreadsheet
cells plus plenty of Visual Basic with a few compiled dlls rolled into
the mix. The dlls (which I wrote in fortran) were the only components
for which I had any confidence.

Fun times!  ;-)

-gyro 

On 1/31/2021 11:17 AM, Eric S Fraga wrote:
> On Friday, 29 Jan 2021 at 13:36, gyro funch wrote:
>> Oooh. That should make Excel spreadsheets even funner to audit.
> :-)
>
> I actually tell (warn?) my students that spreadsheets are an example of
> a "write-only programming language", the other being APL (for those with
> long memories).
>

Re: Microsoft Excel getting features we have had for a long time in org :-)

[tomas]

On Sun, Jan 31, 2021 at 06:17:50PM +, Eric S Fraga wrote:
> On Friday, 29 Jan 2021 at 13:36, gyro funch wrote:
> > Oooh. That should make Excel spreadsheets even funner to audit.
> 
> :-)
> 
> I actually tell (warn?) my students that spreadsheets are an example of
> a "write-only programming language", the other being APL (for those with
> long memories).

At least you can keep your APL programs in an VCS and the diffs might
make sense. Try that with excel.

(Actually, over here, excel is a plague, at least in public administration:
lots of "knowledge" is buried in inscrutable excel macros nobody dares to
touch after a while. This might explain why such sites are crippled for
weeks after a ransomware attack).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Microsoft Excel getting features we have had for a long time in org :-)

[Eric S Fraga]

On Friday, 29 Jan 2021 at 13:36, gyro funch wrote:
> Oooh. That should make Excel spreadsheets even funner to audit.

:-)

I actually tell (warn?) my students that spreadsheets are an example of
a "write-only programming language", the other being APL (for those with
long memories).

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-199-gbc511b

bug#44824: 27.1; Org export as pdf and open file does not open it

[Maxim Nikulin]

On 31/01/2021 23:33, Eli Zaretskii wrote:



To fix the problem it is better to use (make-process :connection-type
'pipe ...) that unfortunately has no higher level wrappers.


Wouldn't it work to let-bind process-connection-type to nil around the
function that starts the async subprocess?



...



Well, I think we should try this, because if it works, it will show us
a way to fix the problem.  (I don't see how lexical-binding could
interfere with let-binding.)


It is not a great problem to use make-process:

https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00364.html

I think that at least a :sentinel should be added to improve error 
reporting. The code just before these lines has another problem (I hope 
it is really rare): 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00353.html


I would avoid shell since direct execution of the handler should be more 
robust, e.g. quoting of arguments is not necessary. Unfortunately RFC on 
mailcap states that command is executed by shell. On the other hand only 
a few of viewer entries have commands that could not be handled without 
shell.

bug#44824: 27.1; Org export as pdf and open file does not open it

[Eli Zaretskii]

> From: Maxim Nikulin 
> Date: Sun, 31 Jan 2021 22:57:57 +0700
> Cc: 44...@debbugs.gnu.org
> 
> >> To fix the problem it is better to use (make-process :connection-type
> >> 'pipe ...) that unfortunately has no higher level wrappers.
> > 
> > Wouldn't it work to let-bind process-connection-type to nil around the
> > function that starts the async subprocess?
> 
> Sorry, for me it easier to reason how to express it in terms of system 
> calls and terminal process groups than if let-bind could override a 
> variable when lexical-bind is set to true.

Well, I think we should try this, because if it works, it will show us
a way to fix the problem.  (I don't see how lexical-binding could
interfere with let-binding.)

bug#44824: 27.1; Org export as pdf and open file does not open it

[Maxim Nikulin]

On 31/01/2021 22:05, Eli Zaretskii wrote:

From: Maxim Nikulin
Date: Sun, 31 Jan 2021 18:15:27 +0700

Now I see that the problem with eshell is the same. I am not familiar
with eshell, but it creates new shell process for every executed
command. Actual handler is killed when underlying handler (kde-open5,
"gio open") and thus xdg-open and the main shell process exit.


What do you mean here by "actual handler" and "underlying handler"?


- actual handler: okular, evince, etc.
- underlying handler is what xdg-open actually calls: kde-open5, "gio 
open", etc. and that maps file type to particular .desktop (or mailcap) 
handler.



To fix the problem it is better to use (make-process :connection-type
'pipe ...) that unfortunately has no higher level wrappers.


Wouldn't it work to let-bind process-connection-type to nil around the
function that starts the async subprocess?


Sorry, for me it easier to reason how to express it in terms of system 
calls and terminal process groups than if let-bind could override a 
variable when lexical-bind is set to true.



And I still don't understand why some people (like Lars) cannot
reproduce the problem at all -- the issue sounds like something that
should fail deterministically on any GNU/Linux system.  What am I
missing?


On 31/01/2021 22:17, Andreas Schwab wrote:
>
> If xdg-open doesn't need to start the program itself, and sends the
> request to an already running process instead, there won't be any
> problem with the disappearing session.

I have been tempting to say that it is a race (either request is 
completed before SIGHUP or not) since Christopher Miles posted a link to 
stackexchange and I have realized the actual effect of an 
antidaemonizing cast I noticed earlier in a package related to org mode. 
On the other hand, I am not familiar with kde and gnome internals. I 
guess they could use a kind of server processes but I have no idea how 
to arrange parts for a convincing demonstration.

bug#44824: 27.1; Org export as pdf and open file does not open it

[Eli Zaretskii]

> From: Andreas Schwab 
> Cc: Maxim Nikulin ,  44...@debbugs.gnu.org,
>   gbio...@gmail.com
> Date: Sun, 31 Jan 2021 16:17:46 +0100
> 
> On Jan 31 2021, Eli Zaretskii wrote:
> 
> > And I still don't understand why some people (like Lars) cannot
> > reproduce the problem at all -- the issue sounds like something that
> > should fail deterministically on any GNU/Linux system.  What am I
> > missing?
> 
> If xdg-open doesn't need to start the program itself, and sends the
> request to an already running process instead, there won't be any
> problem with the disappearing session.

Ah, okay.  Lars, could this be what happens on your system?

bug#44824: 27.1; Org export as pdf and open file does not open it

[Lars Ingebrigtsen]

Eli Zaretskii  writes:

> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system.  What am I
> missing?

The recipe said to start with `M-x shell' -- I wasn't able to reproduce
the problem there.  But with `M-x eshell' I can repeat the problem here,
too.

Perhaps the recipe was wrong?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44824: 27.1; Org export as pdf and open file does not open it

[Andreas Schwab]

On Jan 31 2021, Eli Zaretskii wrote:

> And I still don't understand why some people (like Lars) cannot
> reproduce the problem at all -- the issue sounds like something that
> should fail deterministically on any GNU/Linux system.  What am I
> missing?

If xdg-open doesn't need to start the program itself, and sends the
request to an already running process instead, there won't be any
problem with the disappearing session.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#44824: 27.1; Org export as pdf and open file does not open it

[Eli Zaretskii]

> From: Maxim Nikulin 
> Cc: Eli Zaretskii , gbio...@gmail.com
> Date: Sun, 31 Jan 2021 18:15:27 +0700
> 
> Now I see that the problem with eshell is the same. I am not familiar 
> with eshell, but it creates new shell process for every executed 
> command. Actual handler is killed when underlying handler (kde-open5, 
> "gio open") and thus xdg-open and the main shell process exit.

What do you mean here by "actual handler" and "underlying handler"?

> Functions dealing with asynchronous processes in emacs, namely 
> (start-process ...) and its siblings for shell commands calls 
> (make-process :connection-type 'pty ...) that creates a pseudoterminal. 
> It is redundant for applications that do not require an interactive 
> terminal. When process (xdg-open this case) exits, pty is closed, all 
> processes from the same terminal group receives SIGHUP. So actual 
> handler is killed unless it has set signal handler or has detached from 
> terminal session.
> 
> To fix the problem it is better to use (make-process :connection-type 
> 'pipe ...) that unfortunately has no higher level wrappers.

Wouldn't it work to let-bind process-connection-type to nil around the
function that starts the async subprocess?

And I still don't understand why some people (like Lars) cannot
reproduce the problem at all -- the issue sounds like something that
should fail deterministically on any GNU/Linux system.  What am I
missing?

Re: org-attach-git don't automatically commit changes

[Juan Manuel Macías]

Ihor Radchenko  writes:

> What is more tricky is making sure that workflow for people using the
> old behaviour is not broken. Just changing to (org-attach-dir) will
> break existing git repos in org-attach-id-dir. This should also not be
> too hard (say, we can introduce a custom variable defaulting to old
> behaviour), but exact details may need to be discussed.

I agree: I think a custom variable with the current behavior by default
would be fine.

> In any case, if you provide a patch, it will encourage the org
> maintainers to join this discussion and proceed with changes.

OK, this week I will try to propose a patch here, and bring it up for
(possible) discussion. Thanks for the suggestions.

Best regards,

Juan Manuel 

Re: org-attach-git don't automatically commit changes

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Do you think a possible patch could simply consist of replacing (as I
> have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
> in `org-attach-git-commit'? This would allow you to handle attachment
> dirs as individual git repos, regardless of :ID: or :DIR: properties,
> since "[(org-attach-dir)] Return the directory associated with the
> current outline node. First check for DIR property, then ID property
> [...]".

All the instances of (expand-file-name org-attach-id-dir) should be
replaced. There are 3. That's not a big deal.

What is more tricky is making sure that workflow for people using the
old behaviour is not broken. Just changing to (org-attach-dir) will
break existing git repos in org-attach-id-dir. This should also not be
too hard (say, we can introduce a custom variable defaulting to old
behaviour), but exact details may need to be discussed.

In any case, if you provide a patch, it will encourage the org
maintainers to join this discussion and proceed with changes.

Best,
Ihor

Re: org-attach-git don't automatically commit changes

[Juan Manuel Macías]

Ihor Radchenko  writes:

> The other thing is that `org-attach-id-dir' makes much less sense from
> the time :DIR: property was introduced. So, I believe that
> org-attach-git should be updated. Probably, handling attachment dirs as
> individual git repos can be one of the ways to upgrade the current
> version. I guess, patches welcome.

Do you think a possible patch could simply consist of replacing (as I
have done) `(expand-file-name org-attach-id-dir)' by `(org-attach-dir)'
in `org-attach-git-commit'? This would allow you to handle attachment
dirs as individual git repos, regardless of :ID: or :DIR: properties,
since "[(org-attach-dir)] Return the directory associated with the
current outline node. First check for DIR property, then ID property
[...]".

Best regards,

Juan Manuel 

Re: org-attach-git don't automatically commit changes

[Juan Manuel Macías]

Ihor Radchenko  writes:

> I think you misunderstood how org-attach-git works.
>
> org-attach-git is:
>
> ;; An extension to org-attach.  If `org-attach-id-dir' is initialized
> ;; as a Git repository, then org-attach-git will automatically commit
> ;; changes when it sees them.  Requires git-annex.
>
> So, it is not designed to work when your actual attachment directory is
> a git repo, but rather when org-attach-id-dir is a git repo (initialised
> manually).

Thanks for the explanation: it is clear that I had misinterpreted
`org-attach-id-dir'. Now it makes sense that it didn't work for me.
Anyway, I think the manual at that point is somewhat ambiguous and it
should be more precise, IMHO.

> So, I believe that org-attach-git should be updated. Probably,
> handling attachment dirs as individual git repos can be one of the
> ways to upgrade the current version.

I agree, I think this possibility makes a lot more sense.

Best regards,

Juan Manuel 

bug#44824: 27.1; Org export as pdf and open file does not open it

[tomas]

On Sun, Jan 31, 2021 at 06:15:27PM +0700, Maxim Nikulin wrote:
> Bhavin, thank you very much for your clear report. I have tried once
> more with eshell session and this time I was lucky enough to
> reproduce the problem in both gnome and kde sessions on Ubuntu-20.04
> focal

[...]

> 2221  16:59:43.717489 +++ exited with 0 +++
> 2229  16:59:43.719228 +++ killed by SIGHUP +++

Good catch.

> On 31/01/2021 16:09, to...@tuxteam.de wrote:
> >This chaotic behaviour gives me the impression that it's an
> >environment thing [...]

> Certainly the behavior depends on the desktop environment. You could
> check which DE-specific handler is called (and factor-out xdg-open)
> with
> 
> sh -x /usr/bin/xdg-open /tmp/test.pdf
> 
> As to other options, M-! executes the process synchronously and is
> not affected. M-& has the same pty+SIGHUP problem.
> 
> I am almost sure that I have tried eshell before, but I have no idea
> why I have not noticed the problem that time.

Yes, but in this case it seems I was barking up the wrong tree :)

Cheers & thanks
 - t


signature.asc
Description: Digital signature

Re: tickler file & recurring events

[Saša Janiška]

Ihor Radchenko writes:

> Check org-agenda-show-future-repeats
> ( v org-agenda-show-future-repeats ).

Thanks a lot, that's just what I need!!


Sincerely,
Gour


-- 
A person who has given up all desires for sense gratification,
who lives free from desires, who has given up all sense of
proprietorship and is devoid of false ego — he alone can
attain real peace.

Re: [PATCH] capture: Fix handling of time range for :time-prompt

[Richard Lawrence]

Dear Kyle and all,

Thanks for following up! Sorry it's taken me so long to reply.

Kyle Meyer  writes:

> Testing that against the cases in your initial report, I believe it
> leads to the same results as your patch, so here's a cleaned-up version.

I confirm that this cleaned up version works for me and gets the same
results for my test cases. I think it should be applied (modulo one
nitpick below). Are you willing to apply it, Kyle? I don't have commit
rights myself.

> -- >8 --
> Subject: [PATCH] capture: Fix handling of time range for :time-prompt
>
> * lisp/org-capture.el (org-capture-set-target-location): Bind
> org-end-time-was-given around the org-read-date call to get a return
> value that uses the start time rather than doing custom adjustment of
> the return value.
>
> If org-capture-set-target-location detects that the answer to
> org-read-date has a time range, it strips the end time from the answer
> and calls org-read-date-analyze again.  (org-read-date already calls
> it underneath.)  The regexp it uses, however, can easily match a date,
> leading to a bogus result.
>
> org-read-date-analyze is already capable of processing the time range
> in a way that matches org-capture-set-target-location's intent: when
> org-end-time-was-given is bound, org-read-date-analyze splits off the
> end value of the range and stores it in org-end-time-was-given.  Drop
> the custom logic and let org-read-date-analyze handle the range.
>
> Reported-by: Richard Lawrence 
> Ref: https://orgmode.org/list/87h7obh4ct.fsf@aquinas
> ---
>  lisp/org-capture.el | 35 +++
>  1 file changed, 15 insertions(+), 20 deletions(-)
>
> diff --git a/lisp/org-capture.el b/lisp/org-capture.el
> index f40f2b335..d7b69f228 100644
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -1025,28 +1025,23 @@ (defun org-capture-set-target-location (&optional 
> target)
>  (time-to-days org-overriding-default-time))
> ((or (org-capture-get :time-prompt)
>  (equal current-prefix-arg 1))
> -;; Prompt for date.
> -(let ((prompt-time (org-read-date
> -nil t nil "Date for tree entry:")))
> +   ;; Prompt for date.  Bind `org-end-time-was-given' so
> +   ;; that `org-read-date-analyze' handles the time range
> +   ;; case and returns `prompt-time' with the start value.
> +   (let* ((org-time-was-given nil)
> +  (org-end-time-was-given nil)
> +  (prompt-time (org-read-date
> + nil t nil "Date for tree entry:")))
>(org-capture-put
> :default-time
> -   (cond ((and (or (not (boundp 'org-time-was-given))
> -   (not org-time-was-given))
> -   (not (= (time-to-days prompt-time) (org-today
> -  ;; Use 00:00 when no time is given for another
> -  ;; date than today?
> -  (apply #'encode-time 0 0
> - org-extend-today-until
> - (cl-cdddr (decode-time prompt-time
> - ((string-match "\\([^ ]+\\)-[^ ]+[ ]+\\(.*\\)"
> -org-read-date-final-answer)
> -  ;; Replace any time range by its start.
> -  (apply #'encode-time
> - (org-read-date-analyze
> -  (replace-match "\\1 \\2" nil nil
> - org-read-date-final-answer)
> -  prompt-time (decode-time prompt-time
> - (t prompt-time)))
> +  (if (and (or (not org-time-was-given))

Nitpick: (or (not org-time-was-given)) is equivalent to (not org-time-was-given)

> +   (not (= (time-to-days prompt-time) (org-today
> +  ;; Use 00:00 when no time is given for another
> +  ;; date than today?
> +  (apply #'encode-time 0 0
> + org-extend-today-until
> + (cl-cdddr (decode-time prompt-time)))
> +prompt-time))
>(time-to-days prompt-time)))
> (t
>  ;; Current date, possibly corrected for late night
>
> base-commit: 9e8215f4a5df7d03ac787da78d28f69a4c18e7d3

As for this:

> The original change came in b61ff117b (org-capture.el:
> Set a correct time value with file+datetree+prompt, 2012-09-24), and I
> believe the related thread is
> .

Thanks for the reference to this thread. I would like to be able to do
exactly what Gregor mentioned there:

- be prompted when capturing for the date and time / time range of the
  event/appointment.
- record th

bug#44824: 27.1; Org export as pdf and open file does not open it

[Maxim Nikulin]

Bhavin, thank you very much for your clear report. I have tried once 
more with eshell session and this time I was lucky enough to reproduce 
the problem in both gnome and kde sessions on Ubuntu-20.04 focal


On 30/01/2021 23:28, Eli Zaretskii wrote:

From: Maxim Nikulin
Date: Sat, 30 Jan 2021 22:58:06 +0700

The problem is that emacs does not expect that kde-open5 and thus
xdg-open exits instantly.


Why is that a problem, and how does it cause the invocation to fail,
i.e. not show the file in question?


The question could be addressed to KDE developers, but unlike the
issue with temporary files, in my opinion, pty+SIGHUP problem should
be fixed in org mode.


What do you mean by "pty+SIGHUP problem" in this case?  What exactly
is the problem?


In the https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44824#22 message I 
have posted a link to another thread in emacs-orgmode mail list thread 
with my earlier strace results: 
https://lists.gnu.org/archive/html/emacs-orgmode/2021-01/msg00327.html


Now I see that the problem with eshell is the same. I am not familiar 
with eshell, but it creates new shell process for every executed 
command. Actual handler is killed when underlying handler (kde-open5, 
"gio open") and thus xdg-open and the main shell process exit.


Excerpts from strace obtained for a eshell buffer

2221  16:59:43.513366 execve("/bin/sh", ["/bin/sh", "/usr/bin/xdg-open", 
"/tmp/test.pdf"], 0x7fff74be7f10 /* 58 vars */ 
2224  16:59:43.566865 execve("/usr/bin/gio", ["gio", "open", 
"/tmp/test.pdf"], 0x55ee8454ec18 /* 58 vars */) = 0
2229  16:59:43.711846 execve("/bin/sh", ["/bin/sh", "-e", "-u", "-c", 
"export GIO_LAUNCHED_DESKTOP_FILE_PID=$$; exec \"$@\"", "sh", "evince", 
"/tmp/test.pdf"], 0x55bb59e67bb0 /* 59 vars */ 

2221  16:59:43.717489 +++ exited with 0 +++
2229  16:59:43.719228 +++ killed by SIGHUP +++

Functions dealing with asynchronous processes in emacs, namely 
(start-process ...) and its siblings for shell commands calls 
(make-process :connection-type 'pty ...) that creates a pseudoterminal. 
It is redundant for applications that do not require an interactive 
terminal. When process (xdg-open this case) exits, pty is closed, all 
processes from the same terminal group receives SIGHUP. So actual 
handler is killed unless it has set signal handler or has detached from 
terminal session.


To fix the problem it is better to use (make-process :connection-type 
'pipe ...) that unfortunately has no higher level wrappers. "Pipe" 
process does not creates a pseudoterminal thus its children do not get 
SIGHUP on the exit of the main process. I am unsure concerning best 
values for other arguments however. The complication is that some 
mailcap entries have needsterminal flag, on the other hand they are 
likely irrelevant for GUI.


There is no problem if okular or evince are called directly (without 
kde-open5 or "gio open" wrapper) since main process does not exit while 
window is open.


Maybe the following command executed in eshell (namely eshell, not just 
shell) buffer is the best to demonstrate the problem (for those whose 
desktop environment is affected)


sh -c "xdg-open /tmp/test.pdf; sleep 5"

The window with file content appears for 5 seconds then the viewer is 
killed.


On 31/01/2021 16:09, to...@tuxteam.de wrote:

This chaotic behaviour gives me the impression that it's an
environment thing: desktop environments have the tendency to prime
the environment variables in "creative" ways, often different from
what a login shell would do.


Certainly the behavior depends on the desktop environment. You could 
check which DE-specific handler is called (and factor-out xdg-open) with


sh -x /usr/bin/xdg-open /tmp/test.pdf

As to other options, M-! executes the process synchronously and is not 
affected. M-& has the same pty+SIGHUP problem.


I am almost sure that I have tried eshell before, but I have no idea why 
I have not noticed the problem that time.

Re: org-attach-git don't automatically commit changes

[Ihor Radchenko]

Juan Manuel Macías  writes:

> But if I evaluate this, I get an 'incomplete' path:

I think you misunderstood how org-attach-git works.

org-attach-git is:

;; An extension to org-attach.  If `org-attach-id-dir' is initialized
;; as a Git repository, then org-attach-git will automatically commit
;; changes when it sees them.  Requires git-annex.

So, it is not designed to work when your actual attachment directory is
a git repo, but rather when org-attach-id-dir is a git repo (initialised
manually).

The other thing is that `org-attach-id-dir' makes much less sense from
the time :DIR: property was introduced. So, I believe that
org-attach-git should be updated. Probably, handling attachment dirs as
individual git repos can be one of the ways to upgrade the current
version. I guess, patches welcome.

Best,
Ihor

Re: org-attach-git don't automatically commit changes

[Juan Manuel Macías]

Hi Ihor,

Ihor Radchenko  writes:

> Does it mean that your attachment folder is set in :DIR: property?

No, my attachment folder is build using :ID: property. For example, in
my heading:

*   Test
:PROPERTIES:
:ID: d0e690e2-2ecd-4224-891a-b91257db5389
:END:

And if I evaluate `org-attach-dir' here, it returns the correct path:

#+begin_src emacs-lisp 
(org-attach-dir)
#+end_src


#+RESULTS:
: 
/home/juanmanuel/Documentos/docs-compartidos/org/data/d0/e690e2-2ecd-4224-891a-b91257db5389

But if I evaluate this, I get an 'incomplete' path:

#+begin_src emacs-lisp 
(expand-file-name org-attach-id-dir)
#+end_src

#+RESULTS:
: /home/juanmanuel/Documentos/docs-compartidos/org/data/

So if I replace `(expand-file-name org-attach-id-dir)' with
`(org-attach-dir)' in `(org-attach-git-commit)' [line 7, the `dir'
variable], it works fine when I run 'C-c C-a z'.

Best regards

Juan Manuel 

>
> I suspect that it is a leftover from the major changes in org-attach
> when :DIR: property was introduced. The org-attach-git presumes that all
> the attachments in current file are stored in sub-directories located
> inside org-attach-id-dir, which is no longer guaranteed. In fact, the
> existing approach to treat all the attachments to all headings in
> current file as files in a single git repo cannot be used. I can see two
> possible fixes:
> 1. Treat each attachment dir as individual git repo (breaking change for
>those who are using :ID: property to build the attachment dirs)
> 2. Treat attachment dirs defined by :DIR: property individually and
>leave the :ID:-defined attachments as they were treated before
>(inconsistent).
>
> I am in favour of the first approach since I do not like the idea of
> keeping all the attachments in the whole file in a single git repo.
> I think feedback from other is needed to decide what we need to do here.
>
> P.S. Marking this as a bug.
>
> Best,
> Ihor
>

Re: org-goto and org-store-link/org-id-get-create

[Peter Klenner]

>A fix to this particular issue could be using org-no-read-only in
>org-entry-put. Though more functions may suffer from similar issues in
>read-only org buffers.

Brilliant! Wrapping org-entry-put into org-no-read-only fixes the issue
for me.

Re: bug#44824: 27.1; Org export as pdf and open file does not open it

[tomas]

On Sun, Jan 31, 2021 at 06:39:40PM +1100, Tim Cross wrote:
> 
> Lars Ingebrigtsen  writes:
> 
> > Eli Zaretskii  writes:
> >
> >>> This doesn't work:
> >>> M-x shell RET xdg-open /tmp/test.pdf RET
> >>
> >> How about asking the xdg-open developers to help us figure out the
> >> reason?  Or, failing that, debug xdg-open in the problematic
> >> situations to find out what fails there and why?  E.g., could it be
> >> that it fails because stdin/stdout is a PTY? what happens if you bind
> >> process-connection-type to nil when starting the async subprocess?
> >
> > I'm unable to reproduce the problem at all -- all the various ways of
> > calling xdg-open work fine for me (on this Debian bullseye laptop w/
> > Gnome Shell).
> 
> For me, I get
> 
> M-! xdg-open /tmp/test.pdf works
> M-x shell  xdg-open /tmp/test.pdf works
> M-& xdg-open /tmp/test.pdf fails
> M-x eshell  xdg-open /tmp/test.pdf fails
> 
> The two which fail do not report any error - just now pdf viewer open.
> 
> I also have no problems with org export menu when I choose export to pdf
> and open.
> 
> This was on a Ubuntu 20.10, latest Emacs 27 (27.5.91), mate DE and
> default shell zsh.

This chaotic behaviour gives me the impression that it's an environment
thing: desktop environments have the tendency to prime the environment
variables in "creative" ways, often different from what a login shell
would do.

One var to look for would be, of course, PATH, but I don't know what
other environment variables `xdg-open' looks at; perhaps USER, HOME
are relevant, perhaps more.

May be comparing what `env' says under those different invocations
could shed some light.

Cheers
 - t


signature.asc
Description: Digital signature