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
>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.
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
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
;;
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
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
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
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:
> 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
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
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:
> 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
> 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
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
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
> 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
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: 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 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?
...
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 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
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
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
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
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-
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,
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.
>
> 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/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
<#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
30 matches
Mail list logo
