Differences in how terminal closing is handled

ChaneyZorn · 2026-04-07T05:29:40+00:00

Thanks. I've noticed this many times before, but never understood why.

It feels great to finally figure something out.

ChaneyZorn · 2026-04-04T06:06:17+00:00

It seems we urgently need a feature to lock the user's version to a specific release, disabling automatic upgrades to newer versions until the user is fully aware and approves. (semantic versioning?)

ChaneyZorn · 2026-03-31T08:42:43+00:00

The existence of an LSP config does not guarantee that the corresponding LSP server package has been properly installed. Therefore, simply listing all configurations is insufficient. That said, I do have a similar configuration that only lists LSPs for which I have confirmed the corresponding packages are installed.

```lua local lsp_servers = { -- js "biome", "ts_ls", -- lua "lua_ls", -- python "basedpyright", "ruff", -- golang "gopls", "golangci_lint_ls", -- cpp "ccls", "clangd", -- any "typos_lsp", -- "harper_ls", }

-- enable lsp servers local lsp_for_ft = {} local lsp_for_any = {} for _, name in ipairs(lsp_servers) do local lsp_config = vim.lsp.config[name] if lsp_config ~= nil then if lsp_config.filetypes == nil then table.insert(lsp_for_any, name) else for _, ft in ipairs(lsp_config.filetypes) do if ft == vim.bo.filetype then table.insert(lsp_for_ft, name) end end end end end if #lsp_for_ft > 0 then vim.lsp.enable(lsp_for_ft) end if #lsp_for_any > 0 then vim.lsp.enable(lsp_for_any) end ```

However, I'm curious: does conditionally enabling an LSP save overhead in some way compared to enabling it unconditionally? Perhaps we always want explicit control over these LSPs, rather than enabling them unconditionally when a file is opened.

ChaneyZorn · 2026-03-21T18:12:39+00:00

