I put together a fork of that editor, in C++, with support for buffers, scripting with Lua, and similar things. Nothing amazing, but still quite useful. That was posted here to some small interest:
So I'm not a programmer by trade or hobby, I'm a hardware hacking and sysadmin type. I've dabbled with programming over the years just to try to get my feet wet, with "simple"/"easy" languages like Python, Lua, PHP, etc. I never really got into it and never really grasped the fundamentals beyond basic program flow (something I had already learned with Visual Basic in college 20 years ago).
I saw this on HN a couple of hours ago and figured I'd give it a whirl out of boredom and something to do while dinner was in the oven. I've never touched C before, and while I understand its historical significance and the fact that it's a very low-level language, I was always told to never start with C because I'd never understand it.
Now, I'm not claiming that I understand it to the point I can start writing my own programs, but I will say that the way the author presented this tutorial has built a confidence in me that if I keep pushing at it, I can actually learn to code in C over time. I got through the first chapter and I already have a fundamental understanding of how to manipulate characters and input/output on the command line. Thinking back to my dabbling with bash scripts in the past, I now more fully grasp what I was just guessing at with those.
Granted, it helps that I did start with an understanding of variables, conditional statements, and other basic programming building blocks, but I am no longer intimidated by learning C and I am eager to finish this tutorial. If I still have that eagerness once it's over I'm going to continue learning C, as one of my favorite OSes (OpenBSD) is written in it and I'd love to understand more about how it works under the hood.
Seeing this comment made my morning. As someone who spent way too many years avoiding "hard" subjects that I'd "never understand," who now works in some of the headier waters of computation, I wish more people had this experience of being introduced to a "hard" subject in a way that clicked for them, so they could similarly realize how approachable it is/how capable they are
While I learned a little BASIC as a kid, my first programming language was C, in my 20s. I learned it using the Kernighan & Ritchie book. I can't even remember where I got a C compiler from. Probably a DOS freeware ftp server over dial up.
I eventually got Linux installed (probably from a cd-rom included with a very thick book I bought in person at a book store) so I could use gcc.
If I can learn it under those conditions, you can totally do it! You've got Stack overflow!
I think all you need to really learn programming is a motivation. I was generating rendering instructions for some animation program at the time (ray tracing) and so it seemed like the best thing to do to get the job done. I feel in love.
I've been working on a text editor that uses the chain-of-responsibility design pattern that provides the ability to edit Markdown, AsciiDoc, reStructuredText, and similar content.
Here's yet another guide to building a text editor, using JavaFX, rather than C from scratch:
The second article depicts how the chain works. Using a chain makes combining different features much like snapping together lego blocks. Here's a video of the editor in action---albeit outdated---showing a variable processor, an R processor, and a Markdown processor chained together:
Nope not a tutorial - but the code is nice and clear making it easy to work through and make changes/ add features in as a good learning exercise. The Lite editor plugins also give a good modular way to understand how specific features are implemented and to experiment with etc. The implementation overview (linked in post above) gives a great understanding of what is happening where. Overall its a really nice starting point for playing with the code base and thinking about how to extend or modify for your own use.
This book got me started on my journey of creating a text editor for Android 10 or so years ago. It mainly focuses on data structures for efficiently storing and editing text. I can't recall any GUI-related topics being in there.
My initial implementation was based on this book and used one rich TextView with Spans to do the rendering. After that turned out way too slow I switched to drawing everything myself using the Android 2D drawing API's. It was a fun side project and I learned a lot from it.
I would love to hear about a "first line to last line" tutorial for a simple GTK app in C, python or preferable rust.
To me there seems to be a huge diffuse overhead to GUI programming, which is discouraging for my kind of brain. I thrive building tree houses, but despise puzzles.
That book would probably be very similar to a book about writing your own web browser (since any part of a webpage can be edited by a javascript routine, and modern documents come close to webpages in complexity).
Pavel Klavík is currently programming our own new collaborative rich text editor for OrgPad.com. This will be tightly integrated with Re-frame/ Reagent/ React and be quite specific to OrgPad (so there isn't much reason to open source it or anything like that). I think, it might be one of the few editors written in ClojureScript though.
The issues are multiple. E.g. flickering, when the browser tries to do spell check. The API for spell check is not very useful from what I understood between the swear words by Pavel :-D e.g. it just isn't possible to give it words and receive suggestions back and handle the rest in the application. More and more of the web infrastructure begins to show its root in the static web of the 90s and is hardly helpful for a modern application, where flickering just isn't an option. It seems, we will have our own spell check in the future or whatever to prevent the flickering. There is more stuff like this in the broader web technology stack.
The prototype is I think about 3000 lines of ClojureScript code. It does quite a bit already but there is more to be done. When it is somewhat done, Pavel will probably record a talk about it and put it on our YouTube channel.
Is there a something similar but uses array of bytes as output to application viewport pixels framebuffer? I think it will be way more interesting, especially pixels rendering part. You need implement vector rasterizer (because after you parse ttf font file glyphs represented as sequence of lineTo(x,y) and quadTo(cx,cy,x,y) instructions). You need to implement proper antialiasing (based on area coverage, not sampling, because it gives 256 shades of color not 16x of something like msaa in games). You need to choose some of rendering approaches - for example rasterizing vector objects one by one with blending to background or do some deferring approach with resolving intersection between objects geometrically (to reduce overdraw) and only then walk over pixels and calculate its colors. You also need to implement some dynamic caching and adaptive streaming because you want to zoom big blobs of text and without caching e.g rendering as vector you will not get 60fps and smooth curves without pixelization or LOD changing artifacts)
There's super interesting super-fast very high quality font rendering technique on GPU using extremely simple fragment shader and low-res prerendered texture that contains 3-channel signed distance field.
Zooming big blobs of text at 60fps without caching remains an open problem as it’s necessary to use a GPU shader and all of the approaches make one or another lacklustre trade-offs.
It's simply that drawing a non trivial amount of(nice looking) generic text (accurately) seems simple but actually takes a lot of logic and a lot of processing time relative to a rendering deadline. There are a lot of reasons for this but largely it comes down to having to do a lot of individual rendering every time something changes and when one thing needs to be rerendered (e.g. the user zoomed) it likely means everything needs you have to bulk render everything again in the next 16 or fewer ms.
https://gankra.github.io/blah/text-hates-you/ has a decent description of many of the problems seen with rendering text in the browser setting (which is on the more complex side of text rendering).
Not exactly equivalent, but fabrice bellatd (of qemu, ffmpeg, quickjs fame, among others) has a tiny emacs inspired editor with those features somewhere on bellard.org
Does anyone have a recommendation for what framework(s) to use to build a kind of proof of concept text editor? I've been toying with writing my own editor with some somewhat strange features, not sure where to start if I'm just looking to play around with some ideas. Speed isn't a huge concern, but ease of implementing new features is.
The original editor was introduced here:
https://news.ycombinator.com/item?id=12065217
I put together a fork of that editor, in C++, with support for buffers, scripting with Lua, and similar things. Nothing amazing, but still quite useful. That was posted here to some small interest:
https://news.ycombinator.com/item?id=12137698