Re: [Feature Request] More flexibility in org-speed-commands customization

[Marco Wahl]

Hi Gustavo,

> Org's speed keys are a very interesting feature to which I've long
> been attracted to.  And indeed, I've flirted with it a number of times
> in the past.  But every time I do so, I end up stepping back, because
> I get weary of fat fingering my documents.  The whole set of speed
> keys is more powerful than what I would wish.  I'd love to have speed
> keys for navigation and visibility, but I would also gladly refrain
> from these "too handy" editing keys.
>
> As things stand, the speed keys are defined by combining
> `org-speed-commands-default', a defconst, and
> `org-speed-commands-user', a defcustom.  But the former already
> contains a large set of speed keys, including some quite powerful
> editing ones.  And it is thus hard to remove these keys.
>
> Of course, it is possible.  We could shadow the same key in
> `org-speed-commands-user' to do nothing.  Or, though a defconst, 
> `org-speed-commands-default' can be redefined after loading Org.  The
> first is clumsy, and renders the `org-speed-command-help' buffer quite 
> confusing.  The second feels wrong (because it is).
>
> I don't know if there is a strong reason to hard-code the set of keys
> in `org-speed-commands-default'.  But, if there isn't, could you
> consider (somehow) exposing the whole set of `org-speed-commands' to
> user customization?

This sounds like a good idea to me.

Do you already have a respective patch?


Best regards,
-- Marco

[SOLVED] Re: [BUG] The latest commit "f4687993c53a5339e" caused inline image preview try to convert PDF file link

[numbch...@gmail.com]

Aha, I checkout that commit again, indeed, pdf exist before. Weird, When I
revert this commit. The issue is gone. This is weird. Do you have same
problem?

Hmm, I tried to pull again, Now with the latest commit. The problem is
gone. I guess I must messed something up when I debug org-link-beautify.
Anyway, It's my fault, I have not confirmed this bug before minimal emacs
config. Sorry about that. Nicolas.

[stardiviner] GPG key ID: 47C32433
IRC(freeenode): stardiviner Twitter:  @numbchild
Key fingerprint = 9BAA 92BC CDDD B9EF 3B36  CB99 B8C4 B8E5 47C3 2433
Blog: http://stardiviner.github.io/


On Mon, Aug 17, 2020 at 2:15 PM Nicolas Goaziou 
wrote:

> Hello,
>
> "numbch...@gmail.com"  writes:
>
> > The latest commit "f4687993c53a5339e" added "pdf" file type into inline
> > image rules.
>
> No, it doesn't. "pdf" was already in the list before this commit.
>
> > This caused org-toggle-inline-image try to convert large PDF
> > into png images. Caused very long time suspend.
>
> You can customize the variable and remove "pdf".
>
> Regards,
> --
> Nicolas Goaziou
>

Re: [Feature Request] More flexibility in org-speed-commands customization

[Gustavo Barros]

Hi Marco,

On Mon, 17 Aug 2020 at 06:40, Marco Wahl  
wrote:



I don't know if there is a strong reason to hard-code the set of keys
in `org-speed-commands-default'.  But, if there isn't, could you
consider (somehow) exposing the whole set of `org-speed-commands' to
user customization?


This sounds like a good idea to me.

Do you already have a respective patch?



thank you for considering this suggestion.  But, no, I haven't tried to 
prepare a patch, because even if I got it working, I wouldn't be able to 
contribute it.  Unfortunately, I cannot sign the papers given my current 
employment contract's terms.  So, for the foreseeable future, I'm stuck 
with this situation, and can only contribute with ideas, reports and 
such.


Best regards,
Gustavo.

[Marco Wahl] Re: [Feature Request] More flexibility in org-speed-commands customization

[Marco Wahl]

Hi Gustavo,

>>> I don't know if there is a strong reason to hard-code the set of keys
>>> in `org-speed-commands-default'.  But, if there isn't, could you
>>> consider (somehow) exposing the whole set of `org-speed-commands' to
>>> user customization?
>>
>> This sounds like a good idea to me.
>>
>> Do you already have a respective patch?
>>
>
> thank you for considering this suggestion.  But, no, I haven't tried
> to prepare a patch, because even if I got it working, I wouldn't be
> able to contribute it.  Unfortunately, I cannot sign the papers given
> my current employment contract's terms.  So, for the foreseeable
> future, I'm stuck with this situation, and can only contribute with
> ideas, reports and such.

What a pity about the contribution blocker! But thanks for being clear.

I put this change on my personal todo list. Possibly a public todo list
would be a better place, but that's another story, I guess. 


Best regards,
--
Marco

Re: mailing list archive link in FAQ

[Maxim Nikulin]

16.08.2020 03:25, Kyle Meyer wrote:


Thanks.  I replaced the stale gmane web links I could find on the faq
page and updated the nntp address for the gmane.io move.


Thank you, Kyle. I hope, the update makes the page more useful for visitors.

I am unaware if ControlPersist related TRAMP bug still requires a 
special remark, but the last survived gmane link


http://article.gmane.org/gmane.emacs.tramp/7991

likely could be replaced by

https://lists.gnu.org/archive/html/tramp-devel/2012-03/msg00010.html

if I did not confuse something.

Message-ID: 


Xref: news.gmane.org gmane.emacs.tramp:7991
Archived-At: 

[PATCH] ob-python.el: Fix issue with sessions on remote machines

[Christian Vanderwall]

The function `org-babel-python-evaluate-session' doesn't process temp
file names with `org-babel-process-file-name' before inserting them into
the Python code blocks. This causes a 'No such file' error when the
executing the code blocks on a remote directory.

The attached patch fixes this issue, allowing compilation of Python
source blocks with a remote directory, such as :dir /ssh:user@server:/.

This is my first patch ever, so please let me know if there's ways I can
improve.

Thanks!
-- 
Christian Vanderwall
>From 7cf3d4c53e12addced7d2f65de1632971f44f056 Mon Sep 17 00:00:00 2001
From: Christian Vanderwall 
Date: Tue, 11 Aug 2020 20:26:39 -0700
Subject: [PATCH] ob-python.el: Fix issue with sessions on remote machines

* lisp/ob-python.el (org-babel-python-evaluate-session): Process
temporary file name with `org-babel-process-file-name' before
inserting it into code Python code snippets.

