[HN Gopher] Kilo: A text editor in less than 1000 LOC with synta...
___________________________________________________________________
Kilo: A text editor in less than 1000 LOC with syntax highlight and
search
Author : klaussilveira
Score : 209 points
Date : 2025-05-19 20:28 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| thomasdziedzic wrote:
| How timely, I just finished going through a tutorial that builds
| a text editor like kilo from scratch:
| https://viewsourcecode.org/snaptoken/kilo/index.html
|
| Would highly recommend the tutorial as it is really well done.
| ok_dad wrote:
| Here's a second recommendation for that tutorial. It's the
| first coding tutorial I've finished because it's really good
| and I enjoyed building the foundational software program that
| my craft relies on. I don't use that editor but it was fun to
| create it.
| stevekemp wrote:
| I remember that tutorial fondly.
|
| I played around with kilo when it was released, and eventually
| made a multi-buffer version with support for scripting with
| embedded Lua. Of course it was just a fun hack not a serious
| thing, I continue to do all my real editing with Emacs, but it
| did mean I got to choose the best project name:
|
| https://github.com/skx/kilua
| timw4mail wrote:
| This is one of my favorite moderate-level projects for playing
| with different programming languages.
|
| The original in C: https://git.timshomepage.net/tutorials/kilo
|
| Go: https://git.timshomepage.net/timw4mail/gilo
|
| Rust: https://git.timshomepage.net/timw4mail/rs-kilo
|
| And the more rusty tutorial version (Hecto):
| https://git.timshomepage.net/tutorials/hecto
|
| PHP: https://git.timshomepage.net/timw4mail/php-kilo
|
| ...and Typescript:
| https://git.timshomepage.net/timw4mail/scroll
| pflenker wrote:
| Author of hecto here, thank you for mentioning it! I wrote
| the first version around 5 years ago and I'm happy that
| people still use it. (I updated it in the meantime)
| 90s_dev wrote:
| Reading through this code is a veritable rite of passage. You
| learn how C works, how text editors work, how VT codes work, how
| syntax highlighting works, how find works, and how little code it
| really takes to make _anything_ when you strip away almost all
| conveniences, edge cases, and error handling.
| nulld3v wrote:
| It also inspired this similar Rust project:
| https://github.com/ilai-deutel/kibi#comparison-with-kilo
|
| Although it does cheat a bit in an effort to better handle
| Unicode:
|
| > unicode-width is used to determine the displayed width of
| Unicode characters. Unfortunately, there is no way around it: the
| unicode character width table is 230 lines long.
| 90s_dev wrote:
| > It also inspired this similar Rust project
|
| And these projects:
|
| https://github.com/antirez/kilo/forks
| lifthrasiir wrote:
| Personally, this is the reason I don't really buy the extreme
| size reduction; such projects generally have to sacrifice some
| essential features that demand a certain but necessary amount
| of code.
| vidarh wrote:
| A lot of those features are only "essential" for a subset of
| possible users.
|
| My own editor exists because I realised it was possible to
| write an editor smaller than my Emacs configuration. While my
| editor lacks all kinds of features that are "essential" for
| lots of other people, it doesn't lack any features essential
| _for me_.
|
| So in terms of producing a perfect all-round editor that will
| work for everyone, sure, editors like Kilo will always be
| flawed.
|
| Their value is in providing a learning experience, something
| that works for the subset who don't need those features, or a
| basis for people to customise something just right for
| _their_ needs in a compact way. E.g. my own editor has quirks
| that are custom-tailored to my workflow, and even to my
| environment.
| lifthrasiir wrote:
| You are right, but then there is not much reason to make it
| public because it can't be very useful for general users. I
| have lots of code that was written only for myself and I
| don't intend to publish at all.
| vidarh wrote:
| There's plenty of reason to make it public as basis for
| others to make it their own, or to learn from.
|
| I have lots of code I've published not because it's
| useful to a lot of people as-is, but because it _might_
| be helpful. And a lot of my projects are based on code
| written by others that was not "very useful for general
| users".
|
| E.g. my editor started out based on Femto [1], a very
| minimalist example of how small an editor can be. It cut
| some time of starting from scratch, even though there's
| now practically nothing left of the original.
|
| Similarly, my terminal relies on a Ruby rewrite of a
| minimalist truetype renderer that in itself would be of
| little value for most people, who should just use
| FreeType. But it was highly valuable to me - allowing me
| to get a working pure-Ruby TrueType renderer in a day.
|
| Not "very useful for general users" isn't a very useful
| metric for whether something is worthwhile.
|
| (While the current state of my editor isn't open, yet,
| largely for lack of time, various elements of it are, in
| the form of Ruby gems where I've extracted various
| functionality.)
|
| [1] There are at least 3 editors named Femto, presumably
| inspired by being smaller than Nano, the way Nano
| followed Pico, but this is the one I started with:
| https://github.com/agorf/femto
| fuzztester wrote:
| on first look, the name sounds heavy, but the product actually
| turns out to be very light.
|
| go _figure_.
|
| ;)
| akkartik wrote:
| Funny story: using kilo was the final straw [1] in getting me to
| give up on terminals. These days I try to do all my programming
| atop a simple canvas I can draw pixels on.
|
| Here's the text editor I use all the time these days (and base
| lots of forks off of): https://git.sr.ht/~akkartik/text2.love.
| 1200 LoC, proportional font, word-wrap, scrolling, clipboard,
| unlimited undo. Can edit Moby Dick.
|
| [1] https://git.sr.ht/~akkartik/teliva
| volemo wrote:
| > These days I try to do all my programming atop a simple
| canvas I can draw pixels on.
|
| Why?
| akkartik wrote:
| Terminals are full of hacks. For example, in my terminal
| project linked above the Readme says this:
|
| _" Backspace is known to not work in some configurations. As
| a workaround, typing ctrl-h tends to work in those
| situations."_ (https://git.sr.ht/~akkartik/teliva#known-
| issues)
|
| This is a problem with every TUI out there built using
| ncurses. "What escape code does your terminal emit for
| backspace?" is a completely artificial problem at this point.
|
| There are good reasons to deal with the terminal: I need
| programs built for it, or I need to interface with programs
| built for it. Programs that deal with 1D streams of bytes for
| stdin and stdout are simpler in text mode. But for anything
| else, I try to avoid it.
| ayrtondesozzla wrote:
| Sorry for jumping off topic but I came across mu recently -
| looks very interesting! Hope to try it out properly when I
| get a moment
| akkartik wrote:
| Thank you! Hit me up any time.
| alpaca128 wrote:
| Not GP but the terminal is inefficient and limiting for input
| and UI. For one you cannot detect key-up and key-down events,
| only a full key press. The press of multiple (non-modifier)
| keys at once can't be recognized either. Also there are some
| quirks, like in many terminals your application cannot
| distinguish between the Tab key and Ctrl-I as they look the
| same. But in some (e.g. Alacritty) it can work, so now if you
| have two different keybindings for Tab & Ctrl-I your program
| will behave differently in different terminals.
|
| If you want to do anything that's not printing unformatted
| text right where the cursor is, you need to print out control
| sequences that tell the terminal where to move the cursor or
| format the upcoming text. So you build weird strings, print
| them out and then the terminal has to parse the string to
| know what to do. As you can imagine this is kind of slow.
|
| If you accidentally print a line that's too long it might
| break and shift the rest of the UI. That's not too bad
| because it's a monospaced font, so you only have to count the
| unicode symbols (not bytes)...until you realize chinese
| symbols are rendered twice as wide. Text is weird and in the
| terminal there is nothing but text. But to be fair it's still
| a lot simpler than proportional fonts and a lot of fun, but I
| definitely understand why someone would decide to just throw
| pixels on a canvas and not deal with the historical quirks.
| miki123211 wrote:
| And to make matters worse, unlike a GUI, the terminal
| doesn't provide any semantic information about the content
| it displays to the OS.
|
| This is a problem for accessibility software, screen
| readers, UI automation, voice control etc.
|
| If you want a screen reader to announce that a menu option
| is selected, you need some way to signal to the OS that
| there's a menu open, that some text is a menu option, and
| that the option has the "selected" state. All serious GUI
| frameworks let you do this (and mostly do it automatically
| for native controls), so does the web.
|
| TUIs do not (and currently can not) do this. While this is
| not really a problem for shells or simple Unix utilities,
| as they just output text which you can read with a screen
| reader just fine, it gets really annoying with complicated,
| terminal-based UIs. The modern AI coding agents are very
| prominent examples of how not to do this right.
| vidarh wrote:
| TUI's could be made do this relatively easily. "All" you
| need is to pick an escape sequence to assign a semantic
| label to the following span of text, and have the
| terminal use whatever OS mechanism to make that available
| to assistive tech.
|
| Of course, that doesn't help unless/until at least one
| prominent terminal actually does it and a few major
| terminal applications adds support for it.
| vidarh wrote:
| I think there's lots of scope for improvements to
| terminals, but I feel like this is more a question of
| "nobody has asked for it".
|
| There's been plenty of recent innovation in terminals (e.g.
| support for a variety of new types of underlines to enable
| "squigglies" for error reporting is an example; new image
| support is another), and adding a code to enable more
| detailed key reporting the same way we have upgraded mouse
| event reporting over the years wouldn't be hard, and these
| things tends to spread quickly.
|
| With respect to "accidentally printing a line that's too
| long", you can turn off auto-wrap in any terminal that
| supports DECAWM (\033[?7h / \033[?7l ).
|
| That it's "kinda slow" really shouldn't be an issue - it
| was fast enough for hardware a magnitude slower than today.
| Parsing it requires a fairly simple state machine. If can't
| keep up with VT100/ANSI escape sequences, your parser is
| doing something very wrong.
|
| The difficulty of unicode is fair enough, and sadly largely
| unavoidable, but that part is even worse in a GUI; the
| solution there is to use code to measure the rendered
| string, and it's not much harder to get that right for
| terminals either. It'd be nice if unicode had done this in
| a nicer way (e.g. indicated it in the encoding).
|
| For my own terminal, I'm toying with the idea of allowing
| proportional text with an escape code, and make use of it
| in my editor. If I do, it'll be strictly limited: Indicate
| a start and end column where the text is proportional, and
| leave it to the application to specify a font and figure
| out the width itself.
|
| Worst case scenario would be that you send the escape, and
| the editor doesn't get an escape acknowledging it has been
| enabled back, and falls back on monospaced text and keeps
| working fine in a regular terminal. This way, evolving
| terminal capabilities can be done fairly easily with
| backwards compatibility.
| akkartik wrote:
| Anything is possible to fix; the question is why bother.
| Every fix cuts into the benefit of compatibility. The
| fundamental model of a wrapping/scrolling teletype isn't
| a good fit for the way we use computers today. (It does
| make sense if you work in a real text mode console. Then
| you are really avoiding all the complexity of a graphics
| stack by using hard-coded capabilities your hardware
| provides.)
|
| A simple flat array of pixels seems like a much more
| timeless mental model to build durable software on top
| of. You don't have to wonder how different computers will
| react to a write just off the bottom right of the screen,
| and so on.
| vidarh wrote:
| The reason to bother is that a lot of prefer terminals
| and want to evolve them. The reason they're not evolving
| faster isn't that compatibility is really a problem
| because we see new terminal capabilities gain support
| fairly quickly, but usually because there often isn't a
| major perceived need for the features people who don't
| use terminals much think are missing.
|
| People don't add capabilities to try to attract people
| like you who don't want terminals in the first place.
|
| Wrapping and scrolling can be turned off on any terminal
| newer than the vt100, or constrained to regions. I never
| wonder how a different computer reacts to writing off the
| bottom right of the screen, because that works just fine
| on every terminal that matters. The actual differences
| are relatively minor if you don't do anything esoteric.
|
| A "simple" flat array of pixels means you have to
| reimplement much of a terminal, such as attribute
| rendering, font rendering etc. It's not a huge amount of
| work, but not having to is nice.
|
| So is the network transparency, and vnc etc. is not a
| viable replacement.
| akkartik wrote:
| Availability over ssh is indeed a good point. I've
| reduced my reliance over the network at the same time
| I've grown disenchanted with terminals; thanks for
| pointing out that connection.
|
| The rest are mutually incommensurable worldviews, and we
| have to agree to disagree.
| akkartik wrote:
| _" A simple flat array of pixels means you have to
| reimplement much of a terminal, such as attribute
| rendering, font rendering etc. It's not a huge amount of
| work, but not having to is nice."_
|
| For me the debate isn't about implementing a terminal vs
| something else. I assume one uses tools others build in
| either case. The question is how much the tools hinder
| your use case. I find a canvas or a graphical game engine
| (which implement fonts and so on) hinders me less in
| building the sorts of tools I care about building. A
| terminal feels like more of a hindrance.
| kbolino wrote:
| This isn't meant to detract from the broader point about
| the limitations of terminals, but a simple array of
| pixels is among the least efficient ways to interact with
| modern GPUs, especially if it doesn't support rectangular
| copy operations. The best way to interact with a GPU
| today and for the foreseeable future is through command
| buffers, not direct pixel access per se.
| akkartik wrote:
| The point is well taken. I don't know much about
| interacting with GPUs. I don't particularly care so far
| about getting more performance, given the wildly fast
| computers I have and my use cases (I don't make or play
| games). I _do_ care about power efficiency; do GPUs help
| there? Modern GPU-based terminal implementations aren't
| particularly power efficient in my experience..
| pabs3 wrote:
| Someone else who eschews terminals and replaced them:
|
| https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
| cenamus wrote:
| I really enjoyed the plan9 way of an application slurping up
| the terminal window (not a real terminal anyway) and then
| using it as full fledged GUI window. No weird terminal
| windows floating around in the background and you still could
| return to it when quitting for any logs or outputs.
| vinc wrote:
| Hey Akkartik! That's really interesting! At the moment you're
| still using a terminal to launch the individual apps or
| something else?
| akkartik wrote:
| Whatever works! I mostly use LOVE, and it supports both. Some
| reasons to run it from the terminal rather than simply
| double-clicking or a keyboard shortcut in the OS:
|
| * While I'm building an app I want to run from a directory
| rather than a .love file.
|
| * I want to pass additional arguments. Though I also
| extensively use drag and drop for filenames.
|
| * I want to print() while debugging.
| mac9 wrote:
| This is an interesting concept, how do editors like this fair
| for writing code though?
| akkartik wrote:
| Immature, obviously. Far fewer person-hours of labor have
| been put in relative to what you use all the time. But I find
| it worthwhile to get off the constant treadmill of new
| versions with features I don't care about. Cutting down on
| complexity there creates headroom for me or you to try out
| new approaches I or you might care more about.
|
| My most common development environments these days:
|
| * A live-programming infinite surface of definitions that
| works well on a big screen:
| https://git.sr.ht/~akkartik/driver.love Has minimal syntax
| highlighting for just Lua comments and strings.
|
| * An environment that lets me add hyperlinks, graphics and
| box-and-arrow diagrams in addition to code. Also works on
| mobile devices. Examples: https://akkartik.itch.io/sokoban,
| https://akkartik.name/post/2025-03-08-devlog,
| https://akkartik.name/post/2025-05-12-devlog
|
| The second set of apps are built using the first approach.
| swah wrote:
| Reminds me of Eskil's apps way back when
| https://www.quelsolaar.com/love/development.html
| lor_louis wrote:
| Kilo is a fun weekend project, but I learned the hard way that
| it's not a good base uppon which you should build your own text
| editor.
|
| The core data structure (array of lines) just isn't that well
| suited to more complex operations.
|
| Anyway here's what I built: https://github.com/lorlouis/cedit
|
| If I were to do it again I'd use a piece table[1]. The VS code
| folks wrote a fantastic blog post about it some time ago[2].
|
| [1] https://en.m.wikipedia.org/wiki/Piece_table [2]
| https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
| userbinator wrote:
| _The core data structure (array of lines) just isn 't that well
| suited to more complex operations._
|
| Modern CPUs can read and write memory at _dozens of gigabytes_
| per second.
|
| Even when CPUs were 3 orders of magnitude slower, text editors
| using a single array were widely used. Unless you introduce
| some accidentally-quadratic or worse algorithm in your
| operations, I don't think complex datastructures are necessary
| in this application.
| lifthrasiir wrote:
| The actual latency budget would be less than a single frame
| to be completely non-noticable, so you are in fact limited to
| less than 1 GB to move per each keystroke. And each character
| may hold additional metadata like syntax highlight states, so
| 1 GB of movable memory doesn't translate to 1 GB of text
| either. You are still correct in that a line-based array is
| enough for most cases today, but I don't think it's generally
| true.
| RetroTechie wrote:
| Movement of GB's of data being noticeable should be
| considered a feature, imho.
|
| And if those GB's represent text, with user trying to edit
| that as a single file, well then... PEBKAC.
| lelanthran wrote:
| > The core data structure (array of lines) just isn't that well
| suited to more complex operations.
|
| Just how big (and how many lines) does your file have to be
| before it is a problem? And what are the complex operations
| that make it a problem?
|
| (Not being argumentative - I'd really like to know!)
|
| On my own text editor (to which I lost the sources way back in
| 2004) I used an array of bytes, had syntax highlighting (Used
| single-byte start-stop codes for syntax highlighting) and used
| a moving "window" into the array for rendering. I never saw a
| latency problem back then on a Pentium Pro, even with files as
| large as 20MB.
|
| I am skeptical of the piece table as used in VS Code being that
| much faster; right now on my 2011 desktop, a VS Code with no
| extra plugins has visible latency when scrolling by holding
| down the up/down arrow keys and a really high keyboard repeat
| setting. Same computer, same keyboard repeat and same file
| using Vim in a standard xterm/uxterm has visibly better
| scrolling; takes half as much time to get to the end of the
| file (about 10k lines).
| ofalkaed wrote:
| From what I have experienced the complex data structures used
| here are more about maintaining responsiveness when overall
| system load is high and that may result slightly slower
| performance overall. Say you used the variable "x" a thousand
| times in your 10k lines of code and you want to do a find and
| replace on it to give it a more descriptive name like,
| "my_overused_variable," think about all of the memory copying
| that is happening if all 10k lines are in a single array. If
| those 10k lines are in 10k arrays which are all twice the
| size of the line you reduce that a fair amount. It might be
| slower than simpler methods when the system load is low but
| it will stay responsive longer.
|
| I think vim uses a gap structure, not a single array but
| don't remember.
|
| I am not a programmer, my experience could very well be due
| to failings elsewhere in my code and my reasoning could be
| hopelessly flawed, hopefully someone will correct me if I am
| wrong. It has also been awhile since I dug into this, the
| project which got me to dig into this is one of the things
| which got me to finally make an account on hn and one of my
| first submissions was Data Structures for Text Sequences.
|
| https://www.cs.unm.edu/~crowley/papers/sds.pdf
| shpx wrote:
| VS Code used 40-60 bytes per line, so a file with 15 million
| single character lines balloons from 30 MB to 600+ MB. kilo
| uses 48 bytes per line on my 64-bit machine (though you can
| make it 40 if you move the last int with the other 3 ints
| instead of wasting space on padding for memory alignment), so
| it would have the same issue.
|
| https://github.com/antirez/kilo/blob/323d93b29bd89a2cb446de9.
| ..
| throw10920 wrote:
| > a file with 15 million single character lines
|
| I have never seen a file like this in my life, let alone
| opened one. I'm sure they exist and people will want to
| open them in text editors instead of processing with
| sed/awk/Python, but now we're well into the 5-sigma of edge
| cases.
| vidarh wrote:
| My own editor is array of lines _in Ruby_ , and in now about 8
| years of using it daily, and having the actual editor interact
| with the buffer storage _via IPC_ to a server holding all the
| buffers, it 's just not been a problem.
|
| It does become a problem if you insist on trying to open files
| of hundred of MB of text, but my thinking is that I simply
| don't care to treat that as a text editing problem for my main
| editor, because files that size are usually something I only
| ever care to view or is better off manipulating with code.
|
| If you want to be able to open and manipulate huge files,
| you're right, and then an editor using these kind of simple
| methods isn't for you. That's fine.
|
| As it stands now, my editor holds _every file I 've ever opened
| and not explicitly closed in the last 8 years_ in memory
| constantly (currently, 5420 buffers; the buffer storage is
| persisted to disk every minute or so, so if I reboot and open
| the same file, any unsaved changes are still there unless I
| explicitly reload), and it's not even breaking the top 50 or so
| of memory use on my machine usually (those are all browser
| tabs...)
|
| I'm not suggesting people shouldn't use "fancier" data
| structures when warranted. It's great some editors can handle
| huge files. Just that _very_ naive approaches will work fine
| for a whole lot of use cases.
|
| E.g. the 5420 open buffers in my editor currently are there
| because even the naive approach of _never_ garbage collecting
| open buffers just hasn 't become an issue yet - my available
| RAM has increased far faster than the size of the buffer
| storage so adding a mechanism for culling them just hasn't
| become a priority.
| lor_louis wrote:
| Oh by "more complex" operations I referred to multiple
| cursors and multi line regex searches. I've noticed some
| performance problems in my own editor but it's mostly because
| "lines" become fragmented, if you allocate all the lines with
| their own allocation, they might be far away from each other
| in memory. It's especially true when programming where lines
| are relatively short.
|
| Regex searches and code highlight might introduce some
| hitches due to all of the seeking.
| atiedebee wrote:
| Kakoune has been my main editor for the past year (give or
| take) and uses an array of lines [0]. Ironically, multi-
| cursor and regex are some of the main features that made it
| attractive to me.
|
| I just tested it out on the 100MB enwik8 file I have laying
| around and it does slow down significantly (took 4-5
| seconds to load in the file and has a 1 second delay on
| changing a line). But that is not really the type of file
| you would be opening with your main editor.
|
| [0]: https://github.com/mawww/kakoune/blob/2d8c0b8bf0d7d182
| 18d4c9...
| pmontra wrote:
| I'd love to see the code of that editor. Is it publicly
| available somewhere?
| vidarh wrote:
| There's a wildly out of data repo here[1] that I badly need
| to push updates to, and with the caveat odds are there are
| lots of missing pieces that'll make you struggle to get it
| working on your system. I wouldn't recommend it - I dumped
| in Github mostly mostly because why not rather than for
| people to actually use.
|
| Difficulties will include e.g. helper scripts executed to
| do things like stripping buffers, a dependency on rofi when
| you try to open files, and a number of other things that
| works great on my machine and not so well elsewhere.
|
| I have about 2-3 years worth of updates and cleanups I
| should get around to pushing to Github that does include
| some attempts to make it slightly easier for other people
| to run.
|
| The two things I think are nice and worth picking up on is
| the use of DrB to get client-server, which means the editor
| is "multi window" simply by virtue of spawning new separate
| instance of itself. It's then multi-pane/frame by relying
| on me running a tiling wm, so splitting the buffer
| horizontally and vertically is "just" a matter of a tiny
| helper script ensuring the window opens below/to the right
| of the current window respectively.
|
| But some other things, like the syntax highlighting (using
| Rouge) is in need of a number of bugfixes and cleanups; I
| keep meaning to modify the server to keep metadata about
| the lines and pull the syntax highlighting out so it runs
| in a separate process, talking directly to the server, for
| example.
|
| [1] https://github.com/vidarh/re
| jonstewart wrote:
| ed is the standard text editor.
| revskill wrote:
| So a text editor is about grid manipulation ?
| lbj wrote:
| Funny. These days when I see a headline like that, I assume it's
| some type of web component.
|
| Why are all the commenters so eager to get out of terminals?
| nodesocket wrote:
| This seems like a great alternative for Nano; though Nano is
| really good and just works.
| JdeBP wrote:
| One interesting thing is that even some of those 1000 lines could
| have been eliminated.
|
| It duplicates the C library's cfmakeraw() function, for instance.
|
| https://man.freebsd.org/cgi/man.cgi?query=cfmakeraw&sektion=...
| anonzzzies wrote:
| Ah darn. Closing in on retirement (will never happen, coding is
| too much fun for profit or charity) age, I resistent building an
| editor but I want to. Need to. I hacked so much vim, emacs,
| eclipse, vs code and its all crap (the newer, the worse: all
| these useless gimmicks you won't use past grade school aaarrr
| while lacking power user features). Can I do better? This seems a
| good start.
| giancarlostoro wrote:
| I made a similar editor using Lazarus... since it has syntax
| highlighting components... I guess that's cheating. The more I
| think about it though, I wonder if Freepascal could produce a
| nice GUI for Neovim.
|
| I did try to build one in Qt in C++ years ago, stopped at trying
| to figure out how to add Syntax Highlighting since I'm not really
| that much into C++. Pivoted it to work like Notepad so I was
| still happy with how it wound up.
|
| https://github.com/Giancarlos/qNotePad
| cies wrote:
| Last serious work on this was in 2020. Lacks news worthiness
| imho.
| antirez wrote:
| Check my YouTube channel for an experiment on how I added UTF-8
| support to Kilo showcasing what was, back then, some early
| experiment at using LLMs to ship working code. I need to push
| the changes after some cleanup, but that's not enough for a
| Kilo 2, as it makes things more complicated without showing
| worthwhile programming techniques. So it's sitting on my
| laptop.
___________________________________________________________________
(page generated 2025-05-20 23:02 UTC)