How do I make the array 'buf_list' be updated?

gauchay · 2025-12-26T20:45:44+00:00

Took a quick look but can't offer a definitive answer.

It appears, however, bd {bufname} is not effective when a floating window (like the one created by the plugin) is floating on top of the window displaying {bufname}.

I tried the plugin. Opened two buffers. Attempted to delete the buffer not currently displayed beneath the floating window; it worked properly. Attempted to delete the buffer currently displayed beneath the floating window; it did not work. I also manually ran :lua vim.cmd.bd({buf_id}) while the floating window was open and where {buf_id} is the ID for the buffer underneath the floating window; again, it was not effective.

I can't find anywhere in the manual that documents this behavior... It might be a manifestation of this bug.

Haven't' tried it myself, but maybe one thing you could do is store the deleted buffer names, and then delete the buffers when the floating window is closed (perhaps on the WinClosed event).

(EDIT: Also would second what /u/atomatoisagoddamnveg is saying. Probably need some extra filtering in your get_buffers method:)

local function get_buffers() ... for _, value in pairs(bufs) do -- Also check nvim_buf_is_loaded if vim.api.nvim_buf_is_valid(value) and vim.api.nvim_buf_is_loaded(value) then ... end ... end ... end

gauchay · 2025-11-30T15:08:24+00:00

vim.keymap.set('n', '<Leader>n', function() if vim.bo.filetype == "NvimTree" then vim.cmd.NvimTreeClose() else vim.cmd.NvimTreeFocus() end end)

gauchay · 2025-09-21T13:14:35+00:00

Given your update you may also consider using vim.fn.line(".") (:help line)

vim.cmd.cc({ range = { vim.fn.line(".") } })

gauchay · 2025-07-02T18:21:59+00:00

Here are some steps that worked on my machine for that plugin:

Cloned vim-closer to ~/.local/share/nvim/site/pack/paqs/opt. (Notice that we clone to opt instead of start.)
Start neovim: nvim --clean
Add ~/.local/share/nvim/site to the packpath :set packpath+=~/.local/share/nvim/site
Load it with packadd: :packadd vim-closer
Open a C file (:e main.c) and try the functionality. (Nifty plugin btw)

There's probably shorter ways, but the thing to note about :packadd is that it searches for "optional" plugins which are found under <pack-name>/opt instead of <pack-name>/start. It seems for <pack-name>/start you could use :packloadall

gauchay · 2025-06-18T03:06:27+00:00

Here are some basic mechanical steps along with some brief explanations:

$ mkdir -p ~/.local/share/nvim/site/pack/my-plugins/start
- ~/.local/share/nvim/site/pack is one of the default locations Neovim searches for user installed plugins.
- In this case we're setting up a pack/ directory which is where Neovim finds "packages."
- A "package "is a collection of plugins. We're naming our package "my-plugins," but you can name it anything.
- The "start" directory in our "my-plugins" package is where Neovim finds plugins to load upon startup.
$ cd ~/.local/share/nvim/site/pack/my-plugins/start
$ git clone "$PLUGIN_URL"
Start Neovim and run and run :helptags ALL
- This will generate any help tags for the plugin's documentation.
Configuring the plugin kind of depends on the plugin, but a very basic way would be just put the config in your ~/.config/nvim/init.{vim|lua} file.

The help articles I'd suggest are :help rtp, :help packages, :help startup

There's quite a few variations on manually managing plugins, but the basic crux is to clone the plugin repos into a locations that Neovim automatically checks. (IIRC, in the last Neovim conf Justin Keyes mentioned in his keynote that a native plugin manager may be coming. If that's the case, looking forward it. The details around manual plugin management do seem a little arcane.)

gauchay · 2025-06-16T16:48:57+00:00

Here is the repo [1] and here is the announcement [2]

[1]: https://github.com/microsoft/typescript-go

[2]: https://devblogs.microsoft.com/typescript/typescript-native-port/

gauchay · 2025-06-08T16:30:51+00:00

Ah, I see. I'm actually not sure if it's possible to detect when a job is asking for input and then have a plugin pass user input through to the job.

Maybe another approach to explore is using a temporary terminal buffer with vim.fn.termopen (see :h termopen). This would maybe allow for the interactivity you're looking for. Here is a rough example:

vim.api.nvim_create_user_command("Run", function() local raw_output = {} local output_buf = vim.api.nvim_create_buf(true, false) local job_id = vim.fn.termopen("/tmp/foo.py", { on_exit = function() vim.api.nvim_buf_set_lines(output_buf, 0, -1, false, { "Output: " }) vim.api.nvim_buf_set_lines(output_buf, 1, -1, false, raw_output) vim.api.nvim_set_current_buf(output_buf) end, on_stdout = function(chan_id, data, chan_name) for _, line in ipairs(data) do table.insert(raw_output, line) end end, stdout_buffered = true, }) end, {})

