How I've arrived at SciTE =========================

First draft: 2025-01-31
Published:   2025-04-23

Motivation

There will be a couple of articles coming to the blog next about SciTE customizations, so I thought I would start the series by expressing why I like the editor so much in the first place.

Warning: yes, a programmer is talking about his favorite text editors here, which is similar to the paintbrush for a painter: the editor is our most used tool, our main instrument to convert thoughts into code. A highly subjective topic that have been the source of great flame wars. Please keep in mind that I do not aim to convert anyone, just want to highlight some reasons to consider.

On IDEs

What is the difference between a simple text editor and an Integrated Development Environment? The emphasis is on the first word: if the package offers full integration, it means you should not have to open any other program during the development process: besides the obvious text editing capabilities, it provides interfaces for debugging, version control, file browser, ways to interact with build systems, shortcuts to documentation, just to name a few.

The most important question is: do I want my development process to be centered like this around one single program?

Short drive down memory lane. I started out learning programming in VB6 and Macromedia Flash, both of which provided a fairly comprehensive environment for kids like me, growing up as a Windows user (I was too young to have any serious exposure to DOS). First time I have felt the freedom of choice was with HTML, where even a simple Notepad could be used. At the Uni, in the beginning we studied VB6 some more, then in second semester came Java. We had to use command line tools initially, but after a couple of months we were allowed to switch to NetBeans or Eclipse. NetBeans became my favorite IDE, and although I quit using Java for some time now, I still use NetBeans to this day, in the form of Microchip MPLABX.

Professionally my second most used IDE must be Code::Blocks, which we ran at the company for all our C++ development projects. I consider it more an IDE than just a feature-packed text editor, but it is very lightweight. I will talk about it some more later, as it lies the closest to SciTE (in fact it turns out it also uses Scintilla internally).

I had the chance to see many more IDEs up close for various lenghts of time. Once at Uni we had to port a Delphi program to Java, which was a useful experience because many years later I had to participate in a Lazarus-based project which is very similar. After VisualBasic I had the chance to see VisualStudio again during a C# course, this was where I decided against using any MS programming platform in the future. I have also started a course on Android programming in Eclipse that I did not finish, and later I had some exposure to AndroidStudio through colleagues who had to work exclusively in that environment.

The real problem is that most of the IDEs that I have mentioned carry the aura of exclusiveness for their respective programming language or platform. Maybe Code::Blocks is the only real exception here, but all the others were at one time or another the *One True IDE* which have been blessed. I am not saying that no alternatives exist, because pioneering people always find interesting ways of using software, but in general one have to endure serious pain if does not want to use what is canon. I can also see a pattern where most of these IDEs also run somewhat better on Windows (or exclusively there).

What happens when the winds shift and support for a particular IDE ends? Will I be able to continue the development for an existing system? Will I be forced to switch and retire the old environment, or do I have to set up something in a virtual machine just to be able to do the occasional bug fix? Anything could happen. Also I would like to be clear that I am not just talking about the platform itself (compiler etc.) but IDE features in particular. Do I have to re-learn something, just because I got used to do it in a certain way and it is organized differently in a new version?

Text editors, the opposite extremity

At the University I got to know a couple of guys who studied IT formally from the high school level (I believe this may be called vocational training in English), and some who were just plain computer nerds, so I got exposed to Linux pretty quickly. I was amazed by the simplicity and elegancy of all the command line tools, and at the same time wasn't impressed with the major desktop environments, so I got used to staring at the terminal screen. I completed the C and C++ courses this way, and ultimately wrote my BSc. thesis entirely in Vim, manually invoking gcc and gdb, generating figures with gnuplot, and typesetting with LaTeX.

Somehow I was never drawn to Emacs, but as I have mentioned, I wrestled with Vim for a considerable amount of time. I have a similar relationship here like with Bash: once I get used to it I can do anything in it comfortably, but it is not intuitive in the sense that if I skip some time, not using it say because I have non-programming tasks for a couple of days, some commands always slip from my memory so I end up having to look things up constantly. I even printed the user manual for Vim one time, it is a prized possession now because of the associated good memories, but I haven't opened it in years.

After I graduated, for a long time I did not do much command line work, so I just casually used `mcedit`. Then I drifted more towards the waters of Linux system administration around 2020 with some new projects at the company, and had to do considerably more Bash scripting on remote machines. This was the time when I found `ne`, the Nice Editor, which is my go-to text editor on the command line since. I am even writing these lines in it, which might sound strange as maybe it would have been more appropriate to write it in SciTE, but I have my reasons: I am still getting used to writing regularly to the blog, and without a proper pipeline set up, I am writing these drafts right on the server host. In my view this is not just pure lazyness, but could be considered a type of flexibility, which is very much in relation to the reason why I like lightweight tools even for more complex development tasks.

Best of both worlds

It is important for me to be able to do as high a portion of my tasks in the terminal as possible. Of course many activities can be done in a more productive manner with graphical tools, and some would not be possible without them. Here the emphasis is on *being able*, which is not *striving to*: I just want to be comfortable knowing that if something breaks, or I find myself in a limited environment, I can still do my job. As I have mentioned this is coming from the experience working with remote and/or embedded machines.

It is worth considering which operations would actually *require* a desktop environment, and if there are any alternatives for them. By alternative I mean a different way of executing it, in a terminal with CLI programs. If your answer is that there is no fallback, the next step should be risk assessment, how probable it is that your graphics driver breaks at the next kernel update etc. I am not saying that this is the only answer, you may have backups, not just for the data but bootable systems, virtual machines ready to go, whatever. What I am talking about is just a different answer that is not even mutually exclusive with the other options.

