101–110 of 303 posts
Earlier quoted context omitted.
On the other hand, having system wide keyboard shortcuts will almost certainly impose unwanted constraints on how an app can behave.
Exactly, that's the whole damn point. It's to constrain those app devs from making stupid UI choices.
For people picking up linux for the first time that initial impression is crucial. Dropping people like that into an editor that requires you to somehow know ":q!" is the answer is utterly insane. Same with beginner tutorials using vi. It's straight up bad for linux adoption even if technically superior. Anyone that is a vi fan likely has the skillset to install it themselves - the reverse is not always true.
I think the idea that Vim is "technically superior" should be challenged as well. I've watched, and participated in, dozens of discussions on text editors, and have never been shown a concrete piece of scientific evidence demonstrating Vim's claimed superiority according to any real-world metric. All we have are artificial comparisons where it takes Vim 37 keystrokes to transform a Christmas carol into the lyrics of a death metal song, while it takes Nano an unacceptable 51 keystrokes to do the same (of course, this only works if you take half an hour beforehand to mentally construct that 37-keystroke sequence).
There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…
If you look at how other (console) programs on the system work, Vi(m) is more consistent than Nano. ed, sed, awk, readline, even perl... knowing one of them, you know how to use vi. Likewise, know vi, you know how to use most of these tools (sans visual/modal editing abstraction). Also, it follows the Unix spirit of making small programs (in Vi(m) it can be seen as "a small number of key presses") and composing them…
In my experience, many student's first experience of a command line editor is "git commit", or a similar command, which springs the default editor on them. Learning vim because it just popped up as the default editor is almost impossible.
There was a time (2006?) when I was getting into linux. I was a big microsofty, due to comfort mostly, and I was shamed into trying Linux. Like most people I went Ubuntu first, but wifi drivers at the time were lacking, and nvidia of yore was certainly not better than nvidia of now. Suffice it to say: I spent a lot of time in the terminal trying to fix things. Nano was my tool of choice because: honestly the initial…
> We have a less powerful tool because we want to attract newbies That's exactly it. The modern metrics for anything to be successful is the number of people using it, even if they are completely useless because they did not put any effort into learning the basics. In this case, it would be essentially "ESC", "i" and ":wq". But that's waaaay too hard. No wonder everybody ships a full rootfs in a container for every s…
I mean, we'll be just fine installing vim and make it the default as needed, I'm not so sure about those raised with the "it has to be easy" mantra.
There is a very simple, end-of-discussion type argument why shipping Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works. You can have all kinds of fruitful or fruitless debates about whether there is some deeper sense in which Vim is a "superior" editor, but there is no sensible reason for it to be the default, ever. Conventi…
If you look at how other (console) programs on the system work, Vi(m) is more consistent than Nano. ed, sed, awk, readline, even perl... knowing one of them, you know how to use vi. Likewise, know vi, you know how to use most of these tools (sans visual/modal editing abstraction). Also, it follows the Unix spirit of making small programs (in Vi(m) it can be seen as "a small number of key presses") and composing them…
This is not correct, ctrl+k works anywhere on the line?
I say it seems, because I only skimmed nano documentation.
There was a time (2006?) when I was getting into linux. I was a big microsofty, due to comfort mostly, and I was shamed into trying Linux. Like most people I went Ubuntu first, but wifi drivers at the time were lacking, and nvidia of yore was certainly not better than nvidia of now. Suffice it to say: I spent a lot of time in the terminal trying to fix things. Nano was my tool of choice because: honestly the initial…
It’s “Suffice it to say…”
I've never seen the point in spending time and effort learning and memorising a bunch of vim commands. If I need to do more than simple edits to a file, I'll have a graphical desktop installed and use vscode. I tend to use nano if using a CLI as it's more intuitive.
I've never seen the point in spending time and effort learning and memorising a bunch of contextual menus that I need to point and click through. If I need to do more than simple edits to a file, I'll do the same thing as I would when making simple edits to a file or composing an email, I'll crack open vim and get to work.
Cracked me up good.