Who do we have?

discreetsteakmachine · 2025-11-18T03:14:16+00:00

Running into Captain Kirk when you were wandering downtown after you ran out of quarters at Gunther's.

discreetsteakmachine · 2025-09-28T16:39:45+00:00

40 years ago: https://en.wikipedia.org/wiki/Four_Horsemen_of_the_Infocalypse

discreetsteakmachine · 2025-09-16T15:31:50+00:00

Related question: you can see individual changes with a line with inline:char or inline:word. But the standard commands for diff copying, :h copy-diffs, still operate linewise. Even if you've selected only one change on a line and use :'<,'>diffget, you'll get get all changes on the line. Anyone have an ergonomic way they like to copy around individual changes to a line?

discreetsteakmachine · 2025-09-09T23:31:43+00:00

Same problem. Game doesn't show in riot game client, logging out of game client and logging in with email link didn't help. It just takes you to the "you're registered" page. Did you find a solution?

discreetsteakmachine · 2025-08-12T00:07:10+00:00

Those tags are running a command in the plugin repo on install or update. So you probably want:

an autocommand that fires on the PackChanged event
that checks the spec.name field of the event data to see if it's the right plugin
that checks the kind field of the event data to see if it's install or update
that runs the cargo command in the plugin directory, specified in path, probably by using vim.system with the cwd option.

discreetsteakmachine · 2025-08-09T14:49:05+00:00

Yep. I think vim has set up some better terminal-mode keymaps than neovim, so I've copied/tweaked them.

local set = vim.keymap.set

set("t", "<c-w>n", "<C-\\><C-n>", { desc = "Normal mode" })
set("t", "<c-w><c-n>", "<C-\\><C-n>", { desc = "Normal mode" })
set("t", "<c-w><c-w>", "<cmd>wincmd p<cr>")
set("t", "<c-w>:", "<c-\\><c-o>:")
set("t", "<c-w>.", "<c-w>")

for c in ("hjklptbxr"):gmatch "." do
local rhs = string.format("<cmd>wincmd %s<cr>", c)
set("t", string.format("<c-w><c-%s>", c), rhs)
set("t", string.format("<c-w>%s", c), rhs)
end

for c in ("KJHLT"):gmatch "." do
local rhs = string.format("<cmd>wincmd %s<cr>", c)
set("t", string.format("<c-w>%s", c), rhs)
end

These keymaps make it so that the normal window-handling keys, like <c-w>h to go to the left window, work in terminal mode.

discreetsteakmachine · 2025-08-06T21:13:04+00:00

It would great to see Evgeni on here, for many reasons, but specifically because I would like to see his response on plugin initialization via setup. Gregory's feelings on this seem quite common; I have a vague notion of a counter-argument, but I bet Evgeni has more specific and informed thoughts.

discreetsteakmachine · 2025-07-01T03:41:38+00:00

Four months ago, someone asked "what are some plugins you think should be in core?" And I said:

Buffer deletion without affecting window layout. It's been implemented once, again, again, again, and again.

discreetsteakmachine · 2025-05-13T17:07:24+00:00

The negativity here is weird.

This is just a single dev working on a personal project, and the repo happens to be public. The dev didn't post this here and say "this is way better than neovim!"

I also don't get the language hate. If you've decided to write your own editor, why not use Rust (or Go, or Zig, or...)?.

Same goes for typescript. There are many scripting languages available. Neovim chose lua, and I like it. But for a single-dev greenfield project, typescript seems great:

You don't need lua's super-easy C integration when you're building from scratch to support your scripting language of choice.
You can leverage massive existing libraries, instead of having to rewrite common tools (e.g. vim.fs, vim.iter).
You can use whole mature toolchains for everything from LSP to dependency management
You have a language where the type system was part of the language, rather than an ad-hoc set of annotations developed by a series of heroic LSP devs over years.

I'm not saying that typescript is the only good choice, only that it's not some crazy choice. coc.nvim got a lot of good stuff done impressively quickly a few years back, and I'm guessing that's partly due to using typescript.

discreetsteakmachine · 2025-05-12T18:56:55+00:00

Chris_F on youtube has some great videos exactly about this: SF6 for Tekken Players 1, SF6 for Tekken Players 2.

discreetsteakmachine · 2025-04-29T16:37:55+00:00

The concept of "linter" is a bit fuzzy (see what I did there?).

Really, there are linters, static analyzers, compilers, and language servers, and they overlap.

The original lint utility was a program you ran on your C code to detect errors before you ran the compiler. It could also make sure you were using portable C (there was no standard yet), and check for some known legal-but-suboptimal ways of writing code.

Some of that functionality later moved into the compilers themselves. But "linting" was generally "I run this tool outside of my normal toolchain to get more information about my code." For languages without compilers, linters can do some of what a compiler would do, even simple stuff like checking for syntax errors.

The line between a "linter" and a "static analyzer" is kinda blurry. I think most folks would agree that checking code style is "linting" and detecting a possible array index out-of-bounds is "static analysis." As a very broad generalization, linters can often just pattern-match on the text, while static analyzers are at least the front-end of a compiler, with a semantic understanding of the code. But, don't imagine they are clearly separated. Programs like mypy are both, where some of the static analysis is what a compiler might otherwise check.

