edge

w new features to [my C++ text editor](http://github.com/alefore/edge). It's been a lot of fun. I'm still developing my intuitions for what works and what doesn't, but I've already had plenty of experiences where I've been WOW'ed by what LLMs can already accomplish (as well as, to be honest, plenty of very disappointing cases where it struggles significantly on tasks that I expected would have been trivial). It's a learning experience, seeing things like how to avoid hallucinations; developing an intuition for how much to break down large tasks into smaller ones; or knowing when to abort a conversation and restart it with an improved prompt (vs continue to steer it in the right direction). I think investing up-front in setting up a good context (e.g., good validation logic, useful constant contexts, a good set of "review evaluators" that can push-back against sloppy code) can go a long way to increase the odds of success. It has changed my perception on the applicability of AI for developing software. While I've reviewed all the outputs (and often rewrite parts of them manually), I'm already incorporating it into (some parts) of my development life-cycle. I have many ideas for improvements, but figured I'd share this early and ask for feedback. Hopefully others find it interesting; would love to hear your thoughts.

e::Lines here: https://github.com/alefore/edge/blob/master/src/language/tex...

onfiguration (the equivalent to emacs lisp or vimscript), which just happens to be a garbage collected C-like language.)

inds this interesting, this is mostly implemented here: https://github.com/alefore/edge/blob/28c031230a8babe888ffe1a...

with null but the caller always emitted fully constructed types, or the, much worse, symmetric case).

spatch work to other threads, making sure that no mutable state is shared. When the "async" work is finished, I just have the background threads communicate the results to the main thread by setting a future (i.e., scheduling in the main thread the execution of the future's consumer on the results). Async IO operations are modeled just the same. In the beginning I had used callbacks spaghetti (mostly writing things in continuation passing style), but I started trying futures and found them much nicer. I'll admit that on the surface this makes my code look slightly uglier than if it was directly sync code; however, it allows me to very safely use multiple threads. I think not having to make my classes thread safe (I typically stop at making them thread-compatible) and not having to troubleshoot difficult race conditions (and not having to block on IO or being able to easily run background operations) has been a huge win. If I had to rewrite this from scratch, I'd likely choose this model again. My editor only needs to use mutexes and such in very very few places; it suffices to make my classes thread-compatible and to ensure that all work in threads other than the main thread happens on const objects (and that such objects don't get deallocated before the background threads are done using them). I rolled out my own implementation of futures here: https://github.com/alefore/edge/blob/master/src/futures/futu... (One notable characteristic is that it only allows a single listener, which I found worked well with "move" semantics for supporting non-copyable types that the listener gets ownership of.) Here is one example of where it is used: https://github.com/alefore/edge/blob/5cb6f67e1e0726f8fbe12db... In this example, it implements the operation of reloading a buffer, which is somewhat complex in that it requires several potentially long running or async operations (such as the evaluation of several "buffer-reload.cc" programs, opening the file, opening a log for the file, notifying listeners for reload operations...). It may seem uglier than if it was all in sync code, but then I would have to either block the main thread (unacceptable in this context) or make all my classes thread safe (which I think would be significantly more complexity). I think this is cleaner than callbacks spaghetti because the code still reflects somewhat closely its logical structure. For loops I do have to use futures::ForEach functions, as the example shows, which is unfortunate but acceptable. In my experience, with callbacks spaghetti, it is very difficult to make code reflect its logical structure.

or (https://github.com/alefore/edge). I think it's interesting that I'm finding it hard to focus on some topics, but I'm currently very productive in others.

he things shown on the left of the scrollbar correspond to the lines currently shown on the screen; the parts on the right are a representation of the tree for the entire file. The syntax parsing is a bit dumb: just just based on things like parenthesis, comments, quotes, and brackets and such, not really aware of high semantic concepts (like classes or methods). For C++ (and other C like languages such as Java) this is implemented here: https://github.com/alefore/edge/blob/master/src/cpp_parse_tr... (if it seems too complex, part of it is because I cache previous states, as an optimization, since this runs every time you type a character into the file, refreshing the tree; I want this to work with very large source files, where most of the time you type a character the vast majority of the previous outputs can be reused). I have two other parsers, for Markdown and diff (patches). It should be easy to add more parsers, but I want to clean up the API used by them. Anyhow, you just have to generate a representation of the syntax tree (in this structure https://github.com/alefore/edge/blob/master/src/parse_tree.h). I've been considering integrating this with clang or vscode but haven't gotten around to it. Once you have the ParseTree, the editor will display this information about the scopes (the logic that does that is a bit complex but lives here: https://github.com/alefore/edge/blob/master/src/buffer_metad..., function DrawTree, which returns a string with the characters for a given line). I probably gave you more information than you wanted. :-P Thanks again for your comment.

s a bunch of mistakes, but you may find it interesting as an example): https://github.com/alefore/weblog/blob/master/software-corre...

ers directly (mostly my laptop and my workstation), this works well enough. I don't know if overall it'll save me more time than it has taken me to implement it, but I do believe it allows me to move significantly faster than if I still used Vim or Emacs (or than most of my team mates), especially because it allows me to operate at a higher semantic level than otherwise, eliminating distractions from lower level details. ... and, I guess, it has been a lot of fun to implement it (and I've probably learned a bunch). I think it has played a role for me similar to that videogames have played for some of my friends (e.g., this weekend's challenge may be to generate visualizations for the logs I keep for every interaction I have with each file I've edited; implementing stuff like that feels similar to how in the past I felt about making progress in some videogames).