The 2025 Wheel Reinvention Jam just concluded. See the results.
Two ideas for making better use of the full width of a widescreen monitor when editing source code

About Reimagining the Programming Text Editor


I first explored the idea of presenting a single file in multiple columns like a newspaper. Source code is often aligned to relatively tight widths because it is easier to scan vertically than to scan lines of greatly varying varying width. Most text editors and IDEs are set up to show one file and switch between them. Even though IDEs like Visual Studio technically allow multiple files, the arrangement of these is such a pain that it remains easier to treat them the same way - a single active file at a time. If we have one file open, with a tight column width then we’re not using a sizeable portion of a widescreen monitor. The column approach allowed a much denser display but felt strange to navigate. I abandoned this approach early to concentrate on the second idea but I had considered allowing the whole view to scroll horizontally and to adjust the scrolling to work on whole pages rather than lines.

The next idea was an attempt to use the second half of the widescreen to combine the idea of multiple buffers with easy access to pertinent parts of the code base. I decided at some point to call these “portals”. Each portal is a live view into a fixed section of a file. If I insert text in the document above the section of the portal then the portal stays as it is and is effectively shunted down. If I make changes inside a portal then these are reflected into the main document. I envisage navigating the code pulling the key parts into portals and then performing a task, readily switching between the different portals as the code grows organically in each area.

I learned that writing a basic functioning text editor is much more straightforward than I had imagined. I think that there was enough in the feel of editing using portals to consider developing the text editor further to become my daily driver (much easier than making a generally available editor!)

Things I’d want to try next…

  1. Use Odin’s parser to find functions and add the ability to create portals from a “Jump to definition”.
  2. Figure out a way to manage the portals well when you have more larger portals
  3. Add the ability to have portals into different files
  4. Consider whether inline portals work (I.e you “goto definition” in place - like VS Code Peek Definition but persistent in that location in the file).
Read more
Filters

Recent Activity

I’ve not had as much time over the last days of the jam but thankfully made amazing progress in the first days so that I can at least demonstrate the core of the idea and get a feel for how it will work. I posted a video to Discord (unfortunately too big to upload here) showing me “using” (the editor doesn't save yet) making changes to the editor code itself. In the example I'm modifying my hard coded UI padding offsets and adding them to a theme struct, switching between sections of the file using several portals.

Less time available today but continuing from the restructuring and building out of basic editing functionality I’ve done enough of an editor to start playing with the next idea.

First evening of the Jam. Displaying a source text file (from Odin's core library) in multiple columns (like a newspaper). I wasn't sure this idea would work and I don't think it does, having tried it, but it has fired a few neurons that wouldn't otherwise have fired. There isn't an pretence of editing any text and it's really hacked together code using Odin & Raylib. I'll have to do some basic editing for testing some of my next ideas though.