[HN Gopher] LazyVim
___________________________________________________________________
LazyVim
Author : tambourine_man
Score : 553 points
Date : 2023-07-17 01:52 UTC (21 hours ago)
(HTM) web link (www.lazyvim.org)
(TXT) w3m dump (www.lazyvim.org)
| bilekas wrote:
| This is cool and convenient but a bit bloated for my tastes..
| It's taking forever to install, hangs and the usual Mason
| issues..
|
| In my opinion there is no "One size sits all" configuration of
| vim that could be packaged up for mass adoption.
| loveparade wrote:
| A bit off-topic, but I wonder how much Copilot/GPT cuts into the
| market share of editors like vim and emacs. I used emacs for the
| past few years, but I recently switched (back) to vscode because
| the Copilot integration is really good. There are a lot GPT
| integraton packages for other editors, but they don't come close
| to the deeper integration that vscode has. And of course, vscode
| will probably get priority treatment from Microsoft.
|
| At this point, this is (somewhat unfortunately, I really like vim
| and emacs) a big selling point for vscode.
| whateveracct wrote:
| I've been using a text editor and a repl forever now and don't
| see myself adding to the workflow. I don't optimize things that
| are so far off the critical path of my productivity.
| raydiatian wrote:
| Aren't you giving your code away to Microsoft if you use
| Copilot?
| whompyjaw wrote:
| Ya pretty sure using copilot only applies to personal
| projects. To my knowledge, you can't use LLM's while coding
| at work due to CCI.
|
| However, there are plugins to use LLM's while coding with
| Neovim and Emacs, so, you can still use these editors for
| that if you want.
| [deleted]
| fernandotakai wrote:
| > Ya pretty sure using copilot only applies to personal
| projects. To my knowledge, you can't use LLM's while coding
| at work due to CCI.
|
| copilot for business exists
| https://docs.github.com/en/enterprise-
| cloud@latest/copilot/o...
| jemmyw wrote:
| You can now configure it to not use your code for learning
| VectorLock wrote:
| But it has to use your code for inferencing, doesn't it? So
| it is sending it to someone.
|
| I see this being a blocker at a lot of places. I know in my
| workplace the infosec people are apoplectic about it and we
| supposedly have a 'partnership' with OpenAI.
| willdr wrote:
| Do those places use GitHub? Anything on GitHub has been
| given to Microsoft.
| xyzzy_plugh wrote:
| You're not wrong, and I realize there is nuance here, but
| if you're using GitHub you are already sending your code
| to Microsoft.
| lispisok wrote:
| The master plan is to have everybody writing Microsoft
| Typescript in Microsoft Visual Studio Code using Github
| (Microsoft) Copilot
| valid4life wrote:
| I love using the official copilot plugin with neovim. It has
| easy rebindable keys and a pretty nice set of features.
|
| As you said though.. It won't compete with 1st party love given
| to VSC. For example, I have no idea if "neighboring tabs" is a
| feature in neovim.
| yoyohello13 wrote:
| I use copilot, but I it's not a super game changer in my
| opinion. I can live without it. I often turn it off when I'm
| using SQL or something when it hinders more than helps. It's
| honestly best when I'm writing JavaScript because I'm not very
| good with the language. But when I'm writing a language like
| python which I've been using for a long time it kind of gets in
| the way.
| w0m wrote:
| copilot works wonderfully inside NeoVim; I use it daily. You
| are right that some of the more advanced integrations (Chat,
| direct analysis/explanation) aren't ported though. I use
| shellgpt in tmux for a (not as good but almost) experience.
| adamkf wrote:
| I gave it a try the other day using copilot.lua, and it made
| the whole editor unusably slow. It somehow caused syntax
| highlighting to "lag" for tens of seconds every time I made
| any sort of edit.
|
| Maybe I need to be using the official plugin, and maybe I
| need to disable LSP based syntax highlighting, but that makes
| me wonder what it's doing.
| w0m wrote:
| I have pyright/shell running happily with lsbconfig and
| haven't noticed any lag. There's a way to profile plugins
| to see what's killing you I think.
| maleldil wrote:
| What languages and LSPs are you using? I've never
| experienced this with Python (pyright), Go (gopls) or Rust
| (rust-analyzer). I'm using tree-sitter for syntax
| highlighting. The only special thing is that I'm using
| lazy.nvim (the plugin manager) to load copilot.lua on the
| InsertEnter event.
| adamkf wrote:
| I am using typescript with typescript-language-server.
| I'll give the lazy stuff a try, but I am not sure why
| this would make the editor more responsive outside of the
| initial load.
| pooriar wrote:
| Does it really work wonderfully for you? I am often times
| shocked by how it just can't guess the most obvious
| completions. Then I jump into VSCode to sanity check, and it
| works fine there.
|
| Talking about tpope's official neovim plugin
| buf wrote:
| Just tagging in for comment OP.
|
| Copilot really does work wonderfully for me, as expected
| with any AI code completion. I run copilot and coc.vim
| simultaneously, to be noted. So when I just want to
| autocomplete a word, it'll be coc.vim, but when I want a
| whole line/method/etc built I'll let copilot be my copilot.
| omoikane wrote:
| I never got into these copilot things because I wanted my text
| editor to be predictable rather than magical. As such, I am
| still using regular VIM.
| column wrote:
| It's not like vscode sneaks in the copilot code. You always
| have to validate. Is it magical when you use regular code
| completion?
| omoikane wrote:
| Regular autocompletion also feels magical and
| unpredictable.
|
| This is because I need a tighter visual feedback loop to
| confirm that the IDE has chosen the right identifiers and
| inserted extra parentheses and such, and so I couldn't get
| a few keystrokes ahead of what I see. It's nice for
| debugging where I only need to replace a few things in a
| few lines, and I suppose it might be nice if I am trying a
| new language and wasn't typing very fast anyways. It's not
| something I use regularly for development.
| nextlevelwizard wrote:
| Copilot has native NeoVim support
|
| I don't know what kind of GPT you want in your editor. A
| colleague of mine attached the llama model to his vim, but that
| doesn't seem too useful to me.
| pooriar wrote:
| It's the only thing that tempts me away from Vim. Vim does have
| an official copilot plugin but it seems gimped compared to
| VSCode. I wonder if that's intentional.
| alwillis wrote:
| > A bit off-topic, but I wonder how much Copilot/GPT cuts into
| the market share of editors like vim and emacs.
|
| So you think that the two editors that have been around for
| nearly 100 years combined and are extremely customizable and
| have survived every coding fad, language and technology trend,
| is in danger from AI features?
|
| Short answer: no.
|
| Both Emacs and Neovim has first class support/implementations
| of Co-Pilot and GPT plugins.
|
| For example ChatGPT.nvim [1].
|
| [1]: https://github.com/jackMort/ChatGPT.nvim
| chris_armstrong wrote:
| i love lazyvim, as someone who is productive with vim movements
| and keyboard macros, but has zero interest in learning every inch
| of the vim plugin ecosystem and writing the corresponding lua to
| configure it.
|
| In fact, I've found it easier to learn the ecosystem of what is
| going on and feel more comfortable customising it, now that I
| have a solid base of customisation to build upon.
|
| I just wish the documentation included more commentary on what
| each plugin does and why it is available - having to click
| through on each one is a bit annoying.
| javitury wrote:
| There is also mason for installing LSP servers, DAP adapters,
| formatters and linters.
|
| https://github.com/williamboman/mason.nvim
| dicytea wrote:
| I'm still using this, but now I'm contemplating on switching to
| my system's package manager instead. It was pretty useful when
| I was on Windows, but now I'm just feeling less and less of its
| benefits. The scope is also intentionally limited, so you need
| to eventually install some tools manually anyways (e.g. ccls).
| But I can see the benefits if you work on both Windows and
| Linux.
| stevebmark wrote:
| What was the name of the original Vim magic-auto-default setup
| project? I wish I could remember it! There used to be so many Vim
| questions on Stackoverflow from people who installed Vim ________
| (?) and had no idea what it did. The advice was always: "Stop
| using that, and learn Vim." This project smells like that.
|
| There are two types of Vim users:
|
| 1. "Stop trying to make Vim and IDE with all your fancy plugins,
| learn Vim!"
|
| 2. "Vim is so much more than a text editor, of course you can use
| it as an IDE."
|
| These two Vim users are usually the same person.
|
| You have to learn Vim's terrible, verbose, antiquated commands in
| depth in order to justify using Vim. If you don't use q: (q
| colon) and q/ (q forward slash) in Vim, for example, you probably
| don't know Vim well enough to justify the efficiency loss you
| have compared to you using a modern IDE with multiple cursors.
|
| Aside: It blows my mind that there are still plugin managers
| being invented for Vim. That's a bad sign for an editor. This
| shouldn't exist in userland.
| TonyStr wrote:
| I would argue vim's cryptic commands like q/, gg, ciw, etc. are
| anything but verbose. Especially compared to gui editors where
| similar actions are achieved by clicking through menus.
|
| Your example of commands is a bit odd; I've used many editors
| without knowing how to access search/command history without
| that being a detriment to my usability of the editor. If your
| argument is that one needs a high degree of understanding of
| vim for it to be useful (more so than IDEs), then I have to
| disagree. Vim motions alone skyrocket productivity. Anything
| you can do with multiple cursors, can be done with
| substitution, repeat motions, block select, macros, etc. Then
| there are always plugins, should the built in features not
| satisfy.
| nextlevelwizard wrote:
| >You have to learn Vim's terrible, verbose, antiquated commands
| in depth in order to justify using Vim. If you don't use q: (q
| colon) and q/ (q forward slash) in Vim, for example, you
| probably don't know Vim well enough to justify the efficiency
| loss you have compared to you using a modern IDE with multiple
| cursors.
|
| How is scrolling through your past commands and searches
| anything like having multiple cursors?
|
| If I want to use the same command I just type `:` followed by
| the start of the command and press up and it automatically
| fills in the rest of that command and I can even go back and
| forward in that history. Same with searching.
|
| Also how is any of this "efficiency loss". Whenever someone
| talks about efficiency loss or performance in their IDE it is
| usually some very niche thing that they have gotten good at,
| but often the house of cards crumbles when they try to do
| anything else.
| stevebmark wrote:
| Those two shortcuts are how you edit searches and commands in
| Vim mode.
| alwillis wrote:
| > Aside: It blows my mind that there are still plugin managers
| being invented for Vim. That's a bad sign for an editor. This
| shouldn't exist in userland.
|
| I'm not sure what you're talking about... the fact that plugin
| managers continue to be developed for Vim and Neovim tells us
| there are new use cases today that didn't exist 20 years ago.
| Neovim isn't your undergraduate Vi/Vim from back in the day.
|
| What's amazing is the plugin managers continue to improve,
| especially for Neovim.
|
| Lazy.vim [1] is amazingly good.
|
| Refactoring eliminated 30% of Vim's legacy code and the choice
| of Lua for the scripting language has unleashed a stunning
| amount of creativity in Neovim/Vim community.
|
| [1]: https://github.com/folke/lazy.nvim
| t43562 wrote:
| I think it's hard to beat Pycharm when one is writing something
| new in python - even the community edition - but I always
| gravitate back to vim/nvim without thinking about it because my
| IDE is really the commandline.
|
| It's about how big the project is and how much I know it. The
| smaller and more known it is, the more I cannot be bothered with
| the extreme inconvenience of having to steer a huge oil-tanker-
| like IDE to do what I want and accept that it doesn't exist on
| this machine or that were I want to do work remotely. It has all
| the searching and finding and probably SFTP stuff that could do
| things but that means I cannot use all my CLI muscle memory and
| ways which are far more generally useful.
|
| In a project I'm not familiar with, Pycharm helps me autodiscover
| what's going on better and not waste as much time. It's also good
| for refactoring things with more certainty about whether I've
| broken it or not. A good set of unit tests are much better than
| an IDE but since that's not often available I'll take any
| advantage I can get.
|
| I find that having flake8 setup so that it runs in vim is an
| enormous help on its own even though it doesn't begin to match
| what an IDE can do. For 2-4 screen scripts it gives a good
| balance of preventing annoyingly silly mistakes versus
| convenience.
| S1M0N38379 wrote:
| I have been using LazyVim as my daily text editor/IDE on my 2014
| Macbook Air for about 6 months. It is the only IDE that runs
| smoothly and provides good Language Server Protocol (LSP) and
| plugin support.
|
| After delving into the configuration rabbit hole, I started
| prioritizing 'getting things done,' and LazyVim proved to be a
| good choice.
|
| 1. It is easier to disable a plugin than to configure it.
|
| 2. It's Vim, so it is fully customizable. For instance, I use it
| to write LaTeX and compile it upon saving using my preferred
| LaTeX compiler, thanks to LSP.
|
| 3. It's Vim, so my mental muscle are grateful.
|
| The only aspect I feel could be improved is the AI-assisted
| experience. The available plugins cannot compare to Copilot X
| Chat on VSCode, so most of the time, I find myself switching
| between the editor and a browser window with a ChatGPT-like chat
| to ask for boilerplate code. However, I'm confident that the
| Neovim community will rise to the challenge
| (zbirenbaum/copilot.lua and jackMort/ChatGPT.nvim are good
| starting points).
| kristianpaul wrote:
| I'm getting to learn use vim better. I liked spf13 until plugins
| started to give issues, very annoying.
|
| I compiled vim 8 recently, looks even better that my distro
| package by default. Its a new fresh start to me.
| birds_are_drone wrote:
| For those s who want a nvim experience without the hassle of a
| config file as long as my arm : I warmly recommend you to try
| helix. Exploratory terminal based interface (much like zellij if
| you use that) , terminal based, fast as fk, minimal config
| required(just having the LSP in your path is enough) and the
| documentation is mostly complete.
|
| Try it out
| jetpackjoe wrote:
| I really appreciate not only stating that the dependencies were,
| but also the a brief description of why they were necessary or
| helpful.
| [deleted]
| djha-skin wrote:
| These don't usually take off because people who use vim and emacs
| are people who insist on customizability and aren't into all the
| bloat that comes with IDEs. People who want IDEs aren't
| interested in an editor that lives in the terminal. There is a
| very limited market for something like this.
| pxc wrote:
| > People who want IDEs aren't interested in an editor that
| lives in the terminal.
|
| Emacs is a graphical application. gVim is a graphical
| application. Neovim supports embedding in various GUI clients,
| including Neovide and VS Code.
| vidyesh wrote:
| I disagree, I think these are helping people see neovim as a an
| alternative, drop-in replacement for VSCode or other editors
| with the added benefit of being vim.
|
| I also think once people start using these regularly, they tend
| to learn more about neovim and vim universe how it can be
| customised to their needs, this acts as a starting point for
| many without the need to spend days/weeks setting it up to what
| they are used to.
|
| And for most it becomes easy to just rely on the maintainers to
| add new additions via plugins and/or update as and when
| required without the need to update/break/debug on their own.
| pprotas wrote:
| Strange generalization. There are many people who want exactly
| something like this. LazyVim has a very active community on
| GitHub and YouTube and many people use it daily. The same goes
| for other distros like LunarVim.
|
| I have been using nvim for 3 years as an in-terminal IDE while
| maintaining my own config and have switched to LazyVim.
| w0m wrote:
| The draw of these imo is as a framework for building my own
| config. Something as relatively niche as the lua config for
| NeoVim is hard enough to find good code examples that nicely
| flushed out configs like this are a goldmine.
| qudat wrote:
| Totally agree, which is why I wanted to build a config
| directory to find good examples of code
| http://neovimcraft.com/c/index.html
| 4by4by4 wrote:
| Using LazyVim got me over the hump to switch to neovim from
| vscode. My previous attempts failed when it took too long to
| get an IDE-compatible setup. I suppose I am the type of person
| that wants and IDE/editor that lives in the terminal!
| NathanielBaking wrote:
| I did the same thing and it was also a great learning aid.
| Now I run my own my own set of plugins but this got me past
| that initial learning curve. I think it says something that
| it finally happened to me after 4 decades of software
| development.
| pkulak wrote:
| I use IntelliJ Idea for work, and the most bloated NeoVim setup
| in the world doesn't even compare. I type "vim ." in a project
| directory and NeoVim, with a billion plugins, has come up by
| the time my finger is a cm off the enter key.
| abarwick wrote:
| There's plenty of people inbetween the extremes. I don't want
| the bloat but I'm also busy (tired) and don't want to spend a
| weekend getting my dev env setup. These pre-made environments
| are great to dip my toes in the water; I get the speed of vim
| with some of the "batteries included" ergonomics of actual
| IDEs.
| dkh wrote:
| There's a lot of people who want to make the jump but haven't
| yet because the configuration seems complicated/unapproachable
| and they'll lose too much productivity trying to figure it out
| or using it with a blank slate. These are great in such cases,
| I think.
| linhns wrote:
| Totally agree. I'm not into NeoVim at all, normal Vim is faster
| and still very powerful for me.
| Timpy wrote:
| I really wish I could just put a native neovim or vim text editor
| inside VSCode and call it a day. I absolutely love the lightning
| fast experience of editing with vim. When I know exactly what I
| want to do, I feel like I just ripped a line of spice and piloted
| a trade vehicle across Frank Herbert's universe.
|
| But a lot of my job is exploring a code base and trying to figure
| out what the hell is going on, and I have to concede that setting
| up vim to do this kind of broad exploration isn't that great.
| Being able to click around at random and juggle tabs in the UI
| instead of storing buffers in my head is nice. I know vim can
| solve all of this, but I just found myself gravitating towards
| VSCode when I'm crunched for time and can't be bothered with vim.
| pseufaux wrote:
| Have you tried the vscode-neovim extension? That's basically
| what it does.
|
| https://github.com/vscode-neovim/vscode-neovim
| Timpy wrote:
| It sounds like that's exactly what I was looking for. Thank
| you!
| mnrode wrote:
| Have you looked at the "VSCode Neovim" extension? It uses a
| native neovim editor in the background (instead of just
| emulating VIM like VSCodeVim), so the editing experience is the
| same as native vim.
| joshka wrote:
| I dallied in this briefly, but couldn't get a good rust setup
| exactly how I liked, so went back to vscode pretty quick. Perhaps
| there's a good lazy+rust guide somewhere? I ran into the usual
| sorts of problems of some random plugin with instructions for how
| to install it in some other plugin manager for nvim, which means
| you have to learn two plugin managers and both their underlying
| concepts in order to port the config.
| gsinclair wrote:
| No, you never have to learn two plugin managers. Never.
| lawn wrote:
| You only need one plugin manager.
|
| Most plugins only contain examples for some of them, but in the
| general case you can just add the GitHub url to the manager and
| you're good to go.
| [deleted]
| weka wrote:
| I use AstroVim in the same vein. Been using vim for a while but
| the hardest part of me actually making me want to keep using it
| is the formatting. Somehow, someway, the linting and formatting
| (whether its eslint vs prettier vs whatever else) always makes it
| a battle. VS Code does this to perfection. With vim, I have to
| battle and make small concessions on how formatting behaves.
| ryanslade wrote:
| IMHO the best thing about vim are movements and modal editing.
| Once you have the muscle memory for that it's really hard to go
| back. However, almost every major editor / IDE has a vim mode
| these days which for me is the best of both worlds. I don't need
| to mess with configurations for days but I still get (almost) all
| the power of the vim editing model.
| elliot07 wrote:
| Off topic, but does anyone know what the vim theme is in the
| screenshot?
| knubie wrote:
| Looks like tokyo night.
|
| https://github.com/folke/tokyonight.nvim
| alwillis wrote:
| Same author as Lazy, so that makes sense. I also use Tokyo
| Night, so I recognize it.
| [deleted]
| ctenb wrote:
| What ide functionality is provided by lazy vim?
| kzrdude wrote:
| LSP integration gives access to completion, linter or compiler
| warnings and errors, formatting. It adds file browser views.
| And it preconfigures a nice way to resume an editing session
| (preserve open files).
| localghost3000 wrote:
| After curating my own vim customizations for years I switched to
| this and have been happily using it for about 6 months now. It
| was very easy to change any settings I didn't like and/or port
| over stuff I couldn't live without. It opens lighting fast too
| despite how fully featured it is. Highly recommend.
| hiAndrewQuinn wrote:
| I switched to LazyVim from nvChad because it was the only Neovim
| flavor that had actual documentation for how to get Copilot set
| up.
| pizza wrote:
| Best protip I heard about (n)vim customization: use git branches
| when you want to switch between different configurations. Eg
| something like:
|
| - vanilla/default
|
| - minimal
|
| - fancy
|
| depending on what you want to deal with. If I go months between
| using all these plugins I forget what they do and what changed
| and it's just noisy distractions that invariably lead me to open
| my init.lua file rather than what I actually had intended to work
| on
| pynappo wrote:
| you can also use $NVIM_APPNAME if you want a more "full" switch
| between configurations. especially helpful for trying/switching
| between distributions (i use it for switching between my own
| config and lazyvim). basically, it modifies the paths where
| neovim looks for config and data files on startup:
|
| config path: $XDG_CONFIG_HOME/nvim/ ->
| $XDG_CONFIG_HOME/$NVIM_APPNAME/
|
| data path on Windows: $LOCALAPPDATA/nvim-data/ ->
| $LOCALAPPDATA/{$NVIM_APPNAME}-data/
|
| https://neovim.io/doc/user/starting.html#%24NVIM_APPNAME
| devnullbrain wrote:
| Why not stay in the editor and use `:source`?
| qbasic_forever wrote:
| I had luck using gnu stow to switch configs easily too.
| pizza wrote:
| Hadn't heard of this. Thanks. I guess there are probably
| plenty of little GNU utilities out there that just haven't
| hit their deserved mindshare yet
| tjferrara14 wrote:
| https://kkovacs.eu/cool-but-obscure-unix-tools/
| cerved wrote:
| what do you mean "use Git branches"?
| worksonmine wrote:
| Since the configuration is done in (dot)files you can version
| and track them with git. If you want several setups you could
| have them in branches and just 'git checkout X' in your .vim
| or .config/nvim directory to change it and it would affect
| settings and plugins (as they're also just files).
|
| I don't need it but I can see the use. I do have a dotfiles
| repository however it's very common in Linux and Mac, don't
| know about Windows. If I setup a new machine or spin up a VM
| I just have to clone that repository to have all my
| configurations for everything (even addons for Firefox and
| Chrome).
|
| This article[1] is a good starting point if you want to try
| it out.
|
| [1] https://www.atlassian.com/git/tutorials/dotfiles
| moistoreos wrote:
| The mnemonic bindings I get from my config are an integral part
| of my workflow and super easy to add/update/change. But the
| primary reason for using Neovim is I don't have to leave the
| terminal. I switched entirely to the CLI a few years ago and I am
| more productive here.
|
| If I wanted an IDE, I'd switch to the terminal version of Emacs.
| dumpsterdiver wrote:
| I feel like I _should_ be the kind of person who prefers eMacs
| over vi(m), because I 've always been a hotkey maniac. I'm
| actually not though at all, and I much prefer the simplicity of
| vim. I already have way too many hotkeys lingering in my brain,
| especially since I played the game Age of Empires II.
|
| I don't play many games these days, and I certainly don't use
| their hotkeys (I play exclusively on consoles these days,
| lazily).
|
| None of this likely has anything to do with the article. I'm
| sorry to report that I did not read it. I come here for the
| commentary, not the article. I am guilty of that.
| KRAKRISMOTT wrote:
| Most of the newer Vim distribution are all offshoots of
| Spacemacs/Spacevim. You can see it clearly in the choices of
| mnemonic key bindings.
| wudangmonk wrote:
| I've had several people recommend me their IDEs or some new
| text editor from time to time by telling me that the editor
| supports Emacs style keybindings assuming that is the main
| difference between editors. I've never used emac's native
| keybindings, nor do I use vim's since I don't use qwerty.
|
| While my custom keybindings are something I would not want to
| give up they can be replicated in any other editor that
| provides this basic functionality. What cannot be replicated is
| the whole reason why I prefer emacs, I like being able to use
| it like a file explorer, like a terminal, I like being able to
| open or edit pretty much any type of file I ever use. When you
| combine the ability to work/view most of the files with
| consistent keybindings, that is the killer feature that emacs
| provides, its never been about the keybindings.
|
| I'm curious though, I never really got into vim as soon I
| realized that it only makes sense if your layout is qwerty. Is
| vim just its keybindings? or is it like emacs in that the
| keybindings are not the main reason people use it?.
| alpaca128 wrote:
| > people recommend me their IDEs or some new text editor from
| time to time by telling me that the editor supports Emacs
| style keybindings assuming that is the main difference
| between editors
|
| I get that too but with Vim. People think Vim is just about
| the controls because all they know about Vim is the :q joke.
| No, that IDE's Vim plugin doesn't cut it, because
| unfortunately it comes with an IDE and its distracting
| overloaded UI, weird tab switching behaviour, absolutely
| infuriating popups and other annoyances.
|
| Vim being just a really flexible and fast editor with a
| mostly empty status line as the entire user interface is a
| feature.
| samrjack wrote:
| I used vim for a long time and now use Emacs doom/evil over
| top for most of my daily work. I'd say the part of the key
| bindings that I find hard to live without is the modal
| editing side of it which helps me really think about the
| macros I use when moving around or editing.
|
| The other thing I really love is the integration with the old
| ed editor so you can quickly do several really flexible edits
| with regex and get what you want. I'm sure emac's built in
| functionality can do some/most of the stuff but it's no where
| near as concise and other editors have no such built in
| functionality to speak of.
| dumpsterdiver wrote:
| Oh goodness, I would never use vim as an IDE, or any purely
| text based editor. I pay out-of-pocket to use proprietary
| IDE's, and I consider it a cost of doing business. Vim to me,
| is simply a way to make minor changes to configuration files
| mostly. I would never dream of coding in vim.
|
| Edit: TLDR - vim is _sometimes_ better than sed for making
| changes to files, but in my mind that 's about it.
| ghosty141 wrote:
| The neat thing about emacs is that you can make it behave like
| vim but with easier/more customizability.
| mcpackieh wrote:
| Stick with what you like, if it works for you then that's
| what's most important. Personally I switched from neovim to
| emacs, but I don't care for the 'emacs style' of keybindings.
| Instead I use evil-mode and set my own bindings with hydra for
| everything else. Tbh main reason I switched was elisp envy;
| there's not really a whole lot that you can do with one but not
| the other.
| nithinbekal wrote:
| A much simpler alternative to this is kickstart.nvim. My approach
| to customizing my neovim config was to use kickstart as a
| reference, and slowly add things that I needed.
|
| https://github.com/nvim-lua/kickstart.nvim
| tjdevries wrote:
| glad you are enjoying it :)
| godelski wrote:
| I know it sounds like a pain, but I really am a big advocate for
| learning how to customize vim (or emacs) yourself. These are
| great places to start, but the power of terminal editors is that
| they cater to you at a very personal level. The problem with
| "IDEs" isn't that they are bulky, it is that they railroad you
| into doing something a very specific way. Terminal emulators put
| the custom configuration in your face because that's the point.
| You should edit color schemes if you don't like them. Select only
| tools you actually want or will use. Learn native commands
| (because so many plugins do things that are native and even
| taught in vimtutor). Turn it into a game if you want. Whatever,
| it is personalized __for you__, and that's the point. Start here,
| but make sure to move on and make the editor __yours__
| pkulak wrote:
| I like a good starting point. All these things let you tweak
| them to your heart's content. AstroVim plus 20 lines of
| customization is my ideal Rust IDE. Really takes away my
| motivation to burn a couple weekends doing it all myself.
| jatins wrote:
| > but I really am a big advocate for learning how to customize
| vim (or emacs) yourself
|
| I got caught into this and, for me, it was a waste of a month.
| I found that configuring your editor serves as a great way to
| procrastinate doing "real work". There's always that one last
| thing you wanna get right
| godelski wrote:
| Oh, I can definitely agree that it is easy to get caught in
| it. I think we've all done it. I'm not sure if it is wasteful
| or not because there are at least worse ways to
| procrastinate. I'm pretty sure if you weren't procrastinating
| configuring your dotfiles you'd be procrastinating by doing
| something else haha
| qbasic_forever wrote:
| I use lazyvim and you're still going to be configuring a _lot_
| of stuff by hand with it. It's really just a framework for
| configuring neovim with an opinionated file structure. Compared
| to other neovim plugin 'distributions' this one is pretty hands
| off as far as out of the box config--it really just has the
| bare minimum to get popular language LSPs up, and a lot of
| missing LSP features that neovim hasn't implemented yet (like
| autocompletions). For everything else, like defining your own
| little shortcuts and commands, it's wide open and up to you to
| figure out just like regular neovim.
|
| Basically this distro is useful if you want to play with neovim
| plugins but don't want to spend days surveying the landscape to
| see what are the most popular and usable plugins... lazyvim is
| doing that for you. As far as using neovim goes this doesn't do
| much and it's still up to you to do the work to learn and
| configure it.
| strogonoff wrote:
| Probably what I like about my NeoVim setup (an organic, home-
| grown completely from scratch mess of .vim and .lua files)
| the most is universal containerized language server for any
| project.
|
| It gets me go to definition, peek definition, etc. in
| TypeScript, Python and probably anything else LSP-compatible
| without polluting my main machine with any of those
| development environments and only requires Docker.
|
| The editor detects a special INI file in project directory
| and launches a Docker container that runs a language server.
| The INI file can specify a common Dockerfile (works for zero-
| install Yarn where it mounts repository root as read-only
| volume and just works(tm)) or a project-specific Dockerfile
| that does some system setup (useful in case of complex
| Python/Django backends, for example).
|
| I'd be curious to try a configuration like LazyVim if it
| supported something like that out of the box, but last time I
| checked most of these were written in mind with LSP running
| directly on your host.
| mathisfun123 wrote:
| > Turn it into a game if you want.
|
| some of us don't have time to play games? i mean definitely
| used to when i was a kid but now i have lots of deadlines and
| little enough time _to play games with my human friends_ let
| alone with my editor.
|
| > make the editor __yours__
|
| a good tool is useful _immediately_ and has the _potential_ to
| be personalized. i mean imagine how little carpentry would ever
| get done if every hammer, drill, and tablesaw _needed_ to be
| personalized.
|
| the reality is that software tools, like software itself, are
| much more complex than carpentry tools (and carpentry), and
| thus maybe _can 't_ be immediately useful in the same way. but
| that's why ux engineering exists for software tools and not for
| hammers. so i'm happy to leave it to the professionals to help
| me become productive as fast as possible (even if not
| immediately) when using my tools.
| godelski wrote:
| > some of us don't have time to play games?
|
| So don't. See the next part you quoted from me. But also,
| IIRC you're in grad school (too), right? Little time is kinda
| part of the deal. It sucks, I know.
|
| But like others are saying, vim is useful right away. But I
| do disagree immensely with your premise. A good tool has no
| requirements to be immediately useful. There's lots of
| carpentry tools that require training to use, let alone use
| well. You can be good at vim or emacs in 30 minutes after
| using vim tutor, but like all specialty tools, it takes time.
| And that time really comes from using it, not from sitting
| down and reading about it. The same way you learn how to use
| a jigsaw, experience. Every carpenter has their custom set of
| jigs and way of organizing. Same is true for any engineer, or
| realistically any profession. Whatever it is that makes
| __you__ most effective, that's what you should do. Maybe that
| isn't vim at all and that's okay. I never even implied you
| needed vim, I'm just saying you should customize your
| environment. And like I implied, start with something someone
| else has put together, but learn to customize it to you.
| That'll take time and that's okay. There's no difference in
| using one of these than just using someone else's dotfiles.
| But making your own dotfiles is going to make you better in
| the long run because your tools will match you.
| lawn wrote:
| > a good tool is useful immediately and has the potential to
| be personalized.
|
| Vim is useful immediately! I use it without customization all
| the time when I ssh into a new system for instance.
| mathisfun123 wrote:
| > I use it without customization
|
| i do too - all i know is :bn, :bp, b, e, ciw, v and shift+v
| (and :wq) and it's all i've known for over 10 years. i use
| the arrow keys on the keyboard too! fingers crossed it'll
| last me the rest of my career too.
|
| but i mostly use clion/pycharm and there the defaults are
| reasonable and the ux of shift+shift is absolutely
| unbeatable.
| godelski wrote:
| I'll give you an easy useful command: smart completion.
| In insert mode use <C-x> then <C-p> for a word or <C-l>
| for a line, or <C-f> for a directory path. You can repeat
| them because it is contextual. See `:h ins-completion`.
|
| Also, get away from the arrow keys. And use <C-[> for
| escape. But it is also okay if you don't like vim. If you
| want to learn, there's a community out there and we're
| happy to help, but if you don't then that's okay too. You
| just do you and that's all cool :)
| aulin wrote:
| > i mean imagine how little carpentry would ever get done if
| every hammer, drill, and tablesaw needed to be personalized
|
| This kind of metaphor gets thrown around so often in this
| context. The editor is not your hammer, it's not your drill,
| it's your entire workshop.
| wruza wrote:
| Few last times I tried VSCode it wasn't immediately useful. I
| believe that you're speaking from your own familiarity with
| it. How big is your settings.json?
| mathisfun123 wrote:
| > How big is your settings.json?
|
| Lol empty
| nextlevelwizard wrote:
| >some of us don't have time to play games?
|
| Be honest how productive are you? You probably waste more
| time during your workday than you do work. Not every day, you
| might even have very productive weeks, but think over a year
| how many hours you "waste" on taking breaks to read
| HackerNews or Reddit or make a Tweet or whatever.
|
| You _could_ spend that time fixing issues with your editor
| and that would lead to improved workflow when you get back to
| work.
|
| And in my mind you should use your work time to improve
| yourself and your tools. From the day I started I decide that
| I wanted to be the best at what I do and I can't get there if
| I just do the work. So every day from the day I started
| working I've taken 30-60 minutes per day from my actual
| working time to improve. Be it learning something new or
| configuring my tools (editor, terminal, operating system,
| browser, whatever). And no employer has complained about my
| output nor should they since they are getting better output
| for the same investment.
| mathisfun123 wrote:
| > Be honest how productive are you? You probably waste more
| time during your workday than you do work. Not every day,
| you might even have very productive weeks, but think over a
| year how many hours you "waste
|
| Lol. Except for the odd day a month, I have worked every
| single day for the last 2 years (July 15 2021, when I
| started an internship at FB). I'm in a PhD program and I
| have a 20-30 hour/week job during the academic year and
| full-time internships during summers.
|
| > HackerNews or Reddit
|
| I read hn before bed for a couple of minutes
| xyzzy_plugh wrote:
| At least for me, Vim is immediately useful, and I rarely do
| much personalization. I agree that personalization is not an
| adequate measure of an editor. I don't agree that the problem
| with IDEs has anything to do with personalization.
|
| At least for me, it boils down to wanting an editor for text,
| rather than some specific programming language or
| environment. Traditional IDEs have been very "project"
| focused which isn't useful if you're editing an email or
| writing a poem or munging some logs.
|
| > imagine how little carpentry would ever get done if every
| hammer, drill, and tablesaw needed to be personalized.
|
| This is somewhat ironic to me not because of personalization,
| but because in traditional carpentry (i.e. a master
| carpenter) it is pretty common to make your own tools. That's
| kind of the beauty of woodworking and especially hand tools:
| your tools usually have a lot of wood parts. If they don't,
| they usually end up with a lot of wood parts anyways.
| mathisfun123 wrote:
| > a master carpenter
|
| master carpenters produce artisanal works. those works are
| valued for the craftsmanship itself rather than the
| utility. so it makes perfect sense that master carpenters
| would be incentivized to put thought and care into their
| tools. me? i'm just a tradesman/laborer. okay not really
| but there's still no such thing as "artisanal software", at
| least for sure where the code itself has intrinsic value
| (instead of it _generating_ value). anyway if i ever hit it
| big, make it to master software developer, and have enough
| freedom /time that i can afford to spend it on things like
| personalization, maybe then i will.
|
| > This is somewhat ironic to me
|
| double irony: i'm a compiler engineer and i _chose_ to work
| in compilers in order to be able to have more control over
| what my progams did. but i still don 't have time (or care)
| to personalize my IDE (or vim).
| mcpackieh wrote:
| Ever try to cut wood with a dull blade? I really don't
| recommend it. Even a novice carpenter will benefit from
| taking care of his tools. Admittedly it's more important
| for carpenters because blunt tools can get you injured.
| Excepting RSI issues, the worst that will happen with a
| suboptimal text editor is very marginal inefficiency
| (typing probably isn't the bottleneck anyway.)
| patrick451 wrote:
| A hammer is more like a small linux command line utility like
| tr. An editor is more like a table saw. A table saw is
| immediately useful, but carpenters also spend tons of time
| building sleds and jigs and fences and table extensions etc
| for them.
| synergy20 wrote:
| the original vim has always been my daily editor, yes I did spend
| time learning it along the way and it worth every minute I
| invested, it does everything vscode or other IDE can do for me.
| typing while moving mouse and clicking here and there on an IDE
| is not as productive comparing focusing on keyboard typing, to
| say the least.
|
| the beauty is that I can use it on any servers too.
| cutler wrote:
| I don't get the [Neo]Vim IDEs dichotomy. VS Code and IntelliJ
| both have excellent Vim plugins.
| _V_ wrote:
| I was using neovim but nowdays I just fire up Sublime. neovim
| remains as a choice when I jump to other servers with SSH.
|
| The thing is that when I'm (for example) trying to RE some
| protocol and have bytes-only view, I move things around quite a
| lot. And Sublime has a powerfull tool for this: multiple cursors.
| I can create as many cursors as I need and edit multuple
| instances/bytes at once.
| cayley_graph wrote:
| You can use marks in (n)vim for this!
|
| m<key> creates a mark. If <key> is a capital letter, you can
| jump to it across files.
|
| '<key> jumps to the line of the mark.
|
| `<key> jumps to the line + column of the mark.
|
| Although this doesn't let you _edit_ at the mark. There's
| multiple cursor plugins for that, I suppose... (I'll note that
| macros are useful in a lot of the same ways as multiple
| cursors)
|
| Edit: You can also use :vimgrep or another command that
| populates the quickfix list, and use :cdo to execute a command
| on every entry in the quickfix list.
| vincentkriek wrote:
| I dont understand the multiple cursors, is this better than
| search and replace? I am guessing you are replacing it to the
| same thing at every cursor, but I guess the value is then that
| the from could be different at the cursors?
| xrendan wrote:
| I use this all the time and you can copy a range of values
| with multiple cursors and then paste them into the same size
| range. It's nice for hashes or modifying static lists that
| all need the same changes, but are annoying to regex for
| _V_ wrote:
| It works perfectly together - one is not necessarily
| replacement for the other.
|
| For more complicated things or bigger changes you would go
| with regex search & replace or sed/awk/grep but for small
| one-shot things it is way quicker to just click 5 times and
| do whatever you need to.
| humility wrote:
| A true IDE layer for neovim.
|
| The best part is that the developer(Folke) is very active with
| development and basically helping with all sorts of problems- the
| other day, I opened a pull request and it was resolved within
| hours..
|
| Thank you Folke for the amazing work around neovim not limited to
| lazyvim.
| izoow wrote:
| I've recently been exploring various neovim distributions and I
| feel like at this point neovims package ecosystem has gotten good
| enough that these distributions don't really seem to make my life
| much easier. Many times quite the opposite actually, as I often
| find myself fighting with them when I want fo change something.
|
| The experience is still not as painless as effortless as VS Code,
| distribution or not, but it's definitely gotten a lot better than
| it used to be.
| X6S1x6Okd1st wrote:
| After using vim for more than a decade and slowly acquiring my
| personal config I switched to lazyvim. No regrets.
|
| Also for simple chores like mass converting your config from
| vimscript to lua I'd really recommend bing chat, an LLM with the
| docs loaded works wonders on it, getting all my stuff ported and
| lazyvim set up took less than an hour IIRC
| raphinou wrote:
| NvChad[1]is the first vim/neovim config that worked for me for
| coding. What I also like in NvChad is that all my custom configs
| can be placed under a `custom` directory, leaving the provided
| config as is and easing upgrades of NvChad itself. This doesn't
| seem to be the case with LazyVim.
|
| [1]: https://nvchad.com/
| CiTyBear wrote:
| Many people complain about the time you need to have a proper
| vim. In computer security, I learnt to make my own tools, to
| develop my own script that match what I want to do/scan.
|
| For vim, this is exactly the same. I started with Python so my
| vim became the best Python IDE (for me) and that's all. What I
| said to junior dev is "Here my vim conf, you are allowed to
| copy/paste only what you understand". Then I did some Typescript
| and added a configuration that works for me. Thus, some pain
| point came from my old config in python, I found new good plugins
| and added them. And so on with rust and ruby. Everything is
| commited so now, on a new machine, it takes me the time to
| copy/paste my config and write :PlugInstall.
|
| Everytime I test vscode, it does not do what I want and when I
| look into it, I can't configure it correctly. Vim has always my
| back.
| Shorel wrote:
| This reads so much like that macho programmer who wrote
| everything in assembler from a few decades ago.
|
| I will keep using Sublime Text. No need to suffer needlessly.
| Draiken wrote:
| > that macho programmer
|
| Why do people keep making value judgements about people that
| built tools they trust like they should be ashamed or
| something like that?
|
| Parent simply explained his process and why he uses vim like
| that and why he doesn't like VSCode. There's nothing there
| that says "macho" in any shape or form. I don't understand
| this need to put labels on others like this. Maybe it makes
| people feel better about their own choices? Helps with
| insecurity? I don't know.
|
| Whatever it is, this doesn't add to the conversation at all.
| troyvit wrote:
| This sounds like a refutation, but it's also in the same
| spirit as the parent. "No need to deal with insane
| complexities, I'll stick with my simple editor." Whether
| that's vim or Sublime, that answer works, and that's pretty
| cool.
| Shorel wrote:
| Except that ST is not "simple" by any measure.
|
| It uses the standard bindings I learned with Windows
| decades ago, and builds on that.
|
| Vim forces me to change it all to the vim-like model.
|
| It's about having to learn a new set of key bindings just
| for that program alone.
| troyvit wrote:
| That makes sense, and I definitely wasn't trying to
| denigrate ST. Having not touched Windows since 2003, and
| having come from the vim world I had to learn a few
| aspects of Sublime to help my coworkers out, and just
| like you say, having to learn a new set of keybindings
| was a pain.
| IceDane wrote:
| This is pretty ironic, given that Sublime Text is basically
| dead in terms of community, number of users, etc and
| definitely isn't a full IDE.
| Shorel wrote:
| Been reading that for years.
|
| The language server protocol works perfectly fine with ST4,
| and it is better than ever. Whatever our small community
| needs, it's there.
|
| The fact it is not a "full IDE" is also one of the reasons
| I like it.
| recursive wrote:
| Am I crazy to think that I don't need a "community" to edit
| text?
| cauthon wrote:
| what's the current recommended package manager for vim? I used
| to use vundle but that seems to be unmaintained/deprecated and
| has broken on recent installs.
| be_erik wrote:
| For me it's plug. It just works.
| gejose wrote:
| > Everytime I test vscode, it does not do what I want and when
| I look into it, I can't configure it correctly. Vim has always
| my back.
|
| Can you expand on this? What specifically does not work for you
| on vscode?
| CiTyBear wrote:
| I don't believe in 10x programmer and know this term only
| from HN. I live in France and after 10years programming, I
| never heard a collegue said "I am a 10x programmer". However,
| I always make sure any git project can be worked on with any
| IDE. I use vim, some use PyCharm and most of them use VScode
| and it works fine.
|
| However, I can tell you my main pain point in using VS code
| vs vim: project switching. Many times I have to go quickly to
| another project and close it. When I code in vim this this :
|
| ctrl+Z (go back to term) workon project_2 vim ctrl+P (select
| the file I need to see or quickly edit or show to a colleage
| to explain) :q! (let's say I didn't edit anything) fg (Go
| back to my main task)
|
| Did not know how to be that fast to open/close project with a
| _real_ IDE.
|
| To oppose this, there is one feature I envy of vs code: code
| in docker through ssh seamlessly. Unfortunately this is not
| even available in vscodium.
| DropInIn wrote:
| And then a coworker/boss is at your desk with you and needs to
| show you how to do something and cannot for the life of them
| grok wtf your personalized bs is, requiring them to go get
| their own absurdly personalized mess to show you, and still you
| both have problems because the workload they showed you tonsave
| an hour a day would require you to pull out massive chunks of
| your personalized bs in order to add in a huge chunk of their
| personalized bs.
|
| And that doesn't even get into what happens on shared machines
| (servers etc) where your entire workflow either doesn't work or
| entirely prevents others from being able to get anything done
| on the machine.
|
| Really.... we all recognize the value of standardization when
| it comes to our code but yall fight tooth and nail about
| standardization in other aspects of the profession.... and then
| wonder why everything is a buggy unintelligible mess at 99% of
| workplaces and projects...
| majkinetor wrote:
| Indeed, yet I switched to vscode after 10 years of vim because
| it is next in line to vim when powerfull editor is in question,
| and once you set it up you can have it 0 on-boarding everywhere
| else working on ANY machine you use, including browser. I use a
| lot of machines and I want my editor with me. Its mind blowing
| that you can just login in GitHubs vscode within a web browser
| on any repository and have your own vscode with config,
| hotkeys, extensions and whatnot, the same as on the desktop.
|
| I do miss vim editing constantly, and I could never feel vim
| emulations as a native thing, but vscode is really awesome,
| particularly its keyboard centric design and sync.
|
| Once vim has this "works everywhere and my setup installs in 1
| command" I will get back to it.
| wredue wrote:
| I mean. Helix is a pretty decent editor with a nice set of
| defaults over vim.
|
| Not as customizable. But I pretty much would configure vim to
| do what helix does out of the box anyway.
| lvass wrote:
| >just login in GitHubs vscode
|
| Imagine if you had to do that to every program you want to
| configure. Sure, rsync/git cloning your config may be less
| straightforward than logging in somewhere, but it's far more
| convenient when you have to configure dozens of programs
| anyway.
| lawn wrote:
| For me it feels easy to migrate my config.
|
| Just copy/clone the dotfiles, launch neovim and run a command
| to update the plugins and everything is good to go.
| throwing_away wrote:
| I use it. The defaults are reasonable.
|
| https://github.com/folke/lazy.nvim is maybe a more interesting
| link
| urmish wrote:
| That's just the plugin manager, lazyvim.
| github.com/LazyVim/LazyVim or github.com/folke/dot/nvim might
| be more useful to see how to get the most out of this neovim
| 'distro'.
| pratikch1253 wrote:
| I have tried most of these out of the box neovim stuff and they
| do work for the most part but as soon as you want to tweak things
| it's not as easy. Besides that sometimes plug-ins can just break
| due to a bad merge and that can just break some core feature and
| now you are stuck either finding a fix or just go back and use
| VSCode
| snitty wrote:
| I just open a file stream and write the hex straight to the
| storage device. Anything else is cheating.
| TheRealDunkirk wrote:
| Oblig. https://xkcd.com/378/
| snitty wrote:
| Ooooh, I'd forgotten about that one. Thanks!
| altonas wrote:
| LazyVim got me back into vim. After years of custom configs
| and/or heavily editing lunarvim and nvChad I was getting a bit
| burnt out but decided to give lazyVim a try, and I was absolutely
| blown away. For the first time a vim setup actually felt like a
| real IDE. It took about 60 seconds to go from having lazyvim
| installed to having a fully functional IDE that I could use at
| work in a real environment. That's the same amount of effort it
| would have taken me to set up a fresh install of vs code with
| whatever plug-ins I wanted.
|
| If you've ever been put off by the complexity and setup of nvChad
| or lunarVim, then I highly suggest giving lazyvim (or astrovim,
| its similar but with more "batteries included") a try
| majkinetor wrote:
| I don't buy it. I have so many custom little quirks that no
| ammount of integrated out of the box setup is gonna replace it
| in 60s. Thats unrealistic. I believe its good, but it must be
| for certain class of working habits (for example, its probably
| great for those people that use vanilla anything, including
| vim).
| wrapperup wrote:
| Agreed. Back then, I tried to get into neovim with packer and
| a ton of plugins, then tried AstroVim and stuff broke all the
| time. Went back to vscode.
|
| I tried it again about half a year ago with a much leaner,
| custom lazy (plugin manager, not LazyVim) setup, and now it's
| my main IDE for everything except C++ (clangd sucks, sorry)
|
| It took me less than a day to get a decent config, and now I
| rarely touch it (occasionally there may be a nice plugin to
| throw in). Config is about 2-300 lines, with LSP (rust,
| typescript), harpoon, oil.nvim telescope, etc. Works great.
| senkora wrote:
| What do you use for C++? I was planning to integrate clangd
| into my setup soon.
| roland35 wrote:
| I've had a good experience with ccls, although to be
| honest I haven't really compared it with clangd so I
| can't say if it is actually any better!
| BlackjackCF wrote:
| I had the same issues with AstroVim when it was first
| coming together. Looks like the creator was rapidly
| iterating to try and make it easier to configure.
|
| It's now in a stable enough state that I haven't had any
| issues.
| altonas wrote:
| That's the thing, I absolutely don't want to do a bunch of
| tiny tweaks. I want to write (react) code. For me personally
| I feel like tweaking an IDE gets in the way of that. Yet I
| can take a clean install of lazyvim, use mason to install the
| react language server, and install copilot, and then I can
| immediately start working.
|
| And so that's what I actually do, and I find that to be much
| more pleasant (and lightweight) than other IDEs like VS code.
| majkinetor wrote:
| Then you musta accept suboptimal UX. Its one way to live
| your life.
| altonas wrote:
| Can you actually explain how it's suboptimal UX, and what
| I could be doing better. I want a simple IDE, not
| suboptimal bloat. I don't need 200 keybinds to make a vue
| component.
|
| Just because you have a bunch of custom quirks doesn't
| mean that I do.
| majkinetor wrote:
| Any time somebody else creates something instead of you,
| it must be accepted as suboptimal. We are all unique
| human beeings and have different kinds of habits and
| disfunctions, levels of knowledge etc. so 1 setup for all
| is pretty much impossible and nobody else can do it but
| you. Any time you accept that, you are accepting
| suboptimal UX. If you are doing so you are admiting that
| you are either lazy, or you are good with your potential
| being maxed out at that point (if you are accepting
| anything less then most efficent workflow, given that
| time is the most precious resource).
|
| Actually, when I look at how most of my colegues are slow
| using their tools of choice, even senior ones, I imagine
| I would rather kill myself then using such setup.
| Sakos wrote:
| Or rather it's a matter of trade-offs and some things are
| just "good enough". It's not up to you what's good enough
| for him or me, especially weighed against the amount of
| effort I might have to invest to get something that's
| "optimal" for me.
| throwmeout123 wrote:
| Cant wait until you create your programming language to
| use in the company you created racking up the optimal
| millions while laughing at us lazy slobs!
| majkinetor wrote:
| You can stop immediatelly.
| throwmeout123 wrote:
| Maybe YOU should stop calling other people lazy for
| something actually very productive, aka not wasting
| million hours tinkering with lua for marginal returns
| over investment, often on company time...
| mcbuilder wrote:
| On the flip side, I've been using VIM/emacs for over a
| dozen years, and have gone from extensive user made
| configs to these starter packs (DOOM Emacs with some
| custom stuff on top). I mean I'm happy with a well
| thought out "total conversion" of emacs. I learn the UX
| on top (that is really nice) and I add my own. If I
| started from scratch it would probably be sub-optimal ( I
| mean I could recreate DOOM, but why?)
| masukomi wrote:
| The thing about vim and emacs is that both of them, out
| of the box, suck. BUT, what they both offer better than
| anything else, is the ability to gradually modify them to
| match what your brain needs.
|
| I 100% agree with your hyperbolic "200 keybinds to make a
| view component" But that's ...that's not how it works
| unless that's what your brain wants.
|
| With ALL editors you eventually encounter "ugh, this is
| frustrating" or "i wish i didn't have to do that" and
| then you have 30+ years of plugins and configs you can
| draw on to modify it to match your liking without any
| coding. VERY rarely, you'll want to tweak it in a way
| that there isn't a plugin / config for and you'll find
| communities of very helpful people who'll respond with
| "what about this solution..."
|
| The fact is that _your_ brain is different from everyone
| else's. The less configurable an editor is the less it
| will be able to support the way your brain likes to work.
|
| You _can_ accept pre-made defaults like those provided by
| VSCode OR you can gradually refine your editor to be a
| perfectly crafted tool for your particular and very
| individual way of thinking.
|
| I choose the latter because i spend SO much time staring
| at my editor and trying to convince it to do things that
| are almost always better with automated assistance from
| it.
| majkinetor wrote:
| Exactly. You absolutely need maximum configurability for
| the most important tools in your arsenal. You can pass
| with defaults on less used tools but everyday stuff
| should be as efficient as possible. In my case those
| tools are editor, shell, browser, OS, media player - they
| are customized extensivelly.
| BanazirGalbasi wrote:
| > You _can_ accept pre-made defaults
|
| In my case, I'd prefer to do so. I'm a different use-case
| though, I'm a server admin so I want to be as comfortable
| with bare-bones defaults as possible so that I can jump
| on any server and just use Vim (or sometime just vi!). I
| can't afford the time it would take to set up a custom
| config on every server in every environment, so the most
| I need is a basic .vimrc that has `set number` and a
| couple netrw tweaks that I can copy with scp and get
| going. Most of the time I don't even copy that over and
| run `:set number` when I open a file.
|
| Note that I'm still an intermediate Vim user at best,
| splits and markers are the most complex features I use
| (no macros yet). I know I can edit remote files, so maybe
| once I'm comfortable with that then I can set up some
| real customization in each environment.
| ziftface wrote:
| That's interesting to me since I've been using close-to-vanilla
| lunarvim for the past year and it's been great. I'm just not
| into customizing my editor much, and only touch my config when
| I'm annoyed by something. This seems to be your goal as well.
| Can I ask then what makes lazyvim easier or quicker to set up
| how you want?
| altonas wrote:
| I found lunarvim to just not work that well for web
| development out of the box (if I tried doing anything past
| vanilla JS), and I have no interest in learning about
| lunarvim specific things like the lvim global object to be
| able to tweak it.
| urmish wrote:
| lazyvim is the package/plugin manager and LazyVim is the distro
| conaclos wrote:
| The last version [0] of nvChad uses also lazy.nvim under the
| hood. I am not sure how this could help in your case.
|
| [0] https://github.com/NvChad/NvChad/releases/tag/v2.0
| articsputnik wrote:
| Most people miss "Vim Is More than Just an Editor." The Vim
| Language, its motions, and its modes will make you a better
| programmer and writer. If you invested in the vim language early
| on, you can use it on each editor, browser, and other apps. This
| has nothing to do with the editor yet - these are universal and
| available. For example, there's VSVim for VSCode, IdeaVim for the
| JetBrains products, Vintage Mode for Sublime, and so on. But
| there are also Browser extensions like Vimium or Firenvim, and
| Gmail even adopted some of Vim's shortcuts for navigation (j, k
| for moving, g for jumping).
|
| Everyone who types on a computer eight hours a day should learn
| the Vim language. Yes it's hard initially, but that's the case
| with everything new and different. But getting better every day
| and having more fun coding or writing should be motivation
| enough. Also, imagine, if you work over a decade, how many times
| you had to learn a new editor (notepad++, atom, eclipse, ...)
| some of which do not exist anymore. If you once learned the vim
| language, you are getting stronger. There is a reason the editor
| has existed since the eclipse of programming.
|
| The Vim grammar is exceptional, as spoken language has verbs,
| subjects, and objects, as does the Vim language. The grammar has
| different verbs, to begin with. Copying (or yanking) in Vim with
| y, deleting with d, pasting with p, changing with c, and so on.
|
| You can also see in the comments here people fight over Vim and
| VSCode, where the natural beauty is the language behind Vim. If
| you do not want to configure and customize your own, use VSCode
| and add the Vim extension. But if you're going to get better at
| your job, you should try the Vim language.
|
| Once mastered, you edit text at the speed of thought. Sounds
| cheeky, but it's true for me. Instead of thinking, "I want to
| edit that word," my fingers jump to it and change it with a few
| keystrokes.
|
| I wrote more on https://www.ssp.sh/blog/why-using-neovim-data-
| engineer-and-w... in case you are interested.
| DoubleFree wrote:
| I would substantially nuance most of what you say. I really
| like vim and use it almost exclusively, but it is not
| necessarily the "only" way, or even necessarily the "best" way
| to do things. If the vim grammar clicks for you, great, by all
| means use it. There are people for whom it doesn't click, and
| that's fine too. I do encourage everyone to try it for a bit.
|
| I also would not say learning vim makes you a better programmer
| or a better writer. It makes inputting and changing text easier
| and faster, but that's not what programming or writing is
| about.
|
| I agree that the vim grammar is nice, but the bigger thing that
| differentiates editing text in vim versus other editors is its
| modality. And it is the modality that allows it to have a
| grammar in the first place. And that grammar does break down in
| places, just look at every keybind starting with g.
|
| So yes, try vim, because it is pretty great. But if it doesn't
| work for you, move on to something that does.
| pratikch1253 wrote:
| Why is this upvoted so much this is nothing new??
| pacomerh wrote:
| I have been using Lua to customize Neovim for some time now and
| generally, the experience has been good. From time to time, I do
| encounter issues such as dependency incompatibilities butI always
| manage to find a solution. Recently, though, I experimented with
| LazyVim, and I must admit, it might replace my current setup.
| LazyVim fulfills all of my requirements, it works and looks
| great.
|
| Btw, if you this is your first trying it check out Elijah Manor's
| video: https://www.youtube.com/watch?v=N93cTbtLCIM
| wauter wrote:
| Great project!
| noud wrote:
| Am I the only one using vanilla vim with a minimal configuration
| file (<50 lines)? I set tabs to 4 spaces, put syntax highlighting
| on, set background to dark, add fuzzy finding, and configure
| netrw (default file browsing).
|
| Very easy to setup. Moreover, when I'm on a different computer
| and open (vanilla) vim without any configurations. I know that
| everything is more or less the same as my default vim
| environment. I think it's not that hard to learn developing in
| the default vim environment, with some minor tweaks.
|
| Also related, How to Do 90% of What Plugins Do (With Just Vim):
| https://www.youtube.com/watch?v=XA2WjJbmmoM
| roland35 wrote:
| With less plugins and less custom configuration it becomes much
| easier to work in environments outside your home. Also it is
| more robust and less things break!
| bregma wrote:
| No. I've been dragging my small (106 line) .vimrc around pretty
| much unchanged for at least a couple of decades. It's mostly
| just setting different colour schemes for different filetypes.
| I've been a vi user for about 4 decades.
|
| I need a small, fast text editor that works over remote
| connections, works on Linux and Windows, needs no configuration
| or plugins to be useful, and just works and gets out of my way.
| VSCode does not fulfill most of those needs. Plain old vim (and
| not neovim) does.
| maskros wrote:
| You're not the only one, but my configuration is the opposite
| of yours.
|
| These are the three lines I always use on any vim install.
| let loaded_matchparen = 1 syntax off
| map ; :
|
| The first two lines are crucial, because I find rainbow colored
| text and flashing punctuation extremely distracting. If you
| find monochrome code unreadable, then that's a problem with
| your formatting style that you can easily fix.
|
| The last line is really handy for not having to hold down shift
| so much.
| thenoblesunfish wrote:
| Not at all. This boring answer is very useful for general use.
| I have some fun plugins that have been useful (YouCompleteMe
| was helpful for C development) but they break and I don't
| notice. But at work someome else maintains an IDE for me, so I
| use that.
| JeremyNT wrote:
| I worked this way for ages, but over time I came to appreciate
| some modern IDE-like conveniences like linters (I use ALE for
| this stuff). Especially thanks to LSP (which neovim supports
| natively, though I stick to upstream Vim myself) you can get a
| lot of value from these.
|
| I think it's easy to go overboard though. A lot of plugins (and
| these meta-plugins) provide little value over what vim can do
| on its own with a little configuration.
| 3836293648 wrote:
| Neovim isn't exactly downstream. It's a hard fork from ten
| years ago. They've gone their separate ways for a long time
| srj wrote:
| Yeah I've been using vim with just a custom theme and a fairly
| vanilla .vimrc for 20 years. I just copy it around with me.
| These posts always make me feel like I'm missing out.
| least wrote:
| I use neovim for my development. It has a bunch of plugins to
| facilitate using it as my primary code editor. I don't
| particularly enjoy typing things out over and over again (I
| have RSI) so to me a config that doesn't have things like
| autocomplete aren't going to be acceptable to me long term.
| LSP also makes it easier for autocomplete to function with
| the context of your development environment, which allows me
| to type even less.
|
| I'm not going to sacrifice my 95% use case for the 5% of time
| (probably even less) that I am in a situation where I don't
| have access to my own config. If I am just editing a few
| lines in a config file on a server, it doesn't really matter
| that I don't have my config.
|
| With that being said, not everyone wants or needs plugins and
| their needs are different from mine. Do what serves your
| needs. I would simply advise anyone to consider if their
| workflow is serving themselves or not. A lot of people get
| stuck in the mindset that they need to simplify in order to
| facilitate easy transitions to situations that just don't
| come up all that often.
| devnullbrain wrote:
| Nothing says someone doesn't grok vim like a permanent nerdtree
| pane.
| a1445c8b wrote:
| It helps though with remembering where you are in your
| codebase. Rather than cluttering my brain with the info that
| Nerdtree provides, I can instead use the extra brainpower for
| other things.
| nextlevelwizard wrote:
| There is always people coming over from established purpose
| made IDEs who want to test to waters and bare vim is pretty
| feature parse out of the box, so these huge plugin &
| configuration monoliths offer easy stepping stone into vim.
|
| Of course with these packages you are trading flexibility for
| features and you are inheriting ways of working from someone
| stranger, but it is not that much different than using any IDE.
| While this offers a nice(r) gate into vim-ming it does kind a
| miss the biggest perk of using vim - which is molding it to
| your exact needs and preferences, but that is not something you
| will do over night. I have been in both camps. I have installed
| way too many plugins and then gone to very sparse
| configuration. I think with NeoVim I have found somewhat of a
| balance, but I think reworking your vim config is a natural
| thing every five years or so. We grow as people and developers
| and our needs change and the tools evolve.
| stefncb wrote:
| You're not, mine is only 10 lines and no plugins.
| jstanley wrote:
| I do roughly this too, except my vimrc is about 8 lines. I type
| it out from memory every time I use a new machine.
| majjam wrote:
| Would you mind sharing it? Im just getting to grips with vim
| so any pointers towards some simple improvements would be
| much appreciated.
| gsinclair wrote:
| Take a look at the vim-sensible plugin. No need to install
| it, just see what the generally agreed sensible settings
| are.
| DiabloD3 wrote:
| Most of vim-sensible is already default or equivalent on
| Neovim, fwiw.
| jstanley wrote:
| Sure: set ts=4 set sw=4 set
| softtabstop=4 set expandtab set hlsearch
| set incsearch set wildmode=longest,list
|
| OK, only 7 lines then :)
|
| Basically: tabs are 4 spaces, searching works better, and
| tab completion works like bash.
| tambourine_man wrote:
| Oh no, I need at the very least timeoutlen, visualbell
| and line number. I type that manually when I SSH if I
| must. Don't want to wait for ESC, no beeps at all and I
| wanna know where I am on the document.
|
| And lots more is needed for decent Vim IMO. smartcase,
| set hidden, etc.
| cempaka wrote:
| relativenumber is essential too, unless you like typing
| something like d-638-<Shift>-G just to delete 15 or 20
| lines of text.
| majjam wrote:
| Thank you!
| tambourine_man wrote:
| I'm at home on vanilla vim, but there are some quality-of-life
| stuff I've been collecting over the millennia that are just too
| good to give up on my day to day use. One has to find its own
| balance of custom vs default.
| wffurr wrote:
| I can't use vim at all without at least vim-surround. Too much
| muscle memory for the bindings for that one.
|
| I was absolutely thrilled to find that VSCode's vim emulation
| included vim-surround! I guess someone out there has the same
| problem I do.
|
| So much programming is editing various text surrounds: parents,
| braces, brackets, quotes of various flavors.
|
| I also really like having semantic completions. I get by with
| YouCompleteMe, but it's a little jank in my build system.
| ta1243 wrote:
| I have a one-line vimrc, mainly to undo the damage the change
| in defaults vim 8.0 brought (so I've got things like _set
| t_BE=_ ). I used to have to also have set noincsearch and set
| scrolloff=0, but something in my environment seems to been
| upgrade so I no longer need that in my vimrc
| szszrk wrote:
| I really think this is the best way to use it for many people.
| You need something more complex? It's ok to bundle vim with any
| of great IDE's out there.
|
| I learned how to change colorscheme more than 20 years ago
| because my CRT monitor made it impossible to read comments on
| default themes. I use same command today on my local terminals,
| bastions accessible via web or remote sessions ... for
| basically the same reason.
|
| If you code from one machine spending time to set up IDE and
| then leaving it be makes sense. But if you are more of an
| admin, or learn a lot and jump from host to host, from learning
| platform temporary environments to cloud environments, from
| mobile to some remote mainframe that is being decommissioned
| for past 7 years? You could just figure out how to change 2-3
| basic options and have a predictable environment for next few
| decades.
| thatxliner wrote:
| How does this compare to https://github.com/AstroNvim/AstroNvim
| pkulak wrote:
| Not as much stuff baked in. They are very similar. AstroNvim
| uses Lazy as the package manager as well.
| fvgs wrote:
| My attention span for text editor configuration decreased
| drastically after I finished school. For better or worse, being a
| professional means making the correct trade off when time, money,
| and productivity are at stake.
|
| In the modern era, there are sufficiently many practical editors
| and IDE's with major economic investment behind making them
| highly functional out of the box. I simply cannot justify
| spending copious amounts of time configuring a text editor when
| there's sufficiently good and productive options out there.
|
| Looks like the last edit I published to my Vim config was 5 years
| ago https://github.com/fvgs/.vim
|
| But hey, maybe I'll find some "lazy" time to give LazyVim a go
| and give VSCode a break.
| drngdds wrote:
| Yeah, I don't get the "use Vim for everything" approach unless
| you're just doing it because you find the customization and
| configuration fun. I usually use VS Code for quick editing and
| full IDEs for real work with big projects.
|
| Modal editing is awesome though. I use modified Vim keybinds
| for everything, even web browsing.
| nextlevelwizard wrote:
| As long as you know your tools and can achieve everything it
| doesn't matter which tool you choose.
|
| I tend to mentor a lot of newbies and they often use VSCode,
| but since they are newbies they don't know how to do basic
| things like search (and replace) and I can't help them since
| I've only used vim. I have tried to give VSCode a go couple
| times to get more familiar with it, but I run into same issue
| as you - I simply can't justify in my head the time and effort
| to familiarize myself with the editor, figure out what settings
| to use and which addons to add.
| danjac wrote:
| I've been using vim for years, switched to neovim, and at this
| point I'm ready to throw in the towel and just use vscode for
| anything beyond simple text editing.
|
| The amount of work needed to get a basic IDE up and running for
| your languages of choice, even for commonly used languages such
| as Python or Javascript, is far too much for someone who wants to
| get on with their day job or hobby coding and doesn't want to
| spend precious hours fixing obscure issues in Lua.
|
| Furthermore, the community does not have a good culture of
| documentation and learning: too many plugins have very sparse
| docs, and other online resources such as the Neovim subreddit are
| hostile to newcomers with "RTFM" a common answer. The community
| is also fragmented, with too many ways to do the same thing in
| the name of some platonic ideal of personal freedom over
| practicality.
|
| A simple question like "How do I set up Black with neovim to
| format my Python files on save?" will yield a dozen answers, each
| one with someone's favourite plugin. Setting up that plugin will
| require another plugin, and so on until you end up with a Jenga
| tower of dependencies that doesn't quite work the way you want,
| but is too fragile and time-consuming to tweak correctly.
|
| In the meantime, I can just Ctrl+P and install what I need in
| vscode and be on my way in a few minutes.
|
| I don't particularly like vscode. It's heavy and slow and janky,
| particularly on older laptops. I don't like being sucked back
| into the Microsoft ecosystem after spending years getting away
| from it. But ultimately, I want to just get on with my job, and
| my job is not Lua Developer or Neovim Plugin Expert.
| yjftsjthsd-h wrote:
| > The amount of work needed to get a basic IDE up and running
| for your languages of choice,
|
| I don't think vim is meant to be an IDE. If you want an IDE, go
| get an IDE. If you want a text editor, vim works well. But
| vscode is unwieldy as a text editor, and vim is painful to
| contort into an IDE.
| marricks wrote:
| Exactly this. Don't blame the airplane for not being a car,
| or a submarine for being a beach buggy.
|
| Obviously people have made things for VIM to be IDE like,
| some are cool to me, but completion-integrations-lang-servers
| always seemed so anti-vim to me. Make an HTTP request every
| key stroke to get suggestions? The. Latency.
| konart wrote:
| VSCode does the same. And it has nothing to do with HTTP
| (not by default at least).
| lawn wrote:
| No, Vim can be an excellent IDE. Just not a "works out of the
| box" one.
| DropInIn wrote:
| Then tell the vim fan bois to stop telling people to use vim
| as their ide....
|
| The issue isn't with the fact people try to use it that way,
| it's that those who use vim are adamant it's the best option
| for doing so and berate the Other until they try.
| yodsanklai wrote:
| on the other hand, using vim mode in vscode let you use vim
| where it shines: modal editing. It's the best of both worlds.
| johannboehme wrote:
| not really.. vim is easy to extend and adapt. You loose
| that with only vim mode in vscode. You also loose the
| ecosystem and relevant core functionality like most vim
| core functionality like :grep :vim :make, quickfix list,
| arglist etc..
| jgilias wrote:
| Some time ago I switched from my bespoke Vim setup to Doom
| Emacs. I was pleasantly surprised to find out how "VS-esque" it
| is. As in, it's very easy to set up it for a new language.
| Usually I just need to uncomment the correct line in config.
| And even if it's not there, finding the correct major-mode and
| installing it is usually pretty straightforward.
|
| So yeah, highly recommended! Of course, I use the evil mode for
| Vim keybindings.
| htag wrote:
| If your goal is to avoid becoming an expert in elisp then
| it's certainly possible while using Doom Emacs, but you're
| not getting the full experience.
| [deleted]
| prohobo wrote:
| I just want mouse support... I need a GUI for my projects to
| navigate and organize them well, and I don't like how blind and
| tied up I feel in Neovim.
|
| I'm looking forward to some kind of open source VS Code killer
| with vim editing and native platform builds.
| yadingus wrote:
| Out of curiosity, why do you need your text editor to also be
| a perfect file manager?
| conor- wrote:
| > In the meantime, I can just Ctrl+P and install what I need in
| vscode and be on my way in a few minutes.
|
| Vim's built-in package management means all my plugins are
| stored as git submodules that are installed alongside my
| configs. I don't have to remember what extensions I have and
| Ctrl + P and install them one at a time.
|
| VSCode's settings.json and extension-level configuration is
| also extremely cumbersome. You're paying a time tax no matter
| what tools you're using if you want to customize them to fit
| your workflow. Personally I'd rather pay that tax 1 time with
| Vim and then carry the same setup with me to any PC than have
| to eat that cost every time I need to configure VSCode on a new
| machine.
| KronisLV wrote:
| > I don't particularly like vscode. It's heavy and slow and
| janky, particularly on older laptops. I don't like being sucked
| back into the Microsoft ecosystem after spending years getting
| away from it. But ultimately, I want to just get on with my
| job, and my job is not Lua Developer or Neovim Plugin Expert.
|
| I've personally been test driving JetBrains Fleet and have to
| say that it's pretty okay for most of my lightweight dev needs:
| https://www.jetbrains.com/fleet/
|
| It's still a bit early for it and it doesn't have the same
| ecosystem that VSC has, but it'll probably be even better in
| 1-5 years and is decent already.
|
| For most of the more heavy work I just use JetBrains IDEs, but
| that's very clearly a no go for the less capable devices like
| my netbook.
|
| For even lighter options, on Windows there is Notepad++, which
| has been okay although not an IDE.
|
| There's also CudaText, which feels quirky but has decent
| language support: https://cudatext.github.io/
|
| Maybe even something like Geany is worth a look, depending on
| your needs: https://www.geany.org/
| dcow wrote:
| I cant stand VSCode anymore after using Zed[1]. I mean it was
| always clunky but there weren't better options. Now there is.
|
| 1: https://zed.dev
|
| Edit: I did use Helix for awhile (long enough to still have
| muscle memory for their editing model) but it's just not there
| yet and eventually moved on to Zed.
| p-e-w wrote:
| I love the concept and engineering behind Zed, but
| considering how software startups tend to fare, there's just
| no way I'm going to mentally invest in a closed source dev
| environment.
|
| Even if they succeed commercially, chances are some day
| Microsoft just buys the whole thing and shuts development
| down a week later. No thanks.
| dcow wrote:
| The way I see it if Zed fails I just go back to VSCode and
| I'm no worse off than before. The nice thing about Zed is
| that it's batteries included so it really isn't hard at all
| to pick up. I did in maybe 15 minutes tops, seriously.
| auggierose wrote:
| The description looks cool. It's macos only though for now.
| dizhn wrote:
| I went from VSCode back to vim via Neovim and it works great. I
| am setup for go and lua. I took a base config called kickstart
| and removed things I didn't need. Then I added things I do
| need. As for the community, the channel on Matrix is one of my
| favorite communities. Whenever I needed help, it came instantly
| and with precisely what I need. (They must be getting the same
| things a lot). They never suggested I use a big plugin to solve
| a little problem as far as I can remember.
|
| All in all it looks like we had a wildly different experience.
| I suspect the real issue is that I like to work with vim a
| million times than I did with vscode. You might me biased the
| other way. I feel better on the command line and it's amazing
| how much people have figured out already to make things run
| well and look nice.
|
| Kickstart nvim: https://github.com/nvim-lua/kickstart.nvim
| Francis0xf wrote:
| https://lapce.dev/ might be a good compromise it looks and
| works practically like vscode and runs well on older hardware
| twleo wrote:
| Code should be self-documented. And editor should have a good
| mechanism to help you understand the source code. Emacs does
| better in this angle than Vim by far. You can find the
| documentation for every variable (describe-variable) and
| functions (describe-function) easily and jump to their source
| codes.
| flohofwoe wrote:
| I use VSCode with one of the neovim extensions for 'IDE tasks'
| (none of those extensions is perfect though, but they're "good
| enough"), and a vanilla vim without customization for quick
| text editing tasks on the terminal (sometimes even within the
| VSCode terminal panel).
|
| E.g. for me, "vim" is more like an input scheme that works
| across editors, less a particular product.
| eikenberry wrote:
| An alternative to Neovim or VScode that might be worth checking
| out is Helix (https://helix-editor.com/). It is a Vim/Kakoune
| inspired editor that is really starting to hit its stride. I
| haven't used it extensively yet, but I'm testing using it for
| development now and am thinking of switching to it full time.
| It maintains the minimalism of (Neo)Vim while coming with a
| great builtin setup like VScode.
|
| To get a feel for its development status I recommend reading
| their news post for their 23.03 release.. https://helix-
| editor.com/news/release-23-03-highlights/
| danjac wrote:
| Helix is quite nice, with some sensible defaults and an
| easier setup. The keybindings take a bit of getting used to
| if you are coming from it with years of vim muscle memory,
| but kind of make more sense when you think about it
| (select+action vs action+select). It's still rough around the
| edges but one to keep an eye on.
| Tubbe wrote:
| Without any proper code completion integration (eg. Copilot),
| and no working plug-in system, Helix unfortunately falls
| short for my needs.
| cayley_graph wrote:
| Helix is interesting but I don't really gel with its editing
| language (subject + verb instead of verb + subject like
| (n)vim's). Happy to discuss what I think is lacking in more
| detail, but basically: the premise of 'you can see what
| you're about to operate on before you do the action' is
| satisfied for me by visual mode, and I like macros better
| than multiple cursors. So I don't want a (subjectively) less
| efficient editing language for these features. I think I
| generally agree with the complaints in [1], with the addition
| that I don't want to have to chord (press shift in the case
| of Kakoune, I forget what helix does here) to extend a
| selection.
|
| I wish they'd add a Vi mode. ;)
|
| [1] https://github.com/noctuid/dotfiles/blob/master/emacs/edi
| tin...
| eikenberry wrote:
| I've seen that breakdown before and have skimmed it but
| didn't really find an analytical breakdown of why style X
| is better/worse than style Y for person Z very useful.
| Tools preferences are to personal and varying. It really
| depends on how it meshes with your style and the only way
| to really test that is to try it out.
| erfgh wrote:
| One of the basic tenets of Vim is that it is not an IDE. It is
| a text editor.
|
| By the way, if you need an IDE for Python then you're missing
| the point of Python.
| danjac wrote:
| I don't _need_ an IDE for Python. Of course I can use a plain
| text editor if I want. Hell, nano even.
|
| But right now, today, at work, I have a large legacy Django
| project to maintain, and it's kind of nice having little
| things like auto code formatting and linting to help me as I
| go and prevent me from making dumb mistakes and saving me a
| ton of time so I can focus on the problem at hand, not making
| the code look nice for review and I can hop between buffers
| to fix up the tests as I change the code.
|
| I can certainly just run black/isort/ruff what have you
| manually, or with pre-commit, sure. But it's more productive
| to be able to see changes as I work.
|
| Sure maybe I shouldn't be using Python, and maybe the
| original developers should have written it in Rust or
| whatever. Fine. But that's not what I'm being paid for.
| thenoblesunfish wrote:
| I was going to ask a similar question. This seems really cool,
| but since I already suffer with the complexity of vscode at
| work (but it's supported so is a net win), and I have my Vim
| setup that is small enough to (mostly) understand myself, why
| add a third thing which combines bad features of both? I'm
| responsible when it breaks, and it's complex.
| myth2018 wrote:
| My experience with vim differs drastically and I believe the
| root of most problems you had stems from trying to turn vim
| into an IDE.
|
| I won't argue at all. If you prefer IDEs, you go for it. But
| maybe vim and neovim aren't the best choices.
|
| I use vim as a text editing tool, solely. My .vimrc contains ~
| 20 lines. Use 2 popular plugins to help me finding and opening
| files, and one plugin to support editorconfigs (useful for
| sharing formatting rules with folks using vscode in the team).
| And I use makefiles or other scripts to call external tools
| (formatters, linters etc).
|
| There's probably a billion of plugins which could increment my
| productivity, but honestly I don't care much.
| konart wrote:
| >The amount of work needed to get a basic IDE up and running
| for your languages of choice, even for commonly used languages
| such as Python or Javascript, is far too much for someone who
| wants to get on with their day job or hobby coding and doesn't
| want to spend precious hours fixing obscure issues in Lu
|
| Can't agree with this at all.
|
| I don't think I've spent more than an hour in total setting up
| my vim config back in a day and maybe 1-2 hours in total when
| migrating to neovim (lua, packer etc) and then migrating to
| Lazy.
|
| Yes, you have to spend some time building your own DE, but at
| least now you know what it can really do, all the hows and
| whys.
|
| >Furthermore, the community does not have a good culture of
| documentation and learning
|
| Most of the plugins have docs that can be accessed via (neo)vim
| itself. Usually you can find all information there.
|
| >Setting up that plugin will require another plugin, and so on
| until you end up with a Jenga tower of dependencies...
|
| Not true at all. Only a few plugins have strong dependecies and
| even then you rarely come across a plugin that will have more
| than one dep.
| afarviral wrote:
| Haha 1-2 hours ... Maybe things have improved since 2018 but
| I was up to about 25 hours and still not satisfied with the
| results. That might be just being a perfectionist or coming
| from another IDE and trying to replicate something. But 1-2
| hours is not a reasonable amount of time to set aside to set
| up a truly usable custom ide with neovim to acquire the
| knowledge to drive it.
| konart wrote:
| >and still not satisfied with the results
|
| One can never be satisfied with the results. "There is no
| endgame", right?
|
| 1-2 hours is more than enough to get to work with
| autocompletion, syntax, filesystem explorer and a few more
| plugins for your convenience.
|
| >coming from another IDE and trying to replicate something
|
| This. Some people try to replicate IDEA or something like
| that. Obviously you can spend weeks trying to do this
|
| Hell, configuring https://github.com/mfussenegger/nvim-dap
| + https://github.com/rcarriga/nvim-dap-ui can take a week
| alone I guess.
| impalallama wrote:
| I've plugging away at NeoVim in my spare time trying to get
| it working and it took me a weeks before I just gave up and
| directly ripped someone else's LazyVim config to finally get
| things working in a state I'm happy with.
|
| Never mind that in order to get modern syntax highlighting
| and code completion you need LSP-Server, Mason, and Null-ls.
| The first which has per language dependencies and the 3rd is
| about to be archived.
|
| Also I don't know what world you live in but a tool a verbose
| and powerful as NeoVim you can spend hours just reading the
| documentation and getting a handle on the basics let alone
| configuring things to your liking
| konart wrote:
| null-ls is now archived so you don't need it (dark humor).
| Anyway - you needed it for linting\formatting etc.
|
| Modern syntax highlighting comes with treesitter, you don't
| need anything but theme that supports it.
|
| You also don't really need Mason unless you want an
| automated way of managing your providers. And LSP-config+Co
| is needed anyway - neovim\VSCode and other editors use it
| all the same.
|
| >Also I don't know what world you live in ...
|
| We were talking about building a config, not about learning
| every dark corner of it. You don't have to go much further
| than Packer's or LazyVim readme.md to get a grasp of what's
| going on. Things were much harder when it was vim and
| vimscript + some plugins.
| nicce wrote:
| > Most of the plugins have docs that can be accessed via
| (neo)vim itself. Usually you can find all information there.
|
| This was something which took some time for me to notice.
| There are some plugins which have the best documentations I
| have ever seen, but you need to read it from the Vim.
|
| Example of coc.nvim:
| https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt
| and https://github.com/neoclide/coc.nvim/blob/master/doc/coc-
| con... and
| https://github.com/neoclide/coc.nvim/blob/master/doc/coc-
| api...
| airtonix wrote:
| [dead]
| duckqlz wrote:
| I vehemently disagree with this. I find managing vs code
| extensions a nightmare and having to download them based on
| rating alone when there are 300 extensions for every query is
| untenable in a production environment.
|
| Furthermore if you want to customize a vsc extension to do
| something unique for your set up you have a whole new set of
| issues like finding the settings, documentation etc.
|
| Now if you can get over all of that it's still a bulky, slow
| and cluttered IDE that is constantly sending telemetry data and
| other nonsense around the web
|
| While I haven't tried LazyVim I would strongly recommend
| LunarVim to anyone new to the vim ecosystem. It installs fast,
| needs minimal set up and packages can be installed with a
| single line in the config or through packer. Most things work
| out if the box. But if they don't vim is so mature you can just
| ask chatGPT.
|
| Seems like ease of use is also the aim of lazyvim so I would
| not discourage anyone from trying this flavour as well.
|
| In the end it is whatever works for you.
| baq wrote:
| > I've been using vim for years, switched to neovim, and at
| this point I'm ready to throw in the towel and just use vscode
| for anything beyond simple text editing.
|
| I've done that a couple years ago after ~15 years of happy
| vimming. Still yearning for the text manipulation language
| combined with macros, but all the other gains significantly
| outweigh the worse editing capabilities.
| stavros wrote:
| What are the other gains you like?
| baq wrote:
| There's an extension for almost everything, right there in
| the UI.
|
| The fact that it's electron means there is native support
| for graphical preview in e.g. markdown, mermaid, plantuml,
| jupyter, etc.
|
| Relatively sane defaults. I haven't tweaked much of the
| editor except the color scheme and shell startup timeout.
|
| Zero messing around with language server setup. It's
| 'install extension' and go. Sometimes a window reload is
| required, but it restores the session intact, even with
| terminal history.
|
| Remote ssh (and WSL on windows) is super seamless. The way
| I've used vim was always ssh+tmux. Most of this is
| unnecessary with remote ssh in vscode.
|
| There's probably more but these are what comes to mind
| immediately.
| stavros wrote:
| That's a good list, thanks. I didn't know of remote SSH,
| that's a compelling feature.
| tlonny wrote:
| Sadly I completely agree with you. Whats even sadder is I
| recently made a post proselytizing the virtues of neovim over
| vscode.
|
| The final straw for me was discovering that vscode
| automatically updates packages and imports when moving files
| around a java project - something that doesn't seem possible in
| neovim despite hours of research and lua tinkering.
| ivlad wrote:
| I use vim for years, too but also I keep my .vimrc and, more
| recently, .vim in a git repo (using bare repos for dot files
| discussed here:
| https://www.atlassian.com/git/tutorials/dotfiles). So, getting
| a functional environment on a new system is close to running
| `git pull` once.
|
| I don't update plugins too often, because they work, but I also
| don't use too many. Based on my git history, I last updated a
| vim plug-in 11 months ago.
| weaksauce wrote:
| neovim extension + vscode is a great pairing. full neovim in
| normal and visual mode but you can call out to vscode anytime
| you want in those modes and you also get neovim extensions too.
| it's great and fast... worth a try.
| divan wrote:
| I had the same pain with NeoVim infrastructure, but
| AstroNvim/astrocommunity kinda solved it for me.
| radiKal07 wrote:
| I think it depends what you use it for. I use neovim for
| Flutter and it works great. If I want to do Android dev I need
| Android Studio.
| wheresmycraisin wrote:
| Strange, the only thing I need to do to get everything I need
| these days for a new language is install the right LSP provider
| and point vim to it. It used to be much harder, now it's closer
| to trivial.
| achenet wrote:
| I switched to Helix for this reason :)
| prmoustache wrote:
| I am using mostly default settings on my neovim setup for most
| plugins.
|
| I can't do much with vscode before also install tons of plugins
| and eventually setting them up. The only major difference to me
| is a central marketplace for vscode plugins instead of relying
| on github search engine+recommendations and being subject to
| telemetry I don't want.
| tzhenghao wrote:
| I also went through this phase about a year ago, then just gave
| up and went with VSCode for its superior out of the box
| experience. That said, I still fire up vim to read files in a
| server or make one line config changes, but everything
| else....VSCode.
|
| Related: Imagine having to remember the full scp / rsync
| command to sync source file(s) between your local machine and
| server, but it's just a drag and drop on VSCode.
|
| I've just come around to accept that we've been blessed with
| great hardware over the years, and it's a waste if those extra
| CPU / GPU cycles aren't translated to significant dev
| productivity improvements. I'd take slower (~ ms) editor paint
| times over saving hours messing with vim configurations.
| xdennis wrote:
| > Related: Imagine having to remember the full scp / rsync
| command to sync source file(s) between your local machine and
| server, but it's just a drag and drop on VSCode.
|
| What's hard about this? rsync -a dir/
| server:dir/
|
| I'd much rather have commands in my terminal where I can
| search for them later than do things visually and have no
| record of what I did once and how to repeat it.
| TonyStr wrote:
| Did you try LazyVim or any other neovim distro? Seems like
| you're complaining about configuring neovim from scratch, which
| is that pain that neovim distros aim to remove
| danjac wrote:
| Yes I did. And they work fine, until you need to do that one
| thing (e.g. "Set up Black to format on save"). Now you are
| back in that world of pain of figuring out which plugin needs
| to be installed/configured, only now you are figuring out
| someone else's way of doing it.
| shriek wrote:
| I think you're going about the wrong way if you're reaching
| to plugin for every simple thing in vim. Granted, I will
| say that vim has steep learning curve, it kinda gives you
| the power to do your _own_ way which is probably why you're
| seeing people do their own way. Also, you sort-of have to
| shift your mindset to embrace unix/shell as your IDE. But
| definitely reach out to other tools if it's not your cup of
| tea. Like many others have said, if you're trying to force
| it into something it's not then you're going to have a
| miserable time.
|
| As for your e.g. it would be a simple autocommand to run
| black that's installed in your machine on buffer write
| event in your neo/vimscript.
|
| `autocmd BufWritePost *.py !black %`
| ipaddr wrote:
| Have you asked chatgpt?
| JackJackJam wrote:
| LazyVim gives you Mason to install Black. You could use
| :MasonInstall black and restart Nvim to ensure black is
| loaded.
|
| Or if you want to have it automatically available on other
| setups, black is a builtin formatter in Null-LS, so you
| would just have to add "black" to your builtin list for
| your Null-LS configuration.
|
| Format on save is already set up.
|
| I've not used LazyVim. It took me 30seconds to look at the
| docs to see what was available. Yes, getting to the point
| where you have Mason, NullLS and LspConfig and the glue-
| plugins to make them work well together takes more than
| 30-seconds to set up, but once it is adding a new LSP or
| formatter takes no time at all.
| SanderNL wrote:
| I feel you, but I'd like to point the Finger in the other
| direction as well: (modern) programming is not sane. The tools
| and the environment are not made to be sharp and minimal, we
| are not using hammers and screwdrivers, we are _all_ using
| custom made chainsaws with hundreds of proprietary extensions
| and that's about as minimal as it gets. Sometimes it's actually
| more like wielding multiple nunchucks each covered with
| chainsaws.
|
| It's quite disappointing we need multiple layers of assistance
| to even begin our work. Syntax, autocomplete, go-to def. These
| sound like simple things, but are fiendishly difficult.
| Catering to all the various languages' their idiosyncrasies is,
| as you have noticed, a task beyond the community.
|
| If something like editing some basic pieces of code takes
| multiple man-years to facilitate and requires "language
| servers" I tend to look towards the environment that produces
| such monstrosities.
|
| Maybe we could stop complicating things so damn much?
| Impractical I know, but I won't give up an ideal just because
| it can't be reached (now).
| dbalatero wrote:
| Sorry what alternative are you proposing?
|
| Instead of syntax highlighting do you want... minimal syntax
| in languages? Instead of autocomplete do you just want to
| type the thing out manually? Instead of go-to def do you just
| want the code in 1 file?
|
| These things didn't require language servers historically,
| but LSP was an attempt to reduce "many editors re-
| implementing the same functionality many times" to
| "implementing the same functionality once and connecting many
| editors to it". This has a cost, and YMMV on the docs for
| getting LSPs set up, but I don't think I'd prefer going back.
| I don't use it, but it seems like VSCode has 1-click plugin
| installs for most of these LSP integrations, more or less?
| SanderNL wrote:
| Notice I said these features sound (and should be) easy,
| but they are not. The "intellisense" features themselves
| are fine as QoL improvements.
|
| It's the environment and the languages themselves that
| produces these "problems". I mean, let's say, Python. I
| just don't know what to say to you if you think sanity lies
| in that direction.
|
| I'm in the somewhat marginal Alan Kay camp and think
| computing can and should be reconsidered from scratch. I
| cannot prove we are on a dead end, but I have the strong
| sense that we are and I want to encourage other paradigms
| and ways of approaching development and computing in
| general.
| Arch-TK wrote:
| > The amount of work needed to get a basic IDE up and running
| for your languages of choice, even for commonly used languages
| such as Python or Javascript, is far too much for someone who
| wants to get on with their day job or hobby coding and doesn't
| want to spend precious hours fixing obscure issues in Lua.
|
| First off, editing Python (I am not familiar with Javascript
| enough to make any claims about it) doesn't require any
| sophisticated IDE and can be done quite proficiently in any
| decent text editor. I don't say this having written 3 lines of
| Python in my life, I say this with about 9 years of experience
| writing at least some python almost every single day. I think
| the powerful baseline that an editor such as vim or neovim
| provides is sufficient for most development tasks in most
| languages which aren't e.g. Java. That being said, integration
| of a syntax and type checker can be nice to make development a
| little bit more painless and tab completion can sometimes take
| something which might take 20 seconds to look up and verify and
| turn it into a 3 second task.
|
| Genuinely the initial up-front work for these features for a
| new language for me is to make sure a language server is
| installed in the path and add it to the list of active LSPs in
| my configuration file (one line change).
|
| This takes about a minute or two depending on how quickly your
| package manager can install the language server. Sometimes it's
| some obscure language where the language server isn't easy to
| find. There's a plugin for automating the installation and
| configuration of language servers. There are pros and cons to
| this plugin.
|
| > Furthermore, the community does not have a good culture of
| documentation and learning: too many plugins have very sparse
| docs
|
| This is still true about the lua API for neovim, that being
| said, once you learn it once, it stays mostly stable (and when
| stability breaks, it's mentioned publicly in the changelog) and
| leaves a lot of power at your fingertips. When it comes to
| third party plugins, a lot of them are just snippets of code
| which someone wrote and found useful, I think expecting a book
| on that is a bit excessive, a lot of the time you can just read
| the code or write your own more tailored version.
|
| > other online resources such as the Neovim subreddit are
| hostile to newcomers with "RTFM" a common answer
|
| My personal experience is with the neovim IRC channel which has
| generally been helpful. Although, again, if you learn the APIs
| which neovim exposes, a lot of questions can be answered by
| simply solving the programming problem which presents itself. I
| rarely find myself reaching for a support forum.
|
| > The community is also fragmented, with too many ways to do
| the same thing in the name of some platonic ideal of personal
| freedom over practicality.
|
| There's a difference between the editor having many ways to do
| the same thing and the community having written many solutions
| for the same problem. I would struggle to find a community of
| programmers who don't have the latter problem, but neovim
| doesn't really have the former problem to any major extent.
|
| > A simple question like "How do I set up Black with neovim to
| format my Python files on save?"
|
| ... is a programming question. What events does neovim expose
| hookpoints for to do things such as auto-formatting? There are
| many events but BufWritePre seems the most appropriate. How do
| you call black from neovim? Well the PSF official neovim plugin
| is probably a good starting point. How do you glue this
| together? Well, the on_attach function of the LSP for python
| seems like a good starting point.
|
| Something like:
| vim.api.nvim_create_autocmd('BufWritePre', { buffer = buffer,
| command = 'Black' })
|
| Now how you integrate this into your config is again a little
| programming problem in and of itself. But it's not really a
| complex programming problem. You are after all not trying to
| write some large complex and scalable system. You probably have
| all the tools necessary to organize your code well. I went with
| a highly functional approach which passes functions around
| everywhere but you may be more familiar or happy with another
| approach. The beauty of a neovim configuration is that you are
| the only person who needs to maintain it.
|
| I don't find any of this particularly time consuming. I
| normally don't touch my neovim configuration for months at a
| time as it continues working. I keep it tracked in a git
| repository and synchronise this across machines whenever I
| change something. My only personal annoyances with neovim are
| the fact that they haven't stabilized it yet and that package
| managers for neovim aren't as mature as e.g. something like
| cargo where you can use a lockfile. That being said. It's a
| powerful tool which requires a time investment to learn. But if
| you learn it, you can achieve really quite sophisticated things
| without needing to spend time looking for a very specific pre-
| existing solution. Usually to solve your problem you will need
| only a small handful of lines of lua.
|
| > In the meantime, I can just Ctrl+P and install what I need in
| vscode and be on my way in a few minutes.
|
| That's nice, but what if you want to run a different auto-
| formatter depending on the codebase? What if you want to
| automate this? What if you want to disable auto-formatting
| altogether in some cases? What if you want a configurable list
| of auto-formatters per codebase? With neovim I have this
| particular highly flexible feature working in ~20 lines of lua.
| How much would it take to modify or make a vscode plugin to
| implement these features?
|
| My most common issues with vscode were: lack of flexibility,
| lack of customizability, and lack of transparency. But these
| are expected tradeoffs of such a system. I understand why
| vscode exists with these tradeoffs but I am not willing to make
| them.
|
| I agree that neovim is not for people who are not interested in
| learning their tools. For people who want to just start typing
| code with whatever automations they are reasonably familiar
| with, and willing to accommodate any weird variations in the
| workflow which using a different tool might entail then vscode
| seems like a fine choice. But the main problem with neovim here
| is your own perspective of it. It is first and foremost a
| powerful text editor with an IDE building toolkit. It is not an
| IDE itself. You can use it to very quickly design a bespoke IDE
| which you like, without writing very much code. But you need to
| spend the time to learn its APIs first. If spending the time
| needed to learn it and then writing ~20 lines at a time to get
| it working how you want is not your cup of tea, then don't use
| neovim, it's clearly not for you.
| danjac wrote:
| > I agree that neovim is not for people who are not
| interested in learning their tools.
|
| That, right there, is one of the biggest turnoffs I have
| encountered from the community. The sheer disdain in that
| sentence alone.
|
| I learn many tools, and am deeply interested in learning
| them. That includes languages, frameworks, databases,
| infrastructure tools, operating systems, standards and
| protocols. I wouldn't be in this job otherwise.
|
| However, my time is limited. I have to be selective in what I
| spend time learning. Much of that choice is determined by my
| employer, project and other requirements. Free time left over
| for learning other things is even more limited.
|
| Learning another language and API and plugin ecosystem just
| so I can configure my editor? Maybe for some people, that's
| time well spent, but personally - having spent a fair bit of
| time with neovim to give it a fair shake - I realized that
| what I don't need is a perfect artisinal text editor, but a
| good-enough IDE that lets me do the things I'm either
| actually interested in, or paid to do.
|
| Vim as a simple text editor? Perfect, use it every day when
| dropping into a headless server to edit a config file or two.
| For an IDE? I don't love vscode, but for what I need, it's
| fine.
| Arch-TK wrote:
| > The sheer disdain in that sentence alone.
|
| I'm sorry that you read it this way, I think I could have
| written it differently. That being said, I don't agree that
| any of the things you listed are tools.
|
| Moreover, reading what you wrote in your original comment
| from a more negative stance, I also think it's easy to read
| it as disdainful but I chose not to read it that way. I
| would appreciate it if you were more positive in your
| reading of what I write.
|
| Tools in my mind are things like: a keyboard, your
| IDE/editor, your build system, your VCS, your userspace
| utilities (sed, awk, cat, ls, grep, etc), code formatters,
| code linters. I guess "tool" is probably not the best name
| for these categories given that I can understand why you
| would also call a library a tool but to bring in an analogy
| from woodworking, tools are things you use to make things
| from the materials (what would be libraries, frameworks,
| programming languages, etc).
|
| So having this distinction in mind, I don't think it's
| necessarily incorrect to state that you are of the opinion
| that what I would categorise as "tools" are not worth
| learning and (I should add) modifying.
|
| Again, I would like to stress, I am not trying to make any
| objective claims as to how correct your approach is. I am
| simply observing that there seem to be broadly two
| categories of programmers. Those who feel like investing
| time in learning and writing/modifying "tooling" is
| worthwhile and those who do not. I feel like you fall into
| the latter category.
|
| In this sense, I don't think vim, neovim, or emacs are
| really appropriate for people who don't feel like time
| spent learning and writing or modifying (let's call them)
| peripheral tools is worthwhile. Whereas you feel
| constrained by the need to understand what to you might
| feel are "irrelevant details" (the need to know the API)
| about neovim, I feel constrained by what you might feel are
| "irrelevant details" (the need to adjust to a specific
| workflow which I might not be used to, the need to
| constrain myself to a specific set of plugins) about
| VScode.
|
| That being said, I will say again, to claim that vim takes
| a lot of time to use and configure is simply wrong. But if
| you feel like having to learn an API to use an editor is a
| waste of time then it would explain why your experience
| might be like this. It's not possible to use vim quickly
| without having learned the API. Likewise, I feel like
| having to adjust to a specific way of editing as envisioned
| by a specific company and a specific plugin writer is a
| waste of my time and it would explain why my experience of
| VScode is that it takes a lot of time to configure and use
| whereas your experience is different. This doesn't mean
| that VScode takes a lot of time to use and configure, just
| that it's fundamentally not for me.
|
| I hope the above clarifies things. I would be happy to
| agree on a different term than "tool" or a clearer way to
| distinguish between e.g. an IDE and a library or framework.
| danjac wrote:
| > Again, I would like to stress, I am not trying to make
| any objective claims as to how correct your approach is.
| I am simply observing that there seem to be broadly two
| categories of programmers. Those who feel like investing
| time in learning and writing/modifying "tooling" is
| worthwhile and those who do not. I feel like you fall
| into the latter category.
|
| I use zsh, with customizations. I know git, and
| mercurial, and a few other VCS I've forgotten. I know my
| way around the Linux toolkit. I can configure a Python or
| frontend or Go environment with whatever linters and
| formatters and pre-commit and so on and so on. I have a
| fat repo of dotfiles. Hell, I use vim whenever I need to
| work on headless servers or the odd config file and the
| like. Works fine, in that use case.
|
| Every time I learn or modify a tool, I look at whether
| there is a net benefit in learning it, whether it makes
| me more productive. Zsh shortcuts for example are tiny,
| but I get a nice little productivity boost that adds up
| to many hours over time.
|
| I have spent the hours learning and configuring neovim,
| but run up against that point where that time spent is no
| longer yielding that benefit, compared to just using
| vscode and putting up with its issues.
|
| So, I chose one tool over another. But it's a
| generalization to say I somehow don't think learning
| "tooling" is worthwhile.
| Arch-TK wrote:
| Okay, so it seems you certainly fall into the category of
| people who generally find it worthwhile to learn and
| configure/modify tools. So I really don't understand how
| you came to the conclusion that neovim and vim are not
| worth the time.
|
| Neovim takes a lot less time (weeks to months) to learn
| than something like git (months to years), while I know
| both very well, I find that I am more often interacting
| with my text editor than I am with git.
|
| It seems to me that the tradeoff of using something like
| VSCode, unless it perfectly matches your particular
| workflow, is much more friction than dealing with git vs
| something else.
|
| To that end, if you have given neovim a chance and
| learned it, then I struggle to see how you had problems
| with something like e.g. making :Black run automatically
| before the file is written.
|
| Autocommands are a fundamental vim feature, one of the
| most important for vim related automation aside from
| rebinding. Something you will have encountered as soon as
| you search for "vim how to do X when Y." Figuring out
| that the PSF black vim plugin is a good option for a way
| to run black from inside vim is a matter of a 10 second
| google search. I can understand this being a potentially
| difficult problem if you really had no neovim
| configuration experience, but if you have learned neovim
| then this really is a single line addition to your
| on_attach which you would have already had to configure
| for the python language server of your choice.
|
| And even then, the black documentation page explicitly
| shows how to use vimscript (which can be embedded in nvim
| lua syntax using vim.cmd, again, a basic neovim feature
| you would have encountered in any guide to configuring
| neovim) to achieve this in 4 lines.
|
| I use neovim because it eliminates friction. Whenever I
| do something and find myself repeating an editing or
| reading adjacent task and making mistakes I think to
| myself: "how can I solve this once and for all?" I sit
| down, fix it in neovim and lua in 20-40 minutes. How do I
| justify the time investment? The 40 minutes (or hell,
| even if it took 2 hours it would still be worth it)
| investment once every couple of months to improve some
| aspect of my workflow keeps the friction down and the
| reduced friction more than makes up for the 40 minutes or
| 2 hours of lost time because I would lose much more time
| on frustration and lack of motivation.
|
| This friction doesn't affect everyone as much as it does
| me, which is why I notice other people, less affected
| than me, don't find dealing with learning and
| configuring/modifying/writing tooling to be worthwhile.
| But again, what you wrote indicates to me that this kind
| of friction _does_ matter to you.
|
| So my question is, how do you justify the friction of
| VSCode (as you yourself put it, VSCode isn't perfect)
| when you have tools such as vim, neovim, emacs, or
| whatever else that are designed to help reduce friction
| for a modest but steep initial learning curve.
| sgarland wrote:
| >> I agree that neovim is not for people who are not
| interested in learning their tools.
|
| > That, right there, is one of the biggest turnoffs I have
| encountered from the community. The sheer disdain in that
| sentence alone.
|
| > I realized what I... [is] a good-enough IDE that lets me
| do the things I'm actually interested in...
|
| By your own admission, you're not interested in learning
| tooling.
|
| No one reasonably claims that vim is easy. If you don't
| want to learn it, then don't, but don't take offense when
| someone points this out.
| rcarr wrote:
| This. As someone now in their 30s who didn't learn to code
| until their 20s, I've tried several times with vim/emacs but it
| just isn't worth the hassle because I just don't have the free
| time anymore to endlessly fuck about with config files and
| learning the ins and outs of each program. So many of the
| absolute best seem to use one of vim/emacs but then so many of
| the absolute best started coding when they were children or
| teenagers with time on their side. It would be a lot easier if
| they could develop some kind of easy way to switch between
| these pre made configs but last time I tried chemacs and
| cheovim I couldn't get them to work as expected. I think emacs
| has built this feature or something similar into the release
| coming out soon so I might give it another go in a year or two
| but I dunno.
| johannboehme wrote:
| hmm.. but you also spent a lot of time to learn programming.
| Why not invest some time in the use of professional tools? If
| you master an editor like vim, you'll never need to spend
| time to learn additional IDEs. In the past i needed to learn
| VSCode, Eclipse, IntelliJ, XCode, Visual Studio and some
| other niche IDEs. All have very different menu structures and
| keybinds. Just to unify that was worth the time learning vim.
| rcarr wrote:
| Because I don't need to? I honestly think it would be
| easier to follow along with a tutorial for whatever
| language I'm using in any of those editors you've mentioned
| than one for Vim or Emacs.
| godelski wrote:
| I've never tried neovim, but have been a vim user for over a
| decade and never really dealt with problems where I need to
| touch vimscript at all. Is neovim that clunky? Is it plugins?
| cayley_graph wrote:
| No, it's not clunky. The plugin community is just a lot more
| active, imo. I personally avoid plugins wherever I can, since
| I prefer to write my own little Lua scripts that do stuff the
| way I like. (And I quite like the Lua API-- the lua plugins I
| use seem be a lot faster/less janky than the vimscript ones,
| as well? not sure)
| kzrdude wrote:
| datapoint: lazyvim has had 127 releases since it was first
| released. Which was in november or something like that,
| maybe just 7-8 months ago.
| cayley_graph wrote:
| Yeah, likely to update all the plugins it uses or
| something. I don't use it so unsure :)
| kzrdude wrote:
| It has a lockfile, so it feels relatively sane, I can
| update only when I have time. It's been working well.
| danjac wrote:
| My feeling is that neovim per se, as a piece of software, is
| fine, but that it belongs to one of those developer
| communities that prizes freedom and infinite configurability
| over the day-to-day practicality of getting things done. So
| something like LSP integration has too many ways to do it
| across too many plugins.
|
| If you are deeply involved in the community and are willing
| to put in the time, sure, you could probably build something
| superior to vscode. But the time invested to get there might
| not be worth the marginal productivity gains.
| prmoustache wrote:
| > But the time invested to get there might not be worth the
| marginal productivity gains.
|
| Most of the time invested has been invested by other
| people. My own nvim setup is just a curated list of other
| people suggestions. I haven't put a lot of research into it
| and I still find it easier/superior to use than some other
| editor/ide like vscode.
| marcusramberg wrote:
| Did you actually try LazyVim? It makes this whole process a lot
| easier, with pre-cooked extras for most popular languages.
| danjac wrote:
| Yes I did, and no it didn't really help. Sure it was a much
| slicker starting point, but when I needed to do a bit more
| (ie. configure a formatter) it just added more obfuscation
| than anything. The "pre-cooked" part does help with setting
| up linting, but formatting...you're kind of on your own (if
| you search the source you can find an example with prettier
| but you will still need to add your own integration for
| anything else).
| anyonecancode wrote:
| Vim, the program, I find useful in limited cases. Vim, the
| keybindings, I find I try to use everywhere -- from the browser
| to every IDE I ever work in.
| p-e-w wrote:
| > The amount of work needed not only to get a basic IDE up and
| running for your languages of choice, even for commonly used
| languages such as Python or Javascript, is far too much for
| someone who wants to get on with their day job or hobby coding
| and doesn't want to spend precious hours fixing obscure issues
| in Lua.
|
| "This airplane is the choice of professional pilots! The first
| thing we advise you to do is turn the yoke upside down, it's
| much more ergonomic like that. Also, you probably want to rip
| out the altimeter and replace it with a custom one that has
| more features. And bring your own GPS unit and tape it to the
| windshield, because this plane doesn't have one by default. And
| of course, remember that unlike in your car, 'left' actually
| means right in this plane. This is the professional way. Ah
| yes, when you fly over Canada, you will see a blinking warning
| sign telling you that you're out of fuel. That's just a small
| glitch caused by metric/imperial confusion. It has been known
| for 23 years but we haven't quite gotten around to fixing it
| yet. Don't worry, this plane is still excellent for
| professional pilots. If you feel otherwise, you are probably
| not a real professional."
| dcow wrote:
| This is why I strictly adhere to vanilla Vim.
| danjac wrote:
| I use vanilla vim when I have to ssh into a server and work
| on some config files. As such, I much prefer it to nano,
| and it's installed, or easily installable, on any Linux
| server.
|
| For that use case, it's absolutely great. No complaints.
| rajamaka wrote:
| I spent years and years enjoying using vim for the same
| purpose when I was a sysadmin. I was absolutely disgusted
| beyond belief to find out people actually used it as
| their daily IDE when I became a developer.
| p-e-w wrote:
| You mean the one with syntax highlighting disabled by
| default?
| dcow wrote:
| Yeah. I actually find that no highlighting in some ways
| helps you understand the language better. Because you
| have to parse it, not rely on the highlighting to do it
| for you. When I was learning Rust, I spent a year writing
| Rust in vanilla vim which is by some accounts insane. But
| I did it for the uh immersion. And I'm happy with the
| result.
|
| I do use Zed for working on projects when on my home
| turf. It's just that I've sworn off wasting time
| configuring Vim everywhere. That too is advantageous
| because you have to have a much more thorough knowledge
| of the vim tool instead of relying on plugins to make it
| work for you. And vim is everywhere.
| klardotsh wrote:
| Related prior discussions on this topic:
|
| - https://news.ycombinator.com/item?id=12886067 -
| https://news.ycombinator.com/item?id=23902124
| gsinclair wrote:
| The thing is, using a plugin like 'surround' Is just so
| nice. When you've chosen to use a pleasant and powerful
| editor, I don't see the benefit in depriving oneself of
| further pleasure and power.
| globular-toast wrote:
| Let's not forget that vim isn't really designed to be an IDE,
| though. People just like the editor so much they want an IDE
| with it. Unfortunately using vim itself for that is the wrong
| choice. The correct choice is emacs with evil mode.
| hju22_-3 wrote:
| The correct choice is to instead use something that doesn't
| require a really long time to both learn properly and
| modify until it's decently functional, even including
| premade distributions for it, and just using something to
| get the job done so that, you know, you get the job done
| instead of preparing to get it done and not getting it
| done.
| nextlevelwizard wrote:
| More that you want to carve a bowl out of wood. Vim is like a
| knife that with some modifications you can turn into a
| carving knife. VSCode is like a chainsaw that has attachments
| that have been made for it and it also has bowl carving
| attachment.
|
| If you don't know your tools, then you can easily mess the
| knife modification and not end up with a carving knife. The
| chainsaw with ready made attachments is way easier to get
| going, but in return you have to carry the chainsaw with you
| and if there are any problems with the tool itself you
| probably aren't going to be able to fix or modify it
| yourself.
|
| So it is more like trading initial speed with more precision,
| but also being able to do more after the initial learning
| curve.
| DropInIn wrote:
| Nah vs code is a multitool with both a hook blade (the
| knife younuse for carving out a bowl) And a chainsaw....
|
| Slightly more unwieldy in that specific narrow use case
| than a plain hook knife but you don't need a second tool to
| cut the log you take the wood for the bowl from...
|
| In other words, it's a tool that let's you do near anything
| with minimal modifications whereas vim is a tool that
| requires significant modification just to do Any task other
| than looking at it.
| p-e-w wrote:
| > The chainsaw with ready made attachments is way easier to
| get going, but in return you have to carry the chainsaw
| with you and if there are any problems with the tool itself
| you probably aren't going to be able to fix or modify it
| yourself.
|
| This is where your analogy breaks down for me. The
| "chainsaw" (VSCode) is absolutely perfect for the tasks I'm
| using it for. When I write Python code, the Python
| extension gives me exactly what I want. That's because the
| environment it creates has been fine-tuned based on
| feedback from thousands of users with similar requirements
| to my own. There's no need for me to modify anything, any
| more than I modify my car or my trousers. It's simply ready
| for me to do professional work, and whenever I have special
| requirements, I know that I will find an extension that
| caters to them also. I don't need or want to reinvent a
| wheel that has been invented hundreds of times already, and
| polished to perfection through more man-hours than I could
| ever hope to invest myself.
| nextlevelwizard wrote:
| It does not break down.
|
| Chainsaw is very good at doing chainsaw things.
|
| If what you need to do is cut down bunch of trees then
| chainsaw is exactly what you need. No one in their right
| minds would start with a knife and start building it into
| a saw and then attach a motor to motorize it. Mind you we
| were carving a bowl, but as per Internet argument you
| completely dismissed the use case and inserted your own.
|
| If VSCode does exactly what you need out of the box
| exactly how you want it to do it, then you are set and
| you should use VSCode.
| jahsome wrote:
| I can think of a few YouTubers who would and probably
| have done just what you described. Now that I say that
| though, I realized you used the phrase "right mind" and I
| don't think I'd count many if any in that cohort.
| oblio wrote:
| The problem is that Vim can be used to create config
| files and source code files among other things. VS Code
| can be used for very much the same things.
|
| The output of both tools is practically the same thing.
|
| The niche of things Vim can do and VS Code can't is tiny
| and constantly decreasing.
| xcxcx wrote:
| You can run Neovim on a remote server through ssh. I
| think that's the main difference
| oblio wrote:
| VSCode can do that with the remote extensions.
| skydhash wrote:
| It's always been like this. Vim is an editor, and so is
| Sublime Text, Emacs, VS Code, Geany, Kate, Notepad++, and
| more. What sets vim apart is its ubiquity (it's been on
| every Linux box I touched) and its philosophy of editing
| text (modal editing). Apart from that, it's a matter of
| preferences and practicality.
| slowmovintarget wrote:
| Emacs is a lisp environment, with an editor housecoat on.
| xeyownt wrote:
| You get exactly the same functionality with (neo)vim
| plugins.
|
| Only difference is that because vim has been open-source
| for decade, there are many many more plugins, and hence
| the choice is harder to make. VSCode also helped improve
| the (neo)vim experience (e.g. language servers)
|
| Comparing VSCode and Vim is like comparing a standard
| calculator with an RPN one.
| p-e-w wrote:
| > Only difference is that because vim has been open-
| source for decade, there are many many more plugins
|
| No, the main difference is in the _quality_ of plugins,
| not in how many there are.
|
| For example, Rust-Analyzer provides an official VSCode
| extension, which is professionally maintained by members
| of the Rust core team. The extension is part of the Rust-
| Analyzer project itself, and can be installed with a
| single click, at which point it just works.
|
| For Vim, you have to manually download (and update) the
| Rust-Analyzer binary, install a third-party plugin,
| configure them to work together, and hope (1) that the
| whole thing doesn't break when the plugin or the language
| server is updated, and (2) that this concoction provides
| a tiny fraction of the functionality that the official
| VSCode extension does.
| cgeier wrote:
| > No, the main difference is in the quality of plugins,
| not in how many there are.
|
| I don't think that is true. If you browse the vscode
| marketplace and search e.g. for python [1] you literally
| get hundreds of plugins. If you scroll down only a bit,
| you quickly end up at plugins that only have a few
| hundred to a few ten downloads. I highly doubt that the
| quality of those plugins is better than the plugins for
| (neo)vim.
|
| For your Rust-Analyzer Plugin example: I can install
| Rust-Analyzer with Mason in a few seconds as well and
| then (if you have lsp-zero [3] installed) it also just
| works(tm).
|
| But I agree, keeping a vim configuration up to date is
| akin to a hobby (which I by the way enjoy quite bit).
|
| [1] https://marketplace.visualstudio.com/search?term=pyth
| on&targ... [2] https://github.com/williamboman/mason.nvim
| [3] https://github.com/VonHeikemen/lsp-zero.nvim
| jahsome wrote:
| I'm a vim user, but only because of the keybinds. I use
| VS code an equal amount because I often get too
| frustrated trying to wire the disparate vim tools. The
| never ending fiddling and 30-step process to get the
| equivalent of one click in vs code is exhausting.
|
| The people who _enjoy_ the toil seem to truly struggle to
| comprehend that someone might not want to spend hours
| upon hours learning how to get things working, only to
| immediately forget.
| skydhash wrote:
| > The people who _enjoy_ the toil seem to truly struggle
| to comprehend that someone might not want to spend hours
| upon hours learning how to get things working, only to
| immediately forget.
|
| One of the tips in The Pragmatic Programmer is "Achieve
| Editor Fluency", wherever it's Vim, VS Code, or Sublime
| Text. I use IDEA for java code because in my job, I
| browse code more often than I edit it, and IDEA is nice
| for that. I also use WebStorm for the JS part because
| it's also good for that. But I invested my time into VIM
| because I can do everything above with it and even more.
| I don't want my editor to become an IDE, I want it to be
| powerful in editing and allow for integration, as there
| are slews of tools that work with code and text.
|
| You should invest in your tools, be it Vim or VS Code. I
| chose Vim and Sublime Text because of their speed, and
| JetBrains' IDEs because of their code analysis engine.
| You may have different criteria, but try to follow the
| tip.
| jahsome wrote:
| I do exactly what you described and indicated that
| clearly in my post.
|
| What I'm perturbed by are the people who take it to
| extremes, and are happy to spend hours a week tweaking
| things, and can't fathom someone else might not enjoy
| doing the same.
| oblio wrote:
| > The people who _enjoy_ the toil seem to truly struggle
| to comprehend that someone might not want to spend hours
| upon hours learning how to get things working, only to
| immediately forget.
|
| It's worse than that, it's a religion. Many of them truly
| seem to believe they're achieving a higher "hacker rank"
| or something, while most of it is just tedium and very
| low level learning.
|
| It's rarely learning huge, game changing concepts.
| Frequently it's just chasing obscure docs to obscure
| forums to obscure repos for stuff some PhD student half
| baked a decade ago on their way to their biochemistry
| thesis.
|
| Guess what, I work in DevOps, that's just my dayjob,
| anyway, I don't want to do it as a hobby in Vim, too :-))
|
| And I say this as an "also Vim user". I.e. I use Vim and
| I've used it for more than a decade, just not
| exclusively, best tool for the job and all that.
| cayley_graph wrote:
| For what it's worth, the 'VSCode-level' functionality in
| my init.lua has probably required roughly a few hours of
| maintenance over the ~7 years I've been using Neovim. The
| LSP setup is just a matter of finding a plugin manager
| (or not), installing the lspconfig plugin, pasting in the
| config from the README, and inserting a single line that
| contains the name of the language server you want to
| configure.
|
| It can definitely lead you down all sorts of twisty paths
| if you look at other people's elaborate configs and
| decide to do that sort of stuff yourself but it's very
| pleasant/low-maintenance if you stick to the basics
| (meaning roughly what people do with VSCode). It takes me
| roughly a few minutes to configure Neovim for a new
| language :)
|
| (Of course, there's some other stuff in my init.lua that
| I've put there for fun, like clipboard and window
| management scripts, but that's not strictly necessary.
| I've spent a bit more time figuring out the Lua API to
| write these, but I personally think it's worth it for the
| extra ability to mold the editor to my needs).
| UltLRS wrote:
| There is a vim plugin for VS code. It gives you vim
| keybindings. https://marketplace.visualstudio.com/items?i
| temName=vscodevi...
| 3836293648 wrote:
| That's just plain untrue. Vim always kept its own rust-
| analyzer binary and prompted me to update it. I use emacs
| now and _actually_ have to update it myself
| laeri wrote:
| I agree with your main point, you have to do quite a few
| things to configure these plugins and some of it is not
| straightforward.
|
| However, I program rust using the lunarvim default
| configuration for vim and it has been very
| straightforward. I have all features I need to program
| comfortably and I didn't need to configure anything, the
| defaults were good enough for me. So that doesn't mean
| that vim cannot have the same easy of use if there exists
| some sane default configuration you can just install. I
| am happy with it and not going to change to vscode or
| something else.
| cayley_graph wrote:
| FWIW, I just needed to install the default nvim-lspconfig
| plugin (it's provided by the Neovim maintainers, and it
| doesn't do anything besides provide default LSP server
| configs for a lot of languages to the builtin Neovim LSP
| client), paste in the keybinds recommended by the README,
| and call lspconfig.rust_analyzer.setup in init.lua.
| Configures itself to start whenever rust_analyzer is in
| PATH. Seems to work well enough! I don't think it's
| missing any functionality.
| palata wrote:
| > This is where your analogy breaks down for me. The
| "chainsaw" (VSCode) is absolutely perfect for the tasks
| I'm using it for.
|
| Then just use the chainsaw... and accept that the knife
| may be absolutely perfect for the tasks of somebody else.
| mgdlbp wrote:
| > Canada ... out of fuel
|
| Referencing the Gimli glider. But does vim have any analogous
| issue? In matters of technical correctness FOSS is usually
| the more exacting. You won't find a 1 TB hard drive full at
| 931 GB of used space on Linux, for example.
| p-e-w wrote:
| This was supposed to parody how some of Vim's default
| shortcuts just flat out do not work on non-US keyboards,
| because e.g. typing [ requires pressing AltGr+8 on German
| layouts, but Ctrl+AltGr+8 is _not_ the same thing as
| Ctrl+[.
|
| And yes, it was also a reference to the Gimli glider.
| cerved wrote:
| us international with dead keys is superior
| pohuing wrote:
| And I thought I was going insane when I tried vim. No
| wonder the thing felt horrible to use, it literally
| doesn't work with my pc?!?
| krab wrote:
| What about reserved blocks in ext filesystem? With default
| settings, it will say 5 % free but writes will fail if
| you're not root.
| quickthrower2 wrote:
| Are we talking about Gyrocopters here?
| divbzero wrote:
| Was that expressly written to parody Vim? If so, this line is
| particularly spot on:
|
| > 'left' actually means right
| p-e-w wrote:
| > Was that expressly written to parody Vim?
|
| Yes. The advice to turn the yoke upside down is supposed to
| reference remapping Caps Lock to Escape, without which Vim
| destroys your pinky on a standard keyboard. But it's the
| choice of professionals, so what can we do?
| eptcyka wrote:
| What about control+c? Also, I've never used vim without
| remapping `jj` to <Esc>.
| distcs wrote:
| Ctrl+C and Esc do not behave the same in all contexts.
| The correct replacement for Esc is Ctrl+[.
|
| What if you need to type `jj`? Not uncommon to do so
| while writing math or physics papers. a_{jj}
| sidibe wrote:
| Spacemacs defaults to fd, I don't think I ever
| accidentally left insert mode with that.
|
| Happy vscode user these days. If I find myself fiddling
| with an editor it's a huge red flag to me that I hate
| what I'm working on.
| distcs wrote:
| I still don't understand how these mappings are good.
|
| What if you need to type "fd" in insert mode? Like fd0,
| fd1, etc. Isn't that going to be a pain? Do you never
| have to type "fd"?
| wzdd wrote:
| There is a timeout on multi-key mappings, so if you need
| to type fd0 you type f, wait 'timeoutlen' (1 second by
| default apparently), then type d0.
|
| That's a pain, but it doesn't come up often. In return
| you get quite a lot of functionality (due to vim being
| modal) without having to move your fingers beyond the
| letter keys, which is quite relaxing.
| turboponyy wrote:
| fd sounds much worse as now you can't jump to d
| characters.
| gsinclair wrote:
| False. The fd mapping would only apply in insert mode.
| Jumping to d only occurs in normal mode.
| [deleted]
| turboponyy wrote:
| Oops - you're correct, of course.
| krab wrote:
| Not using this personally but there can be a timeout, or
| you do jk<backspace>j. Fine if the letter sequence is
| rare enough.
| roland35 wrote:
| I think jk is a bit easier to type but they both work
| well!
| dbalatero wrote:
| Not sure why you're getting downvoted, repeating the same
| key with the same finger is slower than dropping two
| fingers down onto `jk`.
| cayley_graph wrote:
| I'm playing into the joke here, but on most terminals,
| alt + <key> will actually be sent to the program as <esc>
| + key. You can use this to avoid pressing escape in
| Neovim.
| xeyownt wrote:
| Interesting tip too! Need to find the right combination
| however, I noticed that Alt-L might be a good one (no
| side effect it seems).
| greggyb wrote:
| That will move your cursor to the right by one character
| after exiting insert mode.
| cayley_graph wrote:
| Entering + exiting insert mode with i and Esc moves your
| cursor to the left by one, so I suppose this neutralizes
| it?
| madsr wrote:
| +1. I mainly use this approach. If your next intended
| move is to go to the next line, Alt-J will exit insert
| mode and go to the next line immediately. Also the same
| for Alt+w/W/b/B, Alt+o, Alt+0, etc etc and it's just a
| matter of using your left thumb at the same time as
| navigating.
| divbzero wrote:
| Nice, I didn't pick up on that one. And I do have Caps
| Lock mapped to remapped to Escape haha.
|
| If any vim enthusiasts haven't read this history before,
| this article [1] provides a good overview of how ex/vi
| came to be. The photo of the Lear Siegler ADM-3A keyboard
| used by Bill Joy largely explains the odd choice of keys.
|
| [1]: https://twobithistory.org/2018/08/05/where-vim-came-
| from.htm...
| stavros wrote:
| But remapping Caps Lock to a combination Ctrl/Esc is so
| convenient, regardless of Vim!
| tambourine_man wrote:
| Aaaactually... professionals map jj to Esc.
|
| JJ Abrams disagrees, though.
| arghwhat wrote:
| Trick for those wanting caps lock to be compose instead:
| ctrl-c also works as escape, and has historically been
| slightly faster due to sidestepping the escape timeout.
| xeyownt wrote:
| Wow super useful, didn't know that.
|
| EDIT: removed comment about cursor behavior of ctrl-c,
| which comes from my vimrc config ^^ Turns out I learned
| that long ago, but never used it :-D
| marcusramberg wrote:
| I've remapped caps lock to ctrl with chords and escape
| when clicked alone. Feel it's the best of both worlds :)
| yoyohello13 wrote:
| Remapping Caps Lock to Ctrl is a life changer in any
| environment. Seriously, just try it. It makes a useless
| key actually useful.
| recursive wrote:
| But I use caps lock. Sometimes.
| dmi wrote:
| I've been using Ctrl-[ instead of Esc for so long that I
| forget that a lot of people don't know about it. This may
| not be convenient on non-English keyboard layouts.
|
| More alternatives:
| https://vim.fandom.com/wiki/Avoid_the_escape_key
| mvanbaak wrote:
| small fun fact: I switched to this when the escape key
| was taken from me (thanks again _NOT_ apple) After
| switching to a newer MacBook that has the escape key I
| did not start using that again, but stuck to the Ctrl-[
| as it just works.
| nextlevelwizard wrote:
| Maybe I've just grown blind to this, but how is this
| relevant? Unless you mean that you _can_ define that
| raverbashing wrote:
| Emacs more likely since the bug is 23 yrs old and the
| gatekeeping
|
| But yeah I agree with the sentiment of parent OP
| oblio wrote:
| [flagged]
| raverbashing wrote:
| Exactly, use arrow keys and be happy, I do it too
|
| (I wouldn't blame vim so much, but more the vim
| greybeards who think they're still using a 70's terminal)
| oblio wrote:
| I actually switch back and forth and I've thought many
| times about remapping u and l and j and k... you know
| what, maybe I should just bite the bullet.
|
| HUJK instead of HJKL, basically WASD moved to the right
| :-)
| cerved wrote:
| the bindings are by far the best thing about Vim
| oblio wrote:
| [flagged]
| schrectacular wrote:
| Do you still use a QWERTY keyboard? Or have you just been
| beaten over the head with them so long that Stockholm
| syndrome is super strong?
| oblio wrote:
| Did you read my original comment? I literally mentioned
| QWERTY as another example of backwards compatibility
| screwing everyone over.
|
| I use QWERTY because I have to, I don't like it and I
| can't do much about it in practice. People frequently
| defend Vi's HJKL vehemently - just like - if I'm not
| mistaken - you, presenting it as a superior option for
| some reason.
| geysersam wrote:
| As if there are "studies" backing the claim that arrow
| keys are easier to use for navigation than the home row
| keys...
|
| Personally I don't want to move my hands from where I'm
| writing to the other side of they keyboard just to move
| the cursor.
| m45t3r wrote:
| Like many things in our field, we try to justify our
| choices, and because generally folks in our field holds
| high standards about themselves, we should justify as the
| only right way. What in reality, it is all about user
| preference.
|
| In the end, use whatever your feel most comfortable. I
| hate the VSCode interface and all of those
| notifications/popups and general slow interface, but I
| can understand who doesn't care or think that even with
| those VSCode is still more efficient for them. I also can
| completely understand the issue that folks say when they
| lost a long time tuning their Neovim configuration to
| their preferences, considering that I just have done so.
| But I still prefer neovim to VSCode nowadays, and not
| everyone needs to think the same, and this is fine.
| oblio wrote:
| I take it you've never played a fast game with keyboard
| controls? :-)
|
| They could have laid out the arrow keys WASD style. One
| up, one mid-down, two to the sides.
|
| Nobody said they had to use dedicated arrow keys. Just
| lay them out like a normal human being. Whatever key for
| up should be up, whatever key for down should be down,
| whatever key for left should be to the left, whatever key
| for right should be to the right.
|
| HUJK, for example. WASD is the standard example.
| turboponyy wrote:
| In the specific case of text editing with vi bindings,
| having up and down on the same row is more convenient,
| since you don't have to move your fingers to perform
| linewise vertical motions (compared to a standard WASD
| "grip"). Navigating within a line using left and right is
| uncommon when using vi bindings, since there are usually
| better ways to jump between locations within a line, so
| it makes more sense to pay the cost of having to move
| your fingers in this case.
|
| Not only that, but I posit that any context that uses vi-
| style binds uses vertical motions much more often than
| horizontal ones (pagers, editors and other applications
| with vi bind ports, etc.).
|
| As for games, whilst WASD might be more intuitive, it is
| technically inferior in tactical shooters, where having
| the W and S keys on the same column means your
| (admittedly somewhat rarely used) forward-motion counter
| strafe will always have an inherit delay due to having to
| move your sole finger dedicated to those two keys. In
| this case, vi-style ASDF is again marginally better.
|
| That being said, your gripe seems to be overstated, if
| this is your biggest problem with vi-style binds.
| oblio wrote:
| > That being said, your gripe seems to be overstated, if
| this is your biggest problem with vi-style binds.
|
| I like their composability and I'm generally fine with
| them, the real Vi problem is just... bad embeddability.
| Almost none of the apps that I'd want to use with Vi
| bindings support them to a native Vi level (Firefox - it
| used to support them well but then they killed the
| extensions; shells with Vi support only have half baked
| support, same for IDEs, let alone stuff like Outlook and
| whatnot :-) ).
|
| Their lack of ubiquity will always doom them to a niche
| thing used by devs and sysadmins, sometimes, and only by
| some of them.
| mdtusz wrote:
| Check out Qutebrowser. It's almost entirely usable from
| the keyboard only using vimlike bindings. Lags behind
| chromium/qt a bit for the actual engine, but these days
| it's totally usable and has become my daily driver.
| turboponyy wrote:
| This is a point I completely agree with. Firefox is the
| perfect example of a context where you would want vi
| binds, but the implementation ends up being half-baked.
|
| The fun part is when web apps like GitLab, GitHub and my
| email provider provide their own keyboard-centric, vi-
| style navigation layer, and I have to compromise between
| either using my browser extension's vi layer or the web
| app's one.
|
| Nyxt and qutebrowser try to tackle this by offering a
| native, keyboard-centric, vi-style navigation model -
| though neither is (yet) a full-featured replacement for
| Firefox or Chromium-based browsers.
|
| For IDEs, I find the emulation to be alright for basic
| editing, falling apart soon after. There is an
| implementation for VSCode that is actually pretty good,
| as it makes use of Neovim as a backend server - though,
| it's of course not perfect, and customizing it is a pain
| I imagine.
|
| Perhaps somewhat ironically, Emacs's evil mode is the
| best vi layer implementation I've used - probably mostly
| because customizing it in elisp is much nicer than
| interfacing with arcane vim APIs.
|
| The vi emulation really is only as good as the
| implementation. The problem is that it has to be
| reimplemented for every context, and made to play nicely
| with the limitations and edge cases of said context. This
| is, of course, a lot of work.
| smarx007 wrote:
| Just tried today to switch from Vim to Neovim as my EDITOR when
| I work over SSH (I use VS Code otherwise, I know about its SSH
| capabilities but don't use them to edit just one file).
|
| Result: had to add a PPA on my Ubuntu server (not ideal but
| OK), most plugins require nvim 0.8+. Switched to the unstable
| PPA (because the stable PPA ships 0.7), turns out it doesn't
| ship the latest release but instead a nightly dev build.
|
| While editing Lua configs of Neovim, I tried to use 'micro'
| just for fun.
|
| Result: my new EDITOR and GIT_EDITOR (that I previously set for
| +startinsert) are now set to 'micro'. Alt+/ for commenting
| code, sane shortcuts, and code highlighting cover 90% of my
| needs.
| constantcrying wrote:
| Setting up vim with IDE features takes an hour maximum + 2
| minutes per additional language.
|
| If that is too much for you, you could have used any of the
| various vim/nvim distributions with the features already there.
| _You could have even used Doom Emacs with vim keys_.
|
| If you don't want to use vim, I do not mind whatsoever, but if
| you put in a bit of effort the solution to your problems would
| appear.
| Barrin92 wrote:
| That's simply not the case because you will, very quickly,
| run into problems. One example I had with vim recently was
| that two different plugins both tried to format the same code
| and actually send each other into some sort of hell loop and
| crashed vim entirely because they called something in a
| circular fashion.
|
| That's absolutely representative of the kind of errors vim
| and neovim configurations have, because it's all independent
| plugins with very little ability to fix weird interactions.
| As soon as you have to customize anything in a slightly non-
| expected way you have no chance to predict if this is gonna
| break one of the dozen things that are basically held
| together with duct tape. VsCode or anyting designed to be an
| actual IDE with its tools better integrated doesn't suffer
| from this.
| gsinclair wrote:
| You're absolutely right that this can happen, but wrong
| that it is representative. Let's take all the serious vim
| users in the world. How many have this kind of plugin hell
| experience? A tiny percentage.
|
| Serious vim users don't try to create a kitchen sink IDE.
| They start with a vanilla base and with their way up,
| including just the features that are important to them.
|
| Starting with something like LazyVim is fine too. Then you
| get a rich set of plugins that have been configured for
| you. Lovely! And now just be thoughtful about what you
| later on top.
| danjac wrote:
| I agree that vim is a perfectly fine text editor.
|
| Yet half the (neo)vim people in this thread are yelling
| it's the One True IDE that can, in fact, do everything,
| and if you are using VSCode or IntelliJ or whatever then
| you must be a noob or too lazy to invest time in your
| tools.
| j16sdiz wrote:
| Sometimes it is too many choices. Each of them have its own
| glitch and dependency. Finding out which one I like most is
| time consuming.
| serial_dev wrote:
| Sure, it's one hour if you did that already 20 times and you
| know the ecosystem.
|
| An hour is barely enough to go through the vimtutor which
| itself is pretty basic (aka you won't get far with it, so you
| need to keep learning and practicing).
|
| If you are a vim newbie, it takes a lot of time to figure out
| you need plugins, then figure out how to install plugins,
| then what's the difference between plugin installers, finding
| the needed plugins for your languages, getting familiar with
| each plugins commands, resolve any conflicts between them,
| then you need file pickers, debuggers, task launchers,
| snippets, split screens, multi tabs, etc... Even then, you
| only made things work once... Good luck figuring that out in
| one hour...
|
| Then you'll need to keep the config working, practice and
| memorize the commands, movements, and maybe customize your
| workflow.
|
| Configuring vim to replace your IDE may be worth it, but "set
| it up in one hour" is, in my experience, extremely
| unrealistic.
| 0xFACEFEED wrote:
| > If you are a vim newbie, it takes a lot of time to figure
| out...
|
| The horror!
| constantcrying wrote:
| I am not talking about learning vim. Of course, that is a
| huge time investment and you have to make your own
| judgement if that is worth it (for me it absolutely was,
| but I was in University with few obligations and lots of
| time).
|
| I am talking purely about going from a vim without IDE-like
| tooling to one including it. _That_ can be done in an hour.
| serial_dev wrote:
| Still, IMO it can only be done in an hour if you've done
| it already... You need more time than that for finding
| the plugin candidates, evaluating them, installing the
| right plugins, then you need a test run where you lookup
| the key bindings, on vim it's not as easy to discover
| features as in a "GUI" IDE.
| constantcrying wrote:
| >on vim it's not as easy to discover features as in a
| "GUI" IDE.
|
| Unless you find the correct plugin :-)
| xeyownt wrote:
| I think it takes at least one month to get into vim, let
| alone mastering any of the plugins, and afterwards you keep
| learning every day.
|
| IMO this is not due to the difficulty of installing plugins
| (which is becoming easier and easier), but rather to
| embrace the vim "philosophy".
|
| Many think that VSCode is better because easier to use and
| has more features. However I think this is because they
| don't use any advanced features of VSCode either, only the
| glaring obvious ones.
| WastingMyTime89 wrote:
| Vim definitely was designed and remains an editor first and
| foremost. The IDE=like functionalities were clearly cobbled
| together later and it shows, on that we agree.
|
| What always surprises me however is why having realised the
| limit of this model, decide to go back to VSCode, another
| editor with cobbled together IDE=like functionalities? IDEs are
| nice. Last time I checked VSCode debugging was still subpar and
| required fiddling with configurations.
| atoav wrote:
| For me vim is a good text editor. You _could_ somehow turn it
| into an IDE -- even into a good one, but that is not what is
| the core value proposition of vim.
|
| I am mostly using sublime text for programming projects and vim
| for editing configs on headless servers. If I like to use vim
| for programming I'd try to add vim keybindings to my IDE
| instead of adding an IDE to vim.
| psadauskas wrote:
| I've felt similarly, and really wanted to switch to VSCode. But
| it gives each pane its own set of tabs, while Vim has a single
| set of "tabs" (buffers) and multiple panes within it.
|
| I've been using N/Vim for 25 years, and even after trying for a
| week or two, I just can't get comfortable with VSCode's way of
| doing it.
|
| https://github.com/microsoft/vscode/issues/143024
| JeremyNT wrote:
| I find the same.
|
| Vim has some core concepts that are unique and (for those of
| us who adopt them) very sticky.
|
| My entire career has been spent trying out IDEs every few
| years in hope of switching, dating back to Eclipse. I always
| try their vim modes too.
|
| But the reality is that the core editing experience in vim is
| so central to how I work that I can never manage it.
|
| I like features, and I have no love for arcane configuration
| of plugins. Yet to this day I've found nothing better for me
| than vim.
| lemper wrote:
| I've stopped using vim and started using visualstudio + vim
| plugin and called it a day. for me, it's just not worth it to
| tinker with truckload of plugins just to get ide features work.
| flippinburgers wrote:
| Now that lsp is a first class citizen in neovim is very usable
| with little modification.
|
| It will never be a ctrl+p install away from feature X system
| though. You do have to put _some_ effort in.
| johannboehme wrote:
| I dont know.. The argument i read all the time is "i don't want
| to invest time in vim". But what kind of professional spends
| hours uppon hours learning his craft (programming), but is
| unwilling to invest some of those hours into mastering
| professional tools? What about sharpening the axe? The amount
| of time i saved by sticking to vim is definitly more that the
| time i needed to learn it.. IDEs are easy mode and waste of
| resources. Its ok to start with them as a noob, but down the
| line i want to customize every part of my toolchain. (And thats
| just horrible to do in VSCode etc..)
| kzrdude wrote:
| Some hours is not what one should put into Vim, IMO. I've
| used it for many years and felt I got better at it very
| gradually (maybe I'm like that with most things). It's much
| more than hours! It's using it every day for a few years :)
|
| To honor the many-years of vim, I relearned a new vim feature
| now: using :g to run a macro like this:
| https://stackoverflow.com/a/5292858
| mangodrunk wrote:
| If someone likes to use vim, then so be it. If someone likes
| to use VSCode, then so be it. IDEs can also be called
| productive mode and use the right amount of resources
| necessary for large projects. They will get the job done, and
| for many it is the preferred option.
|
| Vim doesn't have to be the tool you use when there are
| others. If it was the only tool, I'd agree that people should
| know it better. Thankfully it's not the only one.
| erebearalte wrote:
| I think learning vim was very worthwhile for me cause I now use
| vim bindings if it's supported, but yeah vscode was getting
| slower for me the past few months and I decided to try neovim
| again and man so many things have changed since the last time I
| tried it with the new Lua config. I feel like it'll take me a
| day to recreate a config im satisfied with and it'll probably
| have a few bugs too after using it for a while.
| silasdavis wrote:
| I can identify with much of this.
|
| After an unfortunate bout of Java development, I was flung into
| the arms of Intellij, steadily won over by the indexing and the
| reliability of the refactoring tools. The Vim plugin was good
| enough and defining some chords for editor shortcuts resulted
| in a kind of fucked up fat vim emacs mode that was quite
| productive.
|
| I, too, got fed up of spending inordinate amounts of debugging
| vimscript and incompatibilities to end up with something that
| was slower or buggier than an IDE in certain crucial ways or
| with highly debugging resistant niggles.
|
| But I'm also far from in love with Intellij these days. It's
| slow. Prone to index corruption with lots annoyances I can't
| easily fix myself. I may churn to vscode. But I'm definitely in
| the gravity well of Intellij.
|
| However perhaps this is worth a look. I have historically had a
| fairly high tolerance to plowing hours I'm never getting back
| into fiddling with tools. Just less than I used to. More nixos
| gnome, alacritty than gentoo, xmonad, urxvt...
| pkulak wrote:
| Don't even bother using anything but IntelliJ for JVM work. I
| use Neovim for everything, but not Java/Kotlin.
| Tmpod wrote:
| Same. IntelliJ is just too damn good for JVM work, and
| specially for Kotlin. jdtls ans other Java langservers are
| decent, but unfortunately, kotlin_language_server is miles
| behind IntelliJ.
| freedomben wrote:
| Not only that, but in my experience everyone _else_ will
| be using IntelliJ, so the project is usually dependent on
| IntelliJ in some form. Sometimes subtlely, sometimes not
| so subtlely. It will usually build with gradle since it
| has to for CI /CD, but beyond that everytime I worked on
| a new project I had to fix all kinds of subtle problems
| that were the result of some config/state that IntelliJ
| keeps outside the repo and nobody notices because they
| all use IntelliJ.
| cempaka wrote:
| I spent quite a long time trying to get nvim-jdtls
| configured correctly and playing well with all the other
| LSPs I have configured. Had it _mostly_ working and I did
| like writing a large amount of Java for a greenfield
| project in Neovim, but then a bunch of it broke again when
| I upgraded either nvim or one of its plugins. So I spent
| some time trying to make the IdeaVim plugin work as closely
| as I can get it to my Neovim setup and am finding that to
| be a happy medium. But I might still come back to Neovim
| for raw editing at some point if the LSP issues do get
| sorted out.
| LinXitoW wrote:
| I somewhat like Intellij too, but it seems insanely slow,
| esp. with the Vim plugin. I have to slow down my editing
| sometimes, because all it's fancy features can't handle the
| speed.
| silasdavis wrote:
| When it's having a particular bad day I can sometimes
| rename a file-local unexported symbol faster than it can
| (pointlessly) search the entire repository for the name. Or
| when it's on an indexing holiday I can navigate by memory
| to a file I want with mouse-and-tree faster than it can.
| This make me sad and feels more common than it used to.
| jeffchao wrote:
| Same sentiment here. After 2 decades of development and having
| been through phases such as Gentoo, Vim+plugins, and other deep
| dive hobbies, I enjoyed the time spent, but now I just want
| something that works out of the box. I've found IntelliJ/GoLand
| with Vim bindings to work well for me. That Vim muscle memory
| is something I'll never get over.
| StevePerkins wrote:
| I just want a decent open source native editor with a native
| GUI.
|
| 10+ years ago, when I and almost everyone I knew were on
| Windows or Linux, this was simple and ubiquitous. UltraEdit,
| Notepad++, Vim and Emacs of course, etc, there were dozens of
| options to choose from.
|
| Then I and most developers that I know switched to Macs, and
| now this is an alien concept. There's a dearth of open source
| Mac development, and much of what exists uses Electron or some
| other crutch to avoid committing to the Mac platform.
|
| I've tried Neovim, but the "GUI" version is basically just the
| console version in a window. Might as well just skip it and do
| everything from the terminal.
|
| There is MacVim, but you have to open it from the command-line
| in order for it to scan your home directory properly. If you
| pin it to your dock and launch from there, then it doesn't know
| who you are and launches in stock vanilla mode without reading
| your .vimrc. Same problem with Geany. I could PROBABLY figure
| out how to modify the dock icon to launch with the right flags,
| but the point is that this is unreasonably complex and arcane
| for most users.
|
| So... I just stumble along with VS Code by default, like most
| people these days. It's an odd shame that cross-platform
| desktop app development is as dead as it is, especially
| considering that most devs today are not using the dominant
| platform anymore.
| pretext wrote:
| Have you tried VimR -- Neovim GUI for macOS?
| https://github.com/qvacua/vimr
| iansinnott wrote:
| You can have it both ways! Use neovim to handle key presses in
| VSCode, keep all the benefits of a text editor that (mostly)
| Just Works.
|
| - https://github.com/vscode-neovim/vscode-neovim
| aerhardt wrote:
| Completely agree, I've tried a full vim migration before and
| it's been a futile exercise. JetBrains with the vim plugin does
| it for me.
| mumblingdrunk wrote:
| This is why I switched to Helix. The configuration is
| practically non-existent, and it has default configs for all
| the language servers I could ever want to interact with. I just
| put the language server binary in my path and I'm ready to go
| with autocomplete and all the other features.
| paulvandermeijs wrote:
| I've also switched to Helix recently and I get the feeling
| that is not emphasized enough how much it is about having
| default integrations for modern standards like LSP, Tree-
| sitter, and DAP. It's amazing how much functionality you get
| with just that and not having any plugins or complex
| configuration.
| klardotsh wrote:
| I actually dread the day Helix eventually gets the
| WebAssembly plugins system that's been floated around. The
| current Helix culture of "you get a Kakoune-like editor
| that can do three categories of "bonus" things, and NOTHING
| ELSE" encourages a more manageable pace of development (and
| maybe more importantly: slower updates for those of us
| exhausted of software churn breaking our stacks
| constantly), and discourages feature creep/bloat. I love
| where Helix is at currently. After some tinkering and
| adjusting a few keybinds, and after a few releases for them
| to fix various bugs I'd been dealing with, it's quickly
| become my new favorite editor, and has nearly fully
| replaced NeoVim. Hats off to Helix.
| cayley_graph wrote:
| Helix is cool, but it doesn't have Vim keybinds, which is
| unfortunate. I find its own system to be a little worse than
| Vim's (see my other comment about it in this thread).
| singpolyma3 wrote:
| If you want IDE like features, then of course an IDE is a
| better choice. I've never understood why people and to extend
| vim to try to make it half of an IDE.
| conor- wrote:
| > I've never understood why people and to extend vim to try
| to make it half of an IDE.
|
| Because vim ships with any *nix machine and provides a
| consistent experience no matter where you use it.
|
| Vim is the DE part and people add plugins or whatever to
| enrich the text editing experience with LSPs or other
| language aware plugins, and the I in IDE is in the form of
| the integration with the tooling already available on the
| host.
|
| This[0] might shed some better light on the "why"
|
| [0] https://blog.sanctum.geek.nz/series/unix-as-ide/
| nocman wrote:
| For many people, it's because the choices for an IDE are all
| dog slow, and configuring a few plugins for their editor of
| choice provides a close-enough experience to strike the
| balance they are looking for.
|
| So, no, an IDE is _not_ a better choice for everyone who want
| 's "IDE like features". It is for some, but not everyone.
| gv83 wrote:
| a colleague of mine answered the same question with:
| "jetbrains products reek of java"
|
| which i translated to "cluttered ui" and "not responsive".
| skydhash wrote:
| JetBrains product has always been fast for me, as I
| wouldn't run them on a 10-year-old computer with an HDD
| drive. They've been very configurable, more than other IDEs
| I've used. An IDE is a host of tools, so the UI can be
| dense because they can do so much stuff. You invest in your
| tools, and that can also mean buying a powerful enough
| computer to do the stuff you want.
| gv83 wrote:
| i share your feelings and i'm a happy jetbrains customer
| (and i dont do java!); but i see the point of people not
| feeling comfortable using them specially when coming from
| more pared-down experiences. emacs and neovim are also
| snappier, vscode is marginally snappier, doesn't bother
| me but it's noticeable.
|
| JB also has some glaring holes, like the inability of
| easily specifying an env file to load when running
| projects from the IDE runner (and the plugin to do this
| was half broken with the 2023 versions)
| walthamstow wrote:
| The 'New UI' in PyCharm 2023 is pretty nice. Less of an
| airplane cockpit vibe. Its still a total hog of compute
| resources but I have an M1 machine and never notice any
| problems.
| 59nadir wrote:
| JetBrains have excellent offerings for both JavaScript and
| Python, in my opinion. I happen to like Neovim and I don't use
| the languages you have issues with the Neovim side of, but if I
| were to use an alternative it would definitely be JetBrains
| IDEs.
| wolletd wrote:
| JetBrains also has a excellent Vim Mode plugin that provides
| most features I love Vim for.
| vladvasiliu wrote:
| This is what I use, but it should be noted that vim
| commands clash with the IDE's shortcuts, so you have to
| move them around.
| CGamesPlay wrote:
| FWIW, I still use regular vim with ale [0] and it does
| everything I want. It formats files with Black and isort, shows
| ruff and pyright errors, supports jumping to definitions, and
| has variable information available on hover. It also does this
| for every other language I write in. I have collected my config
| over the past several years, but I pretty rarely encounter
| errors with it. It requires no additional dependencies except
| for the language tools themselves (Black, ruff, etc.).
|
| [0]: https://github.com/dense-analysis/ale [1]
| https://github.com/CGamesPlay/dotfiles/blob/master/files/.co...
| danjac wrote:
| This is the problem though: if you come to Neovim, and ask
| "what is the best formatter/linter" someone will tell you
| "use null-ls". Then a dozen others will say "don't use null-
| ls, it's been deprecated, use efm-langserver".
|
| OK, how do I set up efm-langserver with Neovim? Good luck!
| You could probably use a plugin, or maybe not. You'll need a
| way to install LSP servers. nvm-lsp-installer? Nope,that's
| also deprecated, use Mason. OK, _MasonInstall Black_. Wait,
| it 's not formatting anything. Oh, you might need nvim-
| treesitter. Um...ok, but that's installed already. Ah, you
| just haven't configured it correctly...here is my setup
| (pastes 300 lines of Lua or vimscript with zero context as to
| where you are supposed to load it)....Why are you using efm-
| langserver? Formatter.nvim is all you need! What? That's old
| hat! You should be using neoformat!
|
| If you mention Ale or coc.nvim...they stare at you as if you
| have just stepped out of a time machine from the 19th
| century.
| CGamesPlay wrote:
| It feels like you just told me that the thing that works
| without extra steps isn't cool. Is the problem that you're
| worried about not being cool?
| danjac wrote:
| The problem is when you are a newbie to a space, you
| don't know the difference between "cool" and "what is the
| best practice as defined by the experts".
| divbzero wrote:
| I can see both points of view.
|
| I've definitely been down the Vim config rabbit hole and
| struggled to find the right balance between "cool"
| (actively developed with newer features) vs. "best
| practice" (more mature and stable). My current approach
| is to search Hacker News comments for "vim _plugin-
| feature-I-want_ " and the most popular comments usually
| point me in the right direction.
|
| For what it's worth, I use Neovim with ALE at the moment
| and it works just fine.
| dbalatero wrote:
| I'm a huge Neovim user, but the amount of "hey guys I
| just rewrote this perfectly fine plugin in Lua [for the
| Nth time] check it out" posts every day are tiring.
| cayley_graph wrote:
| I see where you're coming from. FWIW, I've been using
| Neovim for an odd 7 years or so and only use plugins where
| absolutely necessary. I'll usually just add an appropriate
| BufWritePost (trigger after saving the buffer) autocommand
| for the language's file extension that does what I want. Or
| I'll add a keybind in .config/nvim/ftplugin/<lang>.vim (or
| <lang>.lua). You can do fancier stuff with plugins but I
| find that I just don't need it (and you probably don't
| either, by the looks of it).
|
| The default LSP client config at
| https://github.com/neovim/nvim-lspconfig#suggested-
| configura... sets everything up for you, if you're using an
| LSP server. I'm not sure why it hasn't been merged into the
| Neovim repo; possibly because they want to keep the editor
| core fast and minimal.
|
| All this means you have to do a little more configuring
| than with something like VSCode, but to be honest, I
| haven't legitimately needed to make big changes to my
| config in a few years. There's stuff I add for fun (like
| little lua scripts to manage my clipboard and to layout
| tabs the way I want), but to maintain a 'VSCode' level of
| functionality none of it's needed. The advantage of
| spending a little extra time, for me, has been that my
| editor 'fits like a glove', so to speak :)
| prmoustache wrote:
| So basically your problem is feeling insecure because other
| people do different choices.
|
| I didn't care following all the trends, my setup use
| coc.nvim[1] and I don't have any problem with that. I don't
| care about black, I am fine writing python stuff without
| it.
|
| Your setup doesn't have to be complicated because others
| is.
|
| [1] which is still maintained by the way.
| oblio wrote:
| [flagged]
| cassepipe wrote:
| I have also been able to program for years in C with vim +
| ale + gutentags but if you start doing some web with all its
| litlle dsl, it gets overwhelming quite rapidly. In this case
| LunarVim (or others) is a relief.
| _giorgio_ wrote:
| Agree. It's crazy and I've given up. I have windows and linux
| computers, and what works for one, doesn't for the other.
| Setting up a shared vimrc is a nightmare. In the end, I only
| use vim for text. Colab and jupyter for all the programming.
| klardotsh wrote:
| this is basically why I moved to https://github.com/helix-
| editor/helix/ for most things. neovim setup is a nightmare
| these days. 0.5 introducing Lua was both great (yay! vimscript
| sucks!) and horrible (oh no, everyone took this power and made
| a full operating system worth of complex stuff out of it that
| rarely fits together cohesively, and it all updates so
| frequently now that I can't keep up)
|
| I don't actually think it's Lua's fault. And I don't
| necessarily want to jump and say "the improved accessibility of
| this thing turned it into an unusable circus", because that's
| both unnecessarily sassy and also likely prescribing blame in
| some places it doesn't fully belong. But there's _something_
| that tidally changed in that time, and especially in the past
| 2-3 years, my vim setup became a thing I dreaded updating
| (because it would 100% guaranteed, every time, break
| _something_ about my workflow)
| tomaaron wrote:
| If you want to ditch m$ but still enjoy vscode, just use open
| source vscodium: https://vscodium.com/
| CodeCompost wrote:
| Which is practically useless due to Microsoft licensing
| restrictions on plugins.
| Roark66 wrote:
| I'm in a similar boat. I've used vscode, pycharm/idea, visual
| studio and vim etc.
|
| I'm currently giving neovim + i3wm a try, and there are certain
| things I love. Specifically instant switching between my
| browser and my ide, the ide and terminal.
|
| However, the speed of the LSP(tips, method definitions when
| coding) is greatly exaggerated. For example for python there is
| the exact same 10gb ram using behemoth running in the
| background. Is it faster than using the same language server in
| vscode or idea? Yes, a bit, but definitely not 10x faster.
|
| Also, I have 2 complaints. One is about keys. There is a huge
| emphasis in vim world to set your own keys for everything...
| The problem with that is that for some rarely used action one
| forgets... Or one moves to a different machine. I think plugin
| like lsp-zero should more prominently document their _default_
| keystrokes. I prefer to learn these before I start setting my
| own for everything.
|
| Second thing is what makes an ide most useful. A tree view file
| manager. I'm currently using nvim-tree. It's a nice plugin, and
| it works, but it lacks certain features like displaying large
| trees of empty folders in a "collapsed" way like vscode does.
|
| So, for now I'm sticking with nvim, but I can't say for how
| long..
| konart wrote:
| >The problem with that is that for some rarely used action
| one forgets...
|
| Install https://github.com/folke/which-key.nvim and you will
| always have a popup that will tell you what keys to use next.
| CGamesPlay wrote:
| You might be interested in installing the fzf-vim plugin [0].
| It has a user-defined command :Maps which can be used to
| search through all keybindings (you can also do this with
| just :nmap in vim, but the fzf interface is much nicer). It
| also provides :Commands. This behaves remarkably like
| VSCode's command palette.
|
| [0] https://github.com/junegunn/fzf.vim
| gsinclair wrote:
| I think your experience report of the NeoVim subreddit is
| severely misrepresentative of reality. I have never seen a RTFM
| response. Many answers point to exactly which part of the
| documentation would be helpful. Your Jenga tower of
| dependencies is much more imagination than fact.
|
| If you want Black to format your Python files on save, write an
| autocommand. That's what they're there for. If you need help to
| do that, ask for it.
|
| Or if you don't want to take the trouble to learn how to use
| (neo)vim, then don't use it; that decision is fine too.
| oblio wrote:
| > If you want Black to format your Python files on save,
| write an autocommand. That's what they're there for. If you
| need help to do that, ask for it.
|
| The real question would be:
|
| Why does the 50 year old editor with supposedly a huge
| community and tons of editors not have support for a popular
| formatter for probably the most popular programming language
| on the planet, and instead everyone has to write their own
| (probably buggy) variation of that integration?
| skydhash wrote:
| Because it's been here before the formatter and will be
| here after it. I don't think there is any support for any
| formatting tool, except the general act of formatting for
| every formatting tool. And if you find your config has
| multiple lines just to format languages you've touched,
| then it's time to build a plugin or search for one. And if
| you find it, and it's quite not like you want, extend it as
| most plugins are open source and free.
|
| If the tool doesn't suit you, build your own or find
| another.
| cayley_graph wrote:
| It does, you'd just have to install a python plugin that
| registers the autocommand-- or leave out the plugin and
| register the autocommand yourself. The (n)vim/emacs
| communities aren't fond of integrating the hot new thing
| for each language directly into the editor-- I think this
| is a lesson that comes from being 50 years old!
|
| As for whether it would be buggy, I'd doubt it? Unless
| Black's principle of operation is different from most
| formatters, it should just write the formatted contents to
| the file, right? The autocommand you'd use would just run
| Black on your current file on each save. So where % is
| Vim's symbol for the name of the currently open file,
| :silent! suppresses stdout/stderr from the formatter, and
| :! runs a command:
|
| autocmd BufWritePost *.py silent! !<format_cmd> %
|
| (Don't quote me on that, but it should be essentially
| correct. I'm not at a computer right now.)
|
| Actually, it looks like you can install an (n)vim plugin
| from the official Black repo here:
|
| https://github.com/psf/black/blob/main/plugin/black.vim
|
| And then the autocmd would be
|
| autocmd BufWritePost *.py silent! Black
|
| This stuff is documented here: https://black.readthedocs.io
| /en/stable/integrations/editors....
|
| Anyway, I think it's actually a really cool effect of doing
| this that you realize a lot of the scaffolding underneath
| most editors _isn't_ that complicated! It's totally
| understandable :)
| raverbashing wrote:
| Completely agree
|
| (As much as I'm team *Vim) Vimscript is a mess. Oh, so you mean
| 'noremap' means remap this? No way! /s
|
| The story about plugins is so true, regardless of the above.
| People will want you to install a plugin with 5 stars that will
| not play nice with anything else to do something basic like
| pre-save processing. Or one of the 'everything but the kitchen
| sink' plugins that has an end goal of giving you a Borgified
| Vim
|
| And in the end I sincerely don't care, I could use the time I'm
| playing with this to install VSCode, or something else and have
| something more complete OotB
| cayley_graph wrote:
| You might want to give nvim's Lua API a try. They took the
| opportunity to fix a lot of the semantic issues with
| vimscript
| cersei wrote:
| I don't disagree, it's always a balance of "how much time do I
| actually want to spend on my workflow vs getting the work
| done", but I think the only reasonable way to use Vim is to
| build your environment over time (many years) and have it in
| source control so that you never have to do it again. You'll
| still have to keep making updates of course, but that's
| typically a bit smaller time commitment.
| thiht wrote:
| > I don't like being sucked back into the Microsoft ecosystem
|
| You're not though, there's no lock-in.
| johannboehme wrote:
| but there is. VSCode core may be open source, but the plugin
| marketplace certainly isn't. So if you for example use
| VSCodium, you don't have access to the plugin marketplace and
| eather have to use an alternative or manage your plugins
| completely manually on the filesystem.
| thiht wrote:
| So what? You use the plugins available on the platform you
| use, that's standard practice. Would you complain Sublime
| Text plugins are not available on VSCode? Or emacs plugins
| are not available on vim?
|
| This is not lock-in, just a different feature set.
| goku12 wrote:
| They are certainly still trying. I used vscode a while ago.
| Some of the best and most essential extensions like LiveShare
| and Remote are proprietary and worked only on the proprietary
| build of vscode (the last time I checked) and wouldn't work
| on OSS builds like vscodium (why though?). Both these
| extensions and the proprietary build of vscode come with
| telemetry that's either opt-out or always enabled. They nudge
| you ever so slightly and gradually towards the proprietary
| build. I left vscode since I don't like such manipulations.
| thiht wrote:
| It's not lock-in, it's feature differentiation. Other
| platforms are free to develop their alternatives of these
| plugins. There's nothing preventing the community to
| develop a fully OSS Liveshare or Remote extension (and they
| are!)
| lagolinguini wrote:
| > I don't particularly like vscode. It's heavy and slow and
| janky, particularly on older laptops. I don't like being sucked
| back into the Microsoft ecosystem after spending years getting
| away from it. But ultimately, I want to just get on with my
| job, and my job is not Lua Developer or Neovim Plugin Expert.
|
| Personally I've started paying for intellij and using it with
| it's vim emulation. I know it doesn't solve the problem of
| being clunky on older laptops, but it is an amazing experience
| to use. I get the best of both worlds, I get really good vim
| emulation so I don't have to relearn editor shortcuts, I get
| the benefits of a modern full fledged IDE with many useful
| features that work out of the box with basically 0
| configuration (debugger, git, tasks, etc.)
| ibrarmalik wrote:
| Same. I like it better than the vscode vim emulation, which
| is more "strict" and turns to the visual mode when selecting
| anything with the cursor. Which I personally think is the
| worse part of vim.
| jcpst wrote:
| Intellij IDEs for my day job are awesome.
|
| I do have a personal all-products license as well, but I
| hesitate to go "all in" and be dependent on them.
|
| But it is ok to just use a lot of editors for different
| things. VS Code is 'good enough' a lot times. I like writing
| notes in emacs org-mode. NeoVim on the command line.
| Sometimes I use Helix, I think it hits a sweet spot between
| snappiness and minimal configuration.
| Faceless1230 wrote:
| I'd recommend trying a neovim distro like lunarvim out. It has
| black and all other typical ide features configured out of the
| box and doesn't mess with your normal neovim config.
| mkmk3 wrote:
| I tried out spacevim, but then some feature was getting in my
| way and I couldn't figure out how to turn it off (I've
| forgotten what now).
|
| I think thats a disadvantage to some of these heavily
| customized vim flavors. Plugins don't necessarily work out of
| the box, and when they do they promote their own way of
| interaction that sometimes needs to be learned.
| cassepipe wrote:
| As a recent LunarVim user, I can really recommend it.
| Coming from vanilla vim, it has been a pleasure to use.
| More power at the cost of less configuration. And beginner
| friendly (for someone that's familiar with vim)
| xmcqdpt2 wrote:
| I think it's important to know a terminal text editor if your
| work involves remote servers. Then once you know one of the
| good text editor, you may be tempted to use it for other tasks.
| That's where people get into trouble.
|
| The base emacs and vim documentations are actually excellent,
| the problem is the plugins. Just use an IDE for IDE tasks and a
| text editor for text editing tasks! I'm not going to start a
| new project in Intellij just to edit a config file or take
| notes about something. Why would I want to pollute my minimal
| emacs config so that I get a flaky IDE?
|
| (Of course it's fun to program in a text editor because it's
| fast and distraction-free, which is why I use them for hobby
| projects. But for professional work I use professional tools.)
| josephd79 wrote:
| https://github.com/nvim-lua/kickstart.nvim
|
| I started with this config. This made it a lot easier to start.
| delijati wrote:
| I went with a minimal approach ... I still use my `.vimrc`
| file, removed all code completion stuff and added LSP
| https://github.com/VonHeikemen/lsp-zero.nvim/blob/v2.x/doc/m...
| ... next step treesitter but i'm in no hurry :)
| manaskarekar wrote:
| The other comparable setups:
|
| NvChad: https://github.com/NvChad/NvChad
|
| AstroNvim: https://github.com/AstroNvim/AstroNvim
|
| LunarVim: https://github.com/LunarVim/LunarVim
|
| Never got into any of these, but I love that they showcase what's
| possible.
| yxre wrote:
| I find that any IDE-type setup in vim causes vim to lose the
| most important thing, speed. If your movements slow down
| because of too many plugins, the experience is far worse than
| in a normal non-modal IDE.
| adastra22 wrote:
| What is this speed you speak of? I developed in vim for a
| decade, then eMacs for another decade, before finally moving
| to VS Code. I've never been as productive with vim/eMacs as I
| am with Code, or Visual Studio proper / XCode when I have
| cause to sue them.
| cerved wrote:
| Surely you jest, Visual Studio proper is absolute garbage
| adastra22 wrote:
| Maybe for your needs. When I worked as a game developer
| was amazing for visual debugging gigabytes of runtime
| data generated by a game engine with millions of lines of
| code. I could endlessly click through class hierarchies
| to see what interconnections arise at runtime, and setup
| all kinds of complicated breakpoint conditions. Obviously
| you can do all this with gdb or lldb as well, but in my
| experience it never approached the productivity boost of
| a graphical debugger.
|
| Visual Studio is a bit shit outside of games, .net, or
| windows desktop software though.
| aulin wrote:
| May I ask what makes you more productive with vscode?
| Coming from decades of emacs I'm always wondering if I
| should try it. If anything because emacs is a huge time
| sink. You can get lost customizing it to your needs and
| forget that what you needed in the first place was get the
| work done.
| adastra22 wrote:
| It's basically all the benefits of an expertly configured
| and finely tuned emacs setup, except maintained by other
| open source developers so competently that your only time
| spent configuring your editor is clicking "Install
| Plugin" the first time you open a file written in the
| language/framework you use. Sensible defaults, batteries
| included.
|
| The only downside is that as a web tech app it can have
| some noticeable latency. But on a beefy dev laptop or
| workstation the difference shouldn't be noticeable.
| ComputerGuru wrote:
| Editor speed (i.e. responsiveness), not developer speed
| (i.e. productivity).
| User23 wrote:
| Having used all three myself I bounced off VS Code hard
| because getting a usable Ruby setup with all the fixings
| like irb integration and sorbet ls was multiple days of
| frustration and still not working right compared to it just
| working out or the box with Doom Emacs. What's the happy
| path that made VS Code work so well for you? I'm curious in
| case I did it wrong.
| jemmyw wrote:
| The ruby stuff for vscode isn't quite up to quality and I
| find I turn a lot of it off. I've had a good time with
| the fuzzy LSP https://marketplace.visualstudio.com/items?
| itemName=Blinknli...
|
| I think sorbet hasn't got the critical mass of devs using
| it so tooling is hit or miss. And I personally don't like
| it even though I'm well onboard with typescript.
|
| What is irb integration? I tend to avoid that kind of
| thing and just do it in the terminal regardless of which
| editor I'm using.
| User23 wrote:
| > What is irb integration
|
| Stuff like having code locations in irb hyperlink back to
| the code buffer in another window.
| vidyesh wrote:
| This is not a direct response to your experience but a little
| off topic but lazyvim uses lazy.vim which is a _modern_
| plugin manager that lazy loads plugins /extensions, it also
| loads plugins on demand instead of loading them all together
| at startup from your config. It also can lazy-load plugins
| based on events, keymaps, filetypes etc
| mrinterweb wrote:
| I really haven't experienced this. There was one time i
| noticed vim slow down, and that was related to a relative
| line number bug specific to Mac, but that was fixed a while
| ago. I've used many of the ide type neovim premade configs,
| and i use my own which has a lot going on. None seem slow to
| me. Guess it has been a while since I've used a vanilla
| config. Full ide setups in neovim don't seem slow to me,
| especially compared to other full ides or vs code.
| techwizrd wrote:
| I also haven't experienced this much. I use the lazy
| loading functionality for vim-plug, along with async where
| I can. My neovim starts up in only a few milliseconds and
| avoids loading most plugins until I open specific file
| types or use a specific command.
| mrinterweb wrote:
| One more thing. You can start neovim with different
| configs, so if you wanted to launch neovim with a super
| light config, it is possible to have both. Need to do some
| trickery with env vars, but it's not hard.
| wruza wrote:
| I don't mind slowdowns as long as they are synchronous and
| deterministic. But most IDEs and IDE-like plugins work
| asynchronously, so you have to wait and sync all the time. I
| think that this async-all approach gains technically but
| loses methodically, so I stick to basic editing. Ymmw.
|
| What I would like to try is an asynchronous _non-inplace_
| helper. Like a side panel or a bg overlay to the right-ish
| that understands what you're doing and suggests identifiers,
| reference snippets, full type info, etc. Like the whole page
| in a smaller font dedicated to what's under the cursor. Then
| you could choose what to type into the code, or ignore it
| because I already know that. I don't mind typing if it
| doesn't require too much attention.
|
| Another thing I'd like to try is mobile-style typing
| suggestions. First - semi-transparent popups above words in
| case there's a typo or an obvious continuation, applied via
| M-CR. Second - 3-5 most obvious next tokens to insert without
| even starting to type. Like in let start =
| new Date let date|
|
| Suggests ["="]. When you choose it, it suggests ["new",
| "start", "Date", "undefined"]. I bet one could type pages
| with this alone.
|
| This might work nicely with any editing model, imo.
| VoidWhisperer wrote:
| The last suggestion seems somewhat similar to what copilot
| does, although copilot tends to suggest whole statements
| instead of a word
| riffraff wrote:
| I wish copilot.vim had a way to insert only a token from
| the suggestion. I often get stuff which is partly correct
| but "diverges".
| pynappo wrote:
| there is a somewhat hacky way to accept just a word, to
| my understanding, since copilot.vim allows you to access
| the raw text that's being suggested. try out the snippet
| in the linked comment:
|
| https://github.com/orgs/community/discussions/12426#discu
| ssi...
| wruza wrote:
| It's a similar job, but a different value. Copilot writes
| code you don't know yet (supposedly), while this speeds
| up typing what you know you'd like to type. Both modes
| could be useful, I think.
| alwillis wrote:
| > I find that any IDE-type setup in vim causes vim to lose
| the most important thing, speed. If your movements slow down
| because of too many plugins, the experience is far worse than
| in a normal non-modal IDE.
|
| Um... the word _any_ is doing a lot of work in this sentence.
| I never had this problem on a 7 year-old iMac. I tried using
| VS Code on the same machine with just a few plugins on small
| projects and because it 's an Electron app, I'd get
| frustrated and switch back to Neovim. VS Code has come a long
| way but it's no Neovim.
|
| The beauty of new plugin managers like Lazy.nvim [1] is you
| could have 30 plugins configured but Lazy doesn't load all of
| them at once. In fact, it doesn't load any of ones you don't
| need and when they do load, it's asynchronous.
|
| Plugins on Neovim run on separate threads from the editor
| itself, another reason we don't get those slowdowns you spoke
| of.
| zogrodea wrote:
| I can't comment on any implementation details, but at least
| with LunarVim (which I use for daily coding), a slowdown
| when interacting with LSP is very noticeable. Some others
| have attested to this on a GitHub issue.
|
| I'm not doubting your experiences with the lack of a
| slowdown, but there is truth that others do experience it.
| That might be more of a problem with LunarVim itself rather
| than Vim, but how likely am I (as someone who would like to
| avoid what he calls "config hell") or other newcomers to
| avoid whatever pitfalls there are, if a distribution
| designed for ease of use by people who know better fall
| into them?
|
| https://github.com/LunarVim/LunarVim/discussions/3359
| zogrodea wrote:
| After re-reading my comment, I think it was somewhat
| unfair. LunarVim is still the best and most comfortable
| code editing solution for me and the performance hit
| isn't that bad.
|
| The point I made about config hell might also be a bit
| out of place in this subthread since ease of use wasn't
| brought up explicitly in the comment chain I'm replying
| to (although distributions aiming for ease of use were
| mentioned).
| [deleted]
| motbus3 wrote:
| I still use vim. What am I missing?
| Dead_Lemon wrote:
| No exactly on topic, but I enjoyed this parody,
|
| Interview with a VIM Enthusiast: https://youtu.be/9n1dtmzqnCU
|
| also, Interview with a Emacs Enthusiast:
| https://youtu.be/urcL86UpqZc
| mdoliwa wrote:
| I'm Ruby developer, and tried multiple times to switch to vscode
| or one of these heavy IDE like plugins. All the time I'm back to
| my simple setup which is basically vim + fzf(powered by ripgrep).
| CTRL+P I run fzf to find files, CTRL+F to scan files content.
| It's so fast, that every time I'm doing the test switch to
| another tool, I'm missing this speed and get back to it. Some
| time ago I wrote an article for company that I used to work for,
| describing my workflow: https://thecodest.co/blog/rails-
| development-with-tmux-vim-fz... you can check it for more
| details.
| column wrote:
| :i to insert :q to quit without saving :x to quit with saving
|
| For everything else, I use a GUI.
___________________________________________________________________
(page generated 2023-07-17 23:02 UTC)