It has been a while since I posted about RedDiamond, the editor with EDT keypad navigation, but there is finally an AppImage of it. Granted the New World Order wants Flatpaks of everything, but this is one small step. Those of you who are interested can follow the journey forward from its first post starting here. Given Qt Company has gotten Qt run out of much of the IT industry on a rail. Yes, with all of its licensing shenanigans and the relentless pursuit of QML to the detriment of the entire product, everyone has to look for something else because no company not already married to it will spend money on it.
You can download the AppImage from here. I will try to keep pull requests submitted for every major version.
One feature I absolutely wanted in what was going to be “my editor” was file versioning. I had to call them backups so the non-OpenVMS crowd could understand. Every time you save a file, the previous version is moved to the backup directory. The name gets mangled so the full path can be restored. You should notice from the image that it gets a .b000NN version number appended.
By default backups are enabled and the dept is set to 250. A RedDiamond_Backups directory is created in $HOME which you can change. Some of you might be using a tiny SSD for boot and great big freaking drives for development.
Right now all you can really do with backups is look at them. Clicking on one in the list will open it in a new tab so you can view/edit. I need to make that a READ-ONLY tab. In a future release I hope to have DIFF capabilities much like Meld. You should be able to DIFF against a prior backup, the cache version (if any), the file currently on disk, or version control. We are not there yet!
Oh yes, Caches
You can’t change the cache directory. Earlier versions allowed that, but this one cannot. It has to do with the “starting where you left off” capability. The cache directory is determined by QStandardPaths. In particular by whatever gets returned using
Text editors have the following operation choices to make before the first line of their code is written:
- Annoy the ()&*)_*(& out of the user trying to close and go home by prompting them to save each and every file even those unnamed paste buffers.
- ASS-U-ME the user knows what they are doing and throw everything away.
- Use a cache directory so you can close-up and go home without any bother then start right where you left off.
Yes, the third option can lead to issues of developers forgetting to save, building, and wondering why that bug is still there when they know they fixed it. We have a menu option you need to get used to.
At some point I will get around to letting users assign/change shortcuts and you will even be able to assign a shortcut. Actually, if there is some kind of kind of community consensus, I could add a shortcut in a near future release. I’ve been debating between <Alt>-S and [GOLD]-w
Single Instance – Multiple Main Windows
When designing a text editor you have a choice to make; Allow multiple instances or don’t. There are some people that want to open N instances of the same editor so they can have one on each monitor. When you design like that, you end up not being able to use a cache directory or “pick up where you left off.” It’s almost impossible to allow multiple instances if you want to pick up where you left off on restart. When you allow multiple instances you almost always have to nag the user to save and close everything on exit as well. (Unless you take the throw it all away path.)
There are two Singleton classes for RedDiamond: RDSingleton and Overlord.
RDSingleton is responsible for ensuring the database containing themes, open file lists, open window lists, syntax keywords and other data exists at startup. It’s also responsible for keeping track of each MainWindow instance and facilitating communication between windows.
Overlord was originally the Benevolent Overlord for the editor. It’s primary function is to provide each MainWindow access to database and settings values. If it is data that the editor needs to read or write to function, Overlord is how each editor instance gets that data. We don’t sprinkle database I/O all over half of Hell and Georgia in the code.
RedDiamond Window Chatter
CopperSpice hasn’t gotten far enough along to allow detaching a tab which would have allowed for a unique .desktop name and hidden extension to “open” a new window for a tab. This design is actually more functional. It opens up a range of functionality we didn’t have with EDT or LSE. Allow me to paste some images from the PF2 help text.
Via the command line you can move, copy, delete, and sort the contents of some other tab. You can even change the current line in another tab. If you are a grizzled old line editor user, you could have 50 tabs open across 8 windows and edit them all without ever navigating away from the current tab.
Multiple User Configs
Take a look back at the General Settings dialog I showed you when speaking about file versioning and backups. Everything on that tab is stored in a native QSettings configuration file. This is a concept the Diamond editor I originally started poking at had. I gave it a healthy dose of steroids.
The database stores open files, windows, etc. by config name. Each config can use a different theme. You can color coordinate your editor to remind you which client you are working for. Oh, this one uses TAB instead of spaces, maybe I’ll have that config be YABU so I know the editor is set to use TABs.
Maybe you choose to use COBALT for your COBOL clients?
Doesn’t matter. What matters is when you change configs, all of your currently open windows and tabs are closed, the new config is loaded, and all its previously open windows and tabs return. You change projects, but the editor remembers right where you left off.
There is so much more, but kick the tires yourself. There is an AppImage you can just make executable and run!