vim-which-key VS micro-editor

The only Vim distro I'm aware of is SpaceVim (https://spacevim.org/). I just tested it for a short time but it couldn't compete with my hand crafted settings ;-) But I'm using some of the plugins of SpaceVim in my setup, eg. vim-which-key and vista.vim.

Sounds like you want vim-which-key and coc.nvim.

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

Agreed, that's the only time I find missing Emacs' which-key. (Looks like there is https://github.com/liuchengxu/vim-which-key for this.)

I think you mean a plugin which shows available key bindings as you type, which is what vim-which-key does.

Just an extension.

It is https://github.com/liuchengxu/vim-which-key if you are interested.

>Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?

Yes, although 'm' has a totally different meaning in vim (placing a mark), so there is no popup for that. But it works where there are actually sensible choices, even for marks it works and shows you every available one, which is pretty cool

But again, that's not a specifically vim issue, its endemic to TUIs (hence bash completions and all the other hacks to make discoverability accesible). As well, there are some projects to ameliorate this in vim like the which-key family of plugins01 and others like them.

__usability features__ Emacs has a lot of great ideas for usability, some of which have been copied to vim like which-key https://github.com/folke/which-key.nvim https://github.com/liuchengxu/vim-which-key

Printing cheat sheets is helpful. At some point, make your own. which-key.nvim (or vim-which-key) is a plugin I wish I had found years ago. It gives you hints of next keys available to press. It's great for beginners, and experts. It's like the ultimate real-time cheatsheet.

To see more screenshots of micro, showcasing some of the default color schemes, see here.

Not sure these are really popular, but I cannot resist advertising a few utilities written in Go that I regularly use in my daily workflow:

- gdu: a NCDU clone, much faster on SSD mounts [1]

- duf: a `df` clone with a nicer interface [2]

- massren: a `vidir` clone (simpler to use but with fewer options) [3]

- gotop: a `top` clone [4]

- micro: a nice TUI editor [5]

Building this kind of tools in Go makes sense, as the executables are statically compiled and are thus easy to install on remote servers.

[1]: https://github.com/dundee/gdu

[2]: https://github.com/muesli/duf

[3]: https://github.com/laurent22/massren

[4]: https://github.com/xxxserxxx/gotop

[5]: https://github.com/zyedidia/micro

> The worst way to store and manipulate text is to use an array.

Claim made from theoretical considerations, without any actual reference to real-world editors. The popular Micro[1] text editor uses a simple line array[2], and performs fantastically well on real-world editing tasks.

Meanwhile, ropes are so complicated that even high-quality implementations have extremely subtle bugs[3] that can lead to state or content corruption.

Which data structure is "best" is not just a function of its asymptotic performance. Practical considerations are equally important (arguably more so).

[1] https://github.com/zyedidia/micro

[2] https://github.com/zyedidia/micro/blob/master/internal/buffe...

[3] https://github.com/cessen/ropey/pull/67

There are two main ways to configure sudo.The first one is using the sudoers file.It is located at /etc/sudoers for Linux,and /usr/local/etc/sudoers for FreeBSD respectively.The paths are different,but the configuration works in the same way. A typical sudoers file looks like this. The sudoers file must be edited with the visudo command,which ensures the config is free of errors.Running this command as the root user will result in opening vi by default.If you want to use a different editor you can set the VISUAL environment varaible to the editor you want. For example,if you want to use micro as the text editor run:

found that micro has dedicated info page for copy paste

micro: winget install zyedidia.micro