Ihor Radchenko writes:
> Applied onto main changing the commit summary to "org-babel: ...".
> This change will affect all the babel backends that use
> `org-babel-eval'.
That makes sense. Thank you for the correction!
> A small note: If stderr does not contain a trailing newline, it will
> be
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> Feel free to change it in the patch together with tests.
>
> Thank you for driving the discussion and for giving me the opportunity
> to solve the problem (and not just temporarily, but with tests). What
> do you think about the attached pa
Ihor Radchenko writes:
> Feel free to change it in the patch together with tests.
Thank you for driving the discussion and for giving me the opportunity
to solve the problem (and not just temporarily, but with tests). What
do you think about the attached patch?
Rudy
>From 7001ed80e5fd146f6acf
Tim Cross writes:
>>> The 2 big questions I see are "What should be defaults be?" and "How do
>>> we handle the options without adding lots of new switches or suffering
>>> an option permutation blow out?".
>>
>> I am sorry, but I do not fully understand what you are talking about.
>> Which defau
Ihor Radchenko writes:
> Tim Cross writes:
>
>> For me, this is another symptom of our need to define a clearer model
>> for babel processes so that we can get some consistency across the
>> board. Such a model would likely also make it easier for people to
>> develop new babel back ends. We m
Tim Cross writes:
> For me, this is another symptom of our need to define a clearer model
> for babel processes so that we can get some consistency across the
> board. Such a model would likely also make it easier for people to
> develop new babel back ends. We may even need 2 models, one for
> i
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
>> Ihor Radchenko writes:
>>
>>> I do not think that it make sense to display that buffer when the code
>>> finishes successfully. I can see this kind of behaviour
>>> breaking/spamming automated scripts or export---code working in the
>>> p
On Sun, Oct 30, 2022 at 07:09:30AM +, Ihor Radchenko wrote:
> to...@tuxteam.de writes:
>
> >> If you need it, feel free to open a separate feature request for extra
> >> :results options in ob-shell. Possibly providing more details how you
> >> envision this header argument to work.
> >
> > I'
to...@tuxteam.de writes:
>> If you need it, feel free to open a separate feature request for extra
>> :results options in ob-shell. Possibly providing more details how you
>> envision this header argument to work.
>
> I'll mull over it. Perhaps I come up with some (patch) proposal.
Thinking more
On Sun, Oct 30, 2022 at 03:31:32AM +, Ihor Radchenko wrote:
> to...@tuxteam.de writes:
>
> >> What you are describing would better fit into a new :results option.
> >
> > Oh, I missed the popup part. Sounds useful for yet another profile,
> > yes.
>
> If you need it, feel free to open a separ
Max Nikulin writes:
> I agree that stderr may be important. I would not mind to have a buffer
> that combines both stderr and stdout (maybe fontified). Despite order of
> messages in separate streams is not strictly defined, it still may shed
> some light on the reason what went wrong.
I am n
to...@tuxteam.de writes:
>> What you are describing would better fit into a new :results option.
>
> Oh, I missed the popup part. Sounds useful for yet another profile,
> yes.
If you need it, feel free to open a separate feature request for extra
:results options in ob-shell. Possibly providing m
On 29/10/2022 11:05, Ihor Radchenko wrote:
As explained in the above quote, it may be reasonable to display stderr
in the shell (and possibly other) src blocks upon execution.
+ Stderr may contain important information even if the code block
succeeds
- Displaying stderr will raise *Error* bu
On Sat, Oct 29, 2022 at 09:09:04AM +, Ihor Radchenko wrote:
> to...@tuxteam.de writes:
>
> > As I hinted at, I also wanted to have the exit code documented [...]
> Note that what we are discussing here is different from your
> description. A popup window accumulating stderr is displayed upon
to...@tuxteam.de writes:
> As I hinted at, I also wanted to have the exit code documented. So
> my setup was a bit more involved than this. Plus, I didn't want all
> that code scaffolding to show up in the typeset results (my audience
> had enough to digest as it was), so I hid all that in the pro
On Fri, Oct 28, 2022 at 11:43:39PM -0700, Samuel Wales wrote:
> long ago i made the contents of my shell blocks look like this:
>
> {
> code
> } 2>&1
> :
As I hinted at, I also wanted to have the exit code documented. So
my setup was a bit more involved than this. Plus, I didn't want all
that c
long ago i made the contents of my shell blocks look like this:
{
code
} 2>&1
:
On 10/28/22, to...@tuxteam.de wrote:
> On Sat, Oct 29, 2022 at 04:05:19AM +, Ihor Radchenko wrote:
>> Rudolf Adamkovič writes:
>>
>> > Ihor Radchenko writes:
>> >
>> >> I do not think that it make sense to d
On Sat, Oct 29, 2022 at 04:05:19AM +, Ihor Radchenko wrote:
> Rudolf Adamkovič writes:
>
> > Ihor Radchenko writes:
> >
> >> I do not think that it make sense to display that buffer when the code
> >> finishes successfully. I can see this kind of behaviour
> >> breaking/spamming automated sc
Rudolf Adamkovič writes:
>> I do not think that it is a good idea. Code block execution may
>> involve a whole chain of blocks when expanding references. If we wipe
>> the error buffer and multiple blocks are failing, some errors may go
>> unnoticed by the user.
>
> In that case, can we prepend
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> I do not think that it make sense to display that buffer when the code
>> finishes successfully. I can see this kind of behaviour
>> breaking/spamming automated scripts or export---code working in the
>> past may throw error output into unsu
Ihor Radchenko writes:
> I do not think that it make sense to display that buffer when the code
> finishes successfully. I can see this kind of behaviour
> breaking/spamming automated scripts or export---code working in the
> past may throw error output into unsuspecting users.
But the exit code
Rudolf Adamkovič writes:
>>> 1. ob-shell/error-output-after-success
>>>
>>>We seem to trash error output, such as warnings, on success. I
>>>think we should not do this. Now, on the execution of "echo X
>>>&>2", Org says "Code block produced no output." But that does
>>>hold tr
Ihor Radchenko writes:
>> 1. ob-shell/error-output-after-success
>>
>>We seem to trash error output, such as warnings, on success. I
>>think we should not do this. Now, on the execution of "echo X
>>&>2", Org says "Code block produced no output." But that does
>>hold true. The
Rudolf Adamkovič writes:
> Thank you for investigating, explaining, and also fixing the problem! I
> pulled the latest 'main' and everything works a bit, it seems.
>
> Then, to avoid walking in circles, I decided to write some tests, for I
> think shell blocks should never, never, never break in
Rudolf Adamkovič writes:
> I pulled the latest 'main' and everything works a bit, it seems.
I meant to say "a bit better" not "a bit". :)
Rudy
--
"It is no paradox to say that in our most theoretical moods we may be
nearest to our most practical applications."
-- Alfred North Whitehead, 1861-1
Ihor,
Thank you for investigating, explaining, and also fixing the problem! I
pulled the latest 'main' and everything works a bit, it seems.
Then, to avoid walking in circles, I decided to write some tests, for I
think shell blocks should never, never, never break in such basic ways,
let alone i
Ihor Radchenko writes:
> This is actually expected. Without session, ob-shell discards results of
> src blocks that fail and display *Error* window (empty in this case).
>
> If you try
>
> #+begin_src bash :results output
> echo one > one.txt
> echo two > two.txt
> diff one.txt two.txt |
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>>> I did some testing and found no issues.
>
> Update: Today I needed to run some Bash, and it seems broken.
>
> PROBLEM 1: WITHOUT A SESSION
>
>
> CONFIGURATION:
>
> Emacs 29, Org from Git (2f5e7103e59f06631e985
Ihor Radchenko writes:
>> I did some testing and found no issues.
Update: Today I needed to run some Bash, and it seems broken.
PROBLEM 1: WITHOUT A SESSION
CONFIGURATION:
Emacs 29, Org from Git (2f5e7103e59f06631e985d3dd39af21b5b7464ea)
REPRODUCTION STEPS:
Rudolf Adamkovič writes:
> Ihor Radchenko writes:
>
>> See the attached tentative patch.
>> I'd appreciate some testing. Hopefully, I did not break anything.
>
> I did some testing and found no issues.
>
> Great work!
>
> Below, I include some suggestions regarding the patch.
Thanks!
Applied on
Ihor Radchenko writes:
> See the attached tentative patch.
> I'd appreciate some testing. Hopefully, I did not break anything.
I did some testing and found no issues.
Great work!
Below, I include some suggestions regarding the patch.
> * lisp/ob-comint.el (org-babel-comint-with-output): Clean
Ihor Radchenko writes:
> Rudolf Adamkovič writes:
>
>> :
>> : > > hello
>>
>> on the subsequent runs.
>>
>> Better than the new version but still wrong. :)
>
> And this is what drove me crazy during debugging. I do not understand
> the logic of all that ob-comint code.
>
> I have identified that
Rudolf Adamkovič writes:
> :
> : > > hello
>
> on the subsequent runs.
>
> Better than the new version but still wrong. :)
And this is what drove me crazy during debugging. I do not understand
the logic of all that ob-comint code.
I have identified that the hang happens because Org does not cha
Ihor Radchenko writes:
> Is it what you actually saw in the past? I just tried with older Org
> versions on my system and the output is
>
>: [00m > > > hello
No. By "expected", I mean what I expect as a user (and what I would
assert on in a regression test as a developer).
For the record,
Rudolf Adamkovič writes:
> I noticed today that Bash source blocks with ':session" does not seem to
> work with Org 9.6-pre (3e8648775). Does anyone else have the problem?
Confirmed.
The cause is a35d16368
Author: Ihor Radchenko
ob-shell: Fix output containing strings matching `comint-prom
Hello,
Rudolf Adamkovič writes:
> Hello there!
>
> I noticed today that Bash source blocks with ':session" does not seem to
> work with Org 9.6-pre (3e8648775). Does anyone else have the problem?
funnily I observed something similar while generating semester projects
for my students.
Example:
Hello there!
I noticed today that Bash source blocks with ':session" does not seem to
work with Org 9.6-pre (3e8648775). Does anyone else have the problem?
CONFIGURATION FILE:
--
> (setq-default org-use-extra-keys t)
> (with-eval-after-load 'org
> (add-to-list 'org-babel-load-
37 matches
Mail list logo
