Am I the only one using vanilla vim with a minimal configuration file ( 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…
LazyVim
431–440 of 537 posts
Re: LazyVim
#432I 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.
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?
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.
Re: LazyVim
#433Earlier quoted context omitted.
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…
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…
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.
Re: LazyVim
#434Earlier quoted context omitted.
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.
It's not like vscode sneaks in the copilot code. You always have to validate. Is it magical when you use regular code completion?
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.
Re: LazyVim
#435Most 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 Sub…
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.
Re: LazyVim
#436Earlier quoted context omitted.
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,…
> 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…
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.
Re: LazyVim
#437Earlier quoted context omitted.
> 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 positiv…
> 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, an…
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.
Re: LazyVim
#438Earlier quoted context omitted.
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.
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…
Re: LazyVim
#439Earlier quoted context omitted.
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…
> 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 h…
Re: LazyVim
#440Earlier quoted context omitted.
Was that expressly written to parody Vim? If so, this line is particularly spot on: > 'left' actually means right
> 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?