Shiiieeettt.......
Shiiieeettt.......
Oh, no, I totally get it. Vim, and its modernized fork Neovim, are phenomenal editors, and they still hold up today â I was born post-9/11 and I still use Neovim for all of text editing needs, from development work to editing config files. Itâs just better. That said, I do still like 21st century features like LSP linting and auto complete, drop shadows for floating windows, emoji/nerdfonts, and font ligature support, which Neovim and its frontend Neovide provide.
Neovide is a graphical frontend for Neovim just as gVim is a graphical frontend for Vim. I like to think of it as a terminal emulator that can only run Neovim (although you can still :term from within Neovim to get a shell) and communicates with it via RPC, which allows it to have some fun Neovim-specific extensions like allowing sub-character scrolling, animating the cursor as it jumps around the screen, having window opacity, fullscreen etc. configurable via Vim commands and therefore keybinds, and, of course, all the modern terminal emulation amenities like truecolor, full Unicode support, and ligature support (Iâm sorry I just really like Fira Code).
If you havenât already tried Neovim, and there arenât any Vim-9.0-specific features you depend on, I highly recommend giving it a shot. Itâs 100% backwards compatible with Vim 8 and earlier (after you point it at your existing vim config) and it adds support for Lua scripting, a built-in LSP client that all plugins can access so you donât have to rely on CoC for everything (although you can continue to use CoC if you so desire), and community support in the form of Neovim-only plugins such as the fantastic telescope.nvim. It really does feel like Vim turned into a full fledged IDE, without sacrificing anything that makes it Vim â including its performance (external memory-hogging LSP servers notwithstanding).
Why wait? Itâs available from the project page as an AppImage, and if youâd rather build from source, itâs a Rust app â just clone the repo and cargo install --path . (or `cargo install --git github.com/neovide/neovide if youâd rather skip that step)
As for GUI frontends being a hassle, though, I hate to say I kind of agree with you, at least at first â I quite like Neovide now that Iâve gotten used to it (and bothered to configure it to my liking), but Konsole has more sensible defaults for sure. Iâm also in the habit of :q any time I need to go back to a terminal to compile something and it is incredibly frustrating having my terminal emulator close and my entire editing session disappear on me whenever muscle memory takes over.
implying that any developer actually reads warnings
First thing I do on my projects is enable warnings as errors and increase my warning levels when reasonable.
Unfortunately, the same canât be said on the projects I work on at work. Drives me crazy that we get likes 300+ warnings whenever we run the app and that we canât change it because "theyâre just warnings*.
𤢠Good lord.
Though, I say that as I was basically forced to accept code that was using something marked deprecated because it was unreasonable to refactoring the code in that project. And I know weâre never going to change it unless it stops working. đ At least I marked it as an issue on the review.
#![deny(bad_code)], making sure that nobody notices.
Itâs not that we want to ignore warnings. Itâs just that most warnings take time to fix.
Thereâs only so many hours in a day. And we have to accept technical debt in order to deliver, and then pay it off later.
My job does it well by doing a âspringâ and âsummerâ cleaning where we can turn out 100+ warnings into the single digits. Then busy season happens again and weâre back to 200+.
Itâs not that we want to ignore warnings.
Speak for yourself, I promise you the team I work on actively ignores warnings and doesnât even want to solve them as they pop-up. Being told you canât compare doubles (because of precision loss) and ignoring it is on the developer and isnât even that hard to fix. Most of our warnings come from shit like that.
Like, I get it. Itâs probably not worth it to hunt down every âunused variableâ warning (especially in an API where we used to have a variable for it and we donât use it anymore and we donât want to break the existing API so we just leave it there), but thereâs things that are just trivial to fix when youâre working on code thatâs right next to it.
Drives me crazy that we get likes 300+ warnings whenever we run the app and that we canât change it because "theyâre just warnings*.
Laughs in Xamarin. Only 300?
Well, it was a year ago, is Xamarin now finally changed to the new thing (what was itâs name)?
commenting out the whole block
var foo is declared but not used is such a pain in my asshole when doing this.
Woah woah WOAH WOAH.
So youâre saying software for the Artemis landers arenât being built with the latest TypeScript compiler and running on a canary version of v8?!
&& false
that ended up working better anyway
Not sure if it ended up working better, as it landed with nonzero horizontal velocity. Though I suppose weâll never know how well the original system would have performedâŚ
Click to view the GIF
Final flight checks:
âItâs off, so I turn it on and ⌠WALK AWAY!â
At my workplace, we have a lint rule that reports an error if @nocommit is anywhere in the file, plus a commit hook that blocks all commits with @nocommit anywhere in them. It works well and has saved me a few times.
Works pretty well, except the lint rule and its associated tests have to do something like â@noâ+âcommitâ to avoid triggering it,
In a lot of modern work flows this is incompatible with the development pattern.
For example, at my job we have to roll a test release through CI that we then have to deploy to a test kubernetes cluster. You canât even do that if the build is failing because of linting issues.
@nocommit though⌠The idea is that you use it to mark code that is only temporary local debugging code that should never be committed.