laher/neorg-exec

Incorrect "@end" tag placement when executed code block has errors

Opened this issue · 3 comments

This leaves some garbage behind when re-executing a code block after failing.

Example:

@code python
print(f)
@end

#exec.start 2023.10.15T10.54.19AEDT
#exec.end 0.0000s 1
@result
Traceback (most recent call last):

  File "/tmp/neorg-exec/15.python", line 1, in <module>
    print(f)
@end
          ^
NameError: name 'f' is not defined

Which leaves behind the rest of the error message when running the code block again.

Not limited to only python as seen here

@code rust
println!("{}", a)
@end

#exec.start 2023.10.15T10.56.28AEDT
#exec.end 0.0000s 1
@result
error[E0425]: cannot find value `a` in this scope

 --> /tmp/neorg-exec/17.rust:2:32
  |
2 |                 println!("{}", a)
  |                                ^ not found in this scope

error: aborting due to previous error
@end

For more information about this error, try `rustc --explain E0425`.

Unsure if it is helpful or not, but the virtual output does correctly place "@end" at the end of the output.
15_10_2023_11-08-19

I see something similar:

@code bash
jupyter kernelspec list
@end

#exec.start 2023.11.27T00.58.52CET
#exec.end 1.0000s 0
@result
jupyter kernelspec list

/nix/store/zgvppg519rznbr7d8hyifp2wfwr60z9j-python3-3.11.6-env/lib/python3.11/site-packages/IPython/paths.py:69: UserWarning: IPython parent '/' is not a writable location, using a temp directory.
@end
  warn("IPython parent '{0}' is not a writable location,"
Available kernels:
  warn("IPython parent '{0}' is not a writable location,"
  python3    /nix/store/1pp5159pag4dmbhjpbh1fbmy37ngkph6-jupyter-kernels/kernels/python3
  haskell    /home/teto/.local/share/jupyter/kernels/haskell

Available kernels:

  python3    /nix/store/1pp5159pag4dmbhjpbh1fbmy37ngkph6-jupyter-kernels/kernels/python3
  haskell    /home/teto/.local/share/jupyter/kernels/haskell

Thus :Neorg exec clear doesnt clear (all) the generated content

Hi, sorry this is something I struggled with when I was developing this project, and just about kept it under control. No doubt it's worse than it was when I worked on it. Unfortunately the current parser makes this very hard...

Also, I have stopped using neorg for the forseeable [not forever, just until the project gets a bit further along], so I won't be working on this now. I'll update the readme to make it clear.

PRs are welcome, though.

Ta