sadly no; position of hint is determined by the LSP server.

you could use this plugin (now archived) which was the way many people used hints pre-0.10:

https://github.com/lvimuser/lsp-inlayhints.nvim

haven’t tried it myself, but I’ve heard https://earthly.dev/ is supposed to address the execute locally problem

this article suggests shell allowed, but git also has a built-in feature for aliases itself. I prefer these as it allows you to keep using the git command normally (more consistent when you tend to use history search/auto-suggestions heavily).

running git config --global alias.st status, for example, will allow you to run git st as an alias for typing out the full git status (you can also manually add aliases to your ~/.gitconfig).

explanation here, it wasn’t just for the meme: https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102

not sure about escape sequences just yet, but Kitty gives you insane control over font rendering https://sw.kovidgoyal.net/kitty/conf/#fonts

might switch from alacritty to kitty almost just for this (although I’ve been meaning to for a while). the “immediately get scroll back into an nvim buffer to edit as a command” is pretty sweet

another way to start is to only do small configurations at first. as you code maybe you realize you want a tool that shows git diffs, install a plug-in that does that. over time, you gradually build your config. maybe you want to start using leader for custom key maps. a couple days later maybe you think you want a file picker so you add telescope. this 100% will take longer, but you’ll intimately understand why every line in your config is there.

Short, simple, informative, and helpful. 10/10

looks like dtolnay has made a statement

https://gist.github.com/dtolnay/7f5da4bf057b7c6d0d00c6bed3060b96

zsh has ctrl-r as well; this feature is specifically for beginning-of-match and some find it a bit more ergonomic.

I’m struggling to see how bug reports found using this prediction approach would ever be sent as anything but bugs of the predictive debugger itself.

how would end-users ever see bugs caused by a debugger the devs use? how would users of a third-party library conflate bugs in their own code/the third-party code when you can see which lines are which as you debug?

it’s so useful! I used to have some terrible setup going with branches for different OSes in my dotfiles, and chezmoi really simplified the whole thing

https://www.chezmoi.io/ if you’ve got some complexity with your setup. otherwise, could be overkill.

Great article. there was a even a response a year later https://medium.com/front-end-weekly/how-it-feels-to-learn-javascript-in-2017-a934b801fbe

without more information, the most straightforward way is to disable your plugins one at a time and test if things are working (could go the other direction: start from no plugins, and install them one at a time). do this by commenting/uncommenting lines in your config and rerunning sync/clean/install or whatever with your plugin manager.

ideally youd have some idea about what specifically is breaking for you. since you say completion maybe start with whatever you use for that (cmp, mason setup, coc, deoplete, ycm)?

edit: forgot to say, but if you post your config that could be helpful in case there’s an obvious err somewhere. is it all macros that fail or only some with specific motions?

neat! I’ve been using Colima for a while, so it’s cool to see they have a comparison in their FAQ .

bit leery of it eventually switching to a paid model tho

helpful video, just learning rust so I’m not as familiar with Arc yet. also, really glad to see other creators using manim (the data viz library by 3blue1brown), it makes good looking animations.

I recently learned about diffsitter which uses tree-sitter for meaningful diffs