4 ms·

See, that's why even though I'm a terminal user first and foremost, I really like the discoverability of GUIs, and that's where a good GUI is unbeatable by CLI.

by j1elo 4y ago

See, that's why even though I'm a terminal user first and foremost, I really like the discoverability of GUIs, and that's where a good GUI is unbeatable by CLI. This would have just been an entry "Save if needed" in the File menu, right below "Save", and users would probably find it by accident while looking at the menu, even while not actively looking for new ways to save a file. (Not getting into the fact that a well programmed Save function would, IMO, not do anything if there are no changes, i.e. if I was the one writing the code, the Save button would be greyed out, or in the case of vim, :wq would not write anything if no changes had been made... but that's a different discussion)

Am4TIfIsER0ppos 4y ago
A menu? WTF is that? Some sort of out-dated ui element no doubt.
- photonbeam 4y ago
  It should be some phrase you tell a smart speaker, or perhaps a chatbot
armchairhacker 4y ago
programs like vim and tmux desperately need a menu which just shows all available commands (including plugins), even if it’s opt-in. AFAIK no such menu actually exists in vim or neovim because of the way some of the commands are hard-coded
- Tmpod 4y ago
  Telescope[1] on NeoVim can provide such interface. It is not standard, but telescope is becoming really widespread. [1]: https://github.com/nvim-telescope/telescope.nvim https://github.com/nvim-telescope/telescope.nvim
- earthling8118 4y ago
  Check out zellij in place of tmux https://github.com/zellij-org/zellij https://github.com/zellij-org/zellij
- wruza 4y ago
  `:<Tab>`? Or do you mean something else?
  - armchairhacker 4y ago
    Show keycodes (e.g. "<leader> f" next to "open file tree" if you have the keys mapped like that)
rgoulter 4y ago
> even though I'm a terminal user ... I really like the discoverability of GUIs, and that's where a good GUI is unbeatable by CLI. CLI has poor discoverability? Sure; but even on the terminal, discoverability can still be good: A couple of nice examples of discoverability in keyboard-focused programs: - emacs' which-key[0]; there's a vim port[1] too. This shows you (some) of the available keybindings for the next input, and a short label. So you don't have to remember what `SPC h p ...` or all the options under `SPC f...`.. but it still helps to recall that `SPC h` is for 'help' related commands, `SPC f` for file related commands. - emacs' magit[2][3]. Magit is so good at discoverability, that I'd rate it as the best tool for using git with. I've learned more about git from using it. [0] https://github.com/justbur/emacs-which-key https://github.com/justbur/emacs-which-key [1] https://github.com/liuchengxu/vim-which-key https://github.com/liuchengxu/vim-which-key [2] https://magit.vc/ https://magit.vc/ [3] https://emacsair.me/2017/09/01/magit-walk-through/ https://emacsair.me/2017/09/01/magit-walk-through/
- j1elo 4y ago
  Yeah, you're right that CLI discoverability can still be good, but that's the same "can" than when talking about how "Electron apps can be responsive and fast" when putting VSCode as the prime example... yes, they can, but only with a great deal of extra effort from the devs, compared to the instantaneous visual feedback that a new entry provides on a GUI. In practice (which is what matters, ultimately), most CLI tools don't have this desirable property of "discoverable by accident".
  - rgoulter 4y ago
    Slight nit-picking; maybe the distinctions are useful for this conversation: I'd use "CLI" more precisely to refer to command-line invocation of programs (using some shell like bash, fish, or powershell). For programs like vim or nano, I think "TUI" (text-based UI, or sometimes terminal UI) is more suitable. > yes, they can, but only with a great deal of extra effort from the devs, compared to the instantaneous visual feedback that a new entry provides on a GUI. Right. I'd say instantaneous visual feedback is what helps discoverability. Both menus in a GUI, and the menus in a TUI like in the examples above, exhibit that. But, I wouldn't go so far as to say that a GUI menu is inherently discoverable. e.g. The image editor GIMP doesn't have good discoverability, despite being a GUI program with menus. Whereas e.g. nano is a TUI program, but its essential features are much more discoverable compared to vim. The new tmux-alternative zellij borrows the same "show the keymap at the bottom" feature.
