<#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-g
* 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 beha
> 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-
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.
>
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,
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-
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 recogn
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 l
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. Th
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 la
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 F
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?
...
> 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
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 (kd
> 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 l
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
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 progra
> 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
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 default
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: o
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 curre
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
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:4
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
proprie
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
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:5
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
;;
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-atta
>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.
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
30 matches
Mail list logo