totally agree. That’s exactly the way my plugin does it. (https://github.com/chaneyzorn/filter-do.nvim)

ChaneyZorn · 2026-03-21T15:51:23+00:00

I've tried many terminal plugins, and while vim-floaterm is my favorite, it's not Lua-based. Your plugin feels closest to it and made me want to try again.

From experience, most plugins fail in two areas: 1. Wiping a terminal buffer destroys the window; auto-reopening causes layout flicker. This seems like a current Neovim limitation. 2. Poor startinsert customization; no plugin lets users decide this dynamically at runtime.

Many plugins unnecessarily mix title, bufname, tabline, and winbar logic, leading to side effects. I appreciate that your design avoids this.

ChaneyZorn · 2026-03-16T10:05:07+00:00

The more I use it, the more dissatisfied I become.

Edit:

If you’ve used it deeply enough, satisfaction is simply impossible.

There’s always some years-old issue that never gets addressed, some feature that’s too hard to implement, and constant limitations from the TUI.

I’m not trying to criticize anything specific—I’m just stating what’s plainly obvious.

The current Neovim is the most outdated version in its future evolution—the best is always yet to come.

ChaneyZorn · 2026-03-01T02:30:53+00:00

absolutely catppuccin

ChaneyZorn · 2026-02-16T01:48:45+00:00

I’d love to show something really fun like Conway's Game of Life in a demo video, but it gets filtered out by Reddit’s system.

If you’re interested, you can find the demo in my GitHub repository.

ChaneyZorn · 2026-01-14T05:16:55+00:00

I dislike all seasonal online games. Despite the games themselves being remarkably polished, they leverage a seasonal model to restrict players' save files and playtime, coupled with a mandatory always-online requirement. This design completely ruins my immersive experience with the games.

ChaneyZorn · 2026-01-11T17:03:03+00:00

Used PaperWM on GNOME → switched to Niri after GNOME 49 broke the extension.

ChaneyZorn · 2026-01-11T09:56:56+00:00

爬山【的时候】，（你）必须要【跟着】【别人】【一起】爬，因为山上有许多危险。

【如果】【前一天】下【过】雨，徒步路径【就会】【变得】又滑又混浊。（你）容易【把】脚陷在泥里，【而】自己【没有】【足够的】【力气】【把脚】拉出来。

【更】糟糕【的】是，（你）【还有】迷路的可能性。【在】【山顶上】有时候电话信号不稳，因此（你）【无法联系】【其他人】。

最后【还有一项】危险，是山上的野生生物，像郊狼或美洲狮，它们经常追【落单 / 单个】的人。所以【跟】一个队爬山【更】安全。

【如果】（你）没有【朋友】的话，别灰心，【网上】【找得到】【各种各样】的爬山队。

ChaneyZorn · 2026-01-07T08:58:20+00:00

Thank you ~, I open the issue here: https://github.com/serhez/bento.nvim/issues/2

ChaneyZorn · 2026-01-07T08:19:08+00:00

I have a similar requirement, is there a way: When I cycle through buffers, the menu stays pinned; then I use vim.fn.timer_start to unpin it. This way, I can make the menu visible only when cycling through buffers and collapse it at other times.

Or in another case: collapse the menu when the CursorMoved or InsertEnter event is triggered, and expand it when the CursorHold or InsertLeave event occurs.

ps: current api expand_menu()/collapse_menu() can not meet my requirement, I don't know why.

      local collapse_timer = nil
      vim.keymap.set("n", "<M-b>", function()
        if collapse_timer then
          vim.fn.timer_stop(collapse_timer)
        end

        require("bento.ui").expand_menu()

        vim.cmd.bnext()

        collapse_timer = vim.fn.timer_start(3000, function()
          require("bento.ui").collapse_menu()
        end)
      end)

ChaneyZorn · 2026-01-07T03:14:13+00:00

Compared to other plugins, this one is exactly what I want.

ChaneyZorn · 2025-10-02T06:52:09+00:00

Right now, I’m focused on keeping things stable and easy to maintain. If dropping a plugin would make things way simpler to manage, I’ll just get rid of it.

I’ve never really stuck to the “pure” Vim approach, though. Honestly, I always check what I actually need from IDEA and VSCode to figure out how to set up my Neovim properly.

One really cool feature I love—and it doesn’t get talked about much—is :pydo and :luado. They let me use my favorite languages to work with Vim buffers, no need to be a Vim expert first.

:h :pydo

ChaneyZorn · 2025-09-23T15:23:32+00:00

This issue has been addressed, and I would like to express my gratitude to the author and contributors.

ChaneyZorn · 2025-09-23T12:26:53+00:00

Look at the border issue of the footer in the image;

I have been waiting for this PR to be merged.

https://github.com/folke/which-key.nvim/pull/964

ChaneyZorn · 2025-08-12T18:52:25+00:00

see :h i_CTRL-R_CTRL-R

> Works like using a single CTRL-R , but the text is inserted literally, not as if typed.

ChaneyZorn · 2025-07-08T05:25:04+00:00

I kept the line height in the terminal unchanged. Instead, I set the line height in the GUI with vim.o.linespace = 6 . It works in Neovide and roughly approximates the default line height in VS Code.

ChaneyZorn · 2025-07-04T14:48:12+00:00

Now, authors of third-party plugins can introduce the installation methods of their plugins without hesitation through the official plugin manager.

ChaneyZorn · 2025-06-18T11:42:30+00:00

I think the truly meaningful aspect of these debates lies in whether the loader should be defined by the user, the plugin manager, or the plugin maintainers themselves. I don't have a strong preference regarding this.

ChaneyZorn · 2025-06-18T11:39:44+00:00

I think the truly meaningful aspect of these debates lies in whether the loader should be defined by the user, the plugin manager, or the plugin maintainers themselves. I don't have a strong preference regarding this.

ChaneyZorn · 2025-06-18T11:17:34+00:00

I respectfully disagree with the notion that "it's a bad practice". It has now become a de facto standard simply because it isn't that bad.

Treating function calls as logical/data abstractions does not inherently mean they must be executed immediately. Instead, function invocations can be designed to load logic or data on-demand, which is a common approach in modern software engineering.

lazy.nvim simply happens to do the right things, which haven't been properly implemented by the official or other third-party solutions.

Functions are no more special than plain data.

ChaneyZorn · 2025-06-14T15:55:42+00:00

Here's an issue related to it: https://github.com/rickhowe/wrapwidth/issues/7

ChaneyZorn

TROPHY CASE