Asooka 4y ago
GVim does have a menu which lists the commands next to the menu options. That's one area in which I feel neovim has regressed -having a default built-in discoverable interface. The various GUIs on offer for it seem aimed at the expert console user, rather than being an effort to bring good GUI to vim.
wzdd 4y ago
I agree that Vim's a mess, but I don't think a good GUI is unconditionally better because you'd need to cut down Vim's gigantic command set in order to make the GUI comprehensible. Just in this thread we've seen options for: close unless there are changes, discard changes and close, save and close, save if changed and close, and save with encryption and close. These would not be menu items. In a GUI, you would have close (which would always prompt if there were changes, unless you turned it off globally), save (which wouldn't do anything if there were no changes), and perhaps some extra setting somewhere about an encryption key. Which would mean you'd lose the option to unconditionally save (useful sometimes if you have something watching the file and you're testing), and you'd have an extra dialog box which pops up sometimes. In terms of discoverability, it's unconditionally better, but it's not unconditionally better in all other ways.
- politician 4y ago
  Personally, I think Sublime Text and VSCode's feature to search for a command (Cmd-Shift-P, Ctrl-Shift-P) strikes the right balance for discoverability within a large set of commands in a GUI app. I wish the feature was standard in all GUI apps. I wish macOS provided the feature for GUI apps as part of its menu bar implementation.
  - motti 4y ago
    It does. Cmd-Shift-/ and start typing
aidenn0 4y ago
gvim suggest :wqa for "save and quit" in the file menu, which is like ":x" but will save all changed buffers, not just the current buffer. both :xa and :wqa work for this though.
gpvos 4y ago
> This would have just been an entry "Save if needed" in the File menu No, the command would simply not exist because having so many commands would take up too much screen space.
- wruza 4y ago
  Right, the moment any gui app becomes command-rich or option-rich enough, ui designers and/or their fanbase start whining about bloated ui and deleting them. Or reinventing a command line, where you couldn’t see it by accident anymore. These claims that gui could be better are cool in theory but real-world guis are underwhelming, to put it mildly.
Too 4y ago
A good GUI doesn't have a save button at all. It saves automatically when you press compile or change focus to another window. This is how both VSCode and Intellij work. Together with a local history that allows you to go back in time to any point earlier during the day. Writing things in stone or reverting to older state is something reserved for git.

by j1elo 4y ago

Am4TIfIsER0ppos 4y ago

A menu? WTF is that? Some sort of out-dated ui element no doubt.

photonbeam 4y ago
It should be some phrase you tell a smart speaker, or perhaps a chatbot

armchairhacker 4y ago

programs like vim and tmux desperately need a menu which just shows all available commands (including plugins), even if it’s opt-in. AFAIK no such menu actually exists in vim or neovim because of the way some of the commands are hard-coded

Tmpod 4y ago
Telescope[1] on NeoVim can provide such interface. It is not standard, but telescope is becoming really widespread. [1]: https://github.com/nvim-telescope/telescope.nvim https://github.com/nvim-telescope/telescope.nvim
earthling8118 4y ago
Check out zellij in place of tmux https://github.com/zellij-org/zellij https://github.com/zellij-org/zellij
wruza 4y ago
`:<Tab>`? Or do you mean something else?
- armchairhacker 4y ago
  Show keycodes (e.g. "<leader> f" next to "open file tree" if you have the keys mapped like that)

rgoulter 4y ago

> even though I'm a terminal user ... I really like the discoverability of GUIs, and that's where a good GUI is unbeatable by CLI. CLI has poor discoverability? Sure; but even on the terminal, discoverability can still be good: A couple of nice examples of discoverability in keyboard-focused programs: - emacs' which-key[0]; there's a vim port[1] too. This shows you (some) of the available keybindings for the next input, and a short label. So you don't have to remember what `SPC h p ...` or all the options under `SPC f...`.. but it still helps to recall that `SPC h` is for 'help' related commands, `SPC f` for file related commands. - emacs' magit[2][3]. Magit is so good at discoverability, that I'd rate it as the best tool for using git with. I've learned more about git from using it. [0] https://github.com/justbur/emacs-which-key https://github.com/justbur/emacs-which-key [1] https://github.com/liuchengxu/vim-which-key https://github.com/liuchengxu/vim-which-key [2] https://magit.vc/ https://magit.vc/ [3] https://emacsair.me/2017/09/01/magit-walk-through/ https://emacsair.me/2017/09/01/magit-walk-through/

