GNU nano is my editor of choice (2021)(ariadne.space)
ariadne.space
GNU nano is my editor of choice (2021)
https://ariadne.space/2021/08/13/gnu-nano-is-my-editor-of-choice/
302 comments
I'm an enthousiastic vim user. I think everyone who spends a lot if time editing text and who doesn't use vim (or similar) is probably missing out (including the author of this article). I think vim is really good.
But I 100% agree that vim is a stupid default. In almost every context it's going to confuse more people than it makes happy.
But I 100% agree that vim is a stupid default. In almost every context it's going to confuse more people than it makes happy.
Which vim? I prefer neovim personally, but it is not my default editor. I want JetBrains to get off their butts and implement first-party support for Neovim. They would be able to fully ditch their awful vim emulator, and I'm honestly astounded they still have not done a neovim first party plugin yet, or anyone for that matter (last I looked anyway). It would solidify vim for me permanently, being able to pop it into an IDE, and going to a command line and having the same editing experiences (minus IDE witchcraft right).
I think vim or neovim are both fine. The only reason I would caution against elvis is lack of Unicode support. They all give you most of the same interface.
I'm not referring to Elvis though, at least I don't think so:
https://github.com/neovim/neovim/wiki/UI-architecture
https://github.com/neovim/neovim/wiki/UI-architecture
I've tried to like neovim but plain vi works best for me. I've tried to like nano too.
Since you brought up JetBrains, I use no products made by them, at all, any more. I use Eclipse and I don't use a vi plugin in Eclipse.
My habit is if in bash, use vi, if in an IDE (or otherwise at my Ubuntu or Windows (work...I know) desktop), use a regular type of editor.
If I were young and never worked on old Korn shell systems or other old UNIX systems I'd probably not have learned vi and would be a nano user in the shell today.
Summary, in my brain, shell == vi, IDE\|desktop == regular editor
Since you brought up JetBrains, I use no products made by them, at all, any more. I use Eclipse and I don't use a vi plugin in Eclipse.
My habit is if in bash, use vi, if in an IDE (or otherwise at my Ubuntu or Windows (work...I know) desktop), use a regular type of editor.
If I were young and never worked on old Korn shell systems or other old UNIX systems I'd probably not have learned vi and would be a nano user in the shell today.
Summary, in my brain, shell == vi, IDE\|desktop == regular editor
> Since you brought up JetBrains, I use no products made by them, at all, any more.
Just curious. Why?
Just curious. Why?
I have used VI in and out since introduced to it on Xenix in 1993.
Definitely not missing out.
Definitely not missing out.
I know I'm not going to convince everyone, and I know that there are other advanced options that compete (people tell me I'm missing out because I don't use an IDE with all the auto complete stuff).
But I see a lot of people using a text editor that's basically notepad, possibly with syntax highlighting. For an occasional edit that's fine, but if you regularly spend more than an hour editing a file, you would benefit from more features.
Vim has a lot if features I don't know, so I think I'm also missing out (until I learn those features). It takes investment of time to learn an advanced tool.
I'm curious, what text editor do you use?
But I see a lot of people using a text editor that's basically notepad, possibly with syntax highlighting. For an occasional edit that's fine, but if you regularly spend more than an hour editing a file, you would benefit from more features.
Vim has a lot if features I don't know, so I think I'm also missing out (until I learn those features). It takes investment of time to learn an advanced tool.
I'm curious, what text editor do you use?
IDEs of course, and if stuck on UNIX without an IDE, either Emacs (muscle memory goes back to XEmacs glory days) or VSCode.
Pure text editor, Notepad++.
Pure text editor, Notepad++.
What do you think an IDE has that a proficient vim user is lacking?
Neovim is a different beast than vi or vim, definitely suggest looking into it. It's insanely capable, and if major IDE's invested time into supporting it, you wouldn't need to ever choose between Neovim or an IDE, you could just use both together. I think currently VS Code is the only editor that supports Neovim properly, there might be others though.
The neat benefit is you get all the editors own plugins + all of Neovims plugins.
The neat benefit is you get all the editors own plugins + all of Neovims plugins.
If stuck with classical UNIX editors, I rather spend my time on Emacs.
I know VI well enough to save me when nothing else is available, specially helpful when dealing with servers without root account access, and noexec $HOME, and that is good enough for me.
I know VI well enough to save me when nothing else is available, specially helpful when dealing with servers without root account access, and noexec $HOME, and that is good enough for me.
If Emacs ever does the headless UI thing I will crawl back to it, in all honesty. I like the idea of consistent editor key bindings across editors and consistently being able to reuse a powerful editor with any IDE.
What does it mean for an IDE to support neovim?
it probably means to run actual instance of neovim and use it as a backend for current editor's content.
Except you get features of both editors, so IntelliJ would still have their auto complete intellisense features, and Neovim key bindings would still work, and Neovim plugins as well.
Neovide is much better editor that natively supports neovim than vscode.
All vim plugins in vscode have conflicts with other extension rendering them useless
> [...] everyone [...] who doesn't use vim (or similar) is probably missing out (including the author of this article)
Did you read the article? The author used both emacs and vim. Quote:
"I don’t like either of them, for differing reasons: modal editing doesn’t really fit my mental model of how an editor should work, [...]"
I don't get how people who like modal editing can't accept that other people don't.
From my experience with editor debates this weirdly seems to be much more common than the reverse.
De gustibus non est disputandum.
Did you read the article? The author used both emacs and vim. Quote:
"I don’t like either of them, for differing reasons: modal editing doesn’t really fit my mental model of how an editor should work, [...]"
I don't get how people who like modal editing can't accept that other people don't.
From my experience with editor debates this weirdly seems to be much more common than the reverse.
De gustibus non est disputandum.
> I don't get how people who like modal editing can't accept that other people don't.
Hi. I like modal editing and kind of can't accept that other people don't.
I think they just haven't really tried, you know? In my view, it isn't a subjective matter of preference, rather I consider modal editing to be objectively superior: we have the whole keyboard at our disposal to enter commands and manipulate the text, not just tricky key combinations.
Sometimes the objection to modal editing is that you need to keep an eye on which mode you're in, but in my experience. If you're doing it right, you're always in normal mode, unless inserting text. When you finish inserting text, you immediately switch to normal mode.
There, I probably haven't convinced you nor anyone else, but I'm sure all the vim users are nodding along ;)
Hi. I like modal editing and kind of can't accept that other people don't.
I think they just haven't really tried, you know? In my view, it isn't a subjective matter of preference, rather I consider modal editing to be objectively superior: we have the whole keyboard at our disposal to enter commands and manipulate the text, not just tricky key combinations.
Sometimes the objection to modal editing is that you need to keep an eye on which mode you're in, but in my experience. If you're doing it right, you're always in normal mode, unless inserting text. When you finish inserting text, you immediately switch to normal mode.
There, I probably haven't convinced you nor anyone else, but I'm sure all the vim users are nodding along ;)
I get the feeling he occasionally used it, but not intensely for a long time.
Modal editing isn't something that comes naturally. You have to train yourself to use it. I believe everyone can learn to do it as if it's natural.
I learned how to use vi/vim a long time ago, and if you put me in the same position now I probably wouldn't learn to use it. It was a lot of effort. Having done it, I'm really glad I did, but it's hard to see how nice it is before you're put in the effort.
I also like dancing, and often a teacher will make you move in a way that doesn't feel natural. Months later, once you've got the hang of it, it makes total sense that that's the better way. It becomes natural. Driving with a stick shift didn't feel natural at first, now I miss the clutch when it's not there.
Sometimes the "unnatural" way is better. I'm guessing the same is true for the way chefs cut vegetables, or classical guitarists hold their guitar.
I won't fault anyone for not using vim, I understand it's a tradeoff and not everyone wants to put in the effort. And if you don't spend a lot of time editing text, it's not worth it.
Just to possibly annoy even more people: if you spend a lot of time on a keyboard, and you can't touch-type, I also feel you're missing out. (That wasn't natural for me at first either).
Modal editing isn't something that comes naturally. You have to train yourself to use it. I believe everyone can learn to do it as if it's natural.
I learned how to use vi/vim a long time ago, and if you put me in the same position now I probably wouldn't learn to use it. It was a lot of effort. Having done it, I'm really glad I did, but it's hard to see how nice it is before you're put in the effort.
I also like dancing, and often a teacher will make you move in a way that doesn't feel natural. Months later, once you've got the hang of it, it makes total sense that that's the better way. It becomes natural. Driving with a stick shift didn't feel natural at first, now I miss the clutch when it's not there.
Sometimes the "unnatural" way is better. I'm guessing the same is true for the way chefs cut vegetables, or classical guitarists hold their guitar.
I won't fault anyone for not using vim, I understand it's a tradeoff and not everyone wants to put in the effort. And if you don't spend a lot of time editing text, it's not worth it.
Just to possibly annoy even more people: if you spend a lot of time on a keyboard, and you can't touch-type, I also feel you're missing out. (That wasn't natural for me at first either).
There are only two kinds of non-modal editors.
1. A useless, primitive thing in which every single keystroke inserts a character or performs an edit action, and then returns to the initial state. Typically found in the simplest edit controls offered by a windowing UI, or very simple command line editors.
2. A command-oriented editor in which every action is performed by typing a line of input, terminated by Enter to execute the command. E.g. ed, almost. This is always in a command mode, which accumulates characters until Enter, executes, and returns to command mode. If there is a mode for appending lines until . (dot) is entered on a line by itself, then that is modal.
Everything else is modal.
I just fired up Nano. I made some changes and quit with Ctrl-X. Lo and behold, I was dropped into a mode in which I had to type y or n to save or not. Note that the usual action of these keys is to insert the characters y or n into the buffer. I issued y, and was dropped into another mode in which the characters I typed didn't insert into the buffer, but into a prompt asking for the file name.
1. A useless, primitive thing in which every single keystroke inserts a character or performs an edit action, and then returns to the initial state. Typically found in the simplest edit controls offered by a windowing UI, or very simple command line editors.
2. A command-oriented editor in which every action is performed by typing a line of input, terminated by Enter to execute the command. E.g. ed, almost. This is always in a command mode, which accumulates characters until Enter, executes, and returns to command mode. If there is a mode for appending lines until . (dot) is entered on a line by itself, then that is modal.
Everything else is modal.
I just fired up Nano. I made some changes and quit with Ctrl-X. Lo and behold, I was dropped into a mode in which I had to type y or n to save or not. Note that the usual action of these keys is to insert the characters y or n into the buffer. I issued y, and was dropped into another mode in which the characters I typed didn't insert into the buffer, but into a prompt asking for the file name.
Suggesting that nano and vim are both "modal editors" because nano has some confirmation dialogs is not a deep insight, it's just pedantry. And it ignores the entire reason why you'd describe an editor as modal: that changing modes is integral to the editing experience. You can't change modes in nano to make editing more efficient.
That may be the entire reason you would describe an editor as modal, but those who don't like modal editors have a different reason: they claim that they are confused by stateful behavior: that the same inputs cause different things to happen depending on what state the program is in. Usually, plenty of modal behaviors can be identified in whatever alternative they endorse. The depth of that insight is what it is.
[deleted]
> From my experience with editor debates this weirdly seems to be much more common than the reverse.
This reads like confirmation bias to me, and I would argue the inverse.
Otherwise, I agree with you. It’s ok that people have their own preferences.
This reads like confirmation bias to me, and I would argue the inverse.
Otherwise, I agree with you. It’s ok that people have their own preferences.
“because it’s not mainstream enough”
sounds like a skill issue
sounds like a skill issue
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 for more complex actions. In Vi(m), almost everything is composable with everything: jumping to the line, deleting line ranges, joining ranges, etc. In Nano (and in Emacs), you end up with tons of Ctrl-keyX-keyB-keyC presses or cursor movements.
Example: delete a line - you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. In vi, it is just "dd", no matter where your cursor is. Or, delete 5 lines from the beginning with vi: "gg5dd". Not sure how you can get more unixy than that ;)
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 for more complex actions. In Vi(m), almost everything is composable with everything: jumping to the line, deleting line ranges, joining ranges, etc. In Nano (and in Emacs), you end up with tons of Ctrl-keyX-keyB-keyC presses or cursor movements.
Example: delete a line - you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k. In vi, it is just "dd", no matter where your cursor is. Or, delete 5 lines from the beginning with vi: "gg5dd". Not sure how you can get more unixy than that ;)
The so-called "Unix spirit" is itself a rather hilarious mistake from the early days of software engineering, when programmers knew essentially nothing about human/computer interaction and foolishly believed that "efficiency" in a mathematical sense translates to efficient workflows.
It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Email and calendars are often used together, that's why they belong in the same program. Similarly, it makes sense for a programmer's editor to have an integrated terminal, and for a web browser to have an integrated bookmark manager.
"Small programs" is a bad idea that happens to sound like a good one. We don't really need to debate this, as reality has settled that debate long ago. Software serves people, not ideals of rational optimality. And default software must serve the greatest possible number of people well, else it's the wrong default.
It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation. Email and calendars are often used together, that's why they belong in the same program. Similarly, it makes sense for a programmer's editor to have an integrated terminal, and for a web browser to have an integrated bookmark manager.
"Small programs" is a bad idea that happens to sound like a good one. We don't really need to debate this, as reality has settled that debate long ago. Software serves people, not ideals of rational optimality. And default software must serve the greatest possible number of people well, else it's the wrong default.
Integration does not presuppose hard coupling. Different components can integrate and coordinate through standards.
I would argue that having one big app is the one of the worst methods of integration.
I would argue that having one big app is the one of the worst methods of integration.
> Different components can integrate and coordinate through standards.
We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks.
There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands.
Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end.
[1] https://www.nushell.sh/
We've tried that and for the most part, it doesn't actually work in practice. Hell, it doesn't even work between standard Unix programs. They don't "integrate and coordinate" at all. They just push unstructured text around, and in some cases that's sufficient to perform some very basic compound tasks.
There is an upcoming project though that tries to make Unix pipelines work the way they are supposed to: Nushell[1]. It has real composability with strongly typed data that flows between commands.
Guess how they're doing it? Yup, that's right: They're building it all as a monolithic system where the entire pipeline is supervised and interpreted by the shell. Unix is too fragmented and standards are too difficult to develop and implement for any other approach to be realistically feasible. "Small programs" are an evolutionary dead end.
[1] https://www.nushell.sh/
I think youre being uncharitable to the Unix way. the Unix way is more about having a data standard that all programs can use, rather than a front end that does everything.
yes the everything as a stream of text model didn't really scale, but I don't think that disproves the concept. all of your examples could work as well as, if not better if you standardised a data format and/ or protocol.
The current landscape for software isn't really that monolithic. software of any size implements plugins. If you look back to monolithic software of the 80s where there wasn't any expandability, wasn't things like tool kits or shared libraries. In a sense 'small software' didn't lose. it just moved up and down the stack a bit, and arguably still lives on quite successfully on mobile phones.
yes the everything as a stream of text model didn't really scale, but I don't think that disproves the concept. all of your examples could work as well as, if not better if you standardised a data format and/ or protocol.
The current landscape for software isn't really that monolithic. software of any size implements plugins. If you look back to monolithic software of the 80s where there wasn't any expandability, wasn't things like tool kits or shared libraries. In a sense 'small software' didn't lose. it just moved up and down the stack a bit, and arguably still lives on quite successfully on mobile phones.
> It took many decades of trial and error to overcome this dogma, but today's productivity software all features a massive amount of functionality integration, not functionality separation.
Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years.
That's more like the Unix philosophy, not less.
And that's not even to mention that small, composable programs and libraries are NOT incompatible with integration. In fact, they help it.
Yes, so much integration that despite JetBrains IDE functionality being first-class, we have still seen the rise of LSP over the last few years.
That's more like the Unix philosophy, not less.
And that's not even to mention that small, composable programs and libraries are NOT incompatible with integration. In fact, they help it.
LSP took off because it was designed and heavily promoted by one of the most powerful technology corporations on the planet, who already had the ears of tens of millions of developers.
The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight.
This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).
The number of proposed "standards" for solving similar problems over the years that have failed or even been completely ignored is legion. LSP is one of only a handful of software integration standards that have ever found widespread adoption. Meanwhile, there are hundreds if not thousands of integration problems where no standard is in sight.
This universal vision where micro-programs process and pass around standardized data is never going to happen, except on platforms that are completely controlled by a single vendor (see Apple).
Unix efficiency is all about saving time and paper on a teletype. It just happens to have side benefits on modern computers.
Nowadays, most people are going to know the standard Mac/windows GUI shortcuts before they touch a command line.
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.
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.
Beginners don't care about deleting a line, you can press DEL 80 times and get it done. They care about quickly typing something in or changing a config, saving and quitting. Easy to instruct with Nano without having to introduce the concept of mode editing, which is totally foreign to most beginners.
>you'd have to jump to the beginning or the end of the line first, then hit Ctrl-k.
This is not correct, ctrl+k works anywhere on the line?
This is not correct, ctrl+k works anywhere on the line?
It deletes to end of line.
Just tested in GNU nano, version 3.2, the default on Debian Buster, with default settings. Ctrl-K deletes entire line no matter where in the line you use it.
It's cutfromcursor in nanorc if you want the other behavior.
https://nano-editor.org/dist/latest/nanorc.5.html
https://nano-editor.org/dist/latest/nanorc.5.html
Nano default key bindings are not standard either. They are less different than vi from a typical GUI input controls and having a menu at the bottom of the screen help, but they force the user to get used to yet another convention.
I was considering at some point to create a patch to nano to have a simple option to switch to more common bindings or even ask the user on the first run about it. But then I discovered the micro editor and simply have been using that.
I was considering at some point to create a patch to nano to have a simple option to switch to more common bindings or even ask the user on the first run about it. But then I discovered the micro editor and simply have been using that.
The thing is that the most imporant commands are shown at the bottom and just editing a file and the exiting will prompt for a save. This is good UX. No surprises, the most likely thing the user intended is the default and doesn't require any app-sepcific knowledge.
I recall the very first time I was thrown into emacs because it was the default at university terminals (around 1993, I think). And I recall the first time I was thrown into nano (I think it was on Gentoo, maybe around 1999).
The difference in UX couldn't have been more stark.
I recall the very first time I was thrown into emacs because it was the default at university terminals (around 1993, I think). And I recall the first time I was thrown into nano (I think it was on Gentoo, maybe around 1999).
The difference in UX couldn't have been more stark.
I'm pretty sure that's due to conflicts with default console bindings. That being said, always having a cheat sheet at the bottom makes this mostly a non-issue, even when using something easier as a baseline than vi.
They're standard for beginning of line, end of line, cut line when using bash/zsh; that's already most of the way there.
I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.
I use vim day to day but I do miss pico's ctrl-k/ctrl-u behavior for doing quick block cut/paste.
most shells support both emacs shortcuts and vi style commands so there are at least 2 "standards" fwiw.
I think that's why I've never shifted from vi to nano, it appears to be a regular editor but ignores all common key bindings, ctrls+s doesn't save, ctrl+f doesn't find, ctrl+h doesn't replace, etc.
I just fired up Nano on Ubuntu 18 installation.
When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt.
Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the cursor (possibly after climbing to the previous line, if the cursor is at the start of a line), it is objectively, positively wrong.
You can distinguish Ctrl-H from backspace in a GUI system where you get detailed keyboard events. Nano has to work in a terminal.
When I typed Ctrl-S, I was prompted for a file name. Nano saved the buffer into that file. I then made edits and used Ctrl-S again; it saved again without prompting. Furthermore, if nano is invoked with a filename argument, then Ctrl-S doesn't prompt.
Ctrl-H is indistinguishable from ASCII backspace; if it does anything other than erase the character to the left of the cursor (possibly after climbing to the previous line, if the cursor is at the start of a line), it is objectively, positively wrong.
You can distinguish Ctrl-H from backspace in a GUI system where you get detailed keyboard events. Nano has to work in a terminal.
You're right ctrl+s works, I tried it, I always thought it had to be ctrl+o since that's what the bottom panel shows. I was encouraged so I highlighted some text then tried ctlr+c and ctrl+v, unless I hit a wrong key somewhere, it didn't work.
Ctrl-C and Ctrl-V are not common keybindings, unless we are talking about the Microsoft Windows environment, and graphical environments aped after it.
In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y.
Your point stands since GNU Nano doesn't stick to these either.
Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations.
Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.
In the GNU/Linux environment, the standard keybindings are the Emacs-derived ones. Ctrl-A to go to the start of the line, Ctrl-E to jump to the end, ... pasting is called "yank" and mapped to Ctrl-Y.
Your point stands since GNU Nano doesn't stick to these either.
Ctrl-C is interrupt in the TTY environment. This is so entrenched that programs which obtain Ctrl-C as ordinary input rather than a SIGINT signal still use it for interruption. E.g. in Vim, we can use Ctrl-C to interrupt long operations.
Ctrl-V is entrenched as a "verbatim" key: insert the following character literally, even if it is a control character.
+1 for Micro
Yup, I have a bunch of vim bindings to give it standard text editing behaviour because it's just too hard to kick muscle memory when you are exposed to it every day through every GUI text field's common behaviour. Jumping between vim and these makes it even harder.
I'm talking shift+arrow, ctrl+arrow, ctrl+c, ctrl+v... I know how to do it the vim way and often do, but when you jumping between vim and the rest of the world it just becomes annoying to remember to NOT use those. I find the rest of vim doesn't conflict too much... although occasionally I will accidentally type a c when selecting text outside of vim.
Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Not all, but not none.
I'm talking shift+arrow, ctrl+arrow, ctrl+c, ctrl+v... I know how to do it the vim way and often do, but when you jumping between vim and the rest of the world it just becomes annoying to remember to NOT use those. I find the rest of vim doesn't conflict too much... although occasionally I will accidentally type a c when selecting text outside of vim.
Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality. Not all, but not none.
> Unfortunately a significant chunk of what is "intuitive" is about familiarity which in turn can be more to do with commonality.
Of course, and I don't see anything unfortunate about it. Pressing buttons to make pixels on a screen change isn't a natural activity, it's a learned one. And commonality simply means there is less to learn before one can become productive, which is 100% a good thing.
Of course, and I don't see anything unfortunate about it. Pressing buttons to make pixels on a screen change isn't a natural activity, it's a learned one. And commonality simply means there is less to learn before one can become productive, which is 100% a good thing.
The convention on modern *nix is readline/libedit bindings in a shell. These default to emacs-like keybindings that nano ignores. It seems that we have a much stronger case for emacs with the menu enabled than for nano.
I can't think of any program which works like Nano. On the flip side, both man and less provide vim-style navigation. Isn't man the first program we recommend everyone use?
On the flip side, there is GNU info, readline, and bash. The latter two of which sport emacs-style navigation by default, but also support vim-style too. Perhaps where we went wrong collectively was indulging the emacs users such that people like yourself could eventually say "Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works."
On the flip side, there is GNU info, readline, and bash. The latter two of which sport emacs-style navigation by default, but also support vim-style too. Perhaps where we went wrong collectively was indulging the emacs users such that people like yourself could eventually say "Vim as the default editor is a terrible idea: Because its user interface differs significantly from how every other program on the system works."
What doesn’t work like nano? Arrow keys work, backspace deletes, it’s like a GUI text field.
Saving a file is a bit weird but it’s nothing compared to every emacs command being an unlabeled fighting game combo.
Saving a file is a bit weird but it’s nothing compared to every emacs command being an unlabeled fighting game combo.
man does not provide any navigation. It just feeds its output to PAGER which happened to be `less` on your system.
On a more bare-bones system man can feed its output to `more`. Which does not provide vim-style navigation, at least its GNU version.
On a more bare-bones system man can feed its output to `more`. Which does not provide vim-style navigation, at least its GNU version.
Personally, I'd prefer if "ne" was the default, or similar. I love nano, I've installed it many times just so I can do quick one line edits, since I have the muscle memory for nano, but something like "ne" uses standard key bindings that users of other OS' are used to like ctrl + s which some Linux neckbeards will scoff at, but you gotta understand, there is no benefit to force emacs, vim or nano on someone, other than "it forces them to read a manual" alternatively, it might also force them to never use Linux again, which is the opposite of what we all collectively want.
By that logic we should just make "ed" the default editor. It's more like every other line oriented CLI interface element in the system than Nano is.
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have.
What do you mean?
What do you mean?
$ ed
i
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
.
.s/not useful/useful/g
p
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
.s/does not have/does have/g
p
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
w ed_is_useful.txt
389
q
$ cat ed_is_useful.txt
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is useful for writing, because it does have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.
$Here’s the claim:
> [ed] does not have the immediate visual feedback when entering text that even mechanical typewriters have.
…and here’s the counterclaim:
> [ed] does not have the immediate visual feedback when entering text that even mechanical typewriters have.
…and here’s the counterclaim:
.s/does not have/does have/g
p
Typewriters don't have substitution. The immediate visual feedback when entering text in ed is that the keystrokes are echoed to the screen. This occurs regardless of whether you're writing commands or you're in insert mode, such as in this case:
i
Ed is indeed a good choice for a line editor. We're not talking about line editors, though, but about text editors. Ed is not useful for writing, because it does not have the immediate visual feedback when entering text that even mechanical typewriters have. For that, you need a text editor, and between Vim and Nano, only one behaves like most Unix software developed in the past three decades.Line / prompt input is not the same as text editing. View it from a average user / UX perspective. Having Ed as the default editor is just as surprising as Vim.
Power users and Linux geeks might prefer Vim, rightfully, but neither Vim nor Ed are good defaults. Both mandate having them used before as a prerequesite. You want something that as many people as possible can use out of the box as the default.
Power users and Linux geeks might prefer Vim, rightfully, but neither Vim nor Ed are good defaults. Both mandate having them used before as a prerequesite. You want something that as many people as possible can use out of the box as the default.
ed is worth learning. I think the very first thing I learned about computers as a child, at a weird person's behest, was EDLIN.EXE
Ed is the right editor for a Unix simulation running inside a ChatGPT session.
Conversely, as multi-decade Unix user, when I type in "vi" I want to get Vi, I do not want Vim starting.
If I wanted Vim I would have typed in "vim".
If I wanted Vim I would have typed in "vim".
Why?
As per another reply: all the unneeded crayon colours that are displayed when all I want to do is edit a couple of lines in a plain text file.
For me personally, the godawful default syntax highlighting is … quite unfortunate
You don't have to learn vim to craft a git message, most people where I work only know how to exit and they are perfectly fine using vim here or there as prompted.
If someone were to learn to use CLI to begin with, I don't mind sprinkling them with some vi. It's UX for those who are already doing CLI, not some people lingering on GUI.
Though it's not surprising that someone who believe vim has no benefit whatsoever over other editors have this take, quoth another comment that I replied to in this thread:
> 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.
If someone were to learn to use CLI to begin with, I don't mind sprinkling them with some vi. It's UX for those who are already doing CLI, not some people lingering on GUI.
Though it's not surprising that someone who believe vim has no benefit whatsoever over other editors have this take, quoth another comment that I replied to in this thread:
> 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.
How about touchtyping some code in your favourite language but not in linear way? Edit one line here, delete 2 lines there, use some regexp, etc.
I would prefer to use vim over nano personally but as a default, I agree nano is a far better choice.
there is no "default editor" in unix systems per se, only installed by default. whatever the user/distribution sets in $EDITOR/$VISUAL is the one being called.
vi/vim became "default" on linux distros because it was simply always available while emacs was an optional kitchen sink package and there were no other widely accepted alternatives (like midnight commander's built in editor or nano).
vi/vim became "default" on linux distros because it was simply always available while emacs was an optional kitchen sink package and there were no other widely accepted alternatives (like midnight commander's built in editor or nano).
That is easily solved by configuring other programs to use vi keybindings by default. Shells including bash and zsh can be configured to run in a vi-compatible mode, and so can many other programs - there are even chrome and firefox extensions to enable vi keybindings.
Nevertheless, for some reason no one seems to have created a Linux distribution with pure vi input conventions...
Nevertheless, for some reason no one seems to have created a Linux distribution with pure vi input conventions...
ed is the only editor which works like every other console program on the system. Nano does not work like every other program on the system. Neither vi nor nano should be shipped in the base system.
This is the reason why ed was originally "the standard editor".
Of course, moving from teletypes to terminals made it quite irrelevant as we moved to ex/nvi, but ed still has its advantages. It only requires a kernel and a libc, forget even needing ncurses or termcap. It was running perfectly fine on an 11/40 running V6 on 250kB of memory, so it has stayed insanely resource efficient by today standards.
It's not even that bad once the verbose errors are activated (H), and it's still better than using sed or cat > << to recover a partition.
Of course, moving from teletypes to terminals made it quite irrelevant as we moved to ex/nvi, but ed still has its advantages. It only requires a kernel and a libc, forget even needing ncurses or termcap. It was running perfectly fine on an 11/40 running V6 on 250kB of memory, so it has stayed insanely resource efficient by today standards.
It's not even that bad once the verbose errors are activated (H), and it's still better than using sed or cat > << to recover a partition.
There are two types of linux developers, those who use nano and those who haven't yet figured out how to quit vim.
If I forget to change the default editor in Debian and Nano pops up, I have to consult a search engine how to exit it. Just like other people do for Vim, except that Nano's interface is horrible.
It is a weird decision, much like shipping Exim as the default MTA.
It is a weird decision, much like shipping Exim as the default MTA.
If you're googling how to exit nano you're blind. The one thing nano does right with its defaults is to list all the common bindings at the bottom of the screen
^X is …?
It totally obviously means shift + 6 + X.
Too bad that doesn’t exit the program.
Macs in 2022 have an extra ^ on the correct button.
It totally obviously means shift + 6 + X.
Too bad that doesn’t exit the program.
Macs in 2022 have an extra ^ on the correct button.
> Replacing Vi(m) with Nano in the standard install was one of the most important UX decisions made by the major distros in recent years
It sounds like you want a unix with the UI/UX of a different OS. If a user is coming from a world where editors have all coped MS-DOS edit and its notepad progeny then nano makes sense. I am sure this goes for whatever default editor comes with Mac.
If a user is coming from a Unix world where ed, xi and vi were defaults since the beginning then vi makes sense.
This isn't arrogance, its history. Ignoring this part and insisting foreign concepts implemented as defaults to accommodate foreign os users from having to learn to use a new platform is arrogance. Unix has a lost a lot of its heritage to this kind of thinking.
Back in the day you learned how to use a computer using manuals: man intro. Today you install an os and blindly bump into walls hoping to learn the os using discoverable ui hints then falling back to google when that fails. Treating the ui as a discoverable manual means ui changes break the manual which angers and frustrates users. See the whole MS ribbon debate.
It sounds like you want a unix with the UI/UX of a different OS. If a user is coming from a world where editors have all coped MS-DOS edit and its notepad progeny then nano makes sense. I am sure this goes for whatever default editor comes with Mac.
If a user is coming from a Unix world where ed, xi and vi were defaults since the beginning then vi makes sense.
This isn't arrogance, its history. Ignoring this part and insisting foreign concepts implemented as defaults to accommodate foreign os users from having to learn to use a new platform is arrogance. Unix has a lost a lot of its heritage to this kind of thinking.
Back in the day you learned how to use a computer using manuals: man intro. Today you install an os and blindly bump into walls hoping to learn the os using discoverable ui hints then falling back to google when that fails. Treating the ui as a discoverable manual means ui changes break the manual which angers and frustrates users. See the whole MS ribbon debate.
Your point seems to assume that reading manuals is the 'right' way to learn about working with a system.
While it is the preferred way for myself I acknowledge that it is not for a lot of other people.
Furthermore you can easily configure any distro today to 'respect history' as much as you desire by changing a few config files.
That doesn't change the face that the average person interacting with a *nix OS today will not share this history.
Discoverability in UX is a key concept. The people who came up with what you call 'history' simply had no clue about it.
Human Computer Interfaces (HCI, what now broadly falls under the term 'UX') was a subject you studied decoupled from the rest of CS (if the university even offered this). People writing tools where oblivious to UX. And the users where the same folks.
I would go as far and say that ignoring this and insisting on these modal editors as defaults because 'history' indeed borders on arrogance for this very reason.
While it is the preferred way for myself I acknowledge that it is not for a lot of other people.
Furthermore you can easily configure any distro today to 'respect history' as much as you desire by changing a few config files.
That doesn't change the face that the average person interacting with a *nix OS today will not share this history.
Discoverability in UX is a key concept. The people who came up with what you call 'history' simply had no clue about it.
Human Computer Interfaces (HCI, what now broadly falls under the term 'UX') was a subject you studied decoupled from the rest of CS (if the university even offered this). People writing tools where oblivious to UX. And the users where the same folks.
I would go as far and say that ignoring this and insisting on these modal editors as defaults because 'history' indeed borders on arrogance for this very reason.
> The people who came up with what you call 'history' simply had no clue about it.
Saying they didn't have a clue is both disingenuous to those who worked hard on these problems and flat out wrong.
These programs were written for text terminals running over links who's speed was measured in hundreds or thousands of bits per second. The UI had to be as simple and efficient as possible to enable a decent UX over such slow lines. The UI was sacrificed for the UX. Of course after networks got faster these editors weren't necessary but guess what, they were understood, worked and there by default. And they still are. I see no issue with this and learning vi is actually simple once you RTFM.
Saying they didn't have a clue is both disingenuous to those who worked hard on these problems and flat out wrong.
These programs were written for text terminals running over links who's speed was measured in hundreds or thousands of bits per second. The UI had to be as simple and efficient as possible to enable a decent UX over such slow lines. The UI was sacrificed for the UX. Of course after networks got faster these editors weren't necessary but guess what, they were understood, worked and there by default. And they still are. I see no issue with this and learning vi is actually simple once you RTFM.
Are you arguing that discoverability in user interfaces is bad?
Back in the day you'd write your own driver where need be, and compiled almost everything. I'm quite happy to not be back in the day and will take nano for editing a config file over writing C in Vim.
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 learning curve of linux and a modal text editor was far too much.
that said: when I was later shamed into using vi/vim instead of nano.. after my initial hesitation (and a few rounds on vimtutor) I was as confident as I was on nano... what's more, I was "unlocked" and started learning new and faster ways to move.
Being able to replay my last action with "." was nice, and lead me to learn even more native movements.
My watershed moment came when I had to delete a leading series of characters in a file of I think 500 lines.. Not enough to say it's impossible but a real chore.
Nano would not help me in such a situation: but vim did it with no complaints; all I needed to know was the incantation.
I feel like nano shipping as the default editor is a step-back. We have a less powerful tool because we want to attract newbies, but it's the same mistake microsoft makes; When I was into microsoft tooling I had no idea how handicapped I was, the learning curve always had a stop point: everything beyond it was impossible.
I will always be thankful I learned linux in a time where the hand-rails were starting to come up, but that we still used powerful and expressive tools instead of being jailed to the opaque and inflexible systems that have come to dominate for the sake of convenience.
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 learning curve of linux and a modal text editor was far too much.
that said: when I was later shamed into using vi/vim instead of nano.. after my initial hesitation (and a few rounds on vimtutor) I was as confident as I was on nano... what's more, I was "unlocked" and started learning new and faster ways to move.
Being able to replay my last action with "." was nice, and lead me to learn even more native movements.
My watershed moment came when I had to delete a leading series of characters in a file of I think 500 lines.. Not enough to say it's impossible but a real chore.
Nano would not help me in such a situation: but vim did it with no complaints; all I needed to know was the incantation.
I feel like nano shipping as the default editor is a step-back. We have a less powerful tool because we want to attract newbies, but it's the same mistake microsoft makes; When I was into microsoft tooling I had no idea how handicapped I was, the learning curve always had a stop point: everything beyond it was impossible.
I will always be thankful I learned linux in a time where the hand-rails were starting to come up, but that we still used powerful and expressive tools instead of being jailed to the opaque and inflexible systems that have come to dominate for the sake of convenience.
> I feel like nano shipping as the default editor is a step-back. We have a less powerful tool because we want to attract newbies
Perhaps, but your experience sounds like a good blueprint for what new terminal users might want. Start with nano move to more powerful tools when you need them.
Perhaps, but your experience sounds like a good blueprint for what new terminal users might want. Start with nano move to more powerful tools when you need them.
Windows ships with Notepad, which is fine for 99.9% of users.
Those who need more know how to install Notepad++, UltraEdit or Sublime.
Those who need more know how to install Notepad++, UltraEdit or Sublime.
If someone asked you what drill they should buy having never used a drill before, not knowing what theyre going to use it for, but probably 'hanging pictures and stuff'. Would you suggest a top of the line SDS Max drill, or would you suggest some bog standard inexpensive drill that does the basics?
less powerful doesn't mean worse if you aren't using the features. It just makes it harder to use.
less powerful doesn't mean worse if you aren't using the features. It just makes it harder to use.
my concern would be that I dont think people would reach for the more powerful tools; since they arent being pressured into learning them and its impossible to articulate the power you would get until you have it.
I was extremely resistant to learn new things when I thought my current way of working was perfectly fine.
It’s only retrospectively that I realise how limited I was.
I was extremely resistant to learn new things when I thought my current way of working was perfectly fine.
It’s only retrospectively that I realise how limited I was.
It's also hard to articulate power if the people have no need for that power. People stay with nano because it's intuitive and good enough at editing some config files. What else would someone learning Linux even do with a text editor?
I've tried to get into vi and emacs but I honestly never found a good use case for them, even as a developer. When I edit files, the changes are usually very small and I spent most time thinking about what to change. The time it takes to execute that change is negligible. If I need to process large files, those are usually in some kind format that can be manipulated with other tools much more easily. And when it comes to programming, modern IDEs are far superior.
I don't doubt that you can be very productive with these editors but the "it's more powerful" argument always seems to mean "look how I fast I can manipulate large unstructured text files with some keyboard shortcuts magic", which is irrelevant to me.
I've tried to get into vi and emacs but I honestly never found a good use case for them, even as a developer. When I edit files, the changes are usually very small and I spent most time thinking about what to change. The time it takes to execute that change is negligible. If I need to process large files, those are usually in some kind format that can be manipulated with other tools much more easily. And when it comes to programming, modern IDEs are far superior.
I don't doubt that you can be very productive with these editors but the "it's more powerful" argument always seems to mean "look how I fast I can manipulate large unstructured text files with some keyboard shortcuts magic", which is irrelevant to me.
[deleted]
> I was extremely resistant to learn new things when I thought my current way of working was perfectly fine.
It’s not the OS’ job to lecture users about their tools of choice. The Web is full of “vim is the dog’s bollocks” articles, if anyone has a modicum of interest to look at more complex tools.
Now, we have to just set EDITOR in the dotfiles for each new student we get starting their MSc project. They have 6 months to do quantum chemistry stuff, not winning flame wars about whose editor is best. And they have already a lot of inane idiosyncrasies to learn in R and the usual Python libraries.
It’s not the OS’ job to lecture users about their tools of choice. The Web is full of “vim is the dog’s bollocks” articles, if anyone has a modicum of interest to look at more complex tools.
Now, we have to just set EDITOR in the dotfiles for each new student we get starting their MSc project. They have 6 months to do quantum chemistry stuff, not winning flame wars about whose editor is best. And they have already a lot of inane idiosyncrasies to learn in R and the usual Python libraries.
> 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 single executable they make... if learning how to quit vim is too hard, who would want to learn about packaging?
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 single executable they make... if learning how to quit vim is too hard, who would want to learn about packaging?
It's not about difficulty of pressing a few keys, it's about discover-ability.
When you start vim, it says "type :help <register>Enter for information". When you do that, it starts with "Move around: Use the cursor keys, or "h" to go left, [...]".
eheh, so much this. I was about to comment in a less sarcastic way but essentially the same thing.
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.
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.
> I was about to comment in a less sarcastic way
Yeah sorry, I really did not mean to sound aggressive, just trying to share my point. Communication is hard :-).
Yeah sorry, I really did not mean to sound aggressive, just trying to share my point. Communication is hard :-).
This is so wrong. 'they don't want to learn, lets force them'. Understanding that some people don't need it might be waaaay too hard.
Majority of people don't need 'more powerful tool', which needs to be learned for more time than they actually need to use it.
I never said "let's force them". My point is rather that it is fine for projects to not design for the majority. And I really feel like this is quite an unpopular opinion, somehow. The measure for success is typically the number of users, and of course it means that it has to be as simple as possible.
To me, it's perfectly fine to set nano as a default for a distro targeting beginners, but it is also perfectly fine to set vim as a default and say: "if using vim to change the default editor is too hard for you, then you are not the target audience".
To me, it's perfectly fine to set nano as a default for a distro targeting beginners, but it is also perfectly fine to set vim as a default and say: "if using vim to change the default editor is too hard for you, then you are not the target audience".
> Nano would not help me in such a situation: but vim did it with no complaints; all I needed to know was the incantation.
Nano can do regexp search and replace. I think the problem with nano is the menu in the bottom because it makes people think that it's the only things it can do when in fact it's really powerful.
Nano can do regexp search and replace. I think the problem with nano is the menu in the bottom because it makes people think that it's the only things it can do when in fact it's really powerful.
Couple weeks ago I learned hard way that : key just don’t work in certain combination of host locale and VNC client and client locale.
C-c didn’t work, Ctrl+Alt+F2 didn’t work, ssh didn’t work because sshd is not up yet, even VM power cycling button was stuck and didn’t work. Maybe a custom VNC client could have worked. I think I ended up rebooting the host once, just to get out of vi. Second time I just changed locales.
nano by default is good.
C-c didn’t work, Ctrl+Alt+F2 didn’t work, ssh didn’t work because sshd is not up yet, even VM power cycling button was stuck and didn’t work. Maybe a custom VNC client could have worked. I think I ended up rebooting the host once, just to get out of vi. Second time I just changed locales.
nano by default is good.
ZZ would probably have worked for you for quitting (seems to work in plain vi as well as the vims)
This seems a frequent enough issue, that searching "centos can't type colon" in my language yield bunch of SEO blogspams recommending `Shift+11` and `Shift+ZZ`. But neither of which worked in my case; I think Shift+1 was bugged and the file wasn't writable.
>Nano would not help me in such a situation
You could regexp replace all '^[a-z]{4}' (or whatever) with ''. Alternatively you could select area and execute '|sed <whatever>' or '|cut <whatever>'. Advantage: you use the tools you're already familiar with.
You could regexp replace all '^[a-z]{4}' (or whatever) with ''. Alternatively you could select area and execute '|sed <whatever>' or '|cut <whatever>'. Advantage: you use the tools you're already familiar with.
> the initial learning curve of linux and a modal text editor was far too much
> I feel like nano shipping as the default editor is a step-back
Not sure why you'd say it's a step back after giving a very valid reason for why it's a step forward.
Editing configuration files as a beginner can be frustrating on its own. The added friction of fighting with your editor when you just want to change a single line is not something I wanted to deal with.
> I feel like nano shipping as the default editor is a step-back
Not sure why you'd say it's a step back after giving a very valid reason for why it's a step forward.
Editing configuration files as a beginner can be frustrating on its own. The added friction of fighting with your editor when you just want to change a single line is not something I wanted to deal with.
I guess it depends on how you use the system. I have no intention of ever using a Linux as my “main” system. I’m always a visitor on a strange foreign system. I hold my nose, go in, do whatever dirty deed must be done to get it working again.
Usually it’s in some docker image, or an old pi used in my closet, maybe a router, or a cloud vm. But regardless it’s never “home”. I don’t have a personal user, I don’t have a home directory with my own config files. My user is “pi” or “root” or something to that effect. I have been logged in there before, but each time I need to find my way around from scratch. All I need to do is edit some files and get the hell out. And nano is just perfect for it.
Perhaps the worst use of vi-as-a-default is in Cygwin (used to run git on windows by some people still) where vi is popped up to let windows users fill in a git commit message. Fantastic UX. I don’t blame Cygwin for it, but git-for-windows could ship with a different default (even notepad would have been better).
Usually it’s in some docker image, or an old pi used in my closet, maybe a router, or a cloud vm. But regardless it’s never “home”. I don’t have a personal user, I don’t have a home directory with my own config files. My user is “pi” or “root” or something to that effect. I have been logged in there before, but each time I need to find my way around from scratch. All I need to do is edit some files and get the hell out. And nano is just perfect for it.
Perhaps the worst use of vi-as-a-default is in Cygwin (used to run git on windows by some people still) where vi is popped up to let windows users fill in a git commit message. Fantastic UX. I don’t blame Cygwin for it, but git-for-windows could ship with a different default (even notepad would have been better).
Exactly this. That's why I often read comments like "just install zsh it's so good", or "I have this vim config with plugins and everything works as I expect" and have to react - "ok, good for you, but I have to use fresh installs of linux exclusively, often embedded, and I just pray it's not a busybox, so only defaults for me forever". Learning vim to edit a few lines a week on some remote host, because they didn't bother to include nano is ugh... Bad.
honestly, I think you’re right.
one of the things I failed to mention was that one of the reasons I learned vi is that it was the only editor available across all unix and unix-likes. I think it was even mandated by POSIX.
Often these days fresh installs come with nano and not vi, which means that we are tailoring fresh minimal installs to non-power users at the cost of power users. Which is probably what I’m upset about.
I like that nano is available and easy to get; i think it should be in the default installation for anything larger than a pxe image or minimal install, but I am not a fan of this kind of behaviour change.
Git for windows makes a huge deal in its installer about how the default is unchanged for compatibility and how you should pick nano or vsc instead
It should really at least give notepad as an option and strongly suggest that over vi unless you are looking for compat (compat with what?).
Tbh I don’t know why you’d want a bash for it to begin with. The only thing I miss in other shells (cmd/PS) is that you can’t make shell aliases in git.
Tbh I don’t know why you’d want a bash for it to begin with. The only thing I miss in other shells (cmd/PS) is that you can’t make shell aliases in git.
Compatibility with old scripts I presume. And notepad is probably on the list too.
But of course you want bash with git. PS and cmd are just painful to use
But of course you want bash with git. PS and cmd are just painful to use
Something that annoys me is that the only good thing about vim is the idea of composable modal actions.
Don't get me wrong, that feature alone is powerful enough to choose vim as your editor of choice, but... There is no reason whatsoever why you couldn't have an editor with 2022's standards of UX and newbie friendliness that makes use of the same idea; it just hasn't happened.
Even when modern editors adapt vim functionality as a plugin, they just replicate the original design choices. Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.
Has anyone heard of a (serious / developed) effort to create such a product?
Don't get me wrong, that feature alone is powerful enough to choose vim as your editor of choice, but... There is no reason whatsoever why you couldn't have an editor with 2022's standards of UX and newbie friendliness that makes use of the same idea; it just hasn't happened.
Even when modern editors adapt vim functionality as a plugin, they just replicate the original design choices. Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.
Has anyone heard of a (serious / developed) effort to create such a product?
> Has anyone heard of a (serious / developed) effort to create such a product?
The closest I can think of is Helix.
> Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.
Nitpicking a bit, but you can also escape insert mode with Ctrl+[ and alt+any normal mode keybinding. I tend to use alt+h/j/k/l but nothing prevents you from doing for e.g. alt+u to escape insert mode while undoing the previous action.
The closest I can think of is Helix.
> Esc to escape insertion mode is clearly a stupid choice in a modern keyboard setup, but we keep it as a default; we just haven't moved past the original decision.
Nitpicking a bit, but you can also escape insert mode with Ctrl+[ and alt+any normal mode keybinding. I tend to use alt+h/j/k/l but nothing prevents you from doing for e.g. alt+u to escape insert mode while undoing the previous action.
I guess vim keybinds are so ubiquitous it’s probably more valuable to stick with them. If you are truly offended by a particular choice, you can always change them.
It's janky, but does lapce fit your bill?
I just took a look and the docs only say there’s “vim like modal editing”. Given there’s no more info I guess it’s just vim mode? There doesn’t seem to be an effort to redesign it at least.
> I feel like nano shipping as the default editor is a step-back.
I’ve never used a distribution that includes nano, but not also some variety of vi and/or emacs. And there’s no “favorite”/“default” binding in terminal.
There are defaults in the GUI, however those are almost exclusively Kate or gEdit. And new users probably use those far more frequently as their first editor.
The only qualifier I can figure for nano being a default is the number of tutorials/guides that use it.
I’ve never used a distribution that includes nano, but not also some variety of vi and/or emacs. And there’s no “favorite”/“default” binding in terminal.
There are defaults in the GUI, however those are almost exclusively Kate or gEdit. And new users probably use those far more frequently as their first editor.
The only qualifier I can figure for nano being a default is the number of tutorials/guides that use it.
> And there’s no “favorite”/“default” binding in terminal.
There is.
There is the EDITOR environment variable and the alternatives editor. They will be used when a program triggers an interaction that uses a text editor (e.g., mutt, git and more) instead of manually opening an editor yourself.
There are also distributions that only ship with a minimal set of editors, forcing you to install different ones. This might also be considered a "default" editor by lots of people.
edit: if you consider a "default binding" only one for manually opening a text file, then you are right, but I don't think that is what people talk about when referencing a "default text editor"
There is.
There is the EDITOR environment variable and the alternatives editor. They will be used when a program triggers an interaction that uses a text editor (e.g., mutt, git and more) instead of manually opening an editor yourself.
There are also distributions that only ship with a minimal set of editors, forcing you to install different ones. This might also be considered a "default" editor by lots of people.
edit: if you consider a "default binding" only one for manually opening a text file, then you are right, but I don't think that is what people talk about when referencing a "default text editor"
[deleted]
visudo opens nano on most distributions (ubuntu, debian) despite the name being visudo.
whatever the root users $EDITOR variable is set to (and any subsequent created user) is the default.
vi/vim wasn't even installed last time I installed ubuntu minimal: but nano was.
whatever the root users $EDITOR variable is set to (and any subsequent created user) is the default.
vi/vim wasn't even installed last time I installed ubuntu minimal: but nano was.
> Sufficed to say: I spent a lot of time in the terminal trying to fix things.
It’s “Suffice it to say…”
It’s “Suffice it to say…”
> honestly the initial learning curve of linux and a modal text editor was far too much
[...]
> I feel like nano shipping as the default editor is a step-back
Make up your mind about nano being the easy way in, or just admit that you like the vim gatekeeping?
[...]
> I feel like nano shipping as the default editor is a step-back
Make up your mind about nano being the easy way in, or just admit that you like the vim gatekeeping?
nano is anything but "not powerful".
i have yet to find someone doing complex editing stuff in vim that i cant do (i.e. with the same effort or less) in nano. Unironically.
i have yet to find someone doing complex editing stuff in vim that i cant do (i.e. with the same effort or less) in nano. Unironically.
In particular, unless I misunderstood the problem, removing the first n characters in nano works exactly as it would in vim. Regex replace "^...." with "".
Or replace a selection with the output from a call to 'cut'.
Or replace a selection with the output from a call to 'cut'.
Using those kind of Unix tools is like having a time travel machine to understand what kind of mistakes you should never do when Iyou design a software.
Not having system wide keyboard shortcuts is one of them: vim, emacs, nano etc all have a different shortcut to quit the app
Worse still, every software invents his own configuration format.
Thinking that being ultra configurable is a good excuse for not doing the right thing by default is another big one. Syntax highlighting should just work, not only sort of work when you learn a configuration syntax and install little known third party packages
Not having system wide keyboard shortcuts is one of them: vim, emacs, nano etc all have a different shortcut to quit the app
Worse still, every software invents his own configuration format.
Thinking that being ultra configurable is a good excuse for not doing the right thing by default is another big one. Syntax highlighting should just work, not only sort of work when you learn a configuration syntax and install little known third party packages
Right. So everyone should use system-wide keyboard shortcuts. Preferably your favourites, right? At least they should work well for your favourite window manager, I suppose? Because those who like different shortcuts and different window managers are weird and don't understand UX. /s
My preference is to start with a minimalistic system that works on most platforms, and where I can install what I want. If I wanted a system with "sane defaults from someone else's point of view" and working only on a handful of platforms, I would use macOS.
My preference is to start with a minimalistic system that works on most platforms, and where I can install what I want. If I wanted a system with "sane defaults from someone else's point of view" and working only on a handful of platforms, I would use macOS.
> Preferably your favourites, right?
System-wide does not imply unconfigurable, it just means that all programs derive some of their behavior from an external source.
If I want Ctrl+P to paste text across every single application that accepts text and I only have to configure it once in one place, I see that as a win.
System-wide does not imply unconfigurable, it just means that all programs derive some of their behavior from an external source.
If I want Ctrl+P to paste text across every single application that accepts text and I only have to configure it once in one place, I see that as a win.
> If I want Ctrl+P to paste text across every single application that accepts text and I only have to configure it once in one place, I see that as a win.
Ok, so let's say I write a video game. Should my game have reasonable defaults, or should it ask you to go to your system-wide settings and setup all the bindings for my game? For instance, I have a "jump" action. Can I bind it to the spacebar, or should I go check in your system settings what you have assigned to "jump"? What if you have not assigned anything to "jump", should I choose a free shortcut somehow (say using the first available from a list like [spacebar, j, right-shift]) or should I ask the player to go setup the bindings first?
Say people are happy having exactly one configuration for all their programs. What if my game has special controls, and instead of using "awsd" to move, I would like to use "qweasd", but "q" is generally assigned to "quit". Should I give up on having a reasonable UX using the keyboard (because the system-wide shortcuts don't work for my game) and sell my game with an external controller then?
That's the whole thing with standards. It's perfect if you want to do exactly what the standard specifies. It's terrible if you don't. Freedom generally doesn't go well with standard, and somehow it feels like a tradeoff: macOS has a better user experience than linux, at the cost of some freedom. And that's perfectly fine IMO: I don't expect macOS to give me more freedom, or Linux to give me a macOS UX. I just choose between them.
Ok, so let's say I write a video game. Should my game have reasonable defaults, or should it ask you to go to your system-wide settings and setup all the bindings for my game? For instance, I have a "jump" action. Can I bind it to the spacebar, or should I go check in your system settings what you have assigned to "jump"? What if you have not assigned anything to "jump", should I choose a free shortcut somehow (say using the first available from a list like [spacebar, j, right-shift]) or should I ask the player to go setup the bindings first?
Say people are happy having exactly one configuration for all their programs. What if my game has special controls, and instead of using "awsd" to move, I would like to use "qweasd", but "q" is generally assigned to "quit". Should I give up on having a reasonable UX using the keyboard (because the system-wide shortcuts don't work for my game) and sell my game with an external controller then?
That's the whole thing with standards. It's perfect if you want to do exactly what the standard specifies. It's terrible if you don't. Freedom generally doesn't go well with standard, and somehow it feels like a tradeoff: macOS has a better user experience than linux, at the cost of some freedom. And that's perfectly fine IMO: I don't expect macOS to give me more freedom, or Linux to give me a macOS UX. I just choose between them.
> Ok, so let's say I write a video game. Should my game have reasonable defaults, or should it ask you to go to your system-wide settings and setup all the bindings for my game?
Note that I specifically mentioned text. We've all agreed on how to write text, we've all agreed on how to read text, why can't we all agree on how we edit text? Text is a universal standard, games are not. Your game can have whatever keybindings it deems sane but the second I click on a textbox to enter my name I expect my keybindings to work because I'm no longer in the game's context, I'm inside a text context.
Using the user's preferences is a sane default but it's just that - a default, capable of being altered. That default might not be the most intuitive for your specific application and you can let the user know there's a better alternative but at least that default doesn't completely paralyze the user until they've taken the time to learn your specific way of doing things, as is the case with Vim.
Note that I specifically mentioned text. We've all agreed on how to write text, we've all agreed on how to read text, why can't we all agree on how we edit text? Text is a universal standard, games are not. Your game can have whatever keybindings it deems sane but the second I click on a textbox to enter my name I expect my keybindings to work because I'm no longer in the game's context, I'm inside a text context.
Using the user's preferences is a sane default but it's just that - a default, capable of being altered. That default might not be the most intuitive for your specific application and you can let the user know there's a better alternative but at least that default doesn't completely paralyze the user until they've taken the time to learn your specific way of doing things, as is the case with Vim.
>why can't we all agree on how we edit text
We haven't agreed on a script, keyboard, etc. Given that I don't expect us to agree on how to edit text. What are we going with to base this decision on for starters? Popularity? Utility? something else?
We haven't agreed on a script, keyboard, etc. Given that I don't expect us to agree on how to edit text. What are we going with to base this decision on for starters? Popularity? Utility? something else?
> why can't we all agree on how we edit text?
Because there are some extremely different ways of editing text out there. As you mention, vim and emacs are extremely different from Word, though extremely popular. There are certainly many more examples, but I believe those 3 are enough to say that we most definitely have not all agreed on how to edit text.
Because there are some extremely different ways of editing text out there. As you mention, vim and emacs are extremely different from Word, though extremely popular. There are certainly many more examples, but I believe those 3 are enough to say that we most definitely have not all agreed on how to edit text.
> Because there are some extremely different ways of editing text out there.
Key word here being _different_. Different should not be the default. That does not mean we should all be forced to edit text the same way, it just means that the most widely used way of editing text should be the default.
For the most part we have agreed on what the standard way of editing text is in GUI's. nano has its quirks but at least it follows the most widely accepted standard - if you're inside a text editor and start typing text, the text gets appended and magical things happen to your text only after you press a combination of keys.
Key word here being _different_. Different should not be the default. That does not mean we should all be forced to edit text the same way, it just means that the most widely used way of editing text should be the default.
For the most part we have agreed on what the standard way of editing text is in GUI's. nano has its quirks but at least it follows the most widely accepted standard - if you're inside a text editor and start typing text, the text gets appended and magical things happen to your text only after you press a combination of keys.
> it just means that the most widely used way of editing text should be the default.
Yeah, maybe. Not entirely convinced though :-). There is a tendency to reinforce the most widely used ways everywhere. As an artist, you can choose to make the kind of music most people want to hear in a night club, or make the kind of music you, as a musician, like. And accept that maybe that's not for the majority.
The majority is using Windows/macOS/Android/iOS. Linux distros are mostly used for servers (where I would hope that a sysadmin can learn a handful of vim bindings (ESC, "i", ":wq" is enough to start)), and some people (me included) are using a Linux Desktop.
Of course, the more popular Linux Desktop gets, the more people will want it to look like Windows/iOS (because those are by far the most popular). Does that mean all Linux Desktop distros should try to get adopted by those people? I don't think so. Fine if Ubuntu wants to make a "FOSS alternative to macOS", but I would find it sad if it did force others to follow. And it does: most devs don't really know Linux and want the macOS experience, end up using Ubuntu, and write code that works only on Ubuntu. So now many apps rely on e.g. systemd just because Ubuntu chose it. I find it a bit sad.
Yeah, maybe. Not entirely convinced though :-). There is a tendency to reinforce the most widely used ways everywhere. As an artist, you can choose to make the kind of music most people want to hear in a night club, or make the kind of music you, as a musician, like. And accept that maybe that's not for the majority.
The majority is using Windows/macOS/Android/iOS. Linux distros are mostly used for servers (where I would hope that a sysadmin can learn a handful of vim bindings (ESC, "i", ":wq" is enough to start)), and some people (me included) are using a Linux Desktop.
Of course, the more popular Linux Desktop gets, the more people will want it to look like Windows/iOS (because those are by far the most popular). Does that mean all Linux Desktop distros should try to get adopted by those people? I don't think so. Fine if Ubuntu wants to make a "FOSS alternative to macOS", but I would find it sad if it did force others to follow. And it does: most devs don't really know Linux and want the macOS experience, end up using Ubuntu, and write code that works only on Ubuntu. So now many apps rely on e.g. systemd just because Ubuntu chose it. I find it a bit sad.
> Yeah, maybe. Not entirely convinced though :-)
You didn't actually provide an argument against having a sane set of defaults with the option to configure them later.
> As an artist, you can choose to make the kind of music most people want to hear in a night club, or make the kind of music you, as a musician, like. And accept that maybe that's not for the majority.
"For art" is a non-answer when it comes to UX - being "artsy" is almost always terrible UX, including in this particular manner of keyboard shortcuts - very, very few people want "artsy" shortcuts, almost everyone wants familiar defaults, and some people want to then configure the bindings after they've gotten used to the tool a bit.
Art is, by definition, about creativity and originality, which is almost the polar opposite of good UX, which is standardization and conformity.
Making a video game with some esoteric control scheme? Fine, go crazy with your input design, people may love it - that is an artistic matter, less so a UX matter. Making an actual tool that people need to use to get work done? That's a UX problem, and your job is to design the tool to be as painless to use as possible, not to be creative, because your creative desire will, unless controlled very carefully, directly lead to pain and frustration of your users.
You didn't actually provide an argument against having a sane set of defaults with the option to configure them later.
> As an artist, you can choose to make the kind of music most people want to hear in a night club, or make the kind of music you, as a musician, like. And accept that maybe that's not for the majority.
"For art" is a non-answer when it comes to UX - being "artsy" is almost always terrible UX, including in this particular manner of keyboard shortcuts - very, very few people want "artsy" shortcuts, almost everyone wants familiar defaults, and some people want to then configure the bindings after they've gotten used to the tool a bit.
Art is, by definition, about creativity and originality, which is almost the polar opposite of good UX, which is standardization and conformity.
Making a video game with some esoteric control scheme? Fine, go crazy with your input design, people may love it - that is an artistic matter, less so a UX matter. Making an actual tool that people need to use to get work done? That's a UX problem, and your job is to design the tool to be as painless to use as possible, not to be creative, because your creative desire will, unless controlled very carefully, directly lead to pain and frustration of your users.
> You didn't actually provide an argument against having a sane set of defaults with the option to configure them later.
I am not convinced that it is possible to come up with a generic sane set of defaults for all apps in a way that would solve the problem of VIM being fundamentally different. Everybody wants sane defaults, I don't see the debate there.
> "For art" is a non-answer when it comes to UX
Not my point at all (but that's on me). My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.
Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).
I am not convinced that it is possible to come up with a generic sane set of defaults for all apps in a way that would solve the problem of VIM being fundamentally different. Everybody wants sane defaults, I don't see the debate there.
> "For art" is a non-answer when it comes to UX
Not my point at all (but that's on me). My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.
Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).
> I am not convinced that it is possible to come up with a generic sane set of defaults for all apps in a way that would solve the problem of VIM being fundamentally different.
That's not a problem that needs to be solved. "Generic sane set of defaults" excludes vim as an editor by definition.
In terms of which editor should be used by default, vim should not be the default[1].
In terms of keybinding defaults for vim, because vim's modal editing model is so unique, it's totally fine for a universal keybinding system to not trivially integrate with it - just like it's totally fine for libc to not contain every single variant of a memory allocation or string copy function. No abstraction is universal.
> for all apps
Again, a red herring - there's no reason why any programming system has to work "for all the things".
> My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.
This is such a vague statement as to be meaningless. How, specifically, are you claiming that Linux users are different from Windows/MacOS users that a different system is needed?
Moreover, given how obviously the design strategy of "sane consistent (but configurable) defaults" fits in to human cognition, I'm very curious as to why you think it somehow doesn't apply to Linux users. If your answer is "they're more technical" - that's irrelevant. Power users and programmers also want user interfaces for new tools to be maximally sane and consistent during their initial learning period, and the configurable afterward. This isn't a Windows/MacOS/Linux thing, this is a human thing.
> Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).
That's because they're obviously not counter-examples. vim and emacs are not the default editor on the majority of user-facing Linux boxes (graphical Ubuntu) - they have to be picked and learned, and most non-technical users that try quit very fast. Those are not even candidates for a set of defaults - those are highly user-hostile specialized programming tools. You know what the default text editor is in Ubuntu? Gedit. Not vim or emacs, not nano or even pico. Gedit. That's the default, and its behavior very closely matches the behavior of the default text editors on Windows and macOS.
Moreover, there is a set of defaults, without a name, that corresponds roughly to what you get in a text field in Firefox. Left-click to place cursor, right-click for context menu, drag-left-click to select region, ctrl-c to copy, etc. You get this behavior in Libreoffice, Gedit, Firefox, Blender, GIMP, various file explorers, random GTK+Qt widgets, and basically everything else except vim, emacs, nano, and the terminal. That is the standard.
As further evidence: the number of people who know how to use ctrl+z/x/c/v (and other standard text-editing shortcuts) outnumbers the combined amount of people who know how to use vim and emacs, by orders of magnitude.
So, yes, there is a set of defaults on Linux. Vim, Emacs, and Nano are not it.
[1] https://news.ycombinator.com/item?id=34161694
That's not a problem that needs to be solved. "Generic sane set of defaults" excludes vim as an editor by definition.
In terms of which editor should be used by default, vim should not be the default[1].
In terms of keybinding defaults for vim, because vim's modal editing model is so unique, it's totally fine for a universal keybinding system to not trivially integrate with it - just like it's totally fine for libc to not contain every single variant of a memory allocation or string copy function. No abstraction is universal.
> for all apps
Again, a red herring - there's no reason why any programming system has to work "for all the things".
> My point was that "for the majority" is not necessarily the right answer when your system (Linux) is used by a minority.
This is such a vague statement as to be meaningless. How, specifically, are you claiming that Linux users are different from Windows/MacOS users that a different system is needed?
Moreover, given how obviously the design strategy of "sane consistent (but configurable) defaults" fits in to human cognition, I'm very curious as to why you think it somehow doesn't apply to Linux users. If your answer is "they're more technical" - that's irrelevant. Power users and programmers also want user interfaces for new tools to be maximally sane and consistent during their initial learning period, and the configurable afterward. This isn't a Windows/MacOS/Linux thing, this is a human thing.
> Especially because the easiest example (text editors) has huge, obvious counter-examples showing that there is no universal set of defaults to edit text on Linux (nano vs emacs vs vim).
That's because they're obviously not counter-examples. vim and emacs are not the default editor on the majority of user-facing Linux boxes (graphical Ubuntu) - they have to be picked and learned, and most non-technical users that try quit very fast. Those are not even candidates for a set of defaults - those are highly user-hostile specialized programming tools. You know what the default text editor is in Ubuntu? Gedit. Not vim or emacs, not nano or even pico. Gedit. That's the default, and its behavior very closely matches the behavior of the default text editors on Windows and macOS.
Moreover, there is a set of defaults, without a name, that corresponds roughly to what you get in a text field in Firefox. Left-click to place cursor, right-click for context menu, drag-left-click to select region, ctrl-c to copy, etc. You get this behavior in Libreoffice, Gedit, Firefox, Blender, GIMP, various file explorers, random GTK+Qt widgets, and basically everything else except vim, emacs, nano, and the terminal. That is the standard.
As further evidence: the number of people who know how to use ctrl+z/x/c/v (and other standard text-editing shortcuts) outnumbers the combined amount of people who know how to use vim and emacs, by orders of magnitude.
So, yes, there is a set of defaults on Linux. Vim, Emacs, and Nano are not it.
[1] https://news.ycombinator.com/item?id=34161694
> So, yes, there is a set of defaults on Linux. Vim, Emacs, and Nano are not it.
If you mean on Ubuntu, then sure. Ubuntu's target audience is essentially people who want an alternative to Windows/macOS. Not people who want the freedom to use their preferred tools. You think systemd is a sane default and advanced users "just have to change it if they don't like it"? Try replacing systemd on Ubuntu, let me know how it goes. You don't want snaps? Well it looks like it may get harder and harder to not use snaps, because people like you think that it is fine to enforce the most used tools as "the standard". You want to use a tiling window manager? Well many apps will just suck, because people assume that the "standard" is Ubuntu. Same for those apps that require network-manager, or the gnome keychain, etc. The "Linux way", IMO, would be to create CLI tools with minimal dependencies, and then build GUIs on top (maybe even specialized for the latest Ubuntu). But that's not what's happening. You want to use Firefox as a browser, and have a lightweight calculator app next to it? No luck, chances are that your calculator app is shipped with Chromium, because people decided that the standard is Chromium and webapps. And that's if you're lucky, because your calculator may be shipped with a full rootfs in a docker container.
So from my point of view, there are people coming from Windows/macOS to Linux for some reason (apparently not the freedom of Linux, because they don't even wanna know how their system works), and argue against my freedom, because if I don't want the Windows/macOS experience, then I am a weirdo.
> So, yes, there is a set of defaults on Linux.
You mean "the defaults of Ubuntu, which represents most Linux Desktops"? I don't want it. I want the choice to choose the distro closest to my preferences, and let Windows/macOS people choose Ubuntu. But that means that those Ubuntu people should not insist on everyone doing what Ubuntu does.
If you mean on Ubuntu, then sure. Ubuntu's target audience is essentially people who want an alternative to Windows/macOS. Not people who want the freedom to use their preferred tools. You think systemd is a sane default and advanced users "just have to change it if they don't like it"? Try replacing systemd on Ubuntu, let me know how it goes. You don't want snaps? Well it looks like it may get harder and harder to not use snaps, because people like you think that it is fine to enforce the most used tools as "the standard". You want to use a tiling window manager? Well many apps will just suck, because people assume that the "standard" is Ubuntu. Same for those apps that require network-manager, or the gnome keychain, etc. The "Linux way", IMO, would be to create CLI tools with minimal dependencies, and then build GUIs on top (maybe even specialized for the latest Ubuntu). But that's not what's happening. You want to use Firefox as a browser, and have a lightweight calculator app next to it? No luck, chances are that your calculator app is shipped with Chromium, because people decided that the standard is Chromium and webapps. And that's if you're lucky, because your calculator may be shipped with a full rootfs in a docker container.
So from my point of view, there are people coming from Windows/macOS to Linux for some reason (apparently not the freedom of Linux, because they don't even wanna know how their system works), and argue against my freedom, because if I don't want the Windows/macOS experience, then I am a weirdo.
> So, yes, there is a set of defaults on Linux.
You mean "the defaults of Ubuntu, which represents most Linux Desktops"? I don't want it. I want the choice to choose the distro closest to my preferences, and let Windows/macOS people choose Ubuntu. But that means that those Ubuntu people should not insist on everyone doing what Ubuntu does.
Sadly, you chose sarcastic trolling instead of clearly communicating your point. However, it seems like you're assuming system-wide keyboard shortcuts and consistent defaults means you can't change anything.
On macOS, you can change the keyboard shortcuts, including idiosyncratic ones, of (almost?) any application, certainly any pure Cocoa one. I have Word set up so that CmdV pastes unformatted, for example, and I have to use ShiftCmdV if I want the full suite of paste options.
So I guess I feel confused about why you'd rant in defense of "those who like different shortcuts," and then call out macOS specifically, when that's an area where it shines over all others.
On macOS, you can change the keyboard shortcuts, including idiosyncratic ones, of (almost?) any application, certainly any pure Cocoa one. I have Word set up so that CmdV pastes unformatted, for example, and I have to use ShiftCmdV if I want the full suite of paste options.
So I guess I feel confused about why you'd rant in defense of "those who like different shortcuts," and then call out macOS specifically, when that's an area where it shines over all others.
Sorry for the communication style, that's noted. I meant to communicate a point though.
My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set that in the system-wide settings?
I would guess that macOS does not strictly enforce the system bindings, does it? Say it does -> application developers lose flexibility because they can't design a different UX if they want to. Say it doesn't -> application developers now have to decide, for each binding, if they want to define a default themselves (which would be consistent with the rest of their app) or if they want to honor the system bindings (and possibly have a terrible UX that people will complain about).
It's not an easy problem :-).
My point is that I don't want vim to copy with "Cmd + V" (I want the vim bindings there), and maybe I want to reuse "Cmd + V" in Blender for something more important than "paste" (assuming that "pasting" is not really a concept in Blender, I don't know). But still I want "Cmd + V" in Word and in my e-mail client. How do you set that in the system-wide settings?
I would guess that macOS does not strictly enforce the system bindings, does it? Say it does -> application developers lose flexibility because they can't design a different UX if they want to. Say it doesn't -> application developers now have to decide, for each binding, if they want to define a default themselves (which would be consistent with the rest of their app) or if they want to honor the system bindings (and possibly have a terrible UX that people will complain about).
It's not an easy problem :-).
They're not enforced by technical means, usually, but Apple HIG are fairly highly regarded by developers and users alike.
I only do UI programming in wxWidgets so I can't speak for other developer workflows. When I create a menu system, if I don't include accelerators manually, the system-appropriate ones are automatically added for certain things. Additionally, wxWidgets automatically moves Windows/Linux "standard" menu items to macOS-specific locations (e.g., Quit and About menu items), if and only if they're in the pertinent menus at the time they're added to the menu bar. If I add the File menu to the menu bar, and then add "E&xit" to the file menu, it still shows in the File menu.
So, in my experience, it's a strong default, but it isn't constraining; you can easily override that behavior when necessary.
I only do UI programming in wxWidgets so I can't speak for other developer workflows. When I create a menu system, if I don't include accelerators manually, the system-appropriate ones are automatically added for certain things. Additionally, wxWidgets automatically moves Windows/Linux "standard" menu items to macOS-specific locations (e.g., Quit and About menu items), if and only if they're in the pertinent menus at the time they're added to the menu bar. If I add the File menu to the menu bar, and then add "E&xit" to the file menu, it still shows in the File menu.
So, in my experience, it's a strong default, but it isn't constraining; you can easily override that behavior when necessary.
Yeah for UI it makes a lot of sense. Especially if those are "standalone" (for lack of a better word) elements. For instance, changing the accelerators (I guess that's related to the animation when opening a menu, right?) cannot really conflict with anything else. So it's perfect to use system-wide configurations like that.
But I wonder about key bindings. I think it makes sense to have guidelines, and to use "Cmd + Q" to quit whenever it makes sense. But defining this as a high-level action "quit", and letting the user define the binding (e.g. "I want Cmd + S to quit") seems rather complicated to me. If "Cmd + S" is already set system-wide for the "save" action, then the system could tell you "that will disable the 'save' action, are you sure?". But if you go for "Quit with Cmd + J", and "Cmd + J" is not a system-wide binding but instead is used by... say... Blender. Then the system will happily change "Ctrl + Q" with "Ctrl + J", and now what happens if you hit "Ctrl + J" in Blender? Should it quit, or should it do what Blender does for "Ctrl + J"?
I am not sure everything can be configurable. My Firefox toolbar is at the top, on mobile I can have it at the bottom (not sure I can do that on Desktop). But I can't have it in the middle of the page, or vertically on a side. That's a decision that was made by the Firefox devs, not by the system settings. That does not mean we should not expect sane defaults, but I would argue that ":q" is a sane default in vim.
But I wonder about key bindings. I think it makes sense to have guidelines, and to use "Cmd + Q" to quit whenever it makes sense. But defining this as a high-level action "quit", and letting the user define the binding (e.g. "I want Cmd + S to quit") seems rather complicated to me. If "Cmd + S" is already set system-wide for the "save" action, then the system could tell you "that will disable the 'save' action, are you sure?". But if you go for "Quit with Cmd + J", and "Cmd + J" is not a system-wide binding but instead is used by... say... Blender. Then the system will happily change "Ctrl + Q" with "Ctrl + J", and now what happens if you hit "Ctrl + J" in Blender? Should it quit, or should it do what Blender does for "Ctrl + J"?
I am not sure everything can be configurable. My Firefox toolbar is at the top, on mobile I can have it at the bottom (not sure I can do that on Desktop). But I can't have it in the middle of the page, or vertically on a side. That's a decision that was made by the Firefox devs, not by the system settings. That does not mean we should not expect sane defaults, but I would argue that ":q" is a sane default in vim.
You can override things like paste system-wide or you can customize it for a particular app.
Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults.
Even for the obvious example of the text editor, where "everybody wants Ctrl+P to paste", where I precisely don't want that in vim and emacs.
That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves (instead of reusing something I defined system-wide for different apps). Because the app developer knows their app better. If I don't like it, I can customize it or just not use it. "Don't use vim if you want it to behave like Word", in some sense. Both are great, but different. And that's fine.
Even for the obvious example of the text editor, where "everybody wants Ctrl+P to paste", where I precisely don't want that in vim and emacs.
That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves (instead of reusing something I defined system-wide for different apps). Because the app developer knows their app better. If I don't like it, I can customize it or just not use it. "Don't use vim if you want it to behave like Word", in some sense. Both are great, but different. And that's fine.
> The problem is that it makes it harder for the app to have sane defaults.
How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use?
> That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves
The above system seems to fairly easily fit your preference - you can trivially choose to use the app bindings, and GP can trivially choose to use the system bindings.
You're advocating for needlessly restricting user choice by using a design that doesn't allow them to pick between a unified set of system shortcuts (which I, and many other millions of people want) and each app doing it their own way (which is a UX disaster for new users).
How is this not trivially solved by having the app ship with its own set of bindings, then provide a simple toggle switch between "use app defaults" and "use OS defaults/user preferences" that is displayed on first use?
> That's what I meant by "preference": it is your preference to have apps honor your system-wide settings, but it is my preference to let the app developers choose their bindings themselves
The above system seems to fairly easily fit your preference - you can trivially choose to use the app bindings, and GP can trivially choose to use the system bindings.
You're advocating for needlessly restricting user choice by using a design that doesn't allow them to pick between a unified set of system shortcuts (which I, and many other millions of people want) and each app doing it their own way (which is a UX disaster for new users).
> You're advocating for needlessly restricting user choice
Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance.
> How is this not trivially solved [...]
Well first you need to find a way to integrate that toggle in your UI without people complaining too much. Then you need to test that it works on your platform (I see a lot of room for errors, e.g. if the system default is not set, or set to something weird, or conflicting with another app), and then you need to make it work on other platforms (which most certainly won't provide a compatible API). Sounds easy, in practice nobody would want to pay for the work required to do it.
That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
Nope, I'm advocating for letting the app developers do what they want. Enforcing apps to honor the system-wide defaults (not even talking about how to actually enforce it) would just break emacs and vim, for instance.
> How is this not trivially solved [...]
Well first you need to find a way to integrate that toggle in your UI without people complaining too much. Then you need to test that it works on your platform (I see a lot of room for errors, e.g. if the system default is not set, or set to something weird, or conflicting with another app), and then you need to make it work on other platforms (which most certainly won't provide a compatible API). Sounds easy, in practice nobody would want to pay for the work required to do it.
That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
> Nope, I'm advocating for letting the app developers do what they want.
You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all:
> Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults.
That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model.
Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion.
> Well first you need to find a way to integrate that toggle in your UI without people complaining too much...
...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it)
> That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread.
Do you have anything actually relevant that you'd like to add?
You're contradicting yourself. Your comments above are specifically arguing against the idea of implementing this system at all:
> Right. So that's moving the control of the binding from the app to the system settings. The problem is that it makes it harder for the app to have sane defaults.
That is an argument against the OS-meddles-with-the-keybindings system, period. Your statement "I'm advocating for letting the app developers do what they want" is flat-out false - you are advocating against app developers implementing this system at all (and therefore advocating against letting them do what they want) by claiming that it is a bad model.
Additionally, you're trying to quietly change the discussion from "what makes things best for the user/what is good UX" (which has been the actual conversational topic) to "what do app developers want to do" which is completely orthogonal and irrelevant to this discussion.
> Well first you need to find a way to integrate that toggle in your UI without people complaining too much...
...and now you've stopped trying make arguments about the concept itself, and are trying to start arguing about hypothetical implementation problems to argue that the concept is unsound. (MacOS has effectively solved all of these problems, by the way, so this line of reasoning doesn't even pan out - MacOS's model is existence proof that such a system can be effectively implemented and that users will like it)
> That's also the reason why we don't get well integrated Desktop apps, and instead get ElectronJS apps that ship with a full browser: it's cheaper for the devs to ship a website with a browser and pretend that it is a Desktop app than to actually make a Desktop app.
Finally, there's more redirection from "is it a good idea" to "will people implement it" - again, unrelated and irrelevant to the conversational thread.
Do you have anything actually relevant that you'd like to add?
I think we're talking past each other. I'm not trying to win an argument, I'm just sharing my opinion. I reacted to that:
> Not having system wide keyboard shortcuts is one of [those big mistakes]: vim, emacs, nano etc all have a different shortcut to quit the app
In my opinion (and that's an opinion, not a formal proof), this does not work. _I do not want the same shortcut to quit nano, vim and emacs_. The author of that comment does, obviously. Which is why I said "preferably the standard should be your favourite shortcuts, right?". Not as a criticism, but in order to show that this is a preference, and my preference differs from the author's.
My preference is to have vim bindings be vim bindings, and not the system bindings. Sure, the system settings could offer a way to specifically set the bindings for vim instead of using the `.vimrc`. But it would not entirely replace `vimrc`, so it would split the config in what _I see_ as a weird way.
I generally don't see how it would work in practice. I can easily swap "ESC" and "CapsLock" in the system settings, but that's not the same level as setting the shortcut for a high-level action like "save". If you want to set the "save" shortcut globally, then everyone writing a program has to deal with it. First, I don't see how you can enforce it. And second, it makes life harder for developers. For something _I don't personally want_. Therefore as a developer, I won't follow your preference, period.
This is my opinion about the hypothetical idea of having system-wide settings that would unify vim, emacs and nano (that's the point of the sentence above, isn't it?). Maybe someone can implement this in a perfect way, and I would even use it (who doesn't like "perfect"?). But it _feels_ like I fundamentally disagree: _to me_, the fact that vim, emacs and nano all have a different way to quit the app is a feature, not a bug. Therefore it does not need fixing.
But feel free to explain to me what I am trying to say, and why it is logically wrong.
> Not having system wide keyboard shortcuts is one of [those big mistakes]: vim, emacs, nano etc all have a different shortcut to quit the app
In my opinion (and that's an opinion, not a formal proof), this does not work. _I do not want the same shortcut to quit nano, vim and emacs_. The author of that comment does, obviously. Which is why I said "preferably the standard should be your favourite shortcuts, right?". Not as a criticism, but in order to show that this is a preference, and my preference differs from the author's.
My preference is to have vim bindings be vim bindings, and not the system bindings. Sure, the system settings could offer a way to specifically set the bindings for vim instead of using the `.vimrc`. But it would not entirely replace `vimrc`, so it would split the config in what _I see_ as a weird way.
I generally don't see how it would work in practice. I can easily swap "ESC" and "CapsLock" in the system settings, but that's not the same level as setting the shortcut for a high-level action like "save". If you want to set the "save" shortcut globally, then everyone writing a program has to deal with it. First, I don't see how you can enforce it. And second, it makes life harder for developers. For something _I don't personally want_. Therefore as a developer, I won't follow your preference, period.
This is my opinion about the hypothetical idea of having system-wide settings that would unify vim, emacs and nano (that's the point of the sentence above, isn't it?). Maybe someone can implement this in a perfect way, and I would even use it (who doesn't like "perfect"?). But it _feels_ like I fundamentally disagree: _to me_, the fact that vim, emacs and nano all have a different way to quit the app is a feature, not a bug. Therefore it does not need fixing.
But feel free to explain to me what I am trying to say, and why it is logically wrong.
macOS shortcut editing/configuration is an unsung strength of the platform; it’s quite amazing and anyone who uses macOS should spend an hour investigating it.
Your past shortcut change is something I’ve done similarly but you can also assign shortcuts to menu commands that you use often but don’t have one, etc.
Your past shortcut change is something I’ve done similarly but you can also assign shortcuts to menu commands that you use often but don’t have one, etc.
Is is typically the case that there are system-wide in most popular GUIs, like GNOME and KDE. It's even the case in something like i3 or sway. In a GUI environment, you get GUI-wide shortcut keys.
On the command-line, there is no GUI. Yet there are still a number of system-wide shortcuts, but things are a little different, because you are interacting with text. And often, you're only interacting with one program at a time. In most places, ^C, ^D, ^I, and ^Z work the same way. In Bash and other shells and programs that use readline, several Emacs-style shortcuts also work the same, notably ^A, ^E, and ^K.
There are probably others, but you'll notice that few of them have anything to do with copy and paste, because that is often meaningless between programs without a GUI to show multiple programs at once, in which case the GUI, not the CLI, would implement something. There just aren't that many needs for more shortcuts when you have only one program in front of you.
On the command-line, there is no GUI. Yet there are still a number of system-wide shortcuts, but things are a little different, because you are interacting with text. And often, you're only interacting with one program at a time. In most places, ^C, ^D, ^I, and ^Z work the same way. In Bash and other shells and programs that use readline, several Emacs-style shortcuts also work the same, notably ^A, ^E, and ^K.
There are probably others, but you'll notice that few of them have anything to do with copy and paste, because that is often meaningless between programs without a GUI to show multiple programs at once, in which case the GUI, not the CLI, would implement something. There just aren't that many needs for more shortcuts when you have only one program in front of you.
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.
I use vim keys everywhere I can, so from my standpoint “stupid” UI choices are the ones that don’t support modality. I would really prefer having vim keys optional built ins everywhere. Your situation is simpler though - you can just avoid using vim or whatever, there’s plenty of other options available.
Also calling personal preferences of lots of people “stupid” is far from reasonable. I’ve met a lot of smart folks who used vim and emacs, so from my personal experience it’s not correct.
Also calling personal preferences of lots of people “stupid” is far from reasonable. I’ve met a lot of smart folks who used vim and emacs, so from my personal experience it’s not correct.
But that's the thing: in my opinion, this is exactly not the Linux philosophy. Maybe the majority of Linux users want it to behave like macOS and it will go there someday. And at this point I will move to the next thing closest to what I believe is the Linux philosophy.
But right now, I would say simply: "if you want the macOS philosophy, use macOS". And don't get me wrong: macOS is great.
But right now, I would say simply: "if you want the macOS philosophy, use macOS". And don't get me wrong: macOS is great.
Don’t use them if you don’t like them.
Please do impose those unwanted constraints thank you!
[deleted]
> Not having system wide keyboard shortcuts is one of them: vim, emacs, nano etc all have a different shortcut to quit the app
Not even Microsoft has system wide keyboard shortcuts. And copy paste on Microsoft has become a game of luck.
Not even Microsoft has system wide keyboard shortcuts. And copy paste on Microsoft has become a game of luck.
> Not even Microsoft has system wide keyboard shortcuts
Huh? I've used all versions of Windows from 98 onwards, and things like Ctrl-Y/X/C/V/Z, Alt-F4, Alt-Tab, Ctrl-Alt-Del, etc have all worked extremely reliably.
The one exception is the keyboard shortcut for 'redo', which some applications like to bind to Ctrl-Y, and some others like to bind to Shift-Ctrl-Z.
Sure, later versions of Windows have added additional shortcuts like Win-Tab, Win-V (for clipboard history), Shift-Win-S (quick screenshot), Win-X (superuser menu, since Windows 8), but these are absolutely welcome additions.
Huh? I've used all versions of Windows from 98 onwards, and things like Ctrl-Y/X/C/V/Z, Alt-F4, Alt-Tab, Ctrl-Alt-Del, etc have all worked extremely reliably.
The one exception is the keyboard shortcut for 'redo', which some applications like to bind to Ctrl-Y, and some others like to bind to Shift-Ctrl-Z.
Sure, later versions of Windows have added additional shortcuts like Win-Tab, Win-V (for clipboard history), Shift-Win-S (quick screenshot), Win-X (superuser menu, since Windows 8), but these are absolutely welcome additions.
alt+f4, ctrl+s, ctrl+x/c/v, ctrl+z, ctrl+p all work near universally on windows. Up until Windows XP that was also true for F1, but shipping help files somehow got out of fashion. Of course there are exceptions, like conhost, but generally you don't have to think about how to save or quit something on windows
Not just those. Odds are shift+del to cut, crtl+insert to copy, shift+insert to paste still work in the browser text area you use to write comments. Even alt+backspace, the old IBM undo shortcut, still works in pretty much any box that lets you enter text in Windows. That's the power of generic UI components and backwards compatibility!
You can kill windows using alt+f4 on your typical Linux Desktop (Gnome, KDE, etc). Same for ctrl+x/c/v.
It's different for programs running in terminals / terminal emulators for technical reasons. Terminals are not GUIs, they are simple devices with a single byte stream for input (displayed on screen) and output (sent from keyboard) that are interpreted quite literally. E.g. the byte ASCII 'A' will normally result in an 'A' being displayed whereever the terminal cursor happens to be. Typing 'A' on the keyboard will result in 'A' being sent out to the OS. Ctrl+(A-Z) will send the byte values 1 through 26. E.g. Ctrl+C will result in ASCII 3 (0b00000011), aka ETX (End of Text), which will normally be converted by the OS's terminal subsystem into a SIGINT signal that is sent to the "foreground" process running in the terminal. Or, if the terminal is in raw mode, the byte 3 will be read as-is by whoever reads the terminal keyboard. Same goes for ctrl+z (normally SIGSTOP is sent) etc.
Terminal apps can't expect a running clipboard service. There may not be a display or graphics environment running on that machine. The app might run on remote machine. Etc.
Notice how Windows Cmd isn't entirely intuitive about those basic cut&past things, either.
It's different for programs running in terminals / terminal emulators for technical reasons. Terminals are not GUIs, they are simple devices with a single byte stream for input (displayed on screen) and output (sent from keyboard) that are interpreted quite literally. E.g. the byte ASCII 'A' will normally result in an 'A' being displayed whereever the terminal cursor happens to be. Typing 'A' on the keyboard will result in 'A' being sent out to the OS. Ctrl+(A-Z) will send the byte values 1 through 26. E.g. Ctrl+C will result in ASCII 3 (0b00000011), aka ETX (End of Text), which will normally be converted by the OS's terminal subsystem into a SIGINT signal that is sent to the "foreground" process running in the terminal. Or, if the terminal is in raw mode, the byte 3 will be read as-is by whoever reads the terminal keyboard. Same goes for ctrl+z (normally SIGSTOP is sent) etc.
Terminal apps can't expect a running clipboard service. There may not be a display or graphics environment running on that machine. The app might run on remote machine. Etc.
Notice how Windows Cmd isn't entirely intuitive about those basic cut&past things, either.
except when you have a different locale and language, and half your office suite have the original shortcuts, and the other half is translated like:
ctrl + a (abrir, open in Portuguese) instead of select all, that is moved to ctrl + t (tudo, all in Portuguese), and many others.
So, universally for English/US I guess.
ctrl + a (abrir, open in Portuguese) instead of select all, that is moved to ctrl + t (tudo, all in Portuguese), and many others.
So, universally for English/US I guess.
[deleted]
Highly reminiscent of #378:
* nano? Real Programmers use emacs.
* Hey. Real Programmers use vim.
* Well, Real Programmers use ed.
* No, Real Programmers use cat.
* Real Programmers use a magnetized needle and a steady hand.
* Excuse me, but Real Programmers use butterflies. They open their hands and let the delicate wings flap once. The disturbances ripple outward, changing the flow of the eddy currents in the upper atmosphere. These cause momentary pockets of higher-pressure air to form, Which act as lenses that deflect incoming cosmic rays, focusing them to strike the drive platter and flip the desired bit.
* nano? Real Programmers use emacs.
* Hey. Real Programmers use vim.
* Well, Real Programmers use ed.
* No, Real Programmers use cat.
* Real Programmers use a magnetized needle and a steady hand.
* Excuse me, but Real Programmers use butterflies. They open their hands and let the delicate wings flap once. The disturbances ripple outward, changing the flow of the eddy currents in the upper atmosphere. These cause momentary pockets of higher-pressure air to form, Which act as lenses that deflect incoming cosmic rays, focusing them to strike the drive platter and flip the desired bit.
You forgot the last panel:
* Nice. 'Course there's an emacs command to do that.
* Oh yeah! Good ol' `C-x M-c M-butterfly`...
* Dammit, emacs!
https://xkcd.com/378/
* Nice. 'Course there's an emacs command to do that.
* Oh yeah! Good ol' `C-x M-c M-butterfly`...
* Dammit, emacs!
https://xkcd.com/378/
In homage to this, there's now `M-x butterfly' in Emacs.
I have always thought that panel was deserving of treatment from the r/comedyamputation subreddit.
yeah deliberately left that out
How can you even use cat to write? I understand dd or echo, but cat by itself? Cat /dev/whatever and a steady hand?
$ cat <<EOF > test
> this is a test text file
> written with cat
> EOF
$ cat <<EOF >> test
> this is an extra line at the end
> EOF
$ cat test
this is a test text file
written with cat
this is an extra line at the end
> An option will be using other tools but that makes cat incapable of being a text editor.
It’s only a problem if you make mistakes. Real programmers don’t, hence cat is perfectly cromulent.
It’s only a problem if you make mistakes. Real programmers don’t, hence cat is perfectly cromulent.
That said, this is in no way below the practicability of using butterflies and cosmic rays
[deleted]
Right!
>But not sure how you modify them.
Maybe somehow sending escaped "backspace" symbol?
>But not sure how you modify them.
Maybe somehow sending escaped "backspace" symbol?
cat > myfile.txt
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.
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.
> It's straight up bad for linux adoption even if technically superior.
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).
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).
Well there's no convincing you then.
The pros of modal editing is well documented, and I'm not even arguing about the superiority of vim over the likes of emacs.
People who believe using cursor to select, move, copy stuff are better than modal editing, even after all the argument, is probably not going to be swayed ever. As an almost pure vim user, I know how my own speed are significantly improved ever since I adopted vim and its modals, and I don't need to mentally construct keystrokes just like most people don't need to look at a keyboard to type.
The demonstration are mostly some edge cases that don't really happen, but the general speed over general editing, some `V}y` here, some `ci(` there, some `Vjj2>`, `c-vwwGx` etc is what makes vim really shine. And no we don't have to dig a dictionary to type those things, all I had to do was to open vim since that's how muscle memory works.
The pros of modal editing is well documented, and I'm not even arguing about the superiority of vim over the likes of emacs.
People who believe using cursor to select, move, copy stuff are better than modal editing, even after all the argument, is probably not going to be swayed ever. As an almost pure vim user, I know how my own speed are significantly improved ever since I adopted vim and its modals, and I don't need to mentally construct keystrokes just like most people don't need to look at a keyboard to type.
The demonstration are mostly some edge cases that don't really happen, but the general speed over general editing, some `V}y` here, some `ci(` there, some `Vjj2>`, `c-vwwGx` etc is what makes vim really shine. And no we don't have to dig a dictionary to type those things, all I had to do was to open vim since that's how muscle memory works.
> The pros of modal editing is well documented
Finally! Someone who knows where that elusive data is hidden that actually shows why modal editing is better.
Wait, did you forget to link to the study?
Finally! Someone who knows where that elusive data is hidden that actually shows why modal editing is better.
Wait, did you forget to link to the study?
Like I said, there's no convincing you.
On previous tens of discussion surely someone has came up with something, only for you to dismiss it as gimmicky. I am not going to spend much effort on a lost cause, but quick googling came up with this blog: https://eli-rodriguez.com/en/posts/modal-editing-the-superio...
Enjoy moving your cursor around when you edit text, but welcome to the club if I am wrong and you can be convinced.
On previous tens of discussion surely someone has came up with something, only for you to dismiss it as gimmicky. I am not going to spend much effort on a lost cause, but quick googling came up with this blog: https://eli-rodriguez.com/en/posts/modal-editing-the-superio...
Enjoy moving your cursor around when you edit text, but welcome to the club if I am wrong and you can be convinced.
Making a claim followed by only providing anecdotes in support just to then immediately hiding behind the "there's no convincing you"...
Impressive.
Impressive.
Please read the entire the comment chain, the burden of proof is set arbitrarily high, which was suspected from the beginning due to the comment that was initially replied to, hence "no convincing you".
This is made especially difficult by the subjective nature of discussion.
This is made especially difficult by the subjective nature of discussion.
So no data at all, just anecdotes from zealots.
You're right, that's not going to convince me. Because I apply the same basic standard of plausibility that I do to all claims I hear. When someone tells me I should start using homeopathy, and there's no need for any actual evidence in favor of it because the benefits are "well known" to its practitioners, I don't need to hear any more to make up my mind. This is really no different.
You're right, that's not going to convince me. Because I apply the same basic standard of plausibility that I do to all claims I hear. When someone tells me I should start using homeopathy, and there's no need for any actual evidence in favor of it because the benefits are "well known" to its practitioners, I don't need to hear any more to make up my mind. This is really no different.
Considering this is a subjective interest, what kind of data are you looking for? A measuring contest that happen to control on individual skills? What kind of data may satisfy your high bar of acceptance?
Let's take a step back from vim: what kind of data will demonstrate satisfactory performance over any kind of editor for your liking?
Let's take a step back from vim: what kind of data will demonstrate satisfactory performance over any kind of editor for your liking?
Any published study comparing performance of experienced modal vs. non-modal editor users on common tasks would be interesting already. Basically, standard UX research stuff. Figuring out how to control for differences in skill etc. is literally the job of people who conduct such research.
I mean, there are studies examining how the quality of Git commits is affected by blood alcohol levels, so that doesn't seem like an overly exotic topic by comparison.
I mean, there are studies examining how the quality of Git commits is affected by blood alcohol levels, so that doesn't seem like an overly exotic topic by comparison.
Does any such academic study exist for any editor comparison? Since according to you these are "literally the job of people" and "standard UX research stuff".
This seems like a classic case of setting the bar arbitrarily high to stifle discussion - I cannot find any, but would love to be proven wrong.
This seems like a classic case of setting the bar arbitrarily high to stifle discussion - I cannot find any, but would love to be proven wrong.
> Does any such academic study exist for any editor comparison?
I don't know, you tell me. You're making the claim that one is superior. The burden of proof is on you.
I don't know, you tell me. You're making the claim that one is superior. The burden of proof is on you.
The burden of proof is not infinite.
Asking specifically to a level of proof that does not exist either way on a subject that does not pertains to such a level of proof is merely stifling discussion, not to mention that the claim that the editors are equal in capability are not immediately obvious and proof absolving.
Asking specifically to a level of proof that does not exist either way on a subject that does not pertains to such a level of proof is merely stifling discussion, not to mention that the claim that the editors are equal in capability are not immediately obvious and proof absolving.
Expecting a single scientific study is not infinite burden of proof, in response to someone making a claim. It's the least to expect.
Though it's convenient for you that you consider anything higher than your own standards "infinite".
Though it's convenient for you that you consider anything higher than your own standards "infinite".
My favourite is rST headlines:
yypVr-> have never been shown a concrete piece of scientific evidence demonstrating Vim's claimed superiority according to any real-world metric
I wonder if you've ever seen scientific evidence of the contrary? Or any kind of scientific evidence on this matter?
If not, it seems that you're just using this as an excuse to rationalize your own prejudice, and the counter-argument is really easy: absence of evidence is not evidence of absence (in this case, or vim's advantages)
I wonder if you've ever seen scientific evidence of the contrary? Or any kind of scientific evidence on this matter?
If not, it seems that you're just using this as an excuse to rationalize your own prejudice, and the counter-argument is really easy: absence of evidence is not evidence of absence (in this case, or vim's advantages)
I don't need evidence to the contrary because I'm not making any claim. I'm simply doubting the folklore claim (made without evidence) that Vim is technically superior / more efficient in practice. I'm not trying to convince anyone (and indeed I don't believe) that Vim is worse than other editors. But I don't see any reason to believe it is better either, and people merely repeating that claim isn't going to change my mind.
Generally when a discussion of vim comes up the people who use it claim that it's more efficient or whatever. Just look in this thread!
Is difference in number of keystrokes (keychords) not fairly convincing evidence that, at the very least, vim results in less finger effort (and therefore lower risk of RSI) than other editors?
Even if you don't believe that there's a speed advantage (it's entirely plausible that the delay from cognitive processing necessary to navigate vim's more complex interface dwarfs the speed increase of pressing fewer keys), I find it hard to defend the idea that pressing significantly more keys is not ergonomically worse than pressing fewer (controlling for effort variables e.g. using the Carpalx model[0]).
[0] http://mkweb.bcgsc.ca/carpalx/?typing_effort
Even if you don't believe that there's a speed advantage (it's entirely plausible that the delay from cognitive processing necessary to navigate vim's more complex interface dwarfs the speed increase of pressing fewer keys), I find it hard to defend the idea that pressing significantly more keys is not ergonomically worse than pressing fewer (controlling for effort variables e.g. using the Carpalx model[0]).
[0] http://mkweb.bcgsc.ca/carpalx/?typing_effort
I’m not sure any such study exists for any editors, so it’s hard to argue this. However, anecdotally, Vim’s basic navigation (hjkl) and a few common shortcuts (delete entire line dd, new line and type o, change word ciw) are so useful it’s difficult to believe you can’t type can change things faster than an editor without those shortcuts.
I can’t really compare to eg. Emacs bindings, as I have no experience with those, but most text editors have nothing, and if you have to reach for a mouse or arrow keys instead Vim is imo going to be much better once you’ve learnt it.
I can’t really compare to eg. Emacs bindings, as I have no experience with those, but most text editors have nothing, and if you have to reach for a mouse or arrow keys instead Vim is imo going to be much better once you’ve learnt it.
Yeah. I think it's silly to make the claim, by and large. For me, using vim is like a hobby. It helps me get into flow state because I have fun writing and editing code using an editor I know well, have configured, and can zip around in fast without touching the mouse. I never try to convince anyone else to use it, though if a coworker shows interest I'm more than happy to oblige. It's the right tool for me. VS Code and IntelliJ products are the right tools for others, and that's cool too.
Vim seems to suggest that when by muscle memory i try "C-x C-q" (emacs exit).
But the whole modality thing is insane for a newbie; vim is a fine editor as a conscious choice of course.
But the whole modality thing is insane for a newbie; vim is a fine editor as a conscious choice of course.
Furthermore, even easy Vim ("vim -y", "evim") requires users to know to press Control+Q to exit.
That cute bottom bar is the reason Nano wins. It provides a safety net.
That cute bottom bar is the reason Nano wins. It provides a safety net.
to be fair, at least neovim says to press :q! when you try Ctrl+C
why do we care about users who want the easy way out?
There's no "we". I personally care, because I think bad UX hurts adoption.
I used to be a nano user but now whenever I want to use a terminal text editor I will almost always use micro as it has built in support for most languages.
https://micro-editor.github.io/
https://micro-editor.github.io/
Also checkout Helix for those who want Vim with nice defaults (like LSP).
https://helix-editor.com
https://github.com/helix-editor/helix
https://helix-editor.com
https://github.com/helix-editor/helix
I got stuck with jed https://www.jedsoft.org/jed/ as my terminal editor after getting too used to the emacs shortcuts but when emacs -nw became too heavy.
Does anyone else use this? (To be fair I am transitioning to vim now that my emacs muscle memory is waning, and the rate of jed bugfixes likewise).
Does anyone else use this? (To be fair I am transitioning to vim now that my emacs muscle memory is waning, and the rate of jed bugfixes likewise).
I had a period where I was using jed because I was doing stuff with s-lang (mostly Lynx) and using slrn to read news. But then I drifted into the vi/vims because trying to get jed installed everywhere was a pain.
nano is usually installed by default
Vi is fortunately present on just about every unix-like system and in busybox. Typing "v" in the pager and getting thrown into nano always prompts me to installing vim and changing the default editor.
When I got into Linux there was no nano, only vi and ed. Pico came later with the Pine e-mail client.
When I got into Linux there was no nano, only vi and ed. Pico came later with the Pine e-mail client.
> "Pico came later with the Pine e-mail client"
Nope. GNU Nano, like a lot of the early GNU utilities, emulates Pico. I was using Pico/Pine around 1994/95 on UNIX workstations, and Pico was the default editor.
Nope. GNU Nano, like a lot of the early GNU utilities, emulates Pico. I was using Pico/Pine around 1994/95 on UNIX workstations, and Pico was the default editor.
Pico came later than vi/ed. I know nano is a pico clone which first appeared in '99 or so.
Came here to write this, you beat me to it.
My editor of choice is vscode and Intellij, the only time I would use a command line editor is when I am sshing into a server temporarily and just want to make some small edits to a file. I know enough commands on vim to insert/edit text and exit, which works when nano isn't available on the machine and I don't have access to a package manager.
But for everything else, I use a proper IDE. I setup sshfs with remote machines that I use frequently, and just load the folder into my IDE and edit files in my IDE. VIM was designed in a very different era when terminals were small. An IDE gives me an integrated debugger, code completion, code formatting, project management(very useful for hierarchical projects) and integration with tools like VCS, Testing frameworks etc. I still don't understand people who use vim(or nano) as their primary editor.
But for everything else, I use a proper IDE. I setup sshfs with remote machines that I use frequently, and just load the folder into my IDE and edit files in my IDE. VIM was designed in a very different era when terminals were small. An IDE gives me an integrated debugger, code completion, code formatting, project management(very useful for hierarchical projects) and integration with tools like VCS, Testing frameworks etc. I still don't understand people who use vim(or nano) as their primary editor.
An ide provides very little that vim doesn't. If you think it does you're just ignorant about what vim can do. Nano is basically featureless though
I'm quite fond of stories about people using editors besides the Big Two or the Newfangled Brigade. Keep 'em coming, you usually learn something about regular use and what others deem necessary – or can live without.
Nano is interesting in that context, because for many it's the "default" editor, which is a bit weird if you came in to Linux/Unix earlier. I bet a lot of people feel the same when it comes to anything besides ed, though ;)
Nano is interesting in that context, because for many it's the "default" editor, which is a bit weird if you came in to Linux/Unix earlier. I bet a lot of people feel the same when it comes to anything besides ed, though ;)
There's a reason I've always removed nano on every system I administer, and have done so for decades: when I first learned of nano, I also learned that it can corrupt configuration files where line breaks are significant by hard-wrapping long lines, unless you're very careful to always use "nano -w" instead of just "nano". I believe that this default has changed in a recent version of nano, and even before that some Linux distributions shipped with it set to not hard-wrap by default on a global configuration file, but it's still an unnecessary risk (unless you're really sure that the nano version is recent enough to have the new default, and that you'll never ssh to a machine running an older version of nano).
I accidentally turned this on once, IIRC, and discovered the issue after some shell scripting went off the rails. It was pretty irritating.
Still, it led me to a deeper read of the configuration and I ended up enjoying nano more after that. It's come a long way in recent years too.
Still, it led me to a deeper read of the configuration and I ended up enjoying nano more after that. It's come a long way in recent years too.
Ah, a good old fashioned editor wars thread, surely the comments will be reasonable.
_editor1_ sucks.. you can pry _editor2_ from my cold dead hands.
I use vim because I prefer modal editors when editing config files - "normal" mode prevents me from fat-fingering a lot of my config, and undo is a simple "u" away. :setlist allows me to see if I have any stray invisible characters.
However, as a default for new distributions, nano is a solid choice (with the command help on the bottom). Any experienced users can just type vi, or update the EDITOR env var. It's about as friction-less as running a different command.
However, once you grok vi, there's no going back.
However, as a default for new distributions, nano is a solid choice (with the command help on the bottom). Any experienced users can just type vi, or update the EDITOR env var. It's about as friction-less as running a different command.
However, once you grok vi, there's no going back.
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.
> 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
Cracked me up good.
Cracked me up good.
You don't need to spend any time or effort memorising a bunch of menus.
Nothing is going to convince me that a more conventional GUI text editor provides better ergonomics than something like vim or emacs.
If you don’t like that kind of editor, that’s fine. You do you.
If you don’t like that kind of editor, that’s fine. You do you.
One reason among many: less keyboard<->mouse hand movements -> less strain on your hands and wrists. Vscode has decent vim bindings btw.
I learned to type seriously not in an editor which respected CUA/Windows conventions, nor emacs conventions, nor vi conventions. It was the AMOS Basic editor, which I think followed Rexx conventions or something weird. All I remember is that shift-backspace would delete the whole line, which was terribly easy to do by mistake and extremely frustrating for a kid who didn't touch type or know about undo.
That's given me a lot less patience for people wishing to re-train me for some alternate way do do the very basic things in life. Standard interface design is a great idea. The standards we use, even QWERTY, are a lot better than many would give them credit for.
That's given me a lot less patience for people wishing to re-train me for some alternate way do do the very basic things in life. Standard interface design is a great idea. The standards we use, even QWERTY, are a lot better than many would give them credit for.
Nano is the first thing I apt remove upon installing a new Debian box. Yes, I could use update-alternatives to make it non-default, but better uninstall the damn thing so that nobody can hurt themselves...
How do you even hurt yourself with something that has on-screen help?
When people don't know what ^X means - it's Linux, most tools are very specific of flags and the order in which you put them on the command line.
So is nano saying
- SHIFT-[6](^)-SHIFT-X
- SHIFT-[6](^)-x
- CTRL-[6](^)-SHIFT-X
- CTRL-[6](^)-x
All I see is '^X', on my keyboard '^' is on 6. Why the hell isn't this working?
Little does little Sally know that this is a UNIXism, carat means 'CTRL', X is really just 'x' - but how would Sally know? Sally was just trying to do a simple git commit to get used to using Linux in the first place. Is it little Sally's fault for not knowing? No! Will little Sally have a bad taste in her mouth due to using an unfamiliar tool? Yes. And there you go, little Sally has went on back to Windows. -1 user.
So is nano saying
- SHIFT-[6](^)-SHIFT-X
- SHIFT-[6](^)-x
- CTRL-[6](^)-SHIFT-X
- CTRL-[6](^)-x
All I see is '^X', on my keyboard '^' is on 6. Why the hell isn't this working?
Little does little Sally know that this is a UNIXism, carat means 'CTRL', X is really just 'x' - but how would Sally know? Sally was just trying to do a simple git commit to get used to using Linux in the first place. Is it little Sally's fault for not knowing? No! Will little Sally have a bad taste in her mouth due to using an unfamiliar tool? Yes. And there you go, little Sally has went on back to Windows. -1 user.
If our protagonist is familiar with macOS, as is far from impossible, they may be less confused by the ^ prefix, which in macOS means Ctrl: https://support.apple.com/en-gb/guide/mac-help/cpmh0011/mac
>All I see is '^X', on my keyboard '^' is on 6.
Fair. Have to say though if you just invoke `nano` (that is nano isn't opened with a file) there's a tooltip saying check 'Ctrl-G' which explains that ^ is Ctrl and M- is Alt.
Fair. Have to say though if you just invoke `nano` (that is nano isn't opened with a file) there's a tooltip saying check 'Ctrl-G' which explains that ^ is Ctrl and M- is Alt.
Is there a particular reason why you seem to imply that little knowledge == female? Sometimes the meme of "we need to mention girls more" works in unexpected directions if people are not careful.
If gender of hypothetical example persons is selected at random you'd expect a 50/50 ratio. Perhaps this example just happens to fall into the 50% that happen to be female?
There is no reason to assume the worst. It only detracts from the discussion.
There is no reason to assume the worst. It only detracts from the discussion.
I think you're overly sensitive about things that aren't there
Okay..
I've never learnt Vim or Emacs, have always used Nano when editing via the terminal. However I increasingly find myself firing up a VSCode remote session if I need to edit more than a single line.
Remote VSCode is kind of magic, I'm increasingly working in (local) VMs via it. I have one project that is probably never going to never going to support ARM, and I'm close to needing to upgrade my MacBook. I really want an M2, but this project would be hard to run locally on it. VSCode on a remove VM is probably going to be the answer.
Remote VSCode is kind of magic, I'm increasingly working in (local) VMs via it. I have one project that is probably never going to never going to support ARM, and I'm close to needing to upgrade my MacBook. I really want an M2, but this project would be hard to run locally on it. VSCode on a remove VM is probably going to be the answer.
I liked Atom before I jumped into vim.
I installed about 10 plugins that made my vim look almost exactly like Atom, except much faster, I also had a script that could install the exact plugins in any unix system in a few seconds, very useful since I work with VMs.
Best of both worlds, people often forgets/don't know that vim are actually more configurable than other editors - colors, layouts, you name it.
I installed about 10 plugins that made my vim look almost exactly like Atom, except much faster, I also had a script that could install the exact plugins in any unix system in a few seconds, very useful since I work with VMs.
Best of both worlds, people often forgets/don't know that vim are actually more configurable than other editors - colors, layouts, you name it.
I don't understand something. In order to remote develop you've to install VSCode to the remote machine?
Sort of... VSCode will temporarily download and install its remote server on the remote machine, under your user home, when you connect to it. You don't have to do it yourself.
To connect it's just plain ssh, so as long as you can login you can use it remotely. As soon as you connect it gives you a file file browser to select the root for VSCodes built in file browser side bar.
My understanding is VSCode has a client/server architecture and so this was considered in its architectural design from the beginning. Along with file io, it's runs the language servers, git, terminal, and many other plugins remotely.
Not all your plugins will initially be installed on the remote, but it's just a case of going to the plugins panel and clicking one button to install and enable on the remote.
To connect it's just plain ssh, so as long as you can login you can use it remotely. As soon as you connect it gives you a file file browser to select the root for VSCodes built in file browser side bar.
My understanding is VSCode has a client/server architecture and so this was considered in its architectural design from the beginning. Along with file io, it's runs the language servers, git, terminal, and many other plugins remotely.
Not all your plugins will initially be installed on the remote, but it's just a case of going to the plugins panel and clicking one button to install and enable on the remote.
FWIW, vim can edit files over ssh. You still use your local vim, so you don’t need to [even temporarily] download/install your configuration/plugins on the remote machine.
An alternative approach might be to mount the remote directory as a file system with sshfs.
An alternative approach might be to mount the remote directory as a file system with sshfs.
I’m forever stuck with 1980s Turbo Pascal as my heart’s secret place of text-mode editing comfort, and nano is probably the closest thing available by default in most Unixes.
mcedit was closer (and I still use it even though they stopped bundling it with most distributions for some reason).
I love mcedit feature that lets you pipe selected text through a custom bash script.
I love mcedit feature that lets you pipe selected text through a custom bash script.
This is really curious to me. I'm also very partial to mcedit, it's often the first thing I install on boxes. And also, my first programming language was Turbo Pascal. Is that maybe why I like mcedit so much?
Yes!! Thanks for reminding me.
Turbo Pascal was the ultimate in text editing. In fact, it was a complete IDE in a TUI. And the most-used commands were single keystrokes. Edit-run cycles were so fast that I was writing programs to do regular automation tasks.
Turbo Pascal was the ultimate in text editing. In fact, it was a complete IDE in a TUI. And the most-used commands were single keystrokes. Edit-run cycles were so fast that I was writing programs to do regular automation tasks.
I agree with the article. I think most people who think nano is a "weak" editor simply haven't really used it beyond opening a file, editing a line, and then closing it.
I do all my coding in nano, and I'm more than happy. I gave vim a sporting chance, know how to use it reasonably well, and do use it comfortably when editing collaboratively with a vim user. But nano just works, and without having to go through silly mental hoops. And for all the "mental efficiency" talk, in practice 99% of vim users I have interacted with either end up ignoring all the complicated stuff such that vim actively ends up wasting more of their time to do otherwise simple stuff, or manage to shoot themselves on the foot for every other "clever" thing they try to do.
The latest release (7 onwards) has also become even more powerful, now that it allows function calling in macros (previously you could only use pre-bound keybindings)
I do all my coding in nano, and I'm more than happy. I gave vim a sporting chance, know how to use it reasonably well, and do use it comfortably when editing collaboratively with a vim user. But nano just works, and without having to go through silly mental hoops. And for all the "mental efficiency" talk, in practice 99% of vim users I have interacted with either end up ignoring all the complicated stuff such that vim actively ends up wasting more of their time to do otherwise simple stuff, or manage to shoot themselves on the foot for every other "clever" thing they try to do.
The latest release (7 onwards) has also become even more powerful, now that it allows function calling in macros (previously you could only use pre-bound keybindings)
Perhaps it's confirmation bias, but it seems like quite a few vim/emacs/nano discussions have appeared on HN recently (more so than usual), with much of the commentary being along the lines of "Yeah I had a look at vim, but I don't see the point."
What drives people to make comments like this? Why not either put in the work to understand the point, or just move along?
What drives people to make comments like this? Why not either put in the work to understand the point, or just move along?
I wonder if this blog post got written because some discussion about Fedora switching the OS default for terminal text editors to GNU nano spilled over somewhere.
Fedora Linux 33 Change: https://fedoraproject.org/wiki/Changes/UseNanoByDefault
Fedora Linux 33 Change: https://fedoraproject.org/wiki/Changes/UseNanoByDefault
It seems Ariadne hasn't yet come across a code maintenance situation that she couldn't overcome by expenditure of keystrokes into a typewriter-like program.
There is an illusion that it is all you need because using such a thing you can certainly crank out volumes of brand new content. If you have a clear idea of what you're writing, maybe just backspacing over the odd typo is all you need to forge ahead. And you can easily make small fixes to existing content with Nano, Notepad and whatnot. The more you have to think to make those fixes and the smaller is the actual textual change, the less of an impediment is it to use a "nonprogrammer's editor". If it took you 180 minutes to figure out it, shortening the editing from 30 seconds to 5 seconds succumbs to Amdah'ls Law; the speedup is virtually nil.
There can be a range of editing needs in between these use cases, in the context of development.
From Ariadne's experience I don't have the sense that she's worked in a software organization in a team, working on big changes to a big, existing code base and such and under pressure. Moreover, even in such an environment, there are those who survive somehow with goofy non-programmers' editors. You know the types; they announce themselves with their tattle-tale trail of wrong formatting (e.g. tabs where there should be spaces, incorrect indentation, ^M carriage returns in Unix-formatted files ...) spurious blank lines, or else trailing newline at the end of the file, trailing whitespace in lines and such. The times when raw editing is really the bottleneck are rare; and in all the other times, Amdahl's is ever present. Someone who has somehow figured out what needs to be changed where (with no help from any code navigation features in their glorified typewriter) can just crank it out. If what should take 5 minutes takes 45, it's not a big deal in the big picture. The assiduous Turtle armed with Notepad will beat the Hare who aptly uses a programmer's editor, but is unable to settle down to work.
I can see how a developer could convince themselves that all they need is a glorified typewriter program for coding, and easily brush aside any evidence to the contrary. What you Get Done with that typewriter is your direct, personal experience, whereas how other people work is just anecdotes, not hard data.
There is an illusion that it is all you need because using such a thing you can certainly crank out volumes of brand new content. If you have a clear idea of what you're writing, maybe just backspacing over the odd typo is all you need to forge ahead. And you can easily make small fixes to existing content with Nano, Notepad and whatnot. The more you have to think to make those fixes and the smaller is the actual textual change, the less of an impediment is it to use a "nonprogrammer's editor". If it took you 180 minutes to figure out it, shortening the editing from 30 seconds to 5 seconds succumbs to Amdah'ls Law; the speedup is virtually nil.
There can be a range of editing needs in between these use cases, in the context of development.
From Ariadne's experience I don't have the sense that she's worked in a software organization in a team, working on big changes to a big, existing code base and such and under pressure. Moreover, even in such an environment, there are those who survive somehow with goofy non-programmers' editors. You know the types; they announce themselves with their tattle-tale trail of wrong formatting (e.g. tabs where there should be spaces, incorrect indentation, ^M carriage returns in Unix-formatted files ...) spurious blank lines, or else trailing newline at the end of the file, trailing whitespace in lines and such. The times when raw editing is really the bottleneck are rare; and in all the other times, Amdahl's is ever present. Someone who has somehow figured out what needs to be changed where (with no help from any code navigation features in their glorified typewriter) can just crank it out. If what should take 5 minutes takes 45, it's not a big deal in the big picture. The assiduous Turtle armed with Notepad will beat the Hare who aptly uses a programmer's editor, but is unable to settle down to work.
I can see how a developer could convince themselves that all they need is a glorified typewriter program for coding, and easily brush aside any evidence to the contrary. What you Get Done with that typewriter is your direct, personal experience, whereas how other people work is just anecdotes, not hard data.
One argument I rarely see being brought up in the whole IDE/terminal editor wars is why use a terminal editor at all?
For me, the pain of switching between multiple terminals and then to a different gui program like a browser can be a real tiring chore, especially when debugging.
For me, the pain of switching between multiple terminals and then to a different gui program like a browser can be a real tiring chore, especially when debugging.
it is good for basic edits like configuration files.
vim does just as well and has a lot more functionality universally.
vim does just as well and has a lot more functionality universally.
In the olden times, we had IRCA channels for hackers who dedicated their time and energy to certain kinds of software. You would certainly expect to find this person on IRC in a semi-official nano channel. How is it these days? How do you find these awesome experts?
> modal editing doesn’t really fit my mental model of how an editor should work
The whole point of vim is that you change your mental model to become faster at editing text. People don't come into programming with a blank slate about editors, they were introduced to wysiwyg editors from an early age because of Microsoft Word, web based text input, and now phones (with emojis too). A mental model had been impressed already, but that doesn't make it the "default" or the best.
I used notpad++ in college, then switched to vim after I saw my boss edit some code while I was looking over his shoulder. He could do complex editing tasks with just a couple keystrokes and doing them so fast that I couldn't keep up just watching. It seemed like he was editing at the same speed as he was thinking which didn't seem possible to me at the time.
The whole point of vim is that you change your mental model to become faster at editing text. People don't come into programming with a blank slate about editors, they were introduced to wysiwyg editors from an early age because of Microsoft Word, web based text input, and now phones (with emojis too). A mental model had been impressed already, but that doesn't make it the "default" or the best.
I used notpad++ in college, then switched to vim after I saw my boss edit some code while I was looking over his shoulder. He could do complex editing tasks with just a couple keystrokes and doing them so fast that I couldn't keep up just watching. It seemed like he was editing at the same speed as he was thinking which didn't seem possible to me at the time.
> The whole point of vim is that you change your mental model to become faster at editing text.
The whole point of vi and vim was to edit text visually, instead of as lines.
Bill Joy reflecting on vi in 1984:[1]
"REVIEW: What would you do differently?
JOY: I wish we hadn't used all the keys on the keyboard. I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors go, it (is) pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me. ... The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing. I think multiple levels of undo would be wonderful, too. But fundamentally, vi is still ed inside. You can't really fool it.
Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
I think the wonderful thing about vi is that it has such a good market share because we gave it away. Everybody has it now. So it actually had a chance to become part of what is perceived as basic UNIX. EMACS is a nice editor too, but because it costs hundreds of dollars, there will always be people who won't buy it."
...
"REVIEW: What is it that (WYSIWYG document processor) Interleaf offers you that EMACS doesn't?
JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
This business of using the same editor for 10 years - it's like living in the same place for 10 years. None of us does it. Everyone moves once a year, right?"
1: https://web.archive.org/web/20120210184000/http://web.cecs.p...
The whole point of vi and vim was to edit text visually, instead of as lines.
Bill Joy reflecting on vi in 1984:[1]
"REVIEW: What would you do differently?
JOY: I wish we hadn't used all the keys on the keyboard. I think one of the interesting things is that vi is really a mode-based editor. I think as mode-based editors go, it (is) pretty good. One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me. ... The fundamental problem with vi is that it doesn't have a mouse and therefore you've got all these commands. In some sense, its backwards from the kind of thing you'd get from a mouse-oriented thing. I think multiple levels of undo would be wonderful, too. But fundamentally, vi is still ed inside. You can't really fool it.
Its like one of those pinatas - things that have candy inside but has layer after layer of paper mache on top. It doesn't really have a unified concept. I think if I were going to go back - I wouldn't go back, but start over again.
I think the wonderful thing about vi is that it has such a good market share because we gave it away. Everybody has it now. So it actually had a chance to become part of what is perceived as basic UNIX. EMACS is a nice editor too, but because it costs hundreds of dollars, there will always be people who won't buy it."
...
"REVIEW: What is it that (WYSIWYG document processor) Interleaf offers you that EMACS doesn't?
JOY: I can just look at my screen, and when I print it off, it's the same as it looks on the screen. It is formatted, and I'm tired of using vi. I get really bored. There have been many nights when I've fallen asleep at the keyboard trying to make a release. At least now I can fall asleep with a mouse in my hand. I use the Xerox optica mouse instead of the other one because it is color coordinated with my office. Did you notice? I prefer the white mouse to the black mouse. You've got to have some fun, right?
This business of using the same editor for 10 years - it's like living in the same place for 10 years. None of us does it. Everyone moves once a year, right?"
1: https://web.archive.org/web/20120210184000/http://web.cecs.p...
>> The whole point of vim is that you change your mental model to become faster at editing text.
> The whole point of vi and vim was to edit text visually, instead of as lines.
My language was very imprecise here, I should know better when commenting on Hacker News. I didn't mean the original motivation for creating vi, but the main reason why someone in 2022 would learn vim with all the other text editors out there now. The main feature of vim at this point is the modal editing that requires you to change how you think about text editing. If you aren't going to accept this new paradigm, then there's no point learning vim in the first place beyond how to enter and exit insert mode, save, and quit.
> The whole point of vi and vim was to edit text visually, instead of as lines.
My language was very imprecise here, I should know better when commenting on Hacker News. I didn't mean the original motivation for creating vi, but the main reason why someone in 2022 would learn vim with all the other text editors out there now. The main feature of vim at this point is the modal editing that requires you to change how you think about text editing. If you aren't going to accept this new paradigm, then there's no point learning vim in the first place beyond how to enter and exit insert mode, save, and quit.
Discussed at the time:
GNU nano is my editor of choice - https://news.ycombinator.com/item?id=28174810 - Aug 2021 (230 comments)
GNU nano is my editor of choice - https://news.ycombinator.com/item?id=28174810 - Aug 2021 (230 comments)
You can install nano on Windows using scoop, I usually do this so I can have some kind of text editor in powershell when I ssh into a Win11 box.
Once you do a bit of configuration, nano has all the pleasantries you’d want for a quick edit.
Once you do a bit of configuration, nano has all the pleasantries you’d want for a quick edit.
Does anyone have a good tutorial for vim/neovim that they recommended for learning how to use them effectively? I’ve been using vim for over a year for quick edits, but I don’t think I get the most out of it.
vimtutor. It comes with the full vim install, at least in ubuntu. It will give you the basics, then afterward you can run :h <command> to see what the less used commands do.
Exactly what I needed. I learned a lot from it. Thank you!
As a programer, I do some "block edition" stuff it seems I cannot do with nano.
I say it seems, because I only skimmed nano documentation.
I say it seems, because I only skimmed nano documentation.
What exactly is meant by the notion of "vim-like functionality with modeless editing"?
In this article, it seems to mean syntax highlighting and hiding the help bar.
Tiny solution:
include "/usr/share/nano/*.nanorc"
nano is cool for people with a newer background. If you've grown up with vi the muscle memory just beats anything in productivity.
rob81777(1)
europeanguy(3)
All of the old editors are horrible. Nano, vi, emacs... sure they might be conveniently placed, but are a pain to learn. This one is a vast improvement https://micro-editor.github.io/
Wha?! Nothing matches the power of vi or emacs. Nothing.
If you don't want the power, or don't need the tool, fine. I get that.
But calling vi terrible, is like complaining that a sledgehammer is terrible, because you want to hang a picture, and that's all you have.
If you don't want the power, or don't need the tool, fine. I get that.
But calling vi terrible, is like complaining that a sledgehammer is terrible, because you want to hang a picture, and that's all you have.
That's the thing. I want to hang a picture.
That is why you use Emacs. It has `M-x picture-mode` and its successor, `M-x artist-mode'.
Or stay inside vi, and just filter your picture through the standard unix tool for hanging pictures.
[deleted]
Vi is not a sledgehammer, it’s more like laser cutter from dead space. It can both cut huge monsters and make laser cuts on your organs.
I agree with you. The first UI I used on a computer was Volkov Commander, and maybe so, I'm really partial to mc and mcedit. Nano is tolerable, but vim, emacs are just so alien that I'll never touch them.
It's neat to see that nano supports customization at this level, and I can see the appeal for quickly editing files (though there are superior tools for even that nowadays, as mentioned in this thread), or if you're just getting familiar with text-mode editing, but I couldn't take anyone seriously if they _prefer_ it for programming.
For one, the modal interface is so much superior to traditional key chords. It allows you to efficiently manipulate text and move the cursor, without twisting your hand in awkward positions, and remembering an endless amount of arbitrary chords. Emacs is the worst offender at this, and while it's my editor of choice, I couldn't imagine using it without evil-mode. Vim's default bindings are semantically significant, and naturally invite exploration. `c` is for `change`, `d` is for `delete`, `s` is for `substitute`, `w` is for `word`, etc. There are a limited amount of these that can be quickly learned, but the power comes when you combine them. *D*elete un*t*il the period becomes `dt.` *D*elete *i*nside parens becomes `di)`. Etc. Doing this without a modal interface becomes a chore of repeating key presses, or pressing some obscure combination of keys.
Also, nano lacks any sort of plugin system. This means there's no LSP integration, file system or project exploration, running actions on save, etc. I don't blame it; if it had all those things it probably wouldn't be called _nano_...
I'm a firm believer of using the tool you enjoy using, but it needs to be the right tool for the job. Use nano for its intended purpose, but if you edit text for a living, take the time to learn more advanced tools that will ultimately make your job easier.
For one, the modal interface is so much superior to traditional key chords. It allows you to efficiently manipulate text and move the cursor, without twisting your hand in awkward positions, and remembering an endless amount of arbitrary chords. Emacs is the worst offender at this, and while it's my editor of choice, I couldn't imagine using it without evil-mode. Vim's default bindings are semantically significant, and naturally invite exploration. `c` is for `change`, `d` is for `delete`, `s` is for `substitute`, `w` is for `word`, etc. There are a limited amount of these that can be quickly learned, but the power comes when you combine them. *D*elete un*t*il the period becomes `dt.` *D*elete *i*nside parens becomes `di)`. Etc. Doing this without a modal interface becomes a chore of repeating key presses, or pressing some obscure combination of keys.
Also, nano lacks any sort of plugin system. This means there's no LSP integration, file system or project exploration, running actions on save, etc. I don't blame it; if it had all those things it probably wouldn't be called _nano_...
I'm a firm believer of using the tool you enjoy using, but it needs to be the right tool for the job. Use nano for its intended purpose, but if you edit text for a living, take the time to learn more advanced tools that will ultimately make your job easier.
nano has a file browser, and you can have it run actions on save.
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. Conventions matter. Don't surprise me. That's literally UX design 101. If a single program sticks out like a sore thumb because every keyboard shortcut suddenly means something different than it does in all other programs installed by default, that program is the problem.
Replacing Vi(m) with Nano in the standard install was one of the most important UX decisions made by the major distros in recent years, and I can only attribute to blatant arrogance from some of the decision makers that it took so long in the first place.