Before this change, the entire temporary filename was sent to the
Python session for execution, causing a 'No such file' error when the
filename had a Tramp format such as
/ssh:user@server:/tmp/python-ABCDEF.

TINYCHANGE
---
 lisp/ob-python.el | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 69312f2c9..0e3c79522 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -335,7 +335,8 @@ last statement in BODY, as elisp."
 		  "python-")))
 			   (with-temp-file tmp-src-file (insert body))
 			   (format org-babel-python--exec-tmpfile
-   tmp-src-file))
+   (org-babel-process-file-name
+	tmp-src-file 'noquote)))
 			   body)))
 	   (mapconcat
 		#'org-trim
@@ -353,7 +354,8 @@ last statement in BODY, as elisp."
 	  "python-")))
 			   (with-temp-file tmp-src-file (insert body))
 			   (format org-babel-python--eval-ast
-   tmp-src-file
+   (org-babel-process-file-name
+tmp-src-file 'noquote)
(org-babel-comint-with-output
(session org-babel-python-eoe-indicator nil body)
  (let ((comint-process-echoes nil))
-- 
2.28.0

Re: mailing list archive link in FAQ

[Kyle Meyer]

Maxim Nikulin writes:

> I am unaware if ControlPersist related TRAMP bug still requires a 
> special remark, but the last survived gmane link
>
> http://article.gmane.org/gmane.emacs.tramp/7991
>
> likely could be replaced by
>
> https://lists.gnu.org/archive/html/tramp-devel/2012-03/msg00010.html

Ah, nice, thanks for hunting that down.  Will replace.

Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]

[Kyle Meyer]

Ihor Radchenko writes:

>> Using Emacs 26.3 with a vanilla configuration and the Org repo checked
>> out at 5e4542d69 (the commit reported in the subject line), I didn't see
>> the behavior you describe.  With point at the end of the agenda line for
>> A, the state was changed for A.
>
> I think that may happen when you have agenda filter active and an entry
> hidden by filter is between the current and next line.

Thanks.  With 9.1.9 (5e4542d69), that indeed does look to be an issue.

* TODO a
* TODO b   
:drop:
* TODO c

List those in the agenda, exclude drop, and, with point on a's line, hit
M-e (move-end-of-line).  Point is then at the end of the invisible b,
and calling org-agenda-todo acts on b rather than a.

However, as of v9.3.3, specifically a2b69c58f (org-agenda.el: Add
`org-agenda-end-of-line', 2020-02-02), move-end-of-line is remapped and
point ends up at the end of a, avoiding the issue.

Are you able to trigger this "act on invisible entry" behavior with
bound navigation commands in recent Org versions?

Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]

[Ihor Radchenko]

> Are you able to trigger this "act on invisible entry" behavior with
> bound navigation commands in recent Org versions?

The org version of the move-end-of-line works fine on master. Though Org
remapping does not affect my key binding setup (I use alternative
version of move-end-of-line) and I had to redefine the command manually.

Best,
Ihor


Kyle Meyer  writes:

> Ihor Radchenko writes:
>
>>> Using Emacs 26.3 with a vanilla configuration and the Org repo checked
>>> out at 5e4542d69 (the commit reported in the subject line), I didn't see
>>> the behavior you describe.  With point at the end of the agenda line for
>>> A, the state was changed for A.
>>
>> I think that may happen when you have agenda filter active and an entry
>> hidden by filter is between the current and next line.
>
> Thanks.  With 9.1.9 (5e4542d69), that indeed does look to be an issue.
>
> * TODO a
> * TODO b   
> :drop:
> * TODO c
>
> List those in the agenda, exclude drop, and, with point on a's line, hit
> M-e (move-end-of-line).  Point is then at the end of the invisible b,
> and calling org-agenda-todo acts on b rather than a.
>
> However, as of v9.3.3, specifically a2b69c58f (org-agenda.el: Add
> `org-agenda-end-of-line', 2020-02-02), move-end-of-line is remapped and
> point ends up at the end of a, avoiding the issue.
>
> Are you able to trigger this "act on invisible entry" behavior with
> bound navigation commands in recent Org versions?

Re: Bug: org-agenda-todo applied to wrong line item [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.1/lisp/org/)]

[Kyle Meyer]

Dinnyés Dániel writes:

> I have tried reproducing it with a minimal example, and this seems to work
> for me:
>
> * FOO
> ** TODO baz1
> SCHEDULED: <2020-08-16 Sun>
>
> some text
>
> * BAR
> ** TODO baz2
> SCHEDULED: <2020-08-16 Sun>
> *** DONE baz3
> SCHEDULED: <2020-08-16 Sun>
> *** TODO baz4
> SCHEDULED: <2020-08-16 Sun>
>
> When in the agenda, on the front line of item baz, setting it to DONE state
> works fine.
> OTOH, when going to the end of the line on the item baz, trying to set it
> to DONE results in the error message:
> TODO state change from TODO to DONE blocked (by "TODO baz4")
>
> Also, I have (org-enforce-todo-dependencies t), which causes the blocking,
> and (org-agenda-dim-blocked-tasks (quote invisible)), which hides baz2 from
> the agenda... because of this baz1 is followed directly by baz4 in my
> agenda window.

Thanks for the minimal example and configuration.  I can trigger the
issue using that file and

(setq org-enforce-todo-dependencies t)
(setq org-agenda-dim-blocked-tasks 'invisible)

with commit 5e4542d69 checked out.

The issue doesn't happen with the current release (v9.3.7) or the master
branch.  It went away with 27e4d7ce4 (Prevent infinite loop when showing
new time in agenda, 2020-02-14).  I haven't taken a closer look, though.