It’s been over a year since I set up this website, and yet not a single blog post exists. I decided that it’s time to start journaling some of my experiences for you all to enjoy. Let’s start with a little story.

I’m a college student. And the college has their own computers. Linux machines. And naturally, these computers have become, over the years, filled with college-specific programs and idioms. A professor writes their own programs for the students to use, and it turns out they don’t compile anywhere else but the college machines. Something a professor found very useful a few decades ago is now ubiquitous on all college machines, required for the course, and ubiquitous absolutely nowhere else in existence. The list goes on and on.

In the end, you come to the situation where you are absolutely, 100% forced to do your college work on these college machines (often remotely, to boot). This comes with a great deal of problems:

  • Want a GUI application? You’re lucky if they have X forwarding enabled!
  • Even if you can get a GUI, if they don’t have the applications you want to use, you’re out of luck. Package managers are for admins only!

So you’re stuck in a world where GUIs aren’t a given and only the most common of applications are. A good example of this is text editors. All Linux text editors fall into one of the following categories:

  • Something obvious to use, but so basic you’ll be sorely hurting for text editor features that every editor that isn’t Notepad has. Stuff like syntax highlighting or rectangular selection or multiple tabs. Good examples of this are gedit and nano.
  • Something powerful, but require reading the whole manual to even begin using. You know, the kind of text editor that comes with a mission statement and a small army of diehard fans. This includes vim and emacs.
  • Something that’s powerful and easy to use, but it’s a full-blown IDE, so you can’t use it without creating a project, letting it take control of your build system, etc. Eclipse and anything JetBrains makes tends to fall under here.
  • Something that you like, but you can’t install on the machine. Examples include… Basically everything else.

In fact, I’m talking about text editors because I had an idea. What if there existed a text editor that’s familiar to use, reasonably powerful, portable, and easy to install? I’m designing a text editor to be exactly this, called TextX. Here’s how TextX will accomplish this:

  • It will be a terminal text editor, that is, able to run in any old textmode window (that supports ANSI escape sequences). This means you can run it on machines that just can’t expose a GUI.
  • It will use common GUI idioms for editing text. Control-C will copy, and Control-V will paste! Imagine that!
  • It will make use of a title bar, status bar, etc., so that you can poke around menus and activate options without memorizing arcane keystrokes.
  • It will have full mouse support (if the terminal supports XTerm’s mouse extensions). Clicking on the screen to move the cursor? In MY text editor? It’s more likely than you think!
  • It will have all the features you expect from a serious text editor. It almost certainly won’t be as powerful as vim or emacs, but it should hit on all the high points that make those editors useful, while making them easy to use.
  • It will be portable. This means it should be written in C or C++, something every machine in the universe can compile. With luck, you’ll be able to build TextX anywhere you have a C/C++ compiler. It should even compile under Windows using MinGW (or maybe MSVC if I feel like experiencing pain).
  • It will be a single executable only. Installing it from a prebuilt binary should be as easy as copying the single executable over to your target machine. This means no dynamic dependencies (other than, like, libc).

Luckily, there exists a library that makes writing textmode applications (aka TUIs) pretty easy, called curses. Unfortunately, it comes with a few issues: It’s generally shipped as a dynamic library (which we’ve identified as a no-no already), and it won’t work well at all on platforms that may not have terminfo files where curses expects them (that is, Windows). Fortunately, even if these problems prove insurmountable, curses was made before ANSI escape sequences became standardized, and as such, it may be much simpler to just write a library that directly spits out these standard escape sequences without curses. This will be my first big consideration moving forwards: Curses or no?

In the near future, I will be documenting the choices I make and how I implement these choices in this blog. I’ve already set up a GitHub repository for this here. If you’re interested, please give me your feedback!