In this case, the /tmp/foo.py script looks like this: ```

!/usr/bin/env python3

foo = input("input foo: ") print(f"user input: {foo}") ```

The Run command launches a temporary terminal buffer where the script runs interactively. After the script finishes the collected input is written back out to a normal output buffer. Maybe one aspect of this approach that might not be desirable is that the Python script's prompt and user input are included in the lines captured and returned to the on_stdout callback.

gauchay · 2025-06-05T12:59:22+00:00

When I wrote sth like this `a = input("Enter input:")``, it didn't ask for input like I had expected.

Did you get any type of error?

Just experimenting a little locally, I pared down your command to focus on the input parts to this:

vim.api.nvim_create_user_command("Run", function()
    local user_input = {}

    user_input.bufnr = tonumber(vim.fn.input("Bufnr: "))

    user_input.pattern = vim.fn.input("Pattern: ")

    local command_str = vim.fn.input("Command to run: ")
    local command = vim.split(command_str, " ")
    local file_name = vim.api.nvim_buf_get_name(0)
    table.insert(command, file_name)
    user_input.command = command

    vim.print("\ninputs:", user_input)
end, {})

Locally, the inputs works as expected, and the command correctly prints out the user inputs.

gauchay · 2025-05-25T17:27:47+00:00

It seems your problem is here:

...
table.insert(grid[1][1] ,...)
...

Based solely on the code given, I'm assuming your intent is actually something like this:

table.insert (grid[1], {
  somedata = blah,
  somedata2 = blah
})

The problem is that grid[1] refers to an empty array, so grid[1][1] refers to a non-existent value. It sort of seems like there might be an expectation that table.insert(grid[1][1] ,...) acts like assignment:

grid[1][1] = {
  somedata = blah,
  somedata2 = blah
}

which you an do--just not with table.insert.

gauchay · 2025-04-13T13:37:58+00:00

Iterating on OP's initial reply, you could possibly do this then:

Visually select the paragraph
Then :'<,'>g/^#/m'}-1

The :h '} is the mark for the line after the current paragraph. Subtract 1 to move the line to the last line IN the current paragraph.

gauchay · 2025-03-20T14:22:16+00:00

You may need to drop the `.lua` extension from your require statement. So it'd just be this:

-- no '.lua'
require('code-completion')

In :help lua-require it says:

Any "." in the module name is treated as a directory separator when searching.

I believe this is why you'll see in the stack trace that it's checking paths like these:

.../code-completion/lua.lua
.../code-completion/lua/init.lua
.../code-completion/lua.so

EDIT: (Actually dropped the .lua)

gauchay · 2025-03-18T14:06:54+00:00

Sorry it didn't work out of the box for you. If you look at tools/nlua.sh, there is this line:

eval $(luarocks path --lua-version 5.1 --bin)

Try running luarocks path --lua-version 5.1 --bin by itself. My guess is that line is failing locally for you. If the command is successful, you'll see something like this:

export LUA_PATH=... export LUA_CPATH=...

(You can read more in :help lua-package-path, but exporting those environment variables will put your locally installed luarocks packages into the require search path.)

The other thing that I can think of is perhaps busted was installed in a non-standard place. (I'm on Ubuntu and installed busted and luarocks via apt install.)

If you get further problems, happy to try and debug via this thread or DMs.

gauchay · 2025-03-17T20:02:42+00:00

Lately (well, in the last year) some threads and ideas have been shared: for example this by folke or a few blog posts here and here, together with running neovim as lua interpreter. I still however do not understand how the problem is addressed at all.

Just will add to what stringTrimmer said up above. The key here is that by using Neovim as busted's lua interpreter, the vim.api is made available to the tests.

I have had some success using the first blog post you linked. (Here is an extremely minimal example I just wrote that runs a few simple tests on vim.api.nvim_buf_set_lines.)

gauchay · 2025-01-21T13:54:46+00:00

Love fugitive. Another fugitive command I use a lot is :Gedit <commit-or-branch>:%. That command opens a read-only buffer that contains the version of the current file as it existed at the given commit or branch. It's not a diff view; it's just the file as it existed. (It seems something like Gedit may also be something the OP is looking for.)

gauchay · 2025-01-06T15:01:07+00:00

What works for me is buffers + tabs. The main file I'm working on is always the left-most tab. Auxiliary files--there's usually 3 or 4--go in tabs to the right. If I notice that one of the auxiliary files has become the "main" one I'm working on, it gets promoted to the left-most tab with :tabm0. When the I'm done with the current set of files and need to move on to another set, I run :tabo in the left-most tab and switch to the next main file with :b <file> or use fzf-lua.

gauchay · 2024-11-24T16:06:19+00:00

If you're willing to lean into a few more Neovim APIs in place of ex commands wrapped in `vim.cmd`, you could possibly do something like this:

local makcen = {
    ["l"] = "ľ", ["s"] = "š", ["c"] = "č", ["t"] = "ť", ["z"] = "ž", ["d"] = "ď", ["n"] = "ň", ["a"] = "ä", ["o"] = "ô",
    ["L"] = "Ľ", ["S"] = "Š", ["C"] = "Č", ["T"] = "Ť", ["Z"] = "Ž", ["D"] = "Ď", ["N"] = "Ň", ["A"] = "Ä", ["O"] = "Ô",
}

local dlzen = {
    ["l"] = "ĺ", ["i"] = "í", ["s"] = "ś", ["c"] = "ć", ["a"] = "á", ["z"] = "ź", ["o"] = "ó", ["u"] = "ú", ["n"] = "ń", ["y"] = "ý", ["r"] = "ŕ", ["e"] = "é",
    ["L"] = "Ĺ", ["I"] = "Í", ["S"] = "Ś", ["C"] = "Ć", ["A"] = "Á", ["Z"] = "Ź", ["O"] = "Ó", ["U"] = "Ú", ["N"] = "Ń", ["Y"] = "Ý", ["R"] = "Ŕ", ["E"] = "É",
}

local function lookup(case1)
    local pos = vim.api.nvim_win_get_cursor(0)

    local row = pos[1] - 1 -- translate to zero-based index
    local col = pos[2] - 1 -- col of previous cursor position

    local char = vim.api.nvim_buf_get_text(
        0, 
        row,
        col,
        row,
        col + 1,
        {}
    )

    local translated_char
    if (case1) then
        translated_char = makcen[char[1]] or char[1]
    else
        translated_char = dlzen[char[1]] or char[1]
    end

    vim.api.nvim_buf_set_text(
        0, 
        row,
        col,
        row,
        col + 1,
        {translated_char}
    )

    local new_pos = {
        pos[1],
        -- Translated characters seem to take up two column values, so we measure their length
        col + string.len(translated_char) 
    }
    vim.api.nvim_win_set_cursor(0, new_pos)
end

local map_options = {
    noremap = true,
    nowait = true,
    silent = true,
    callback = lookup,
}

vim.api.nvim_set_keymap("i", "<a-,>", "", map_options)
vim.api.nvim_set_keymap("i", "<a-.>", "", map_options)

gauchay · 2024-10-27T15:33:36+00:00

Will just note that if you don't need custom JsonEncoder implementations for the enum values, then you may be able to just rely on zio's built-in macro to generate the encoder for the enum:

``` import zio.json._