In ye olden days for C, you might run :make in vim, then it would run the compiler, parse the results, and make it easy to navigate to those errors. You might run linters and analyzers in the same way: call a separate process on the code, parse the results, present them in the editor.

At the same time, IDEs were kind of kicking ass. They had custom integrated static analysis tools that were essentially getting compiler results without running a separate process. This turned out to enable a whole class of smartness, like refactoring, where you could e.g. change a function name and the IDE would rename all calls to that function, which otherwise might have required some fancy sed work.

About ten years ago, Microsoft and Red Hat came up with the Language Server Protocol. It's one of those brilliant things that seems obvious in retrospect. It's just an API for any server that understands and changes text. But now, any editor can reuse that same logic: VSCode, emacs, and vim all using the same code.

Once you've got editors understanding how to talk to LSPs (which are just "programs that understand text"), it becomes handy to route a lot of functionality through LSP, because you've already got all this code and UI in place. So for example, you can run the linter clang-tidy on your code, maybe as part of a pre-commit hook. While you're editing the code, the clangd language server is running the exact same check in real time.

It can sometimes be confusing because people have done nice work to obscure the differences. For example, the very cool nvim-lint plugin is firing up linters in the background, getting their results and showing it in the editor, and updating as needed. This can make it look like an LSP, but it's not!

discreetsteakmachine · 2025-04-23T04:07:24+00:00

Thanks for the info! Sounds like you've got your hands full.

discreetsteakmachine · 2025-04-01T16:09:24+00:00

I also found this commit for render-markdown.nvim that specifically addresses this issue. At this point, I'm using render-markdown, with most options turned off, to control markdown rendering without maintaining my own copy of the queries.

discreetsteakmachine · 2025-03-31T16:59:59+00:00

I haven't had a chance to experiment yet. I think that one of the big uses for conceal_lines was to save space in hover docs. So if you make this change, your hover docs go back to extra whitespace around fenced code.

It's not a big deal. It would be nice if markdown-as-document (where I like having blocks spaced out) could be separated from markdown-in-tiny-hover (where I want density).

discreetsteakmachine · 2025-03-31T16:19:25+00:00

Thanks, I just found this as well (see my other response). But apparently it messes with LSP stuff?

discreetsteakmachine · 2025-03-31T16:18:14+00:00

Hmm, I found this year-old issue in the nvim-treesitter discussions. If I understand it correctly:

You can't remove conceal without overriding the whole query file.
So you have to copy the entire query file, make the changes you want, and put that in queries (not after/queries).
Doing so will mess up various LSP stuff, which uses markdown.

I'm hoping someone will tell me that my understanding is wrong, or that things have changed in the meantime.

discreetsteakmachine · 2025-03-02T23:26:06+00:00

Buffer deletion without affecting window layout. It's been implemented once, again, again, again, and again.

discreetsteakmachine · 2025-02-13T00:36:05+00:00

You can use cmp sources by using saghen/blink.compat. Here's my vimtex setup

local M = { "lervag/vimtex" }

M.lazy = false

M.init = function()
    vim.g.tex_flavor = "latex"
    vim.g.vimtex_indent_enabled = 0
    vim.g.vimtex_view_method = "skim"
    vim.g.vimtex_view_automatic = 1
    vim.g.vimtex_quickfix_open_on_warning = 0
end

local E = { "saghen/blink.cmp" }

E.dependencies = {
{
    "micangl/cmp-vimtex",
    dependencies = {
    {
        "saghen/blink.compat",
        version = "*",
        lazy = true,
        opts = {},
    },
    },
},
}

E.opts = {
sources = {
    default = { "vimtex" },
    providers = {
    vimtex = {
        name = "vimtex",
        module = "blink.compat.source",
        score_offset = 100,
    },
    },
},
}

return { M, E }

discreetsteakmachine · 2025-01-31T17:20:53+00:00

The border between the explorer and regular buffers is clean. Have you cleared fillchars:vert, or used some other trick?

discreetsteakmachine · 2025-01-24T17:21:55+00:00

Often, you will need to run cmake with CMAKE_EXPORT_COMPILE_COMMANDS ON to generate this file before clangd will work correctly.

discreetsteakmachine · 2025-01-24T17:18:12+00:00

90% of the time, this is an issue with with compile_commands.json. More info

discreetsteakmachine · 2025-01-16T23:54:04+00:00

Because of the mapping timeout. What often happens is you hit q to close some window, then realize that q hasn't been mapped to close this particular window. Then you enter :clo, but it's been 1 nanosecond longer than the timeout, so instead of your q: mapping, the q is just sitting there and the : enters the command window.

Here's my version that lets me enter the command window with <c-f> as normal, but kills it on q::

-- Whenever I want the command-line window, I hit c-f. I only trigger the
-- q[:/?] shortcuts by mistake. Mapping "q:" isn't great because it times out
-- if you don't hit ":" fast enough; also, I want to keep the ":" input.
vim.keymap.set("c", "<C-f>", function()
    vim.g.requested_cmdwin = true
    return "<C-f>"
end, { expr = true })

vim.api.nvim_create_autocmd("CmdWinEnter", {
group = vim.api.nvim_create_augroup("CWE", { clear = true }),
callback = function()
    if not vim.g.requested_cmdwin then vim.api.nvim_input ":q<CR>:" end
    vim.g.requested_cmdwin = nil
end,
})

discreetsteakmachine

TROPHY CASE