▲ 102 points
back
98 comments
> The default key bindings are intuitive. Input text as normal, use directional keys to move around, use Ctrl-S to save, Ctrl-O to open, Ctrl-X to exit.
Ctrl-X to exit is not intuitive. That's used to cut text almost everywhere. Instead, use Ctrl-Q (quit).
It's been 35 years since CUA[1]. Another terminal editor, micro[2], already adopted these conventions—Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste—other terminal editors should as well.
> Ctrl-C to copy, Ctrl-X to cut, Ctrl-V to paste—other terminal editors should as well.
Blasphemy. Especially in a terminal environment.
Ctrl-C has meant "Interrupt" since the 1960s.
IBM and MSFT decided to bastardize the Macintosh's Cmd-C into Ctrl-C for "Copy", but this is a historical tragedy that should not be propagated.
Ctrl-S means "XOFF ~(Pause output)", and Ctrl-Q means "XON ~(Resume output)".
What a something means is defined by how many people use it for a given definition. If tomorrow half the earth starts saying "fork" for knife then that is what "fork" will mean - the ratio for ctrl-c meaning copy vs its Unix meaning is even stronger. Being there first has exactly zero importance
I am a heavy terminal user and I am fine with an editor using ctrl c,x,v and for copy,cut,paste. It isn’t “Blasphemy”, there’s plenty of ways to send a signal to a process if you really need that. It’s an editor. Let’s chill a bit.
> Ctrl-C has meant "Interrupt" since the 1960s.
Terminal != Terminal application
Would you really want your SSH connection or editor session with unsaved changes just exit after pressing one key combination? Interactive applications have different requirements than a commandline with much more limited inputs. There's no reason to be against Ctrl-C for copy in a text editor.
Back in those days Mac OS didn't had a terminal, unless for developers using MPW.
From my perspective of using nano for all simple text editing on linux, ctrl-X to exit seems very intuitive to me.
Plus it's even used in that one famous Matrix scene[1] where he is trying to close out of whatever he sees open on his computer. ;)
[1]: https://youtu.be/sjoad6gcRzs?t=31 (31 ~ 50s)
But nano doesn't use Ctrl-S to save and Ctrl-O to open, so Mle already breaks with nano.
Nano should not be the "standard" as that community is small.
I would just use the emacs defaults.
What's with the hacker community and their obsession with a terminal emulator? You're just writing to a framebuffer when you call printf. You may as well cut out the middleman and get better, more responsive controls and rendering of a GUI (and let's not pretend this application is not a GUI). I prefer nedit, just wish it would support Unicode. Or maybe I don't and Unicode should just stop existing. I also notice nedit has less input latency than vim on most terminal emulators.
Decoupling the machine where you do the edit/build/run cycle from the machine where you get your key presses and mouse movements processed has a number of advantages in the general case and is practically non-negotiable in a subset of cases.
By having my editor (and the LSP servers, etc.) running on a different machine I can afford to have it be a big, high core count Linux machine maybe with GPUs in it that is arbitrarily hot or loud or heavy. For many languages (C/C++, Haskell, Rust, there are others) either the build or the go-to-definition or some other frequently-done thing are slow on even the best laptop / quiet PC.
By having the client machine be an appliance running a terminal emulator, my colleagues and I can be indifferent to one another’s choices in desktop environment: there can be Mac people and Windows people and desktop Linux people etc. In my case I can have a slim little MacBook Air that can drive a big display, play sound properly out of the box, wake/sleep properly out of the box, and otherwise get out of the way while I work on the “real” computer, which can be anywhere with a manageable ping from here.
There are disadvantages too: mostly that networks go down, GUIs are nice for some things, and others. It’s not a free lunch.
It’s a tradeoff (and I’m aware that it’s surprising to many that regular computers still aren’t fast enough for many hackers), buts it’s not just Luddism.
One can run GUI editor just as well either directly via ssh -Y or via VNC. So this is not an argument for a terminal editor.
> What's with the hacker community and their obsession with a terminal emulator?
Because unlike web apps, terminal apps are often fast (and even faster when the terminal has HW acceleration, see for example https://alacritty.org). Unlike native GUIs, they can easily go through a low-bandwidth network connection (e.g. ssh). They are often portable and can be easily made stable without a huge stack of dependencies.
Terminal / monospaced font gives a lot of calmness to your screen. It also forced you to think about keyboard shortcuts and controls in general.
But why would I want to think about keyboard shortcuts and remember controls, if we can have better, self-discoverable interfaces rather than something designed in the 1970ies?
I have already done enough of it since Timex 2068 was considered modern.
Because our main work environment is the shell..? Writing code in a terminal is seamless and fast, and it fits very well in a tmux workflow.
Mine is the IDE and whatever a shell can do, a language REPL does X times better.
Terminal emulators, IMO, have 2 big reasons they are popular. First is that they work like a better, more stable web browser in the sense that they provide a standard platform to develop UIs on. Second is that the command shell is arguably the best general purpose UI we have for computers today and it lives in the terminal.
You might not have the luxury of a GUI in many (most?) production (or staging, for that matter) environments.
Should you be spending a lot of time in the production environment though? Also, in many places, the list of things you can do in the production environment is quite short (viewing logs or reconfiguring things), because the app runs off a Docker-or-whatever container and is written in a compiled language (so you can’t just hack together a bugfix in vim on the production server).
You can use xnedit which supports unicode (UTF-8).
https://sourceforge.net/projects/xnedit/
It can read nedit default setting file.
It also supports antialiased fonts, has an improved file selection box, indent rainbow and more...
> What's with the hacker community and their obsession with a terminal emulator?
I spend a lot of time ssh’ed into other computers where there is no gui.
I often tell new devs that there are different formats for computer programs, just like with media.
1. One dimensional, text only
2. Two dimensional desktop
3. Three dimensional VR / AR, etc
Just like audio, video and physical immersive art, having one that exists doesn’t make the others invalid, bad, or useless. You need to pick the right format for the job.
If you’re doing “low level” things one dimensional is often the most useful - which, I think, is why the hacker community prefers terminal based.
(not to mention you can often view lower dimensional things in higher dimensions, but not the other way around (something like running a terminal in VR vs VR in a terminal))
They are easier to implement than yet another X Windows clone, so that is why, they go with the easier path.
there's xnedit, but I think you'll have to compile it yourself. I only had to do "apt install libmotif-dev" to get it to build with "make linux"
Love when projects use asciinema to show a quick demo. It's incredibly useful tool
A better alternative is to record the window with a screen recorder. Here is why, point by point:
* You get a video in a standard container and modern compression format you can host anywhere, and edit with video editing tools.
* Screen recorders can capture the microphone too, so you can explain what you're doing.
* Importantly, they can also capture the mouse cursor, which is useful even in a demo of a TTY app that has no built-in mouse support, because you can point to things in the terminal and highlight them as you speak. Mouse-based copy and paste actions are easier for the viewer to follow when there is a cursor.
* Everything you see is captured, pixel for pixel (other than very very fast, fleeting actions that are quicker than the frame rate, obviously).
* If in the demo you need to scroll up through the TTY history with the scrollbar or Shift-PgUp, that is all nicely captured. Your scrollbar is included in the video.
I can't recommend asciinema becuase while the tools to record TTY sessions are free, the animated rendering is done by uploading to the website. There are ways to self-host asciicast, but that looks like a huge PITA compared to a video file you can send to someone as a mail mail attachment, drop into a Slack channel, or put into a shared file directory. I don't want to become a host to give someone a file.
I tried alternatives to asciicast like ttystudio; they are all a hassle compared to even the most basic screen recording app like kazaa on Ubuntu, and lose on all the above points. But at least some of the alternatives give you a GIF file you can put anywhere.
Some work by simulating an ANSI terminal internally, rendering it to pixels and taking snapshots of that state --- which is just a form of screen recording!
I would say it's fair to TTY specific recording an anti-pattern. It seems cool and everyone is doing it, until they slap themselves on the forehead one day.
Made me doubt about my fidelity towards vis[0] but then realized mle does not have vi-like modal editing.
I randomly stumbled on Vis a week ago and have been pretty obsessed with it. It’s amazing how little code it is (eg builds from source in a couple seconds), and the Lua integration is really cool! Also, Vis has really cool structural support for multiple cursors. I’m working on a WebAssembly port of Vis…
I don't want to be mean. I do notice sometimes that "small text editors" have a habit of becoming more and more "fully featured" until they're not small anymore.
I saw this editor recently as a consequence of noticing that there seems to be a rewrite of the termbox library (ncurses alternative) in progress: https://github.com/termbox/termbox2
How do I say it? mlee? mleh? mlay? em-el-ee?
I'm a "mleh" person
I think it's supposed to be Emily.
Melee
> Stackable key maps (modes)
Does this mean I can have a vi-like experience, but I have to configure it myself? A quick look into the help page of mle was not very helpful.
Modes doesn’t mean Vi-like; just that you can have multiple commands on the same bindings.
The power of Vi is in the grammar. It’s fairly intuitive to combine motions with verbs, and you can string together chains of commands without much thought.
For example, “04wd$VU” would uppercase the first four words in a line and delete the rest of the line.
I don’t think something like that would be achievable with the basic key mapping that Mle has.
Does there exist a terminal-based editor with VS Code shortcuts? 90% of the time all I want is the multi-cursor mode (Ctrl-D etc).
Vim colleagues insist I could just write macros, yeah no.
"I want X"
"Here you go"
"Yeah no"
> Favor simplicity over portability
Not sure if I'd go with that one.
Unless you plan to run it on some exotic Unix, why you'ld prefer portability over simplicity?
Looks much like vim, what's the differentiation?
vim is also super extensible with plugins - one of the biggest reason to use it.
It isn't anything like vim since it doesn't utilize a modal paradigm. Rather what mle means with modes is different keymaps depending on context, i.e. replace grep with git grep if .git exists. If you want to compare to something else, it can said it's a more advanced (aforementioned keymaps, splittable windows, and others) Lua-extensible nano.
My guess is the idea is that you can easily extend and customize it since the code base is kept small and simple (10k loc seems quite neat).
I'm personally not the crowd who'd use this kind of software. My preference is emacs which has a different philosophy when it comes to "hacking" the editor.
This project might be something for the suckless crowd.
I always liked the way Borland C++, Power Menu, and Norton Commander worked.
Written in C! I see you like to live... dangerously.
What's dangerous about this? I don't know much abojt security, are text editors a common threat vector?