Cells not being executed

[sho-87]

Are there any quarto/slime/slime-cells settings that need to be set in order for cells to be automatically executed after being sent to ipython?

Currently, when I send cells to ipython the code goes across but not executed because it seems like the lines are broken with shift-enter instead of enter:

I have to switch to the terminal window, enter insert mode, and manually hit enter to execute the cell

This is on Windows 11.

My config files, if relevant:

• https://github.com/sho-87/dotfiles/blob/master/nvim/lua/plugins/modules/quarto.lua
• https://github.com/sho-87/dotfiles/blob/master/nvim/lua/plugins/modules/slime.lua
• https://github.com/sho-87/dotfiles/blob/master/nvim/lua/keybinds_nvim.lua#L430-L440
• https://github.com/sho-87/dotfiles/blob/master/nvim/lua/utils.lua#L190-L196

[jmbuhr]

Maybe this is related to jpalardy/vim-slime#368 and/or jpalardy/vim-slime#373
I think there are some solutions but they never made it to a PR: jpalardy/vim-slime#301, jpalardy/vim-slime#283, jpalardy/vim-slime#299

So some change to https://github.com/jpalardy/vim-slime/blob/e5ae6a6d479c97d5352969574130956798e480b7/ftplugin/python/slime.vim is necessary.

[jmbuhr]

Oh, wait, I think I found the issue!

[jmbuhr]

The file I linked in vim-slime is part of ftplugin for python, so it will only run in a python file. But our filetype is of course quarto.

This creates the tricky situation where the correct behavior should not depend on the filetype of the document, but on the type of the target.

[jmbuhr]

This also suggests that both options, bracketed_paste and python_ipython don't actually do anything in the config (the first is only used when sending to tmux, the latter only when the filetype is python)

[jmbuhr]

I had noticed the same issue when executing code chunks that e.g. define a function, but I didn't realize that this is because we are not actually using the ipython paste mode. Interestingly, other things do work for me. Can you test these code chunks for me?

```{python}
import numpy as np
```

```{python}
np.zeros(10)
```

```{python}
def hello():
  print("hello")

```

```{python}
def hello():
  print("hello")
```

On my system, only the last one does not correctly send the final <cr> to execute, the others run.

Oh, looks like blank lines in between are also not working.

```{python}
from dataclasses import dataclass

@dataclass
class Point():
  x: float
  y: float

  def __add__(self, other):
    return Point(self.x + other.x, self.y + other.y)

```

Runs the part before def and then complains about the indent at def.

[jmbuhr]

I have a fix over at jmbuhr/quarto-nvim-kickstarter#17 now.
Note: this is using neovim nightly to account for upcoming changes and thus needs the master branch of nvim-treesiter, and 'nightly-treesitter' of otter.nvim.

The context-checking code should be integrated into quarto-nvim or otter.nvim eventually, though at this point I wonder if it already makes sense to write our own little code-sending functionality (vim-slime is surprisingly small and it would be nice to convert parts of it to lua for our usecase).

[sho-87]

@jmbuhr actually in my case none of those examples are executed automatically. they all require manually entering insert and pressing enter:

on a related note to kickstarter, I've been finding that I have to dig through the kickstarter codebase to find notes on configuration/usage. it seems that kickstarter is the primary source of setup notes for the nvim plugin - is there a reason for this? it feels a bit strange for a user new to quarto, but not new to nvim. for example, it feels inverted for changes/fixes to be made to kickstarter and integrated into the main nvim plugin at a later point?

[jmbuhr]

The overarching reason is that neovim already has many great and very specific plugins that I wouldn't want to incorporate directly into quarto-nvim. For example, nvim-cmp is the current state-of-the-art completion framework that people use. Shipping our own code completion would mess with that, so instead I provide a completion source for nvim-cmp. But that still has to be configured. Moreover, I can't automatically configure the required plugins, because that would mess with people's existing configs.

That being said, I agree with your point! I had noticed that configuration of other plugins that is relevant to quarto is not necessarily in the right place. I will take all the plugins and their configuration that interact direcly with quarto (that would be lsp, treesitter, completion, I think) and consolidate them at into one file. This should make it easier for people with their own config to copy the relevant parts into the correct places in their own config.

In that particular case, the reason I tried out the fix in the config instead of the quarto-nvim plugin is that there is nothing the plugin can do about this because it is indeed a configuration issue at the interaction of quarto and another plugin. This wouldn't happen for issues with the actual quarto plugin of course.

[sho-87]

That being said, I agree with your point! I had noticed that configuration of other plugins that is relevant to quarto is not necessarily in the right place. I will take all the plugins and their configuration that interact direcly with quarto (that would be lsp, treesitter, completion, I think) and consolidate them at into one file. This should make it easier for people with their own config to copy the relevant parts into the correct places in their own config.

I was thinking even updating the documentation here with new changes that are introduced over in kickstarter might be sufficient, but yeah centralizing would be useful as well i think. or even just update the readme here with links to the relevant kickstarter bits. I dont think it needs to be a massive restructure! It was mostly a case of quarto not working properly on my end and trying to find information on how to fix it, and not knowing where to look other than the kickstarter code

[jmbuhr]

Yes, and just having things in the same file will already make a big difference I think, and easier to link to like you said.

[jmbuhr]

https://github.com/jmbuhr/quarto-nvim-kickstarter/tree/nightly Should also correctly execute python code chunks in ipython now. Plus I centralized the quarto-relevant plugins into one file. Still working on a balance between making things accessible and clearn and a huge info-dump. I would be happy about thoughts on the readme and code comments in the lua/plugins/quarto.lua file as I think there are a bunch of areas to improve onboarding.

[sho-87]

thanks for the update - everything is much easier to find/follow now!

I think generally it looks pretty good. the only super minor nitpicky point would be:

• I'm not sure I would know what the conceal related options are for without watching through the video series as I dont see it mentioned anywhere else

honestly I think your video series was the most useful thing for demonstrating what quarto is, how to use it, and available options. I know its linked in the kickstarter readme, but I'd be tempted to link it front and center on the quarto-nvim readme as well, as it's relevant to anyone new to quarto (not just those new to nvim)

[jmbuhr]

Thanks for the feedback! I did that just now indeed (8a7f49f)

Also, yes, conceal is weird. Especially because it can come from different places (treesitter and old-school syntax files). That's part of the reason why I have now commented it out (=disabled it) by default in the kickstarter config.