I have spent plenty of time tuning up NeoVim and I really enjoy the text editing experience, but the IDE-like experience is still so, so far from the out-of-the box capabilities of a JetBrains product:
* visual debugging - cli debugging could simply never come close, not matter how much you love using a keyboard over a mouse
* hyper-powerful refactoring, well beyond what any of these language server plugins currently provide: rename file and have all imports corrected, extract class or function to different file and again have all imports corrected, etc.
* Out of the box using the interpreter or compiler from the docker-compose stack - everyone on the team instantly has an identical development environment
* Attaching the visual debugger to your app running in a docker-compose stack
The list goes on and on.
I would love to feel like the "real developer" trope by using only the terminal tools stitched together by endless config and scripts and whatnot, but the hit to productivity is impossible to justify.
> visual debugging - cli debugging could simply never come close, not matter how much you love using a keyboard over a mouse
Have you had a look at nvim-dap? It's awesome and I have a much better debugging experience than in VSCode/JetBrains (as it's completely keyboard driven). Have a look: https://youtu.be/SIYt1dopfTc
I mostly agree with this. If you primarily work on java/kotlin/csharp etc. it is hard to live outside intellij universe.
I am a web developer & my current dev setup involves sway window manager(with vim style bindings), intellij (with IdeaVim), ranger file manager (has vim style bindings), firefox with vim vixen, and of course NeoVim (for editing scripts).
They are all disparate tools, and have their quirks around vim emulation, but overall its a good enough coherent experience that I am quite happy with.
If you want even more vim bindings in your life checkout vim emulation in the web browser. If you browse a lot of link heavy websites it's quite nice, and the shortcuts are good.
There's a specific programming language where JetBrains hasn't gained much against the OSS alternatives, and that's Rust. Mainly because they decided to implement their own language analysis instead of adding support for the most wide-used one (rust-analyzer).
And it still lacks the ability to run remote containers a-la VSCode, where you can leverage all dependencies to the container itself.
Visual debugging in my experience is automatically jumping through the source files inside the editor. Which is nicer than asking the debugger to show 10 lines around the current line. There are some attempts like DDD that I think are not very popular.
Edit: also showing variable values while hovering with the mouse. Also, I forgot that Dr Racket can show you the call stack graphically connecting different source lines
Mainly that everything you could want to see while debugging is available without touching anything, no keystrokes, nothing. It's all in your view by default, with zero configuration or setup.
Showing the actual file and the ability to visually view the call stack and jump back up it is fantastic.
Setting breakpoints with a click or keystroke while viewing in the file is another important aspect.
Having the breakpoints available between runs without adding them to a text file... the list just goes on and on with little quality of life aspects.
Inspired by these cool looking setups, I spent many days trying to setup a modern NeoVim setup, but ultimately failing to produce a really usable experience.
I feel these really tuned out Vim/NeoVim setups are the modern equivalent of really tuned out Linux setups, as in they are something you can spend a lot of time working on and creating some very hacker like cool setups, but ultimately usability is not so great compared to a more full blown and integrated IDE like VSCode.
And I'm a hardcore VIM -user, dont' get me wrong, but making these configurations where you combine like 10-20 different plugins, it's gonna be a whole incoherent experience with many different thought paradigms colliding easily.
I do love the idea of having something working in Vim as perfectly as in VSCode for example, but the actual experience is not there. Ultimately things like C++ code completion and intellisense require a lot of work and code to get right, and NeoVim/Vim attempts are not there yet, for example I had to give up when the only way to figure out what compilation flags a project uses meant configuring it manually.
But they sure are cool for hacker-type setups and look cool for sure.
I have a tuned-out linux (i3) setup and it really is my productivity superpower. I remember how much time I used to spend clicking between open applications, and now I am 2 macros from basically any open window.
I think the important part is building up over years. When I tried to set something like this up all at once when I was young, but difficulty remembering anything made it get in the way. By adding incrementally, I get to understand each piece, and incremental pieces that aren't useful are forgotten.
It certainly changes things as a C++/embedded dev using a custom build system. The Jetbrains ecosystem is not an option.
I really like 99% of everything with VSCode except, 1) it kills my CPU and 2) the terminal experience is terrible. I spend all day in a shell and I want to move around quickly.
You are doing it wrong. You start with a bare vim/neovim editor. Then you learn the basic keystrokes of vim and maybe adjust them a bit for your fingers. Then you add, for example, an autocompletion plugin or tool (there is COC.vim or native-LSP for neovim); then you add a theme; then you add a files explorer, etc...
This is done over the course of a "few years". I understand this is not an instant solution like an IDE is, but Vim takes a lot investment in terms of muscle memory or configuration to finally have a setup that "fits you". Once that happens, that's where Vim/Linux/your-shell will "click". You can't fit a mass-consumer IDE to your style, you have to "fit in". That's not the case for these tools.
Personally, my needs when editing source code are not unique enough to be worth spending a "few years" fiddling with vim when at least 80% of my needs are covered out of the box with an IDE. Not to mention that I only spend a fraction of my development time actually writing and editing source code.
This is why it's optimal to avoid copying some vim ninja's ~/.vimrc because if you do it's usually too much to process all at once, especially how it differs from the default.
You're still "fitting in" to a workflow with Vim, and one that's arguably suboptimal if your setup would benefit from the kind of computer aid to software development that an IDE would provide out of the box. IDE's are not perfect by any means, but they're better than something that got started as a trivial 'visual' mode for ed (a line-based editor) to make it more useful on glass teletypes.
With coc.vim/Native-LSP I hardly feel the need for an "IDE" experience. I had troubles (and almost switched back) with autocompletion and syntax detection before LSP but now I think it's at par with most IDEs.
Congrats on autocompletion and syntax! Now do visual debugging, safe refactoring, type and parameter name hints shown inline, and package management. The first 3 are used on daily basis, the last one maybe once a week.
> Ultimately things like C++ code completion and intellisense require a lot of work and code to get right, and NeoVim/Vim attempts are not there yet, for example I had to give up when the only way to figure out what compilation flags a project uses meant configuring it manually.
It intercepts compilation calls to generate a clang compilation database used by C and C++ LSP implementations. This way you just have to compile the project the normal way, only wrapping the initial call (for example, to `make`) with bear: `bear make`.
Once you have the database, a LSP server like ccls should work out of the box with the project.
For me, VS Code fails to be productive in a myriad of other ways which I cannot enumerate now because I always forget them, and vim is the productive powerhouse I know inside out, where everything makes sense.
So due to this I had the will to investigate and make this work the first time, which was painful back in the day, but now it feels rather out-of-the-box and automatic, especially since nvim 0.5.0 was released.
I still sometimes fire up VS Code when I get frustrated with something, but I always find something else broken there and go back to nvim.
One thing I'm eyeing though is Onivim 2, though it's not ready yet.
The problem with VsCode is that it's so GUI-dependent. It's no good for e.g. working remotely via SSH, or even for a lightweight, productivity-focused, low-distraction workflow. Really, we need a UX more like the old text-mode IDE's of Borland's "Turbo" and Microsoft's "Quick" series, complete with intuitive faux-GUI elements (menus, windows/frames, widgets) that could all be efficiently operated via keyboard navigation as opposed to the mouse. That would be cool-looking in a way that hackers can appreciate, while also being highly productive for day-to-day use.
Big fan and user of LunarVim (esp as a ol' vim fuddy duddy).
I especially love the community aspect of it. Chris' youtubecasts routinely draw 20+ people. Lot of genuine excitement about tools.
I understand neovim (or any other tool) requiring personal setup/configuration is not for everyone. And that is totally okay (see vscode, jetbrain etc). There are several alternatives and something for everyone out there.
I have been using LunarVim for the last couple of months. I will have to give Doom and NvChad a look as well.
One thing I appreciate about lunarvim (in its latest iteration) is that it keeps all its settings sequestered from the neovim settings, launchable as 'lvim.' If I want a simpler editing experience with all the bells and whistles, I can still just use 'nvim'
> Using someone else's configurations kinda defeats the purpose.
No it doesn't. Vim itself is just a set of someone else's configurations. The important thing is that someone else's configurations can eventually become your configurations, but there's absolutely no reason to "start from scratch" unless you're particularly idiosyncratic.
Good artists copy, great artists steal. Bad artists do neither.
Here's a reason to start from scratch: You don't need to dig through the complex, customized setup of someone else and figure it all out. You also don't need to learn unfamiliar software without even knowing what parts are integrated by default and what's customized.
Starting from a clean setup means I know exactly what every part of my configuration does. I can still use a default Vim setup on a server because I started from that and added every change myself step by step as I learned new things about the editor.
> Good artists copy, great artists steal. Bad artists do neither.
The "stealing" part of that phrase, in its original meaning, implies deep understanding of what's being acquired. So, basically an extension of what I was just describing.
Also I'd call Vim more a tool than art.
>Here's a reason to start from scratch: You don't need to dig through the complex, customized setup of someone else and figure it all out. You also don't need to learn unfamiliar software without even knowing what parts are integrated by default and what's customized.
>Starting from a clean setup means I know exactly what every part of my configuration does. I can still use a default Vim setup on a server because I started from that and added every change myself step by step as I learned new things about the editor.
Again, vim itself constitutes a complex, customized setup of someone else that you have to figure out. There's obviously a scale here -- you've just picked a point on that scale and declared it the correct place to be (write your own vim clone, and you'll really know what every part does). And really, if you want your knowledge to be truly portable, you probably shouldn't be modifying vim whatsoever (or perhaps specifically, none of the defaults), because you'll deviate from a default Vim setup on arbitrary servers (change jk to <ESC> and you'll burn the wrong thing into your muscle memory, and perhaps even forget ESC...).
But the value of customizing vim is... to customize it! To adapt it to your workflows and fashion. Treat default/server vim as some unique, pure instance of vim, perhaps even as a separate editor altogether, and treat your own vim.. as your own! And then it doesn't really matter. And regardless, unless your vim package is doing some dramatic changes to vim's fundamental model and design, it's rather trivial to know both -- so trivial I'd consider it an overblown non-concern.
The bigger concern with these packages (and where I think the "start from scratch" mentality generally derives from) is that vim's extension model is rather fragile, and pretty much lacks any useful debugging tool, so when it comes time to debugging why your copy is so slow in certain scenarios, there's really not much you can do except read and reason about the config file(s) thoroughly, which of course is much harder if you didn't write it.
>The "stealing" part of that phrase, in its original meaning, implies deep understanding of what's being acquired.
I've always interpreted it as taking ownership over the concept -- you copy it, and then infuse your own mutations into it to produce something uniquely qualified for the constraints and context you're plugging it into. A deep understanding is a nice to have (to better mutate it more effectively, and correctly), but not necessary for usage of the concept/tool (in the fashion that, for vim, I must understand the "vim mindset", but I don't need to know vim internals to be successful, or to have succesfully stolen it for my own machinations). Understanding is not the key here, it's ownership.
Another way to view it is like christopher alexander's pattern theory -- the base patterns are communally known and shared, and can be plugged in freely to the design. However, to be made beautiful, the pattern must be modified to fit within the constraints of its environments... including the other patterns in use (as well as any unique constraints for the situation, e.g. the home owners requirements, geographic requirements, etc). Those modifications impact the others, which then impact the object under question, in a kind of feedback loop until you reach an equilibrium.
That is, patterns (usage of libraries, packages, frameworks, etc) are not at all a problem. The mistake would be to stop there, and not further adapt it as needed. Or rather, to misunderstand the pattern as the final design. Another example from a programmatic perspective, to take a pattern like OOP FACTORY and construe the design as somehow "pure" and refuse to modify it despite your requirement really being "a bit like a factory, and a bit like a singleton" or what have you.
Have to disagree. Great artists only listen to their inner voice and create something timeless and unique [edit]that touches its recipients deeply[/edit] IM(not so humble [edit] since i can be an arrogant ass[/edit])O.
I think people who are trying to turn Vim into an IDE entirely miss the point on why IDEs, generally, eat productivity, instead of produce productivity.
That said, Telescope.nvim is a powerhouse of awesome. This guy did the right thing by making that the centerpiece of his config.
Enlighten us, I am missing the point I guess.
I'm way more productive with VS Code than Neovim until I fully configure Neovim to have syntax highlighting, LSP integration, file search and so many other plugins.
I don't think IDEs eat productivity, my only gripes with them are resource consumption, which I can fix to a certain degree, and decentralization overhead, when the IDE is language-specific.
VScode sometimes shows me the wrong file for the function definition (very nasty also when it's the 'right' file from the wrong git worktree).
Remote view loose all the opened tabs very often.
Once, I suspected a bug in the logger due to truncated traces but it was VScode which truncated the line (nedit a very old editor didn't have this issue).
Also I had regularly to ask my colleague to stop it's VScode because it was using >30GB of RAM, fortunately this doesn't happen anymore either VScode or its plugin is fixed or she has given up configuring as an IDE I don't know.
I'll be honest. I really like projects like these (Spacemacs is another one that comes to mind), I've been a Vim user for a decade or so. Now I use IntelliJ since I primarily work with Spring, but for other side projects or one-off tasks these setups are really cool.
That being said, if this is intended to be widely adopted/viewed like Spacemacs, the marketing and presentation need a bit of work. Between the 'Chad' signifier and the screenshots sharing a color scheme with a tricked-out desktop and other terminal tabs, it's hard to tell if this is a serious standalone project or, to be frank, someone just showing off.
I thought “Google” put this lie to bed. But anyways, this looks like a slightly self aware project that markets precisely to who it needs to, given the list of “Chad contributors”.
Although at first I wanted to give the benefit of the doubt by thinking maybe it was made by someone named Chad or whatever, the name of their newest release ("MegaChad") points toward it being a reference to Chad Thundercock, a fictional character in a series of 4chan memes popular among members of the "incel" community. Probably not something a "serious" or "professional" project would choose.
It's hard for me to imagine anyone installing this project and using it. Even when picking and installing vim plugins one by one it's hard to remember what they all do and how to use them. I think it's better to see this project as an inspiration, like looking at someone else's dotfiles.
As a counter point: most IDEs come with defaults for many things and offer the ability to customize. Whether it's better to have defaults that you have to override or have no pre-configured tools seems dependent on the user and the tool. I've personally been turned off by how much work it takes to get vim functional on the same level as my other tools and have often wished someone had put together a better starting point and explained how to integrate, extend and customize. I like that if I want to, I can build up from zero to a totally personalized vim setup, but I don't like that most of the time I have to start from zero and build a totally personalized setup.
Interesting point. I think it has two sides to it:
1. I started using Spacemacs which got me into using Emacs(mainly for org mode in the beginning). I'm not capable of building an emacs config from scratch(nor do I care).
2. In Vim though I already have my vim config and have been customizing it. When I try to use these neovim distributions, they're very far off how I configured my vim and I have no idea how to reconcile these two things.
I feel like once you are capable enough to configure it on your own, you won't really be happy with these things, but neovim is also almost like the ever changing javascript ecosystem. There are new completion engines coming out every day, new file trees, etc. etc. I don't feel like changing to the next best lsp engine every 6 months.
Also, spacemacs seems to have a better hook mechanism when it comes to configuring the default configuration.
Yes, I agree with you. The installation of a plugin is the easy part. Properly configuring it to fit _your_ needs and remembering the commands is the hard part. No all-in-one setups can make this effort go away.
I'm inspired to investigate Neovim; I'll do it tomorrow.
I don't need an IDE; I just want a good editor that I can use over an SSH connection. GUIs are groovy when you have one; but sometimes you are constrained to working without one.
neovim is in a honeymoon phase with the recent release of v0.5. Ive been maintaining a search directory site as a hobby https://neovimcraft.com and every couple of days there are a handful of new plugins to add to it. Now is the time to give neovim a shot!
Dude, that looks beautiful. I'm going to dig into getting that set up in WSL first thing Monday. I've been using IntelliJ Projector when I'm developing in Windows lately. It is awesome, but it gets a little bit glitchy.
I just tried the latest VSCode Vim plugin version and it still forgets the cursor column when moving through uneven lines [1]. That's basic functionality, so I wouldn't call the VSCode plugin a viable alternative to a proper Vim-based editor and I doubt it'll ever be since the issue is open from 2017.
Tangentially: What GUI (presumably some skin on Gnome or KDE) are they using in the screenshots? To be clear, I don't mean for NeoVIM, I just mean in general. It looks fucking sweet!
Yes you are correct. A lot of people might think that TUI "requires" some kind of decorations like ncurses offer, had the headline referred to this as a CLI application/program then we could accept it, but this is strictly speaking a TUI.
* visual debugging - cli debugging could simply never come close, not matter how much you love using a keyboard over a mouse
* hyper-powerful refactoring, well beyond what any of these language server plugins currently provide: rename file and have all imports corrected, extract class or function to different file and again have all imports corrected, etc.
* Out of the box using the interpreter or compiler from the docker-compose stack - everyone on the team instantly has an identical development environment
* Attaching the visual debugger to your app running in a docker-compose stack
The list goes on and on.
I would love to feel like the "real developer" trope by using only the terminal tools stitched together by endless config and scripts and whatnot, but the hit to productivity is impossible to justify.
I just want to build software.