j1elo 4y ago
Yeah, you're right that CLI discoverability can still be good, but that's the same "can" than when talking about how "Electron apps can be responsive and fast" when putting VSCode as the prime example... yes, they can, but only with a great deal of extra effort from the devs, compared to the instantaneous visual feedback that a new entry provides on a GUI. In practice (which is what matters, ultimately), most CLI tools don't have this desirable property of "discoverable by accident".
- rgoulter 4y ago
  Slight nit-picking; maybe the distinctions are useful for this conversation: I'd use "CLI" more precisely to refer to command-line invocation of programs (using some shell like bash, fish, or powershell). For programs like vim or nano, I think "TUI" (text-based UI, or sometimes terminal UI) is more suitable. > yes, they can, but only with a great deal of extra effort from the devs, compared to the instantaneous visual feedback that a new entry provides on a GUI. Right. I'd say instantaneous visual feedback is what helps discoverability. Both menus in a GUI, and the menus in a TUI like in the examples above, exhibit that. But, I wouldn't go so far as to say that a GUI menu is inherently discoverable. e.g. The image editor GIMP doesn't have good discoverability, despite being a GUI program with menus. Whereas e.g. nano is a TUI program, but its essential features are much more discoverable compared to vim. The new tmux-alternative zellij borrows the same "show the keymap at the bottom" feature.

Asooka 4y ago

GVim does have a menu which lists the commands next to the menu options. That's one area in which I feel neovim has regressed -having a default built-in discoverable interface. The various GUIs on offer for it seem aimed at the expert console user, rather than being an effort to bring good GUI to vim.

wzdd 4y ago

I agree that Vim's a mess, but I don't think a good GUI is unconditionally better because you'd need to cut down Vim's gigantic command set in order to make the GUI comprehensible. Just in this thread we've seen options for: close unless there are changes, discard changes and close, save and close, save if changed and close, and save with encryption and close. These would not be menu items. In a GUI, you would have close (which would always prompt if there were changes, unless you turned it off globally), save (which wouldn't do anything if there were no changes), and perhaps some extra setting somewhere about an encryption key. Which would mean you'd lose the option to unconditionally save (useful sometimes if you have something watching the file and you're testing), and you'd have an extra dialog box which pops up sometimes. In terms of discoverability, it's unconditionally better, but it's not unconditionally better in all other ways.

politician 4y ago
Personally, I think Sublime Text and VSCode's feature to search for a command (Cmd-Shift-P, Ctrl-Shift-P) strikes the right balance for discoverability within a large set of commands in a GUI app. I wish the feature was standard in all GUI apps. I wish macOS provided the feature for GUI apps as part of its menu bar implementation.
- motti 4y ago
  It does. Cmd-Shift-/ and start typing

aidenn0 4y ago

gvim suggest :wqa for "save and quit" in the file menu, which is like ":x" but will save all changed buffers, not just the current buffer. both :xa and :wqa work for this though.

gpvos 4y ago

> This would have just been an entry "Save if needed" in the File menu No, the command would simply not exist because having so many commands would take up too much screen space.

wruza 4y ago
Right, the moment any gui app becomes command-rich or option-rich enough, ui designers and/or their fanbase start whining about bloated ui and deleting them. Or reinventing a command line, where you couldn’t see it by accident anymore. These claims that gui could be better are cool in theory but real-world guis are underwhelming, to put it mildly.

Too 4y ago

A good GUI doesn't have a save button at all. It saves automatically when you press compile or change focus to another window. This is how both VSCode and Intellij work. Together with a local history that allows you to go back in time to any point earlier during the day. Writing things in stone or reverting to older state is something reserved for git.