Ptext: A Nano-like text editor built with pure C | Hacker News Reader

Ptext: A Nano-like text editor built with pure C

github.com

147 pointsasicsp66 comments

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.

There's a "thanks" section at the end of the README which links to it, from what I can see.

thanks! i'll update my comment

They also thanks viewsourcecode.org but don't directly link to their excellent tutorial on how to build Kilo yourself: https://viewsourcecode.org/snaptoken/kilo/

I like the extensive way Antirez has commented the data structures (and the rest of the codebase), something that was missing in the ptext code.

Indeed. Also the default editor for ELKS (Linux for PC/XT and ATs).

Yep. Fit for my sole purpose of using other editors: Editing vim Makefile when I decide to recompile.

Don't forget about Micro

https://micro-editor.github.io/

It's written in Go though, so quite a bit less portability.

Not really pure C, plenty of #include that aren't part of ISO C standard.

Pure UNIX/POSIX C, more likely.

"Pure C" doesn't really mean anything, but if it did mean something it would mean "only C", not "only standard C", wouldn't it?

The programming language C is defined by ISO C, this isn't 1970's any longer.

Thus pure C, by definition is what the said standard since 1989 says what the programming language and standard library is supposed to be.

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.

The world is full of impure C.

Objectively we have a clickbait title.

Yes, and much of what is in the later versions of the C standard haven't been adopted widely by C programmers.

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

There is a reason why they are called system and vendor libraries, and not standard library.

They are third party libraries, outside the language reference.

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 means the programming language C, defined by an international standard called ISO C, since 1989.

I think that's "Standard C"?

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.

Pure C means using the programming language C, alongside its standard library, without any kind of extras.

This "pure c" won't compile with any random C compiler, unless it happens to be a C compiler in a POSIX environment.

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

A point of view I disagree with, there is no point using pure C in the title, when it clearly isn't.

This is HN, we police articles after all.

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.

Is it a reasonably common thing for Windows users to operate a text editor from a terminal? (Outside of WSL)

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.

I'd say it's not a reasonably common thing for Windows users to do anything from a terminal.

For power users, sure, for all the same reasons you'd do it on Linux even when running a GUI.

Neat, I am a fan of minimalist text editors. There is also uEmacs: https://github.com/torvalds/uemacs

I’ve been wanting to make a library for Pico-like interfaces, with the commands and key combinations listed at the bottom of the screen.

I thought something like that must exist, but I haven’t found it yet…

I'd love something like this that could be called from sh like dialog can.

I guess it’s hardcoded to run in something shaped like xterm or better.

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.

read the code. and i liked doing that. while i do mostly java, c++ and rust. there is an elegant beauty in pure C code.

pure? Is nano not pure enough?

We call that vim

cool, maybe, like to sharpen C skills with a side project ?

It seems like the author is trying to say "no dependencies other than libc, not even ncurses".

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 was shocked to discover that the source code distribution for GNU nano is over 3 megabytes.

To be fair, it also has more features than I expected, e.g. syntax highlighting. And I’m sure it runs on an obscene number of platforms.

I'm usually not one who complains about bloat, but I think this does not meet expectations set by the name "nano".

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.

Indeed, one would expect it to be 1000 times bigger than pico. At 3 MB that's even plausible...

And “Pico” is the message composing editor originally written for the “Pine Is Not Elm” email client.

I mean, 300kB is just the changelog and >1MB is configure script... Translations take up a lot as well.

I am not arguing nano is pinnacle of minimalism, but it is not like it's 3MB of C code.

Nano has syntax highlighting?!

yes. and you can turn it off with passing option:

-Y none

or:

—-syntax=none

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.

First time I heard about nanorc!

There’s something really cool about Nano. It’s almost everywhere, it’s super simple, but doesn’t have bonkers key combos like vi and emacs.

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

UNIX libc, as it depends on POSIX stuff.

Too bloated. The ultimate goal will be "planck" with zero lines of code. :-)

I feel the urge to post an xkcd here. https://xkcd.com/378/

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.

Reply on news.ycombinator.com