date:20200908




Kyle Meyer  writes:

As I mentioned in the message linked upstream, it doesn't happen 
when
running just test-org/org-read-date 
(BTEST_RE='test-org/org-read-date'),

so there's some sort of interaction between tests.


Sorry, I was a little late getting to this, and it seems to be 
resolved- but this was my experience as well.

Running just that test didn't seem to fail.

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]




Bastien  writes:


Hi No Wayman,

I pushed 4f49ebb6d, a small variant of your initial patch,
which pass the test fine by checking whether the variables
are bound outside or not, ignoring them if not.

Thanks again for the fix!


Sounds good to me! Thanks, Bastien.

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]




Jack Kamm  writes:

Also, could you try executing some simple ob-python session 
blocks and

see if they hang? e.g.,

#+begin_src python :session :results output
  print(1+1)
#+end_src

#+begin_src python :session :results value
  1+1
#+end_src


These both work for me now on master as of f17d301e1.
I ran make test and recieved the following output:


1 unexpected results:
  FAILED  test-ob-python/session-multiline


Applied the patch you provided, re-ran make test and recieved:

Ran 862 tests, 862 results as expected, 0 unexpected (2020-09-09 
00:12:49-0400, 15.237936 sec)

12 expected failures


Source blocks executed correctly as well.

Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument

2020-09-08 Thread Ihor Radchenko

> I applied a small variant of it as a700fadd7, thanks.
>
> (See also the comment I added with f17d301e1, which basically means
> that such changes are made as exceptions.)

For record, the old behaviour did not only affect a single external
package. For example, https://github.com/TonCherAmi/org-starless was
also affected.

Best,
Ihor

Bastien  writes:

> Hi D,
>
> D  writes:
>
>>> Then, can as well use `mapcar', or even simply manual loop over line
>>> positions.
>>
>> How about this?
>
> I applied a small variant of it as a700fadd7, thanks.
>
> (See also the comment I added with f17d301e1, which basically means
> that such changes are made as exceptions.)
>
> -- 
>  Bastien

Re: idea for capture anywhere in x

2020-09-08 Thread Ihor Radchenko

> is something like this possible?


It's very easy. Below is a part of my capture (bash) script for qutebrowser:

emacsclient 
"org-protocol://capture?template=$TEMPLATE=$URL=$TITLE=$SELECTED_TEXT=$QUTE_HTML=$QUTE_FIFO"

Best,
Ihor

Samuel Wales  writes:

> dunno if this is sensible, but istr you can capture using emacsclient?
>
> i really like hte org capture extension in firefox and want it for
> everything in x [which means emacs itself using mouse and what little
> else i run].
>
> my idea was, to emacsclient to call org protocol to a defined capture
> template just like the firefox extension.  this would be alled from
> the wm menu.
>
> is something like this possible?
>
> -- 
> The Kafka Pandemic
>
> Please learn what misopathy is.
> https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: idea for capture anywhere in x




I use a deamon specifically for this. Here's a gist with my setup 
(thought slightly out of date, this will work as a base):


https://gist.github.com/progfolio/af627354f87542879de3ddc30a31adc1

Re: idea for capture anywhere in x

2020-09-08 Thread Samuel Wales

On 9/7/20, Maxim Nikulin  wrote:
> 08.09.2020 12:05, Samuel Wales wrote:
>> well for a non-emacs application, i want to select text and capture
>> using wm menu.
>
> Do you mean a tiny tool that takes content of X primary selection or
> clipboard and passes it to emacs-client org-protocol argument?

maybe.  guessing probably.  i want it to take contents of x primary
selection or clipboard and get it into emacs using a capture template
item.  whether this requries oprg-protocl, idk.

so basically fluxbox menu calls some trivial command which invokes
capoture on my already-existing capture template such as the one that
i already use for hte firefox org-capture extension to use.

> Implementation should have a few lines of code and should allow you to
> bind it to window manager menu or hotkeys. On the other hand I do not
> see great difference from pasting text directly to emacs. Customization
> glue (primary selection/clipboard, name of template, etc.) is thicker
> than code that do the actual job.
>
> The harder part is extracting of formatted text (that could be
> application specific) and converting it to org markup. I had a look
> into emacs sources and did not find extension points to obtain
> application-specific format, so external tool could provide some benefit
> (e.g. capturing link with description from libreoffice).

while such features would be great, my needs are modest i think.  i
would be delighted with just plain text.

but if possible i'd want it to be inserted as utf-8 even if the
terminal or deluge or whatever uses some different encoding.

>
>
>

-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Babel: parse error when output contains opening bracket

2020-09-08 Thread ian martins

Of course there's never a problem in fixing things. I'm curious how you did
it. Will look when I have a chance.

On Sun, Sep 6, 2020, 5:57 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > I've written an alternative org-java.el that doesn't have that
> > problem.
>
> I hope you don't mind the fix I just integrated -- it's simple
> enough for being in 9.3.8, the next stable release.  Obviously
> your updates ob-java.el will probably make it obsolete once
> we can move on after 9.4.
>
> Thanks,
>
> --
>  Bastien
>

Re: Bug: [PATCH] org-datetree-insert-line doesn't honor headline spacing customization [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

2020-09-08 Thread Vasilij Schneidermann

Hello Bastien,

> Thanks for the patch.  I tried it and these two tests fail:
> 
>FAILED  test-org-datetree/find-date-create
>FAILED  test-org-datetree/find-iso-week-create
> 
> Perhaps you can check the value of `org-blank-before-new-entry' and
> insert a blank line only if needed?

