[HN Gopher] NvChad: An attempt to make Neovim TUI as functional ...
___________________________________________________________________
NvChad: An attempt to make Neovim TUI as functional as an IDE
Author : axiomdata316
Score : 124 points
Date : 2021-08-16 23:35 UTC (2 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| harryvederci wrote:
| Looking good! I'm too invested in my own config, but will
| definitely look for some ideas to steal :)
|
| Random remark: lots of Dutch words contain "jk", so insert-
| remapping that to <ESC> can be quite confusing to some people.
| nicolaslem wrote:
| 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.
| davidkunz wrote:
| 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.
| rjzzleep wrote:
| 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.
| memco wrote:
| 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.
| Shadonototro wrote:
| as functional as an IDE? X doubt
|
| how do you debug your native program?
| Jamustico wrote:
| Using someone else's configurations kinda defeats the purpose.
|
| You should adapt Vim to your needs, not yourself to other
| people's needs.
|
| That being said, these types of projects are nice to get inspired
| to change your Vim config.
| setr wrote:
| > 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.
| alpaca128 wrote:
| 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.
| setr wrote:
| _> 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.
| peakaboo wrote:
| I always start from scratch. The reason is, I know what every
| single line does because I put it there.
| scns wrote:
| 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.
| clearing wrote:
| 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.
| Redoubts wrote:
| 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".
| cartesius13 wrote:
| >the 'Chad' signifier
|
| What do you mean by this?
| hoppyhoppy2 wrote:
| Although at first I wanted to give the benefit of the doubt
| by thinking maybe it was made by someone named Chad or
| something, 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.
|
| https://knowyourmeme.com/memes/virgin-vs-chad
|
| https://knowyourmeme.com/memes/gigachad
| ethelward wrote:
| Yeah, it has left the 4chan community and entered the
| mainstream quite some time ago; e.g. here
| (https://old.reddit.com/r/virginvschad/), and it even has
| derivatives now (https://knowyourmeme.com/memes/swole-doge-
| vs-cheems).
| hkmaxpro wrote:
| Similar projects:
|
| LunarVim https://github.com/lunarvim/lunarvim
|
| Doom Nvim https://github.com/NTBBloodbath/doom-nvim
| scelerat wrote:
| 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'
| gregf wrote:
| I have really been enjoying the simplicity of lunarvim. Just
| the basics, add what I want extra.
| ahurmazda wrote:
| 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.
| rubyn00bie wrote:
| 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!
| mattrighetti wrote:
| Was wondering the same
| soperj wrote:
| I'd also like to know.
| hkmaxpro wrote:
| bspwm
|
| See https://github.com/siduck76/dotfiles and
| https://github.com/NvChad/NvChad/issues/22#issuecomment-8138...
| soperj wrote:
| thank you!
| tomchuk wrote:
| Looks like the author is running BSPWM, their configuration (in
| their dotfiles repo) is available here:
| https://github.com/siduck76/dotfiles/blob/master/thinkpad/bs...
| denton-scratch wrote:
| 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.
| pelagicAustral wrote:
| > An attempt to make Neovim CLI as functional as an IDE
|
| So, like a vegan burger.
| KitDuncan wrote:
| Tell me you never had a vegan burger without telling me you
| never had a vegan burger.
| maxnoe wrote:
| Nitpick:
|
| This is not CLI, right? This is TUI.
|
| Reading the headline I thought this was about using nvim as a
| command line tool as opposed to an interactive editor (e.g. as a
| sed replacement).
|
| CLI (Command Line Interface) means to me means the options /
| arguments / flags of calling a single command.
|
| This is about a specific nvim configuration (or set of plugins)
| to make nvim a powerful TUI (terminal user interface) IDE
| UI_at_80x24 wrote:
| 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.
| dang wrote:
| Ok, we've s/CLI/TUI/'d the title above. Thanks!
| DiabloD3 wrote:
| 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.
| mixedCase wrote:
| 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.
| etangent wrote:
| How do you open a grid with 6 files using keyboard only in
| your IDE? I assume it's possible.
| renox wrote:
| 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.
|
| And no CLion isn't better C++ IDEs sucks..
| DiabloD3 wrote:
| Resource consumption and based around non-ergonomic setups is
| mostly why I've rejected IDEs as along as they've existed.
|
| If I want an IDE, I'll continue doing what I do: tmux, with
| vim in one or more panes, bash in one or more panes.
| lordleft wrote:
| VS Code is kind of the ideal example of an IDE because it's
| not an IDE until you want it to be, in the precise ways you
| want it to be.
| davidkunz wrote:
| If someone is interested in using Neovim as an IDE (without pre-
| configured setups), I recorded a YouTube series:
| https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
| nobleach wrote:
| I clicked the link while thinking, "I wonder if these videos
| are as good as DevOnDuty's videos". Imagine my surprise.
|
| Thanks for making such high-quality content.
| davidkunz wrote:
| Wow thanks so much, that's so kind of you and it really made
| my day!
| 2wrist wrote:
| thanks for this.
| davidkunz wrote:
| I'm glad you like it!
| inDigiNeous wrote:
| 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.
| zozbot234 wrote:
| 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.
| cbushko wrote:
| I too had some fun getting a nice neovim setup going but in the
| end I just wanted to get work done instead.
|
| I settled on https://github.com/LunarVim/LunarVim and then I
| customize my lv-config.lua with the extra pluggins/settings I
| want.
|
| 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.
| verall wrote:
| 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.
| csomar wrote:
| 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.
| zozbot234 wrote:
| 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.
| csomar wrote:
| 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.
| cjaybo wrote:
| 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.
| feanaro wrote:
| > 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.
|
| Not sure if I understand this right, but have you heard of
| https://github.com/rizsotto/Bear?
|
| 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.
| skrtskrt wrote:
| 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.
|
| I just want to build software.
| davidkunz wrote:
| > 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
| scns wrote:
| Whoa holy flying spaghetti monster!
| ilrwbwrkhv wrote:
| What is visual debugging. Isn't it still just looking at
| variables etc?
| linspace wrote:
| 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
| wffurr wrote:
| termdebug is the builtin thing with vim:
| https://www.dannyadam.com/blog/2019/05/debugging-in-vim/
|
| There's a ton of plugins for visual debugging.
| skrtskrt wrote:
| 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.
|
| Again... _with no setup or configuration_
| lf-non wrote:
| 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.
| hemloc_io wrote:
| 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.
|
| https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/
| kenniskrag wrote:
| or qutebrowser https://qutebrowser.org/
|
| qutebrowser is a keyboard-focused browser with a minimal
| GUI. It's based on Python and PyQt5 and free software,
| licensed under the GPL.
|
| It was inspired by other browsers/addons like dwb and
| Vimperator/Pentadactyl.
| lf-non wrote:
| Qute is pretty cool. I have tried qute & vieb in past,
| but I do depend on other firefox extensions too, and
| intertia keeps pulling me back to FF.
| ahnick wrote:
| If you are going to go down the vim as an IDE path, wouldn't you
| just use Onivim? (https://v2.onivim.io/) Or is the licensing the
| issue?
| Jamustico wrote:
| There is no reason to use onivim when there's Vscode and Vim
| plugins for it.
| leppr wrote:
| Last I tried the VScode Vim plugins all had some lag that
| made it annoying to use, while Onivim was responsive.
|
| It's not something inherent to vim emulation though, the
| Jetbrains or Visual Studio plugins were good, so it's
| possible this is now fixed.
| caslon wrote:
| >forced graphical
|
| >ugly graphical at that
|
| >Javascript extensions
|
| >no Lua extensions
|
| That is all around a terrible idea, made even worse by the fact
| that it's proprietary software.
___________________________________________________________________
(page generated 2021-08-19 23:01 UTC)