101–110 of 135 posts
Yes, that's what .vimrc is for, but now that's one more config file to keep track of.
There's been a number of "anti-vim, use a real ide(TM)" posts coming into my feed lately and I don't get why. Do people really get buttmad about this? I switched from vscode to vim as I found it to be largely much faster in getting around when I started my new job, some people find the opposite. A ok. Why do people try to force us into these largely closed solutions? ( Mainly it's vscode, which has a real EEE threat)
I've never gone for vi(m), even after roughly 25 years of using Linux now. I'm not trying to force you into anything, certainly not anything closed. I used NEdit until its lack of utf-8 and ancient GUI library started causing trouble. Then I used Slava Pestov's JEdit, which was wonderfully extensible and portable. Now I use vscode, which is just so outrageously well made that even electron and Microsoft can't scare m…
It's a bad analogy because a car's controls are operated while carefully piloting a ton of metal at life ending speeds around 17 assholes on their phones while your editor is operated safely at your desk. Your car also has few enough vital controls that they can all be given a physical manifestation while your editor has a lot of functionality and most provide some way for you to access all of this functionality easily. All options have some downsides and mental overhead.
You can provide a wide array of buttons possibly in sub and sub sub menus see content creation applications. Specifically 3D modeling apps.
Filtering options as you type. Consider application launchers on most platforms where you could type Fir to launch Firefox.
Sequences of shortcuts after you have exhausted the standard fare. See Emacs default key bindings for an extreme example.
The thing is that even Holding down Control while you press c is an example of a modal action. The C key either inserts its character or copies selected to a buffer based on whether the control key is held down. This is modal!
The same is to a degree true of sub menus as the functionality presented changes based on which menu is open and which options you have picked previously.
You are to some degree paying the inevitable cost of navigating a large number of functions and the only thing you can do is either forego the power of additional functionality by using simpler tools or figure out how to pay it in the least expensive fashion.
You've elevated your preference to how to pay this tax to a scientific choice and reduced a massive number your fellows to Luddites in an abusive relationship with their editor defending their choice with misplaced pride. I invite you to consider that perhaps 1/4 of your fellows aren't simply idiots and perhaps there are reasons that for them this method of dealing with complexity is effective for them.
Earlier quoted context omitted.
I've never gone for vi(m), even after roughly 25 years of using Linux now. I'm not trying to force you into anything, certainly not anything closed. I used NEdit until its lack of utf-8 and ancient GUI library started causing trouble. Then I used Slava Pestov's JEdit, which was wonderfully extensible and portable. Now I use vscode, which is just so outrageously well made that even electron and Microsoft can't scare m…
stick shift That is an unfair comparison on the edge of a strawman. In vim, you see your mode right at the cursor shape (bar in insert, block in normal, selection in visual). It’s like saying that DEs are bad because switching active windows is modal. Why not send input to the first window in the taskbar by holding ctrl and to the second by holding ctrl-shift then? Does that sound absurd? Even when you make a modal m…
Earlier quoted context omitted.
I’ve went through various editors and IDEs in past years. 2 years ago, I started using vim for exact same reason as yours. Nowadays, I use both vscode and neovim but mostly neovim as it’s faster for me. The problems I see are - - not everyone is comfortable with customizing their editor. - the meaning of bare-minimum features is different for everyone. - some of us try hard to learn vim and then give up, declaring it…
Does (neo)vim offer a similar debugging experience? Visually stepping through code and setting break points and stuff? I like vim's code navigation, but I miss the autocompletion features of bigger editors. Can you make vim tab complete like sublime? Last I tried, it was never as "one key to rule them all", but required some additional finger-fu and attention. Also moving selected code around (so I can make engine no…
For code-completions coc.nvim offers similar config and plugins as vscode. There is official lsp support for neovim now but coc.nvim works fine.
Earlier quoted context omitted.
> lighter and faster While it is true that it has advanced somewhat since it's electron days, this is still not the case. It is at best acceptable. > open source Not in any way that matters. Try packaging a not crippled version of the application and you will find out in short order.
> While it is true that it has advanced somewhat since it's electron days, this is still not the case. It is at best acceptable. It is faster than Jetbrains IDEs or Eclipse. > Not in any way that matters. Try packaging a not crippled version of the application and you will find out in short order. https://vscodium.com/
This was not my experience at all, but it's been a little while since I tested it so this could be the case.
This version is crippled. The plugin system works because of a workaround to a proprietary server, which will inevitably be broken on purpose when it gains any traction.
One tool that helped me a lot was learning about :h usr_01.txt. There are 45 or so of these pages. Reading through some of them was one of the most useful ways to learn vim. What's weird is very few blogs or articles mention these even existing despite the suggestions for using vimtutor or reviewing the :h command for finding help on specific settings.
Same goes for Emacs, nobody points you to the Info system, which is absolutely amazing. Perhaps this is because both vimtutor and the Emacs tutor do refer to their respective help systems, but given the sad state of most help systems beginners are familiar with I think they can be forgiven for not taking the recomendation seriously. Its worth really emphasizing to beginners that there is a follow up to the simple vim…
VIM - Vi IMproved
version whatever
by Bram Moolenaar et al.
Vim is open source and freely distributable
Become a registered Vim user!
type :help register for information
type :q to exit
type :help or for on-line help
type :help version8 for version info
Earlier quoted context omitted.
vim - is not my tool of trade, I am developer so I prefer IDEs like Intellij for coding and for config files I will use kate for local and for remote nano will do the job. It makes no sense to learn vim because I am hit with it once a year, I better learn tools like "tail" and "grep" this ones are useful for what I do. But sure if you are a sysadmin or ssh daily and edit big complex config files the sure learn vim if…
I mean, based on the complaints outlined in your comment above it kind of sounds like vim _is_ a tool of your trade (albeit one that you don't use very often). The basics are probably worth learning just so you don't have to care when you run into vim (opening files, inserting text, save and exit). Learn it once and you're good to go. Or you can keep resetting the default editor to nano. You do you, friend.
nano /etc/congig.cfg
my only issue was with crontab, since it was using nano but someone changed it to vim so I was surprised by it, I really had to google how to exit it. Since I edit cronjobs once a year and for config files I can use nano it would be a waste to learn vim, I would just forget all the shortcuts - not sure how other people memory works by me I forget stuff I do not use , like regexp I use them 2 times a year and each time I need to read again what symbol does what.
I am not sure who to blame for making vim the default (in EDITOR), I could swear it was nano and someone in our team had to switch it vim to fuck with the rest,
Earlier quoted context omitted.
> While it is true that it has advanced somewhat since it's electron days, this is still not the case. It is at best acceptable. It is faster than Jetbrains IDEs or Eclipse. > Not in any way that matters. Try packaging a not crippled version of the application and you will find out in short order. https://vscodium.com/
> It is faster than Jetbrains IDEs or Eclipse. This was not my experience at all, but it's been a little while since I tested it so this could be the case. > https://vscodium.com/ This version is crippled. The plugin system works because of a workaround to a proprietary server, which will inevitably be broken on purpose when it gains any traction.
I don't think that's exactly true. The marketplace server is proprietary, but you can still install extension by hand https://github.com/VSCodium/vscodium/blob/master/DOCS.md#ext.... It's not ideal, but it's far from crippled.
Earlier quoted context omitted.
I'd happily race using vim against anyone using any pointer device. Your very fast 0.1s accumulates over the day, the week, the year. Versus never moving your hand away from the keyboard.
trackpads are the keyboard, on ThinkPad laptop for example you can use it entirely with only your thumbs.
In vim, you just have your cursor inside the (...) and do `ci)`, which is (c)hange (i)nside `(, which instantly deletes all the test inside the (...) and you can type that stuff out easily
For a trackpad, don't you have to manually select all that text, hit delete, then start typing again? Or is there a better way I'm not thinking of
Earlier quoted context omitted.
stick shift That is an unfair comparison on the edge of a strawman. In vim, you see your mode right at the cursor shape (bar in insert, block in normal, selection in visual). It’s like saying that DEs are bad because switching active windows is modal. Why not send input to the first window in the taskbar by holding ctrl and to the second by holding ctrl-shift then? Does that sound absurd? Even when you make a modal m…
Yes, visual feedback reduces the chance of errors with mode switching. I believe (correct me if I'm wrong) it's one of the improvements vim has on old vi. Unlimited undo is another one vi certainly didn't have from the start. I did say the stakes are much lower. But shouldn't we make less critical interfaces with the same care we make more critical ones? And yes, many things we still have in UIs are arguably mode swi…
I don't understand how you can speak so authoritatively as if I'm accessing a completely different part of my brain when I'm using vim modes when I'm telling you that having to navigate a cursor to click, drag, and select all text is so much more context switching
And also, that ci) command? It's a language. You can do `ci"`, which is (c)hange (i)nside " to instantly change a string without having to hold the backspace button or manipulate a cursor.