I've looked at the tests and concluded that your proposed approach is better
and updated the patch accordingly.

Vasilij
From 47085037a1882a2a723076a47972feb35cc42a7b Mon Sep 17 00:00:00 2001
From: Vasilij Schneidermann 
Date: Tue, 8 Sep 2020 22:15:25 +0200
Subject: [PATCH] Ensure blank line if needed for datetrees

---
 lisp/org-datetree.el  |  2 ++
 testing/lisp/test-org-datetree.el | 56 +++
 2 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/lisp/org-datetree.el b/lisp/org-datetree.el
index ce91591f1..d4ccc84bb 100644
--- a/lisp/org-datetree.el
+++ b/lisp/org-datetree.el
@@ -185,6 +185,8 @@ inserted into the buffer."
 
 (defun org-datetree-insert-line (year  month day text)
   (delete-region (save-excursion (skip-chars-backward " \t\n") (point)) 
(point))
+  (when (assq 'heading org-blank-before-new-entry)
+(insert "\n"))
   (insert "\n" (make-string org-datetree-base-level ?*) " \n")
   (backward-char)
   (when month (org-do-demote))
diff --git a/testing/lisp/test-org-datetree.el 
b/testing/lisp/test-org-datetree.el
index 5557d5e23..daebcaace 100644
--- a/testing/lisp/test-org-datetree.el
+++ b/testing/lisp/test-org-datetree.el
@@ -26,7 +26,7 @@
   ;; When date is missing, create it.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* 2012-03-29 .*\\'"
 (org-test-with-temp-text ""
   (let ((org-datetree-add-timestamp nil))
(org-datetree-find-date-create '(3 29 2012)))
@@ -34,7 +34,7 @@
   ;; Do not create new year node when one exists.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* 2012-03-29 .*\\'"
 (org-test-with-temp-text "* 2012\n"
   (let ((org-datetree-add-timestamp nil))
(org-datetree-find-date-create '(3 29 2012)))
@@ -42,24 +42,24 @@
   ;; Do not create new month node when one exists.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'"
-(org-test-with-temp-text "* 2012\n** 2012-03 month"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* 2012-03-29 .*\\'"
+(org-test-with-temp-text "* 2012\n\n** 2012-03 month"
   (let ((org-datetree-add-timestamp nil))
(org-datetree-find-date-create '(3 29 2012)))
   (org-trim (buffer-string)
   ;; Do not create new day node when one exists.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* 2012-03-29 .*\\'"
-(org-test-with-temp-text "* 2012\n** 2012-03 month\n*** 2012-03-29 day"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* 2012-03-29 .*\\'"
+(org-test-with-temp-text "* 2012\n\n** 2012-03 month\n\n*** 2012-03-29 day"
   (let ((org-datetree-add-timestamp nil))
(org-datetree-find-date-create '(3 29 2012)))
   (org-trim (buffer-string)
   ;; Sort new entry in right place.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-02 .*\n\\*\\*\\* 2012-02-01 .*\n\n\\*\\* 2012-03 
.*\n\\*\\*\\* 2012-03-29 .*\\'"
-(org-test-with-temp-text "* 2012\n** 2012-03 month\n*** 2012-03-29 day"
+"\\`\\* 2012\n\n\\*\\* 2012-02 .*\n\n\\*\\*\\* 2012-02-01 .*\n\n\\*\\* 
2012-03 .*\n\n\\*\\*\\* 2012-03-29 .*\\'"
+(org-test-with-temp-text "* 2012\n\n** 2012-03 month\n\n*** 2012-03-29 day"
   (let ((org-datetree-add-timestamp nil))
(org-datetree-find-date-create '(3 29 2012))
(org-datetree-find-date-create '(2 1 2012)))
@@ -68,14 +68,14 @@
   ;; in entry.  When set to `inactive', insert an inactive one.
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* \\(2012-03-29\\) .*\n[ 
\t]*<\\1.*?>\\'"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* \\(2012-03-29\\) .*\n[ 
\t]*<\\1.*?>\\'"
 (org-test-with-temp-text "* 2012\n"
   (let ((org-datetree-add-timestamp t))
(org-datetree-find-date-create '(3 29 2012)))
   (org-trim (buffer-string)
   (should
(string-match
-"\\`\\* 2012\n\\*\\* 2012-03 .*\n\\*\\*\\* \\(2012-03-29\\) .*\n[ 
\t]*\\[\\1.*?\\]\\'"
+"\\`\\* 2012\n\n\\*\\* 2012-03 .*\n\n\\*\\*\\* \\(2012-03-29\\) .*\n[ 
\t]*\\[\\1.*?\\]\\'"
 (org-test-with-temp-text "* 2012\n"
   (let ((org-datetree-add-timestamp 'inactive))
(org-datetree-find-date-create '(3 29 2012)))
@@ -91,9 +91,9 @@
   (org-trim (buffer-string)
   (should
(string-match
-"\\*\\* H1.1\n:PROPERTIES:\n:DATE_TREE: t\n:END:\n\\*\\*\\* 2012"
+"\\*\\* H1.1\n:PROPERTIES:\n:DATE_TREE: t\n:END:\n\n\\*\\*\\* 2012"
 (org-test-with-temp-text
-   "* H1\n** H1.1\n:PROPERTIES:\n:DATE_TREE:

Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument

2020-09-08 Thread D

Hi Bastien,

> I applied a small variant of it as a700fadd7, thanks.

thank you!

> (See also the comment I added with f17d301e1, which basically means
> that such changes are made as exceptions.)

I fully understand, though I do believe that this change is beneficial
to the way org-forward-heading-same-level works overall, in a "principle
of least astonishment" sort of way.  I would agree with Ihor that it
does reflect the docstring better this way.

Best regards,
D.

variable-pitch-mode misaligns org-mode heading tags

2020-09-08 Thread Protesilaos Stavrou

1. Run 'emacs -Q'
2. Open a new Org file 'C-x C-f /tmp/test.org'
3. Insert the following contents:

* TODO this is a test :tag:
* TODO here is another test :tag:

The tags should align to the right with the standard monospaced font.

4. Run 'M-x variable-pitch-mode'.
5. The tags are now misaligned.

Please see attached screenshots for the before and after states of the
'variable-pitch-mode' activation.

Running 'M-x describe-char' in the space between the heading's title and
the tag informs us that the space's face is the same as the heading's
(e.g. 'org-level-1').

I am also relaying the technical insight of Adam Spiers. Please see
attached plain text document or visit the comment's URL:
https://gitlab.com/protesilaos/modus-themes/-/issues/85#note_407147422

Overview of my setup:

+ GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.22,
cairo version 1.17.3) of 2020-08-14

+ Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)

* * *

This message was also posted on debbugs.gnu.org, bug#43272.

--
Protesilaos Stavrou
protesilaos.com
I've investigated this and it's not nearly as easy as I had hoped. It turns
out that the right alignment supported by display properties can only align
space, not text. Something like this works as an experiment:

```lisp
(with-current-buffer "org/TODO.org"
(put-text-property (region-beginning) (region-end)
'display '(space :align-to (- right 10
```

If a region of space characters is selected, the above will adjust the region's
width so that its right hand side is 10 character widths in from the right
margin. However if the region contains text, it will make that text invisible.

This could be used to *left*-align the tags, but not *right*-align them, which
doesn't really work because each heading's tags can be a different number of
characters wide.

So to get our desired behaviour of adjusting the space in between the heading
and the tags correctly in order to right-align the tags to [the right margin
specified by
`org-tags-column`](https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-09/msg00728.html),
we'd first have to calculate the display width of the (proportionally spaced)
tags text, and then subtract that from the right margin.

In theory this width can be retrieved via `pos-visible-in-window-p` with the
`PARTIALLY` argument set to `t`, but I haven't got that working yet, and even
if I could, it would need to be done dynamically for each line and then the
corresponding text property updated whenever that width changed (e.g. any of
that line was edited, or when the window was scrolled to bring different
headings into view).

However that raises questions about how well this would perform, since it would
be creating quite a lot of work to do on each redisplay. I suspect that the
emacs gurus would say that support for right-alignment of variable pitch text
would need to be added to emacs's internal display routines (the ones written
in C, not Elisp). But that's only a vague guess. Hopefully I've
underestimated what emacs can currently do here and there's an easier solution,
but there's little chance of finding out either way without asking on the Org
list, and then falling back to the `help-gnu-emacs` or `emacs-devel` list if
it's even too difficult a question for any of the Org gurus.

Re: Help debugging R source code block output problem with :session

2020-09-08 Thread Jack Kamm

Hi Chuck,

> this is already present in `org-babel-R-evaluate-session' in the call to 
> `org-babel-comint-eval-invisibly-and-wait-for-file'' just a couple of lines 
> further down in the `(cl-case result-type (value ...))' branch.
>
> The other use of `tmp-file' in that block is the one that requires the 
> prefix, right?
>
> So nothing more to fix.
>
> ??

You're right, I didn't notice that it's already present -- nothing more
to fix.

Jack

[PATCH] org-element: Hide parsers boilerplate into plist-creating macros

2020-09-08 Thread akater

We replace some repetetive code with macro calls org-prog-plist and
org-let*-prog-plist.  The macros are not very conventional but hopefully
their docstrings are illustrative enough.  In effect, all subexpressions
of the form

:begin begin
:end end
:contents-begin contents-begin
:contents-end contents-end

and so on, are removed, together with some let* forms.

Macros expand to code that is essentially the original code, only the
order of key-value pairs in resulting plists is different.

One might argue that it is desirable to have key-value pairs plisted in
specific order, maybe somewhat unified.  A rejoinder: plists are meant
to be order-independent while those who delve into these fairly
low-level plists regularly enough to be bothered by the properties'
order, can be considered org-element experts (voluntary or not); I
believe it is only instructive to an expert to be reminded of the
structure of the algorithm that constructs plist in question, especially
if such algorithms are highly imperative.  That said, I did rearrange
some assignments to make resulting plists look a little prettier.  I
also outlined (but not implemented) a mechanism for (partially)
specifying positions, in comments.

I tested most redefined parsers with new definitions applying them to
one sample object of each kind.  Left untested (as I'm not familiar with
Org markup for the corresponding objects) are

- inlinetask-parser
- diary-sexp-parser
- horizontal-rule-parser
- planning-parser
- entity-parser
- export-snippet-parser
- latex-fragment-parser
- macro-parser
- radio-target-parser
- statistics-cookie-parser
- target-parser

Still, diff shows that only trivial subexpressions, as described above,
are discarded there.  I did check that Org(+contrib) builds with this
patch.

Minor note on org-element-inline-babel-call-parser:
org-element--parse-paired-brackets alters point.  That's why I felt it
would be more appropriate to put the corresponding binding/assignment on
top level of an explicitly imperative macro, rather than keep the
binding in a more localized let form, as extent of the operation is not
localized.



signature.asc
Description: PGP signature
>From d9d108f97917c1b55841df907510bcc89f8db406 Mon Sep 17 00:00:00 2001
From: akater 
Date: Thu, 16 Apr 2020 02:25:59 +
Subject: [PATCH] org-element: Hide parsers boilerplate into plist-creating
 macros

* lisp/org-element.el (org-prog-plist, org-let*-prog-plists) (org-let*-prog-plist): New macros.  Build plists without boilerplate.

(org-fold, org-dekeyword): New functions.  Dependencies for the above.

* lisp/org-element.el (org-element-center-block-parser)
(org-element-drawer-parser, org-element-dynamic-block-parser)
(org-element-footnote-definition-parser)
(org-element-plain-list-parser, org-element-property-drawer-parser)
(org-element-quote-block-parser, org-element-section-parser)
(org-element-special-block-parser, org-element-babel-call-parser)
(org-element-clock-parser, org-element-comment-parser)
(org-element-comment-block-parser, org-element-diary-sexp-parser)
(org-element-example-block-parser, org-element-export-block-parser)
(org-element-fixed-width-parser, org-element-horizontal-rule-parser)
(org-element-keyword-parser, org-element-latex-environment-parser)
(org-element-node-property-parser, org-element-paragraph-parser)
(org-element-planning-parser, org-element-src-block-parser)
(org-element-table-parser, org-element-table-row-parser)
(org-element-verse-block-parser, org-element-entity-parser)
(org-element-footnote-reference-parser, org-element-inline-babel-call-parser)
(org-element-inline-src-block-parser, org-element-latex-fragment-parser)
(org-element-link-parser): Use org-prog-plist to build plist

(org-element-headline-parser, org-element-inlinetask-parser)
(org-element-item-parser, org-element-timestamp-parser): Use
org-let*-prog-plist to build plist

(org-element-radio-target-parser, org-element-statistics-cookie-parser) (org-element-subscript-parser, org-element-superscript-parser) (org-element-table-cell-parser, org-element-target-parser) (org-element-underline-parser, org-element-verbatim-parser): Use
just #'list to build plist

(org-element-comment-block-parser): Fix a typo in docstring.
---
 lisp/org-element.el | 2584 +++
 lisp/org-macs.el|  259 +
 2 files changed, 1421 insertions(+), 1422 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index a693cb68d..e40f881b9 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -691,29 +691,26 @@ Assume point is at the beginning of the block."
 	   (re-search-forward "^[ \t]*#\\+END_CENTER[ \t]*$" limit t)))
 	;; Incomplete block: parse it as a paragraph.
 	(org-element-paragraph-parser limit affiliated)
-  (let ((block-end-line (match-beginning 0)))
-	(let* ((begin (car affiliated))
-	   (post-affiliated (point))
+  (list 'center-block
+	(nconc
+	 (org-prog-plist
+	   block-end-line (match-beginning 0)
+

Re: Help debugging R source code block output problem with :session

2020-09-08 Thread Berry, Charles

Jack,

Maybe I am confused here:

> On Sep 8, 2020, at 7:51 AM, Jack Kamm  wrote:
> 
> Yes, if we did that then tmp-file would have a prefix like
> "/scp:user@hostname:", and elisp would then know to read the result file
> from the remote host.
> 
> Before pasting tmp-file into R code, we should also call
> 
> (org-babel-process-file-name tmp-file 'noquote)
> 
> to remove the tramp prefix when referring to the file from R.

this is already present in `org-babel-R-evaluate-session' in the call to 
`org-babel-comint-eval-invisibly-and-wait-for-file'' just a couple of lines 
further down in the `(cl-case result-type (value ...))' branch.

The other use of `tmp-file' in that block is the one that requires the prefix, 
right?

So nothing more to fix.

??

Chuck

Re: eldoc recursion error

On Tue, Sep 8, 2020 at 11:27 AM Matt Price  wrote:

>
>
> On Tue, Sep 8, 2020 at 10:53 AM Bastien  wrote:
>
>> Hi Matt,
>>
>> Matt Price  writes:
>>
>> > In a new org file, add these lines:
>> >
>> > #+begin_src python
>> > print
>> > #+end_src
>> >
>> > position cursor inside block and the error message occurs.
>>
>> I can't reproduce the bug.  What version of Emacs are you using?
>>
>> Can you give a recipe starting with emacs -q?
>>
>
> I htink I have it now.
>
> $ emacs -q
>
I forgot to say, this is emacs git (2.8.0.50 from yesterday) and org-mode
master (current)

>
> (require 'org-eldoc) ;;(or navigate to lisp/org-eldoc.el and eval-buffer)
> create new org file, add this content:
>
> #+begin_src python
>  print
>  #+end_src
>
> ensure eldoc-mode is turned on. place cursor inside block.
>
> If for some reason that doesn' t work try manually running
> `org-eldoc-load` and repositioning cursor.
>
>
>> Thanks!
>>
>> --
>>  Bastien
>>
>

Re: idea for capture anywhere in x

2020-09-08 Thread Maxim Nikulin


08.09.2020 15:03, Diego Zamboni wrote:


Doom Emacs has an 'org-capture' script that uses emacsclient to 
externally invoke a new frame with 'org-capture' in it. Maybe this could 
be a good starting point?


https://github.com/hlissner/doom-emacs/blob/develop/bin/org-capture


Thank you for the link. I have found it interesting due to I am unaware 
what is considered as best practices in relation to invoking of emacsclient.


Though I am a bit lazy to try doom-emacs just now. Does the script works 
correctly if emacs server is already running but with no frames at the 
moment of script execution?


A couple of things I have noticed in the script:
- Systemd service file in emacs stops server without redefining of 
kill-emacs-hook.
- Despite it was not exactly the same problem, cleanup in shell script 
after completion of a child process was discussed in [1]. Some subtle 
aspects are better highlighted in the non-top rated answer. I suspect, 
in the case of emacs races might happen in different places.


[1] https://unix.stackexchange.com/a/444676 "Forward SIGTERM to child in 
Bash"

Re: [feature request] org-at-timestamp-p should accept multiple parameters

2020-09-08 Thread Adam Faryna

Ok, maybe I misunderstood the purpose of this function. I wanted to use it
to check if the timestamp is active or inactive and I tried to get it by
using (org-at-timestamp-p 'inactive) while pointing at the timestamp. But
actually when I call it on any timestamp like [2020-09-04 Fri], <2020-09-04
Fri> I always get nil. So either it's a bug, or I miss something.

Thanks,

Adam

On Tue, 8 Sep 2020 at 15:26, Bastien  wrote:

> Hi Adam,
>
> thanks, but I still need to understand the exact change you suggest
> and what general fix/improvement it will provide.  Probably a patch
> will be easier to understand for this.
>
> Thanks,
>
> --
>  Bastien
>

Re: eldoc recursion error

On Tue, Sep 8, 2020 at 10:53 AM Bastien  wrote:

> Hi Matt,
>
> Matt Price  writes:
>
> > In a new org file, add these lines:
> >
> > #+begin_src python
> > print
> > #+end_src
> >
> > position cursor inside block and the error message occurs.
>
> I can't reproduce the bug.  What version of Emacs are you using?
>
> Can you give a recipe starting with emacs -q?
>

I htink I have it now.

$ emacs -q

(require 'org-eldoc) ;;(or navigate to lisp/org-eldoc.el and eval-buffer)
create new org file, add this content:

#+begin_src python
 print
 #+end_src

ensure eldoc-mode is turned on. place cursor inside block.

If for some reason that doesn' twork try manually running `org-eldoc-load`
and repositioning cursor.

> Thanks!
>
> --
>  Bastien
>

Re: eldoc recursion error

Hi Matt,

Matt Price  writes:

> In a new org file, add these lines:
>
> #+begin_src python
> print
> #+end_src
>
> position cursor inside block and the error message occurs.

I can't reproduce the bug.  What version of Emacs are you using?

Can you give a recipe starting with emacs -q?

Thanks!

-- 
 Bastien

Re: Help debugging R source code block output problem with :session

2020-09-08 Thread Jack Kamm

"Berry, Charles"  writes:

> Also, I wonder if the `:results value' case can be handled in a similar 
> manner, viz. 
>
> -  (let ((tmp-file (org-babel-temp-file "R-")))
> +  (let ((tmp-file (with-current-buffer session (org-babel-temp-file "R-"

Yes, if we did that then tmp-file would have a prefix like
"/scp:user@hostname:", and elisp would then know to read the result file
from the remote host.

Before pasting tmp-file into R code, we should also call

(org-babel-process-file-name tmp-file 'noquote)

to remove the tramp prefix when referring to the file from R.

Re: eldoc recursion error

On Tue, Sep 8, 2020 at 10:25 AM Bastien  wrote:

> Hi Matt,
>
> can you provide a recipe to reproduce the problem?
>
> oops, sorry, that was stupid.

In a new org file, add these lines:

#+begin_src python
print
#+end_src

position cursor inside block and the error message occurs.

Re: [feature request] org-at-timestamp-p should accept multiple parameters

Hi Adam,

thanks, but I still need to understand the exact change you suggest
and what general fix/improvement it will provide.  Probably a patch 
will be easier to understand for this.

Thanks,

-- 
 Bastien

Re: eldoc recursion error

Hi Matt,

can you provide a recipe to reproduce the problem?

Thanks,

-- 
 Bastien

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]

2020-09-08 Thread Jack Kamm

Kyle Meyer  writes:

> That's on a Debian system with the python executable pointing to Python
> 2.7.16.  If I set org-babel-python-command to python3 (3.7.3) at the top
> of test-ob-python.el, I see the same thing.  I haven't dug any farther
> yet.  Jack, presumably you don't see the stall on your end?

No, the tests don't stall on my end (Archlinux with manually compiled
emacs 28). I also tested on a debian10vm and the tests passed there too.

But since we know it's related to 4df12ea39 that gives some
clues...could you try the attached patch to see if it fixes things?

Also, could you try executing some simple ob-python session blocks and
see if they hang? e.g.,

#+begin_src python :session :results output
  print(1+1)
#+end_src

#+begin_src python :session :results value
  1+1
#+end_src

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 1cded4515..a5af55892 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -223,6 +223,9 @@ (defun org-babel-python-initiate-session ( session _params)
 (org-babel-python-session-buffer
  (org-babel-python-initiate-session-by-key session
 
+(defvar org-babel-python-eoe-indicator "org_babel_python_eoe"
+  "A string to indicate that evaluation has completed.")
+
 (defconst org-babel-python-wrapper-method
   "
 def main():
@@ -324,7 +327,9 @@ (defun org-babel-python--send-string (session body)
 	   (comint-output-filter-functions
 	(cons (lambda (text) (setq string-buffer
    (concat string-buffer text)))
-		  comint-output-filter-functions)))
+		  comint-output-filter-functions))
+	   (body (format "%s\nprint('%s')"
+			 body org-babel-python-eoe-indicator)))
   (if (not (eq 'python-mode org-babel-python-mode))
 	  (let ((python-shell-buffer-name
 		 (org-babel-python-without-earmuffs session)))
@@ -333,13 +338,10 @@ (defun org-babel-python--send-string (session body)
 	(py-shell-send-string body (get-buffer-process session)))
   ;; same as `python-shell-comint-end-of-output-p' in emacs-25.1+
   (while (not (string-match
-		   (concat "\r?\n?"
-			   (replace-regexp-in-string
-			(rx string-start ?^) "" comint-prompt-regexp)
-			   (rx eos))
+		   org-babel-python-eoe-indicator
 		   string-buffer))
 	(accept-process-output (get-buffer-process (current-buffer
-  (substring string-buffer 0 (match-beginning 0)
+  (org-babel-chomp (substring string-buffer 0 (match-beginning 0))
 
 (defun org-babel-python-evaluate-session
 (session body  result-type result-params)

eldoc recursion error

I know there have been a couple of updates to org-eldoc lately.  After
updating to current master, I get this error in source blocks if eldoc mode
is turned on:

eldoc error: (error Lisp nesting exceeds ‘max-lisp-eval-depth’)

Is there an easy fix for this? is it a generic eldoc problem or specific to
org?

Thanks!

Matt

Re: [feature request] org-at-timestamp-p should accept multiple parameters

2020-09-08 Thread Adam Faryna

I think the problem is general. If you work with any timestamp that is
agenda like, you can't check using this function if it's active or
inactive. The one solution would be to remove parameter "agenda" and
consider every timestamp as a agenda like (the "timestamp" in "
org-at-timestamp-p" suggest that there is time information in it anyway) by
default, or keep it as it is but extend parameter list with support of
named parameters where agenda-like can be activated with :agenda t,
inactive timestamp with :inactive t, with default values nil.

Thanks,
Adam

On Sat, 5 Sep 2020 at 13:59, Bastien  wrote:

> Hi Adam,
>
> you forgot to copy the emacs-orgmode list - can you repost your email
> there?
>
> Thanks,
>
> --
>  Bastien
>

Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument

Hi D,

D  writes:

>> Then, can as well use `mapcar', or even simply manual loop over line
>> positions.
>
> How about this?

I applied a small variant of it as a700fadd7, thanks.

(See also the comment I added with f17d301e1, which basically means
that such changes are made as exceptions.)

-- 
 Bastien

Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]