Hacker News Reader

Comment by j1elo | Hacker News Reader

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)

View on HN

> 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

[1] https://github.com/liuchengxu/vim-which-key

[2] https://magit.vc/

[3] https://emacsair.me/2017/09/01/magit-walk-through/

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".

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.

> I'd use "CLI" more precisely to refer to command-line invocation [...] For programs like vim or nano, I think "TUI" (text-based UI, or sometimes terminal UI) is more suitable.

Agree! I also consider that distinction but didn't think of it when writing. Luckily we knew we were talking about the same thing :)

You're right about the GIMP example, but I think that just means that being a GUI program is not an automatic, free-pass guarantee to discoverability. GUIs make software capabilities more evident by the mere fact that they are there right in your line of sight, but of course it still needs a touch of good organization. But that becomes then a matter of visual design and information overload, which is a whole new area.

TUI programs can be perfectly discoverable, as any well written Ncurses app can show. I don't use many, but the first one that comes to mind is Aptitude. You can just run it and, again, most if not all of the possible actions and settings of the program are right there in front of you to explore or notice.

`which-key` is great. But that is already ubiquitous through the standard top-left drop-downs in a GUI:[1] Press `Alt-F` (File, underlined F), all options drop down, then `S` (Save, underlined S).

[1] Or a standard GUI. Emacs can be run as a GUI (not terminal).

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.

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.

It does. Cmd-Shift-/ and start typing

> 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.

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.

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

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

Check out zellij in place of tmux https://github.com/zellij-org/zellij

`:<Tab>`? Or do you mean something else?

Show keycodes (e.g. "<leader> f" next to "open file tree" if you have the keys mapped like that)

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.

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.

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.

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

It should be some phrase you tell a smart speaker, or perhaps a chatbot

Reply on news.ycombinator.com