261–270 of 303 posts
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.
Earlier quoted context omitted.
> 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…
> 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 - be…
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).
Earlier quoted context omitted.
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.
> [...] 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 e…
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.
Earlier quoted context omitted.
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 th…
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.
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.
Earlier quoted context omitted.
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 m…
> 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 pref…
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.
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…
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 func…
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.
Earlier quoted context omitted.
> We have a less powerful tool because we want to attract newbies That's exactly it. The modern metrics for anything to be successful is the number of people using it, even if they are completely useless because they did not put any effort into learning the basics. In this case, it would be essentially "ESC", "i" and ":wq". But that's waaaay too hard. No wonder everybody ships a full rootfs in a container for every s…
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.
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".
Earlier quoted context omitted.
> [...] 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 e…
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…
Earlier quoted context omitted.
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…
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 func…
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.