I'll keep researching and see if I can come up with anything.
This is particularly difficult.
When instrumenting `org-add-planning-info` with edebug the
resulting timestamp always has its time portion (given and/or
end-time) ignored.
Tried it with both my personal setup and emacs -q. No
Bastien writes:
No Wayman writes:
Well, back to square one -- the "fix" breaks setting the end
time
of an existing schedule timestamp for me with.
I reverted it as 771c66f79.
Unfortunate, but I see the same breakage with the patch. I stepped
through trying to set and end time of an
Kyle Meyer writes:
> With Org's master (f17d301e1), the second one hangs for me with Emacs
> 26.3. Quickly stepping through org-babel-python--send-string, it
> appears to get stuck in the accept-process-output call.
>
> Using an Emacs built from master, there's no hang on my end either. If
>
No Wayman writes:
> 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,
Jack Kamm writes:
> 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
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-
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.
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
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
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!
--
Bastien
No Wayman writes:
> Unfortunately I'm unable to get the test suite to run correctly.
> I've followed the instructions in the testing/README, but the
> tests hang due to some sort misconfiguration with python and
> readline on my end:
>
>> Warning (python): Your ‘python-shell-interpreter’
Bastien writes:
If you can investigate why the test broke,
that'd be helpful. Thanks!
Unfortunately I'm unable to get the test suite to run correctly.
I've followed the instructions in the testing/README, but the
tests hang due to some sort misconfiguration with python and
readline on
No Wayman writes:
> Bastien writes:
>
>> Applied in maint as c7abcd514, thanks.
>
> Thanks, Bastien. I noticed org-end-time-was-given is bound similarly.
> This binding doesn't affect my usage, but I wonder if it is necessary.
> If you think it isn't, I'd be happy to submit another patch
No Wayman writes:
> Bastien writes:
>
>> Applied in maint as c7abcd514, thanks.
>
> Thanks, Bastien. I noticed org-end-time-was-given is bound similarly.
> This binding doesn't affect my usage, but I wonder if it is necessary.
> If you think it isn't, I'd be happy to submit another patch
Bastien writes:
Applied in maint as c7abcd514, thanks.
Thanks, Bastien. I noticed org-end-time-was-given is bound
similarly.
This binding doesn't affect my usage, but I wonder if it is
necessary.
If you think it isn't, I'd be happy to submit another patch
removing it.
Hi,
No Wayman writes:
> The current behavior of `org-add-planning-info' does not include the
> time of day when
> it is passed the TIME argument. This is because `org-time-was-given'
> is initially let-bound to nil
> during the scope of the function.
>
> The attached patch removes that binding
The current behavior of `org-add-planning-info' does not include
the time of day when
it is passed the TIME argument. This is because
`org-time-was-given' is initially let-bound to nil
during the scope of the function.
The attached patch removes that binding and allows the caller to
pass
17 matches
Mail list logo
