Refactoring chunk extraction

[PMassicotte]

https://github.com/R-nvim/R.nvim/tree/better-code-chunk-extraction

I have made a proof of concept on this branch. Basically, we can use get_code_chunks() to extract all chunks from the current buffer (regardless of the language).

Then we can filter code chunks to only keep these with eval:true, of for a certain language.

The chunks_up_to_here() is now very short

R.nvim/lua/r/send.lua

Lines 329 to 346 in fde972e

	--- Send to R Console a command to source a file containing all chunks of here
	--- code up to this one.
	M.chunks_up_to_here = function()
	local bufnr = vim.api.nvim_get_current_buf()
	local chunks = quarto.get_chunks_above_cursor(bufnr)
	chunks = quarto.filter_code_chunks_by_eval(chunks)
	chunks = quarto.filter_code_chunks_by_lang(chunks, { "r", "python" })
	if #chunks == 0 then
	inform("No runnable code chunks found above the cursor.")
	return
	end
	local codelines = quarto.codelines_from_chunks(chunks)
	M.source_lines(codelines, "chunk")
	end

[jalvesaq]

It doesn't work with this if I do <LocalLeader>ch on the Python code below:

---
title: "Testing..."
---

First paragraph.

```{r}
x <- 1
```

Second paragraph.

```{python}
y = 10
```

End.

[PMassicotte]

Right. it is because send_lines check with get_lang() is the cursor is in a python block, if so, will use reticulate.

[PMassicotte]

If you place the cursor elsewhere it will work.

[PMassicotte]

This should work with the latest push.

[PMassicotte]

<localleader>cc and <localleader>cd should work now.

[jalvesaq]

It works now, but the behavior is a bit different from the "main" branch. For example, if the Quarto document is:

---
title: "Testing..."
---

First paragraph.

```{r}
x <- 1
```

Second paragraph.

```{python}
y = 10
```

Third paragraph.

```{r}
w <- 2
z <- 3
```

End.

If the cursor is on w <- 2, the "main" branch includes the line w <- 2. The new branch sends only complete chunks and, thus, doesn't include any line of the current chunk. I see no problem in changing the behavior, but some users might be used to the old behavior.

[PMassicotte]

Good point. I'm unsure of the best approach here and don’t have a strong preference. Let's think it through and decide on the best option. Feel free to make changes, especially if there are any quick wins.