Thanks for creating this package! I enjoy the minimalist Jupyter-like workflow of python-mode when combined with code-cells.el and comint-mime.
While testing it out, I discovered that the following example file results in a somewhat surprising behavior in code-cells.el:
for i in range(10):
print("Hello world")
# %%
print("Test")
If I place the cursor above the first # %% line and invoke code-cells-eval, then it prints out "Hello world" only once. So it appears that the first line of a Python script is never considered part of a cell. (If I place a shebang or blank line above the for loop, then it runs as expected.)
For comparison, I tried doing the same in Spyder, which prints "Hello world" 10 times as expected. I also tried it in VSCode, which simply doesn't recognize the area above the first # %% as a "cell" and therefore does nothing. I guess both of these behaviors make some sense.
I think this is not a big issue in practice, as I'll usually want a shebang on the first line of the file anyway, but I thought to report this anyway :).
I'm running it on Emacs Mac port (v29.1) with the following config:
Thanks for creating this package! I enjoy the minimalist Jupyter-like workflow of
python-mode
when combined withcode-cells.el
andcomint-mime
.While testing it out, I discovered that the following example file results in a somewhat surprising behavior in
code-cells.el
:If I place the cursor above the first
# %%
line and invokecode-cells-eval
, then it prints out "Hello world" only once. So it appears that the first line of a Python script is never considered part of a cell. (If I place a shebang or blank line above the for loop, then it runs as expected.)For comparison, I tried doing the same in Spyder, which prints "Hello world" 10 times as expected. I also tried it in VSCode, which simply doesn't recognize the area above the first
# %%
as a "cell" and therefore does nothing. I guess both of these behaviors make some sense.I think this is not a big issue in practice, as I'll usually want a shebang on the first line of the file anyway, but I thought to report this anyway :).
I'm running it on Emacs Mac port (v29.1) with the following config: