Implemented help screen

This commit is contained in:
luxferre
2023-07-28 09:31:43 +03:00
parent 1aeace39f0
commit aa8b5d3ee1
2 changed files with 53 additions and 4 deletions
+2 -1
View File
@@ -112,6 +112,7 @@ Cut lines |`mod D [number] Return` |Cut N lines (starting from current row)
Paste |`mod p` or `mod v` |Paste the line(s) from the clipboard into the current position
Undo (pseudo)|`mod u` |Discard all unsaved changes and reload the file contents
Shell command|`mod e [command] Return` |Save current file, run an external shell command and reopen the file
Help |`mod h` |Displays on-screen help (press Return to get back to normal mode)
## FAQ
@@ -119,7 +120,7 @@ Shell command|`mod e [command] Return` |Save current file, run an external shell
Well, there are several reasons why nne was created:
1. **Minimum overhead**. A text editor is the most important tool on every system, and it's crucial that it does not itself get in the way in terms of resource consumption. Most well-known and established text editors, however, are already bloated beyond repair, up to the point that x86_64 static builds of Vim and Vis against musl libc are sized 3433600 and 644288 bytes respectively. And these are only two examples. On top of that, their codebase already is so large that it cannot be easily (or at all) maintained by a single person. On the contrary, nne weighs around 68k bytes when statically linked with musl, and the sub-1000 SLOC limit (that actually turned out to be sub-750) makes it easy to comprehend by anyone familiar with ANSI C whoever will be reading its source code.
1. **Minimum overhead**. A text editor is the most important tool on every system, and it's crucial that it does not itself get in the way in terms of resource consumption. Most well-known and established text editors, however, are already bloated beyond repair, up to the point that x86_64 static builds of Vim and Vis against musl libc are sized 3433600 and 644288 bytes respectively. And these are only two examples. On top of that, their codebase already is so large that it cannot be easily (or at all) maintained by a single person. On the contrary, nne weighs around 68k bytes when statically linked with musl, and the sub-1000 SLOC limit (that actually turned out to be sub-770) makes it easy to comprehend by anyone familiar with ANSI C whoever will be reading its source code.
2. **Maximum portability**. This editor is designed to be source-compatible with any POSIX environment and with any architecture a POSIX environment can run on. There is no OS-specific code and no external dependencies. You don't need to find or build any libtermkey, terminfo, ncurses and other nonsense for the target architecture you want to compile nne for. It also doesn't require a specific build system: just a simple command line to compile a single file. By the way, it also doesn't contain any compiler-specific quirks: any C89-compatible compiler can build nne binary in a POSIX environment (GCC, Clang, zig cc, tcc).
3. **Maximum freedom**. Public domain deserves a decent lightweight text editor, just like it deserves SQLite, oksh and pdpmake. Besides mg (whose portability is questionable as of now), vce (that can't into UTF-8) and ue (that is straight up unusable on modern terminals), there were no notable text editors released into public domain.