Mle is a small, flexible, terminal-based text editor written in C

Do not favor simplicity over portability to more than one platform. (Feel free to ignore this if you work for Microsoft, as the maintainer of calculator.exe, and similar work.)

Definitely favor simplicity over portability to systems that use sign-magnitude integer representations, or have 36 bit words and 9 bit bytes, or binary files that add extra zeros to pad your file to a full sector, or have no POSIX or Windows API whatsoever, or whose null pointer is not an all-zero bit pattern, ... even if your program runs on some computer they have in the basement of the Smithsonian, they are not going to to risk installing it there, and if they do, nobody will use it.

rkta• 4 years ago

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.

KMnO4• 4 years ago

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.

Gualdrapo• 4 years ago

Made me doubt about my fidelity towards vis[0] but then realized mle does not have vi-like modal editing.

[0] https://github.com/martanne/vis

williamstein• 4 years ago

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…

frou_dh• 4 years ago

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

haunter• 4 years ago

Love when projects use asciinema to show a quick demo. It's incredibly useful tool

kazinator3• 4 years ago

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.

ducktective• 4 years ago

that reply....omg! kazinator is a man of focus, commitment and sheer f*king will

gnubison• 4 years ago

Counterpoints:

* Asciinema text uses the user’s preferred font instead of whatever monstrosity of a Comic Code font the developer happens to like

* Asciinema text can be selected and copied

* You can zoom in on it and it’ll still be high quality

etc. Arguing against Asciinema is like saying you prefer when people take screenshots of their Gnome Terminal windows instead of inserting code blocks into their blog posts :p

amadeuspagel5• 4 years ago

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.

[1] https://en.wikipedia.org/wiki/IBM_Common_User_Access

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

Andoryuuta• 4 years ago

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)

amadeuspagel5• 4 years ago

But nano doesn't use Ctrl-S to save and Ctrl-O to open, so Mle already breaks with nano.

sigzero• 4 years ago

Nano should not be the "standard" as that community is small.

quesera16• 4 years ago

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

jcelerier• 4 years ago

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

alpaca128• 4 years ago

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.

pjmlp6• 4 years ago

Back in those days Mac OS didn't had a terminal, unless for developers using MPW.

otikik• 4 years ago

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.

qualudeheart• 4 years ago

I would just use the emacs defaults.

Aperocky2• 4 years ago

Looks much like vim, what's the differentiation?

vim is also super extensible with plugins - one of the biggest reason to use it.

forgotpwd162• 4 years ago

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.

Aperocky2• 4 years ago

That's too bad, I was assuming it does.

Modal editing is definitely a must for terminal editors, and generally good for all editors.

ghosty141• 4 years ago

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.

dbttdft• 4 years ago

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.

jbverschoor3• 4 years ago

Terminal / monospaced font gives a lot of calmness to your screen. It also forced you to think about keyboard shortcuts and controls in general.

9dev3• 4 years ago

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?

pjmlp6• 4 years ago

I have already done enough of it since Timex 2068 was considered modern.

c0mptonFP• 4 years ago

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.

pjmlp6• 4 years ago

Mine is the IDE and whatever a shell can do, a language REPL does X times better.

hobo_mark2• 4 years ago

You might not have the luxury of a GUI in many (most?) production (or staging, for that matter) environments.

9dev3• 4 years ago

Because what, you sit in the server room with a monitor plugged into the rack and work on production code?

If something can open a shell remotely, it can show a GUI remotely.

Kwpolska• 4 years ago

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

ziml77• 4 years ago

This explanation doesn't do it for me because you also wouldn't be able to run any text editor you like. Basically you're going to be using vi (or possibly vim or nano). It also shouldn't be a daily activity to be poking around directly on a production machine, and if it is then why not setup something like sshfs and use a local text editor on the file? Then you can use whatever GUI or TUI editor you'd like.

benreesman2• 4 years ago

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.

_0w8t2• 4 years ago

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.

stjohnswarts• 4 years ago

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"

eikenberry• 4 years ago

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.

pjmlp6• 4 years ago

They are easier to implement than yet another X Windows clone, so that is why, they go with the easier path.

karteum• 4 years ago

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.

0x20cowboy• 4 years ago

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

dpeterc• 4 years ago

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

jbverschoor3• 4 years ago

I always liked the way Borland C++, Power Menu, and Norton Commander worked.

hobo_mark2• 4 years ago

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.

Brian_K_White• 4 years ago

"I want X"

"Here you go"

"Yeah no"

gilnaa• 4 years ago

"I want X" "Here's Y" "Yeah no"

bitwize• 4 years ago

Written in C! I see you like to live... dangerously.

Zababa• 4 years ago

What's dangerous about this? I don't know much abojt security, are text editors a common threat vector?

t43562• 4 years ago

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.

Mle is a small, flexible, terminal-based text editor written in C

Related Stories