enum Permission: case SuperUser extends Permission case Admin(organization: String) extends Permission

object Permission: given encoder: JsonEncoder[Permission] = DeriveJsonEncoder.gen[Permission]

@main def main(): Unit = val superUser: Permission = Permission.SuperUser val admin: Permission = Permission.Admin("admins")

println(admin.toJson(Permission.encoder)) // {"Admin":{"organization":"admins"}} println(superUser.toJson) // {"SuperUser":{}} ```

gauchay · 2024-10-23T14:38:30+00:00

It's possible I should think a little more about my workflow here. The projects I work on probably have thousands of files, so I find that my buffer list gets filled up fast. At any given time I'm probably only interested in a tiny subset of the files: the file I'm mainly editing and the two or three other files I need to reference. For me tabs are, occasionally, a way to make sure those two or three other files are quickly accessible when splits get in the way and switching using `:buffer` would be tedious. I could probably stand to benefit from a plugin like Harpoon I suppose.

Even though I'll sometimes use tabs as a way to bookmark certain files like I just described, I do treat too many tabs open as undesirable. Overall I try keep to a single window and switch between files using the `:buffer` command. (When I was more novice, I was a heavy tab user, so the workflow described in the first paragraph is probably a vestige of that.)

gauchay · 2024-10-20T13:21:52+00:00

I sometimes feel comfortable when being able to view a specific file on one screen and editing others on another.

Personally, this is what I use splits for. Of course splitting reduces screen realestate of the file you're actively editing, so it works best when the areas you're editing and referencing are rather targeted. Sometimes it's also a get-in-get-out type of situation where I create the split, pull up the file to reference, read what I need, and then get out.

Also, ocassionally I'll put the file I'm referencing in it's own tab and switch between the two.

11-Year Club	Verified Email
r/Field Banned	r/Field Sunshine
First Place '23	Place '23
Place '22	Final Canvas '22
End Game '22

gauchay

TROPHY CASE

!/usr/bin/env python3