> 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.
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
> What a something means is defined by how many people use it for a given definition.
Only in context.
I don't really care what Windows people do with their Ctrl keys.
But using Ctrl-C for copy in a terminal environment (from TOPS-20 to Linux and macOS, and whatever MSFT calls its captive Linux env) is wrong.
It is wrong because Ctrl-C already performs another critical (more important) system function. It can't do both, and forking (knifing?) up the UI to have it do different things is a mistake.
Sometimes standards emerge rather than from formal bodies but by broad experience and consensus. The Microsoft operating systems dominated human experience for decades. I’m sorry that other systems did different things, but on the basis of cumulative human experience, these key bindings are in fact standard. Any variance, no matter how ideologically pure, is opposed to the collective human experience of cut and paste key bindings. Why do that to people? Because of some market outcomes from 30 years ago didn’t go the way you prefer so we should impose confusing experiences on everyone? That’s audacious.
Ctrl-C for copy is not a standard in the UNIX/POSIX terminal environment, and it cannot become so, due to the preexisting meaning. Any other usage in that context is wrong and will fail.
Your bias is in your experience too. There may be more of you than there are of me, globally, but your language (UX expectations) is not universal, and will fail in other places.
> Ctrl-C for copy is not a standard . . . and it cannot become so, due to the preexisting meaning.
This is a non-sequitur. Standards change all the time, even things with a preexisting meaning.
I also seriously doubt you believe it yourself. You brought up the example of Ctrl-Q earlier. Is it truly your position that it's not possible for the standard meaning of Ctrl-Q to be something other than XON?
It is my contention that, in a terminal environment, any attempts to redefine the standard meaning of Ctrl-Q as something other than XON will fail because it is impossible to do so consistently.
Ctrl-Q does not even reach the application in a standard terminal configuration. It is possible to configure the terminal to allow it, of course, and some existing applications do so.
However, it will not become "standard" because it cannot be ubiquitous, or even common except in certain classes of application.
And what would you do with Ctrl-Q? Quit? Ctrl-C has you covered there (retroactive mnemonic: "Cancel").
So don't bother trying to redefine Ctrl-C either, you will only cause unnecessary pain for your users, and adoption hassles for your software.
Windows users are not your target market for terminal-based software. So instead of inventing your own creole Esperanto patois, just speak the local language!
But a text editor is not an interactive operating system repl for controlling jobs and files. Why would it matter? I don’t think the key bindings in Kerbal Space Program have much to do with the key bindings in Factorio either.
Because that's the intuitive behavior in the terminal. The other programs you listed launch their own window and are obviously a different context.
Even things like vim and emacs (the foundational terminal editors) will give you a message that ctrl+c doesn't work the way you expect (admittedly in emacs you have to hit it repeatedly), because it's so expected that it's assumed that's what you're going to try.
You can have different behavior with ctrl + c, but it's going to be confusing enough that you're also going to have to print a message for everyone else.
No, that’s how certain type of OS launched jobs behave, specifically pipes or daemons in foreground. There have always been programs that have very different behavior in their interaction that do not honor the job control binding. Emacs comes to mind, almost all Usenet readers, etc.
At one time it did. In fact I think exactly zero screen oriented editors I have ever used in a terminal don’t honor control c as break. Giving a statement that it doesn’t work isn’t handling it the way the terminal line oriented programs work.
I would not argue that a screen-oriented editor should interrupt/exit on Ctrl-C. Certainly not without confirmation.
(Note that "Break" is another key sequence entirely. If someone asks you to send a Break, you would not send Ctrl-C.)
I am arguing that setting Ctrl-C to any other action (esp a very common action like Copy) in a terminal environment application of any kind, e.g. a screen-oriented editor, is a bad idea.
That is how all launched executables behave, in the terminal environment.
After loaded, some executables install their own handlers for Ctrl-C. None of them are copy/paste.
Emacs does nothing on a single Ctrl-C, and a double Ctrl-C evokes a "this does nothing" message. Vim prints a "how to quit" message.
I'm sure you can find an example of a terminal based program that does something less reasonable with Ctrl-C. I'm not sure you can find an example that treats Ctrl-C as copy. But you could certainly write one. You should expect people to complain if you do!
Rather I think there’s a distinction between line oriented and screen oriented. I don’t think screen oriented programs tend to honor the line mode meh bindings. When you press control-d in top do you expect it to close the terminal?
Ctrl-D means "End of transmission", which is appropriate to exit a program which expects to receive input. A process monitor like top isn't oriented toward input, particularly, so I would not expect Ctrl-D to do anything. And it does not.
By the way, Ctrl-D does not close the terminal either. It tells the shell that you're finished sending input, which means it has no more work to do and should exit. If you have jobs running in the background, it will warn you first (default config). If the shell exits, and it was the only thing running in the terminal, the terminal may then decide to close itself. Some do, some do not.
Back to Ctrl-C though, using your example of top as a screen-oriented program: when you press Ctrl-C in top, it interprets the input as Interrupt, and ... exits! Just like a user in a terminal environment would expect. :)
Yes, I’m aware of what it does. But do you have any screen oriented programs that treats ^D as a signal to close stdin?
You are right, it does exit on ^C. I picked it as an example of something that seems compliant but doesn’t actually behave like a line oriented program as a screen oriented program.
> But do you have any screen oriented programs that treats ^D as a signal to close stdin?
stdin is a different thing in a screen-oriented program than a line-oriented one, yes. Screen-oriented typically operates on characters not strings, roughly.
Closing stdin in a screen-oriented program doesn't really have a meaningful interpretation.
But if you'd like an example of a screen-oriented program that exits on Ctrl-D, I can offer musikcube. Not very well-known perhaps (though it's a great music player), and to be fair I consider the Ctrl-D behavior to be a UX oddity, however harmless.
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.
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.
ssh is a transport method. Of course it should not interpret in-line application commands.
xterm should also not respond to an application command.
An editor is an application, and it should respond. You can choose to handle interrupts instead of immediately exiting of course. But the meaning is intact.
A well-behaved application in a POSIX environment will not fight the well-established conventions. There are many reasons for this, but the two most obvious are:
- The implementation of the expected behavior might be outside of your control. Try pressing Ctrl-S in some terminals, and you will find that it does not reach the application because flow control is handled at a lower layer. By convention.
- Just don't abuse your users! If they get accustomed to using the non-standard Ctrl-C for copy, and then use that same action in another application, they might lose data and it will be your fault.
> If they get accustomed to using the non-standard Ctrl-C for copy, and then use that same action in another application, they might lose data and it will be your fault.
That ship has sailed. Today, most people are accustomed to using Ctrl-C to copy.
But Mac OS (Xerox PARC) invented cut/copy/paste/undo, and defined the keys to be Cmd-X/C/V/Z. Instead of trodding upon well-established conventions (including those in use in the Apple II-][-// world), they made their own new ones.
Microsoft didn't make their own keyboards (at the time), so was at a bit of a disadvantage when they copied the functionality from Apple. They didn't have to choose Ctrl, but they apparently decided that multitasking and job control were the domain of non-personal computers and not their problem.
Is it, though? I’d argue that nano is the most accessible, easily discoverable, and usable editor for simple text editing available on almost any Linux system out there.
It’s no IDE, but it never claimed it was either. It doesn’t require a manual, as even the shortcuts are shown at the bottom of the screen for reference. And it includes syntax highlighting, tab handling, and basic cut/copy/paste handling.
What is it you’re missing from a standard text editor?
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.
X and VNC and all the others place much higher demands on your network connection.
If all your boxes are reasonably local those can be great options, but they still don’t obsolete tmux and stuff. Nothing obsoletes tmux and stuff.
Whether it’s vi or emacs or tmux or whatever: this field is too competitive to let shitty stuff stick around for decades. People who go all terminal know the alternatives, they’ve tried them, they try the new ones, and they know what the fuck they’re doing.
While I agree that ssh -Y requires a somewhat fast connection, VNC works at 10 MBit/s. RDP and XDPA works at 3 MBit/s.
And if the speed is lower, then typically it also implies a high latency. Then I have found that running a GUI remotely via xpra gives a better experience than running an editor with IDE features under ssh and tmux. I suspect XPRA protocol simply has less round trips than a terminal IO as the latter was never designed for high-latency links.
> 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.
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 find they're very different parts of memory. Keyboard shortcuts live in your hands -- they're muscle memory.
Trying to remember where some option in a cluttered dropdown menu you used 20 minutes ago is working memory, something I'm personally terrible with. It's either whiplash out of a flow state, or risks sidetracking me.
It takes practice to build muscle memory, but it's something that generally stays with you for a long time, so it's an investment.
The point is that you don't think about keyboard shortcuts. You just think about the thing you need to do, and let your hands do it.
Doesnt have to be shortcuts.
You know where the items are. Press menu -> 3x down, enter, enter, tab, tab, type something, done. Compare that to the same by mouse.
This is why old cashier systems are so super fast.
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.
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).
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.
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))
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.
* 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
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
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.
For an interactive program, favor simplicity over portability to more than a handful popular platforms that people are actually using.
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.
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.
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/