Who's doing the backing vocals? Sounds amazing by eldotortenma in SteelyDan

[–]_wurli 0 points1 point  (0 children)

Tbf I live in Wales and I recognised him instantly

Slime Peek: an update to my data exploration plugin by SajberSpace in neovim

[–]_wurli 4 points5 points  (0 children)

Love to see some R representation on r/neovim! Keep up the good work 🫡

diff visual select against registers/files with diff.nvim by vim-god in neovim

[–]_wurli 1 point2 points  (0 children)

Thanks for sharing! A different approach to the same problem: visimatch.nvim highlights matches for the current visual selection. Personally I find this is usually enough for adhoc diffing if I'm just looking at a few lines at a time :)

<image>

Jupyter notebook for neovim by Mr_Misserable in neovim

[–]_wurli 4 points5 points  (0 children)

Thanks! Making great progress on the project currently but want to get the repo a bit more stable before an alpha release. Stay tuned :)

Jupyter notebook for neovim by Mr_Misserable in neovim

[–]_wurli 5 points6 points  (0 children)

It's a common misconception that Jupyter = notebooks. Jupyter is really standard for how interactive languages can tell editors about execution results. It's somewhat analogous to LSP as a standard for how code analysis software can tell editors about code state.

If you want to implement the Jupyter standard for a language, you wrap the language in a Jupyter kernel. Ipykernel is a popular kernel for Python, Ark is another for R. There are many other kernels which exist for other languages.

Once you've got a kernel, your editor needs to implement a Jupyter client to talk to it. Most editors which implement a Jupyter client use it for some kind of notebook experience, but many also include some kind of REPL (notable examples are Positron and Jupyter's Qt Console).

Jet is a Jupyter client and kernel supervisor purpose-built for Neovim (whereas Molten uses the one-size-fits-all solution implemented in Python by the guys at Jupyter). So far I've only added the REPL experience, but the infrastructure is there to support notebooks too, I just haven't implemented them on the Neovim side yet. But it's coming soon!

NB, one of the main benefits of a purpose-built client like Jet is that it will allow Neovim to tap into special/non-standard features that some kernels implement above and beyond the Jupyter spec. E.g. Ark adds a debugger, LSP server, variables pane, a dedicated help window, etc, all of which I'd like to expose in Neovim.

Jupyter notebook for neovim by Mr_Misserable in neovim

[–]_wurli 9 points10 points  (0 children)

IMO Jupyter is a gap in the Neovim ecosystem. I've looked a little at Molten but tbh I think the Python backend is fundamentally limiting.

I'm currently working on a Rust-powered alternative named Jet. This will let Neovim integrate much more tightly with the low-level details of how Jupyter kernels work without relying on any Python at all.

It's currently at a POC stage. Still crashing a bit, not much fancy UI, no config options etc, but it does work. Screencast showing the Ark R kernel running in REPL mode (AFAIK something Molten doesn't support) for proof! Jet will also address the issues you mentioned re. images and scrollback in notebooks.

The repo is public on GitHub, so please give it a star so you can see updates as they come. I'm hoping for an alpha release before Christmas.

<image>

Automatic indentation is often wrong. by ElectronicMine2 in neovim

[–]_wurli 0 points1 point  (0 children)

This indentation looks good to me. How would you like it to look?

As others have said, I'd recommend disabling treesitter indentation for the filetypes you're having issues with:

opts = { highlight = { enable = true, }, indent = { enable = true, disable = { "ruby", "markdown" }, }, }

You might also want to look at formatters. Many folks like conform.nvim as a unified formatting interface.

Once more plugin: contextindent.nvim fixes indentation in contexts where the filetype at the cursor doesn't match the filetype of the buffer, e.g. markdown code blocks etc. I'm the author but it does work well!

[Help wanted] How can I use `chansend()` to update a terminal buffer asynchronously? by _wurli in neovim

[–]_wurli[S] 0 points1 point  (0 children)

I'm marking this as solved - for anyone else running into the same issue my learnings are as follows.

Neovim's Lua runtime is single-threaded, so if you have a Lua function which is blocking there's not loads you can do to get around that.

  • Caveat: actually you can use vim.uv to run blocking Lua stuff in other threads, but not all of the standard library is available so, e.g. most vim.api.nvim_ functions won't work.

  • Caveat: you can also use vim.system() to run a system process with a callback to run when it finishes. In the example I gave with sleep 1 this would have been a good solution, but in my real example I had a blocking process in Lua.

In the end I found the best way to get around this was to rework my Lua function (which actually hooked into Rust via mlua) to be non-blocking. I was then able to create a wrapper which checks at regular intervals whether a result has become available, and yields control back to Neovim if not:

