uemacs VS micro-editor

Neat, I am a fan of minimalist text editors. There is also uEmacs: https://github.com/torvalds/uemacs

maybe you're talking about the uEmacs Linus Torvalds still uses today? it's still maintained by him to fit his needs: https://github.com/torvalds/uemacs

u/DellOptiplexFan Ironic, since the literal creator of Linux uses a fork of microemacs https://github.com/torvalds/uemacs

Torvalds's Emacs is nice. https://github.com/torvalds/uemacs

Looks like he uses a thing called uEmacs.

Why don't you ask Linus? Or even better, read his motivation in his fork of microemacs (not GNU Emacs).

He doesn't. Linus uses MicroEMACS [0], which is an entirely different editor that uses emacs bindings.

It's not the lisp machine that incidentally happens to edit code that GNU Emacs is.

Or, as he puts it [1]:

> I use this abomination called "micro-emacs", which has absolutely nothing to do with GNU emacs except that some of the key bindings are similar.

[0]: https://github.com/torvalds/uemacs

Then on the other hand he has his own fork of µEmacs: https://github.com/torvalds/uemacs

Micro editor (https://micro-editor.github.io/) works best for me but it's terminal-based.

Simple yet customizable? My thoughts go to Sublime Text if you want a GUI editor and closed-source is OK, or Micro if you want a TUI editor that is open source:

https://micro-editor.github.io/

Like OpenBox, most casual users can be dropped in and know their way around their interfaces, and both options are kinda lightweight compared to other modern options. There is power available for serious customization if you want (you can write plugins for them in Python and Lua, respectively).

Personally, both Vim and Emacs do not remind me much of OpenBox. I think i3wm is more a Vim, and I guess XMonad is the most Emacs-like window manager I've tried. (Arguably, EXWM is the only truly Emacs-like window manager...)

Love the look, definitely throwing me back to the halcyon QBasic days.

Another way to achieve an old school raster style green screen aesthetic is to combine cool-retro-term with the minimal editor "micro".

https://github.com/Swordfish90/cool-retro-term

https://github.com/zyedidia/micro

This is great! I used to install micro[0] as "nano with better shortcuts", but it was always a bit of an overkill, so I'm really happy with this change.

One quirk that remains: even with --modernbindings, Ctrl+X and Ctrl+C will add to nano's clipboard, instead of replacing whatever is there.

[0] https://micro-editor.github.io

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