Let me illustrate with an example, which is a bit silly but true as it had happened to me. I have mentioned Code::Blocks before, one of the main features that makes it an IDE is that it has its own build system, with configuration residing in the project's CBP file. This can be a good thing or a bad thing, I am not very fond of Makefiles either but both has its strengths. I cannot recall the exact details but one time I remember we had a hard time because we thought a project can only be built via the C::B GUI itself, but that would have been problematic for some reason, version or architecture mismatch or something like that. We had to build it on the command line and being in a hurry, we tried to convert the CBP into a Makefile which is doable but very unpleasant. Somehow we did not think about easier solutions, like I am just finding out that C::B has a command line argument that execute only the build (without launching the GUI presumably). Also I have to check this sometime, but the package itself does not seem to depend on the X system or anything graphical so it may work on headless machines without installing a whole bunch of otherwise useless stuff. Yeah the example is a bit forced as alternative ways seem to exist, but the main principle is true that the best solution was not intuitive, while the obvious but brutish solution was painful.

What I am proposing is to think of a setup that involves command line tools, and never abstracts them away so much that you loose track of what is happening in the background. Also if one finds themselves in a tight spot, it must be easy to extract what command to run manually. Best would be to keep a couple of separate terminals open for the build and run commands, and leverage only the windowing system, but that becomes kind of tiresome over long sessions. So we are basically looking for a text editor that has built-in support for running user defined commands and displaying output. If you can find one that runs in a terminal and you can find everything in it intuitively, great I am happy for you. I am tired of trying to remember keyboard shortcuts though, my memory being too busy to store things like standard library API (I hope) so I need graphical menus as well. And with that, we have arrived at SciTE! At last, you must be thinking.

Features of SciTE

Scintilla is a stand-alone text area component specifically made for displaying and editing program code. As I have mentioned, many editors use it and Code::Blocks is among them, but the creator Neil Hodgson have also built a dedicated framework around it, so naturally I went for the Scintilla Text Editor itself.

The program is very lightweight, starts up instantly. We can see the usual housekeeping stuff up top by default: menu, toolbar, tabbar. There is also a title bar that displays the full path of the active file. I believe the status bar is not turned on by default, but the option can be found easily in the menu. One prominent feature on the UI is the output pane, which displays the stdout of the program selected to run when you hit "Go", but it is subject to some highlighing effects itself through the `Errorlist` syntax, and also it is a terminal so you can write in it and execute custom commands if you have the notion.

Speaking of syntax, naturally a dedicated programming editor's main function is to help with highlighting. Scintilla has so called lexers, which are modules for different languages or at least families of them, analyzing the text and parsing it into code tokens, so it can apply different coloring effects to them. I believe the lexers themselves are hard-coded, but each uses a corresponding property file, so many aspects of the syntax highlighting is customizable. This is not limited to the visuals either, for example the lists of different keyword types can usually be edited. There are per-lexer properties also for determining what lexer to use for what file extension, but it can also be changed on-the-fly with one click.

Of course the possibilities for customization do not end here, and in fact there is a similar property system in place to personalize almost every aspect of the program. This is one of the main strengths that appeals to me, being used to working with config files, and here you can edit the properties within the program itself, applying and seeing the results instantly after saving the file. Just to name a few, the user can permanently hide toolbars, change the contents of the status bar, define keyboard shotcuts, set indentation and wrapping styles, alter how code folds work, and apply highlighting to the current line or every word matching the one under the cursor. Generally speaking, you can set the color, font and text style of everything that is displayed inside the main Scintilla editing panes.

It is important to note that many properties support having different values according to the selected lexer. This can even be unsettling at first because the visuals or even behavior may differ slightly from the usual if someone has many customizations for one lexer and starts to use a new one (some lexers have weird defaults). What I would like to bring to attention here is that the contents of the Tool menu, i.e. `Compile`, `Build`, and `Go` (aka. run) can be set up to use any outside (preferably CLI) tool. This is the very feature that makes SciTE feel almost like an IDE, and even one that can be used for every single language you would like! Well, at least if it is among the 97 that is supported at the time of this writing...

I will end the list of customization features mentioning that built-in fuctionality can even be expanded with scripts, for which mainly the Lua language is used. As far as I know, Lua is purposely made for this kind of application, embedding in other software to provide the possibility of scripting. It is pretty simplistic and can be learned quickly, with SciTE providing facilities to test the script you are working on by one press of a button. Almost any internal property can be set in this way, and you can call built-in editing functions as well to make powerful macros.

Parting thoughts

I very much like the saying that "you can never be wrong for *not* using any one particular tool". I think it resonates well with the free and open-source mindset, where we are always wary of anyone saying that there are no alternatives. A text editor should be just another cog in the machinery of our development pipeline, and we should be ready to replace any part should it start to miss some gearteeth. If you want to learn to be more versatile, I urge you to get to know the command line tools behind your IDE better, and also maybe consider using an editor that does not hide these away behind the curtains.

I recommend SciTE for those who want to use a graphical IDE without having to deal with a large monolithic block. It may require a bit of tweaking to make it feel really ergonomic, but the program tries to be partner in this by providing many ways to fine-tune the experience. After that, it will just serve you reliably.

In case you would like to check out some of my customizations, or just want to see a couple of screenshots from SciTE, you are welcome to take a look at the other posts in the series:
(Links soon to follow.)