[HN Gopher] Ptext: A Nano-like text editor built with pure C
___________________________________________________________________
Ptext: A Nano-like text editor built with pure C
Author : asicsp
Score : 120 points
Date : 2023-12-25 11:21 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| JonChesterfield wrote:
| 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.
| kamranjon wrote:
| 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.
| springogeek wrote:
| There's a "thanks" section at the end of the README which
| links to it, from what I can see.
| kamranjon wrote:
| thanks! i'll update my comment
| garbagepatch wrote:
| 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/
| torh wrote:
| 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.
| rahen wrote:
| Indeed. Also the default editor for ELKS (Linux for PC/XT and
| ATs).
| mogoh wrote:
| pure? Is nano not pure enough?
| tekla wrote:
| We call that vim
| nittanymount wrote:
| cool, maybe, like to sharpen C skills with a side project ?
| tyingq wrote:
| It seems like the author is trying to say "no dependencies
| other than libc, not even ncurses".
| lovelyviking wrote:
| 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
| schemescape wrote:
| 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.
| The_Colonel wrote:
| I'm usually not one who complains about bloat, but I
| think this does not meet expectations set by the name
| "nano".
| chungy wrote:
| 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.
| cozzyd wrote:
| Indeed, one would expect it to be 1000 times bigger than
| pico. At 3 MB that's even plausible...
| erik_seaberg wrote:
| And "Pico" is the message composing editor originally
| written for the "Pine Is Not Elm" email client.
| gray_-_wolf wrote:
| 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.
| FredPret wrote:
| Nano has syntax highlighting?!
| lovelyviking wrote:
| yes. and you can turn it off with passing option:
|
| -Y none
|
| or:
|
| ---syntax=none
| matteoraso wrote:
| 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.
| FredPret wrote:
| 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.
| matteoraso wrote:
| >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.
| pjmlp wrote:
| UNIX libc, as it depends on POSIX stuff.
| queuebert wrote:
| Too bloated. The ultimate goal will be "planck" with zero lines
| of code. :-)
| thechao wrote:
| ?
| kuroguro wrote:
| I feel the urge to post an xkcd here. https://xkcd.com/378/
| tczMUFlmoNk wrote:
| 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.
| WesolyKubeczek wrote:
| I guess it's hardcoded to run in something shaped like xterm or
| better.
| nine_k wrote:
| 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.
| MobiusHorizons wrote:
| 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.
| nox100 wrote:
| Completely fails on any non-ASCII for me.
|
| Sorry, I don't mean to be mean. It's just frustrating to see
| people not understand that text editing is hard and then write
| some editor and be like "See, it's so simple" not realizing they
| didn't see the rest of the iceberg
|
| https://news.ycombinator.com/item?id=27236874
| pharrington wrote:
| 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_Colonel wrote:
| 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.
| stevekemp wrote:
| 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 a, o, 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:
|
| https://github.com/skx/kilua/issues/49
| JonChesterfield wrote:
| Can unicode be implemented in a thousand lines or so of C?
| vidarh wrote:
| 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.
| schemescape wrote:
| 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...
| Aloha wrote:
| I'd love something like this that could be called from sh like
| dialog can.
| gdevenyi wrote:
| Don't forget about Micro
|
| https://micro-editor.github.io/
| rahen wrote:
| It's written in Go though, so quite a bit less portability.
| pjmlp wrote:
| Not really pure C, plenty of #include that aren't part of ISO C
| standard.
|
| Pure UNIX/POSIX C, more likely.
| djur wrote:
| "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?
| pjmlp wrote:
| 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.
| torstenvl wrote:
| 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.
| halayli wrote:
| 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.
| pjmlp wrote:
| Pure C means the programming language C, defined by an
| international standard called ISO C, since 1989.
| tom_ wrote:
| 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.
| pjmlp wrote:
| 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.
| mise_en_place wrote:
| Neat, I am a fan of minimalist text editors. There is also
| uEmacs: https://github.com/torvalds/uemacs
___________________________________________________________________
(page generated 2023-12-25 23:00 UTC)