Cool. Compiled easily, made a binary that does look like a text editor, let me make new files and edit an existing one. Only linked against libc, about a thousand lines of C.
So yeah, that is indeed a working text editor that doesn't link against ncurses and the like. Smaller than I would have expected it to be.
Most of that is probably attributable to being based on Kilo: https://github.com/antirez/kilo - a tiny text editor written by antirez who notably also created Redis. Antirez has a bunch of really interesting side projects if you dig into their github repo.
This is objectively untrue, and everyone knows it. A huge amount of C code in the real world goes beyond ISO C. Saying that "C" consists only of what is in the ISO standard is ideological flamewar.
Using system and vendor libraries is part of the C language. We're not talking about language extensions here, we're talking about #include <unistd.h>.
they aren't part of whatever standard yet they are still pure C. Pure C is not a well defined term but it refers to the fact that only the C language was used for the project. Which C version and whether other libs have been used is not part of the term.
Pure C surely just means you're only using C. As in, no C++ or Objective C or whatnot. Nothing wrong with calling out to POSIX functions, at least nothing not already obvious.
Using an API in a language says nothing definite about how that API is implemented.
The API could well be implemented in what you call "pure C".
So that term isn't very meaningful in the way you claim it is, and there is no need for you to be policing it. If it was about "dependency free" could maybe agree more.
The term is often used to indicate that the source code of the project itself does't make significant use of other languages like C++, and to allude to a sense of simplicity (which is often subjective).
I'll not enter the pure-C vs. non-pure-C debate, but this heavily depends on a Unix-like OS and VT100-like terminal. Forget to compile it for Windows, for example.
Very nice project, well organized, with a terse style. Comments are missing but not necessary.
Some Windows servers use the Windows Server Core edition and you can manage it only via terminal if you choose to. In those cases, a command line text editor is useful. I'd say it's not super common from my experience. More often I see people using RDP or SMB file shares for file editing.
Now that hardware terminals are gone, it's a very safe bet.
But xterm is,way rich, it supports esoteric advanced stuff like sixels, etc. For a basic text editor, without split windows, colors, and such, a subset of VT-52 capabilities may suffice.
My guess would be it targets VT-100, but it wouldn't have to be hardcoded, non-curses applications can still make use of the terminfo database to determine the capabilities of whatever terminal they are attached to.
Such an editor will be written in HQ9E+, my fork of HQ9+ with the following semantics:
H: prints Hello, World!
Q: prints the program's source text
9: prints the lyrics to 99 Bottles of Beer on the Wall
E: behaves like a nano-like text editor
+: increments the accumulator
A transparent preprocessor can of course be used to add the necessary "E" to the empty source as part of the build step.
I decided once to recompile nano on mac os because it has some bug or some color missing. I don’t remember why exactly but I do remember a lot of trouble with dependencies … and then my impression was that this tiny editor - is a monster.
It is of course depends with what you compare but still it was shockingly bigger then I was prepared/wanted to see
>I decided once to recompile nano on mac os because it has some bug or some color missing. I don’t remember why exactly but I do remember a lot of trouble with dependencies
Apple is weird about nano. By default, it uses Pico when you try to use nano, which is the text editor that nano is based off of. It seems to be because of concerns over the GPLv3, but the switch isn't made clear to the user, which is pretty deceptive.
Keep in mind that nano's name is derived from the fact it's a clone of pico, and things might start to make more sense. GNU nano's name is a play on words, not a statement about its size.
Nano has a surprising amount of features. I actually use it as my main text editor, and I rarely find myself lacking anything I could possibly want. Off the top of my head, it has the ability to run 3rd party code, a file browser, autoindenting, linting, macros, and a rudimentary autocomplete. A lot of it's reputation for being weak comes from bad defaults, which can be quickly fixed by ricing your nanorc file.
Like many I appreciated seeing Antirez's kilo project, and went my own direction with a trivial fork: adding support for an embedded lua scripting language, allowing multiple buffers, and flexible syntax highlighting for different languages, etc.
For me one of the challenges was getting UTF8 support, since I live in Finland and am exposed to ä, ö, and other characters. It was a fun learning experience, even though I never intended it to become a "real editor" and I continue to use emacs on a daily basis.
Quickly looking over the (closed) bug reports I see the discussion I had with myself back in 2016 which largely caused me to rewrite the core in C++ so I could take advantage of modern facilities to make UTF8 work more easily:
I think you're reading intent that isn't there with this project. The author states its a WIP, and is writing it as a learning experience for building text interfaces without ncurses.
The lack of non-ASCII support is not mentioned on github, so this warning about this basic capability (which is often taken for granted) is certainly useful.
Define implementing Unicode. If you want to support rtl/bidi and grapheme clusters and every little detail, probably not.
But 99% of the utility for most people is there if you can find the right column, and. move left and right by character instead of byte, and can output UTF8 sequences correctly. In C it's a minor pain, but not impossible.
Libgrapheme will get you there for the most part. It will let you find characters, words, sentences. It’s nice because it returns byte offsets so you can use them directly for C data structures. I wish there was a way to get the number of characters along with byte offsets which helps with things like line breaking.
Thank you for this reference. Deriving a freestanding C99 implementation from the standard sounds great. That can probably be rendered as a single source file to drop into a project that otherwise deals only in ascii.
Yeah, but you've added a dependency, which the author doesn't seem to want. If you're willing to add dependencies there are multiple other options too.
So yeah, that is indeed a working text editor that doesn't link against ncurses and the like. Smaller than I would have expected it to be.