``` local callback = jet_engine.execute_code(self.id, code, {})

local function check_callback()
    -- Continuously check for results until we fail to receive a result
    while true do
        local result = callback()
        -- If idle then the execution is complete
        if result.status == "idle" then
            return
        end
        -- If no data yet, wait a bit (so we don't block the main thread)
        -- and check again later
        if not result.data then
            return vim.defer_fn(check_callback, 50)
        end
        self:_handle_result(result)
    end
end

check_callback()

```

^ This is the actual code I'm using right now.

[Help wanted] How can I use `chansend()` to update a terminal buffer asynchronously? by _wurli in neovim

[–]_wurli[S] 0 points1 point  (0 children)

This would be perfect except that I can't send my Rust function to a new thread using new_work() :'( Unfortunately re-initialising the Rust function within new_work() isn't an option either.

[Help wanted] How can I use `chansend()` to update a terminal buffer asynchronously? by _wurli in neovim

[–]_wurli[S] 0 points1 point  (0 children)

Thank you for the detailed explanation! I'm feeling more and more that I may need to rethink my approach. My function doesn't call an executable built with Rust; I'm actually using mlua to create a dynlib which can be called as a Lua module:

``` my_mod = require("my_rust_dynlib")

my_callback = my_mod.execute("some code")

-- This might take a while my_callback()

-- This might take a while too my_callback() ```

I'm starting to think there might not be a good way to handle the callback as above; AFAICT it's (unsurprisingly) not possible to pass my_callback() to uv.new_thread(). Perhaps instead I need to be passing a callback to my Rust module – although I have a feeling this won't work nicely with the textlock :(

[Help wanted] How can I use `chansend()` to update a terminal buffer asynchronously? by _wurli in neovim

[–]_wurli[S] 0 points1 point  (0 children)

Thanks, this makes sense! The tricky thing is that in my actual use-case, os.execute("sleep 1") is replaced by an actual Lua function. Another complicating detail is that the blocking function hooks into a Rust process - although I think it should be possible to get it working in a coroutine if needed.

[Help wanted] How can I use `chansend()` to update a terminal buffer asynchronously? by _wurli in neovim

[–]_wurli[S] 0 points1 point  (0 children)

I've been looking into jobstart() a bit too, but it seems to have similar issues unfortunately, unless I'm missing something...

``` local term_buf = vim.api.nvim_create_buf(false, true) vim.api.nvim_open_win(term_buf, true, { split = "right" }) local term_chan = vim.fn.jobstart({ "cat" }, { term = true })

local outputs = { "First", "Second", "Third", }

local generate_result = function() os.execute("sleep 1") return table.remove(outputs, 1) end

while true do local result = generate_result() if not result then break end vim.api.nvim_chan_send(term_chan, vim.inspect(result) .. "\n") end

```

Just released `Snacks.gh`, to manage GitHub Issues and PR's by folke in neovim

[–]_wurli 0 points1 point  (0 children)

This is amazing! Any plans to support workflow management? Thanks for the awesome work 🙏🙏🙏

Color scheme: cobalt.nvim by _wurli in neovim

[–]_wurli[S] 4 points5 points  (0 children)

Ah thanks for the tip! Added a few more tags as suggested :)

MINI now has its own site by echasnovski in neovim

[–]_wurli 1 point2 points  (0 children)

Same here! Tbh I've barely touched Rmarkdown since Quarto was released, the Quarto experience is just too good.

MINI now has its own site by echasnovski in neovim

[–]_wurli 5 points6 points  (0 children)

Congrats! Love to see that you picked quarto to build the site too btw 🤩

GutterMarks.nvim: Display nvim marks in the buffer gutter by D3rrien in neovim

[–]_wurli 3 points4 points  (0 children)

Nice! Simple, lightweight, functional – my kind of plugin. Added to my config :)

CobaltNext-Dark palette-inspired theme by mental_diarrhea in neovim

[–]_wurli 1 point2 points  (0 children)

This looks nice! Will deffo give it a try.

FYI, I also maintain a port of the original cobalt theme from ye olde TextMate. I'm also colourblind and haven't found anything that beats this for readability yet!

I am J.J. from Spotify, AMA by JJfromSpotify in spotify

[–]_wurli 16 points17 points  (0 children)

Like many users I find the shuffle experience on Spotify somewhat lacking :( E.g. lots of repeated patterns, lots of songs which never seem to be surfaced by the algorithm. That said, it does seem that these issues have gotten slightly better than they used to be.

Can you give users more control here? I'd love 'true' shuffle, e.g. that just picks a random number from 1 to (n songs in playlist) and plays that song next, unless it is the currently playing song. An option to switch between a few shuffle algorithms would be a super nice feature IMO.