[HN Gopher] My (Neo)Vim workflow
___________________________________________________________________
My (Neo)Vim workflow
Author : Hadi7546
Score : 77 points
Date : 2024-06-26 11:25 UTC (4 days ago)
(HTM) web link (seniormars.com)
(TXT) w3m dump (seniormars.com)
| Squeeeez wrote:
| Well, there goes the evening. Merging configs trying out stuff.
|
| Is this your own? Or just one you liked?
| commandersaki wrote:
| Probably my most useful (neo)vim productivity tip is:
| vim.keymap.set('n', '\\.', ':tabedit %:p:h<CR>')
|
| My leader is \, so when I press \\. it will open netrw in a new
| tab in the directory containing the file whose buffer I was just
| editing. I use this all the time when I need to navigate source
| trees as I don't care much for fuzzy file finders. Credit to
| -romainl- who taught me about %:p:h.
| kzrdude wrote:
| I've got a lot of shortcuts set up for telescope (fuzzy finder
| ui in neovim). One of them is leader fa for "find around" which
| limits the file list to current directory and the next level
| down (only). It's quite useful in the same scenario.
|
| The regular fuzzy finder is unfortunately useless in the home
| directory (too many files), with this limit, it's useful.
| JoshTriplett wrote:
| This is really handy, thank you!
|
| There's a shorthand :Texplore which does the same thing as your
| :tabedit invocation. Also, if you change it to
| ':Texplore */%:t'
|
| , it'll open the directory of the current file and put the
| cursor on the current file.
|
| I've added this to my .vimrc: noremap <C-b>
| <Cmd>Explore */%:t<CR>
|
| This binds Ctrl-b to browse in the directory of the current
| file.
| pawelduda wrote:
| I have the same, except via ranger.vim, which integrates it
| with said program - it's an excellent pairing
| Zizizizz wrote:
| I imagine you aren't going to install a plugin for this but
| oil.nvim is really great for this as you can also use it to
| edit your directory listing like a buffer to easily
| create/rename and delete files and directories.
|
| https://github.com/stevearc/oil.nvim
| 29athrowaway wrote:
| I believe that your toolchain should be doing work for you, not
| the other way around.
|
| A toolchain should also be discoverable and well documented.
|
| A toolchain should also be complete:
|
| - editing
|
| - syntax highlighting
|
| - syntax validation
|
| - linting
|
| - building
|
| - testing
|
| - profiling
|
| - debugging
|
| - searching
|
| - documentation
|
| - version control
|
| Optionally also
|
| - deploy
|
| - inspect logs
|
| You can do a lot of work and testing to these working correctly,
| install a "distribution", or you can simply use an IDE.
|
| You can argue that you can do all these things with plugins, but
| plugins do not follow unified guidelines and the result can be an
| inconsistent experience like the Dwarf Fortress menus.
|
| A TUI editor with many plugins installed isn't necessarily faster
| than an IDE. Languages like vimscript are interpreted, not
| compiled. And many implementations not always take advantage of
| multi-threading capabilities.
|
| Among the distribution of TUI editor users, only a small subset
| of users can get their toolchain to be ergonomic, complete and
| work correctly. The rest just have a minimal experience that just
| gives them more work to do and that places a quality handicap on
| them.
|
| How do you read profiler output in your TUI editor? or show test
| coverage? or run a specific test case in a test file and get a
| test report? 99.9% of the time the answer will be "Well, I
| haven't set that up yet...but look at this multiple cursor
| trick!". And the median skill level TUI editor user often hasn't
| even set up a linter or something like LSP integration.
|
| What TUIs are excellent for, in my opinion, is to encourage an
| immersive experience that's distraction free. But now many IDEs
| have distraction free modes.
|
| They can be good for customization (which can even result in
| customizations that make your work _more_ difficult), although
| IDEs have SDKs that are not hard to use and many plugins are open
| source.
|
| TUI editors are also more compatible with working on remote
| hosts.
|
| Now, through customizations you could in theory create a
| universally superior development experience compared to what IDEs
| offer, but that is yet to be seen. Only in some aspects TUI
| plugins have achieved this level of excellence in specific areas,
| like Magit for emacs.
| c-tb wrote:
| the problem with that mindset though, is if you don't want
| several of these features. or you use a variety of languages
| and tools where the common interface is the terminal. i work
| professionally in Kotlin so i would never use vim over IDEA
| over that. but getting all sorts of other languages working in
| something as bulky as IDEA is a huge pain and not generally
| worth it.
|
| for the longest time (pre-LSP), my non-kotlin dev experience
| was just vim-polyglot and running watch - build in a :vsp and
| it gets you far.
| drawnwren wrote:
| This reads like the sort of academic engineering that I hate
| working around. You ask great questions for research, but the
| truth of the matter is quite simple.
|
| You can just open both editors next to each other and ask how
| they are. For me, it's trivial to see that vim is at least an
| oom faster than VSCode. I don't need to profile or show test
| coverage. I can just use it and it works. Even if they were
| about the same speed, the less-than-perfect vim mode
| implementation always takes too much time out of my editing
| flow.
|
| Occasionally, an ide will have such a great curated experience
| that I'll use it for something specific -- but the general case
| is a no contest for me.
| 29athrowaway wrote:
| The vimscript implementation doesn't have many of the
| innovations of modern scripting languages. No JIT,
| pretenuring, inline caching, etc.
|
| All your "one OOM away from VSCode" scripts run in a script
| language that is in the slowest category among all
| programming languages: interpreted languages.
|
| There are probably millions of dollars invested in making
| scripting languages like JavaScript faster, but that's not
| the same case for vimscript. Same applies to other languages
| behind IDEs such as Java. So that intuition is not true.
|
| With hardware accelerated widget toolkits, the TUI advantage
| is not necessarily true either.
| drawnwren wrote:
| Yeah, I'm not arguing whether that's right or wrong.
|
| It just doesn't matter. Vim is objectively faster. I don't
| care how many millions of dollars or pl optimizations my
| editor has. I care how quickly it works.
| ibotty wrote:
| Most nvim plugins are written in lua.
| vincentkriek wrote:
| I usually doubt about this, am I missing out on useful tools
| because I like my terminal based environment. Editing is much
| better when you have tools that are keyboard first, I think
| everyone agrees about that.
|
| My conclusion now about an integrated environment (like an IDE)
| versus a more handbuilt (like vim) is that a handbuilt one
| requires the dev to know it's tools. With an IDE you are
| seduced to trust the magic black box, that the box will help
| you. This makes it that when stuff goes different then expected
| (usually user error), you are lost.
|
| With a more custom environment you are pushed to learn your
| tools. And while this is not a given, I like this approach
| more. I might miss some fancy new tools, but the tools I do
| use, I *know*. This could be done with an IDE but is more
| forced in a terminal based flow.
| 29athrowaway wrote:
| You can map most actions in an IDE to a key combination.
|
| And IDEs have integrated terminal panes as well.
| vincentkriek wrote:
| Never said it can't be good in an IDE. But there is
| something that draws people to vim, which isn't just the
| cool factor. IDEs often even have vim modes but vim itself
| is a nicer editor.
|
| Same way an IDE is a nicer debugger, linter, profiler, test
| run platform...
| eikenberry wrote:
| The primary mistaken assumption you've made (though some TUI
| users also suffer this) is that the TUI is the integration
| point (the IDE) and that is not the case. Text editors, like
| Neovim, are are only the editor part or component of the IDE,
| your terminal shell environment. The shell has had decades to
| refine its place as the integration point for development. It
| works very well and keeps closer to the classic, do one thing
| and do it well, mentality. This has many benefits that don't
| translate well to GUI IDEs as they just can't match the
| flexibility and maturity of the shell ecosystem.
| 29athrowaway wrote:
| We can all agree that the UNIX philosophy is powerful. Having
| a uniform interoperability mechanism (e.g.:
| stdin/stdout/stderr, exit codes) helps integrate different
| tools easily. I use shell commands to get things done often.
|
| But that doesn't necessarily negate what I said: having a
| complete toolchain with a complete set of capabilities is the
| end goal. How you achieve that is means towards an end. If
| you achieved it with a TUI editor, good.
|
| But there's a subculture in the TUI editor world where the
| end goal is often the prestige of being a TUI editor user
| rather than how capable the tooling makes you. And the
| situation in the wild is that most of these TUI users have a
| sub-optimal development experience that causes them to push
| more defects, because even though you could integrate LSP, a
| linter, etc... a lot of them don't.
|
| With respect to when vim was invented, you have a
| supercomputer now. You may be solving a performance problem
| you don't have.
|
| If editing with a minimal experience is a deep part of who
| you are, yet you are not going to pay for the cost of
| detecting and correcting preventable problems which can cost
| the company thousands to millions of dollars... maybe you are
| not acting in the best interest of your development org, your
| colleagues, your career or your family even. What do we call
| a person that exhibits that behavior?
| jclulow wrote:
| > the situation in the wild is that most of these TUI users
| have a sub-optimal development experience that causes them
| to push more defects
|
| What an amazing pile of unsubstantiated horsefeathers!
| sodapopcan wrote:
| > 99.9% of the time the answer will be "Well, I haven't set
| that up yet...but look at this multiple cursor trick!"
|
| Ah yes, the classic "takedown" with the invented statistic
| about what people "probably" haven't done while "probably"
| focusing on something less important. Bravo.
|
| Side note: most Vimmers don't use multiple cursors... it's
| 99.9% of them, I believe!
| 29athrowaway wrote:
| Still better than the circular arguments like vim is faster
| because vim is faster.
| sodapopcan wrote:
| It'a not better, they are both worse. The best editor is
| the one you know. I also know lots of people who use IDEs
| and don't use most of their features.
| 29athrowaway wrote:
| If we have a test or a linter that prevents a problem,
| that runs in a couple of milliseconds, and you didn't run
| it because you are too cool to run it, then we are no
| longer talking about subjective preferences about tools.
| We are talking about responsibility.
|
| If your code caused data loss on production because you
| are LARPing about being a hotshot instead of adopting the
| processes that keep the code running I don't care how
| fast your editor is.
| sodapopcan wrote:
| Lol, you're exactly who I'm complaining about. I do agree
| with you: I also dislike people who don't learn their
| tools and don't do the things you're talking about. But
| just because you're using an IDE doesn't mean you're
| going to use all of its features. Conversely, if you're
| going to use a text editor, you absolutely have to ensure
| you have that stuff.
| MegaDeKay wrote:
| Similar to this, Typecraft on YouTube has an excellent "Neovim
| for Newbs" course that is really great. He starts with vanilla
| Neovim and basically turns it into an IDE. He uses some of the
| same plugins as this article does, but also goes into depth for
| "the new hotness" (as this article calls it). What is quite nice
| is he breaks the different functions up into separate lua scripts
| rather than putting it all into one big config file.
|
| https://www.youtube.com/watch?v=zHTeCSVAFNY&list=PLsz00TDipI...
|
| There is a separate playlist that shows how to smoothly integrate
| Tmux with Nvim so you can do things like Ctrl H/J/K/L between
| Neovim splits and Tmux splits seamlessly.
| glennericksen wrote:
| +1 to Typecraft for reworking your Neovim setup. As a longtime
| Vim user, I adopted Neovim with my Vim .vimrc in order to use
| Copilot. With Typecrafts guidance, I switched to Lua config,
| and really happy with where I ended up. Haven't touched VSCode
| in months.
| manbash wrote:
| The article should at least preface with some explanation about
| lazyvim.
|
| Some snippets simply have comments like "I use lazy.nvim to load
| plugins" and that's it.
| pacomerh wrote:
| after years of using my custom neovim config I honestly just
| transitioned to lazyvim and it removed so much maintenance
| time, I'm happy with it
| bionsystem wrote:
| I hate when that happens, a lot of searches around the neovim
| ecosystem ends up with various replies that assume 96 layers of
| knowledge even before understanding what the solution is about.
| MistaGobo wrote:
| Renaming variables should be done using an LSP, not find/replace.
|
| I'd try to avoid using your mouse altogether; because it's faster
| and for me, avoids neck/shoulder strain.
|
| Also, I'd recommend oil.nvim which is great for doing file
| exploration and manipulating. You can edit/move filenames
| naturally in a vim buffer, and then save to apply changes.
| shmerl wrote:
| How do you rename it with LSP?
|
| For now I got to setting up LSP configs and servers for a few
| languages but didn't get into using it yet besides getting
| extra syntax highlighting.
| PsyNyde wrote:
| use `vim.lsp.buf.rename` to rename using lsp. for example i
| use `vim.keymap.set("n", "<leader>rn", vim.lsp.buf.rename,
| opts)` to rename.
| shmerl wrote:
| Thanks for the pointer!
| MistaGobo wrote:
| require('lspconfig')['tsserver'].setup{ on_attach =
| on_attach, ... }
|
| local on_attach = function(client, bufnr) vim.keymap.set('n',
| '<leader>rn', vim.lsp.buf.rename, bufopts) end
| DiabloD3 wrote:
| try something like: vim.keymap.set('n',
| 'gr', function() local clients =
| vim.lsp.get_clients({ bufnr = 0 }) for _, client in
| ipairs(clients) do if
| client.server_capabilities.renameProvider then
| vim.lsp.buf.rename() return end
| end end)
| shmerl wrote:
| I'd recommend fzf.lua for search, it's very cool.
| throw156754228 wrote:
| Vim life.
| tasuki wrote:
| > First, I use copilot to complete test cases and boilercode - I
| don't trust it for logic
|
| Very interesting! I want to write the test cases myself. When
| copilot writes some code that passes my tests, I think I can
| trust it.
|
| If you don't even trust copilot to write your logic, how can you
| trust it to write the specification for how the logic should
| behave?
| sevg wrote:
| I think it's easier to review test cases as they tend to have
| less code, less complex logic, and less interaction with other
| code.
| threePointFive wrote:
| My biggest gripe with the ecosystem right now is complete lack of
| any consistency around language servers, which seems to come from
| the fact that many were written assuming they would only ever be
| a VSCode plugin (ie. typescript-language-server). The author is
| using coc.nvim which appears to be a VSCode compatibility layer
| for nvim to deal with this. I've primarily used Mason.nvim just
| to manage my LSP installs. I'd really love for LSP (and DAP)
| tooling to make its way into distribution repos, but I'm not sure
| what needs to change to make that a reality.
| intothemild wrote:
| Very true. Also don't forget nvim-lspconfig.
|
| Finally the tooling around LSPs has got better, but I feel it
| needs to go further. Modern languages like Go and Rust have
| excellent LSPs, but java. It's not great. I know java is just
| an absolute mess when it comes to tooling, but I wish there was
| some standardisation here.
| alentred wrote:
| I, for one, have recently refactored my NeoVim config in the
| exact opposite direction: now using mostly default nvim settings,
| dropped lots of plugins, etc. Feels great really. Quite honestly
| I was simply tired of maintaining my old configs. It ended up to
| be easier to (re)learn some default key mappings instead.
|
| This, however, only works with software with good backward
| compatibility. Here is to nvim to be that kind of software.
| zingerlio wrote:
| For casual users like me, I find Kickstart
| (https://github.com/nvim-lua/kickstart.nvim) a good and sensible
| default that's not too opinionated.
___________________________________________________________________
(page generated 2024-06-30 23:02 UTC)