It has been a very long time coming, life kept getting in the way here, but my Diamond editor changes are ready for pull. For those who don’t give a rat’s behind about the pull request, here are the new packages. These are not official. I have tested these Diamond editor packages in bare installs of said operating systems. For Ubuntu installs you need to use the Software Installer, not dpkg from the command line because dpkg won’t install dependencies.
Note: I don’t remember if I fixed it or not. If you have an existing diamond config, sometimes the only theme you get is the one you had. Just rename your config file before installing. There aren’t that many settings.
Packages
Package Creation
Yes, we now have both RPM and Debian creation.
build-diamond-deb.sh checks for a Debian based distro then does everything necessary for a full build of source to create a Debian package. One of the things it does up front is run Artistic Style on the src directory.
When the shell scripts run they use this configuration file. The same configuration file is run when you choose to execute Astyle from within Diamond if you are editing in the src (or any sub-directory.) The Artistic Style command looks first in your local directory then in the project root and I forget where else.
If multiple developers will work in a code base a method of enforcing common style so things are readable is needed. Artistic Style works well in most of the shops I’m at.
The astyle-diamond.sh is really just a helper.
#!/bin/sh
#
astyle -n src/*.cpp src/*.h
#build-diamond-rpm.sh does the same thing for RPM creation. It checks for a RedHat based distro and checks to ensure rpmdevtools has been installed.
Both packaging scripts dump the diamond tree into /opt/diamond. The .desktop file is copied to the appropriate location and a symbolic link is created in the appropriate directory so one can type diamond at the command line and have it run no matter what directory the user is in.
The third digit of a release really should no longer be allowed to be a zero. It has to do with RPM packaging viewing that as the “build number.” Most counting systems don’t start at zero.
Summary of changes
The summary at this post is still pretty accurate. Life has just been in the way and I have been focused on getting the packing done. Probably best to install one of the packages to kick the tires.
For “Why EDT?” Read this post.
For “Why Themes?” Read this post. If you don’t want to read the entire post I will include the ending paragraph here.
Do you know why Betty Crocker cake mix crushed the competition despite there being dozens of other brands on the shelf?
This was the days when women actually called themselves a “House Wife” and were proud of it. All of those other cake mixes were “instant.” You just added water and put them in the oven. With Betty Crocker you added an egg. Adding an egg crossed the psychological barrier and the conscientious house wife could honestly say “Yes, I baked it myself.” Adding an egg made it not instant and therefore okay. Instant is what the bad wives did and you would never find them featured in Good Housekeeping.
Putting in place the groundwork for community themes is the text editor equivalent of “adding an egg.” Allowing users to create plug-ins is the text editor equivalent of allowing too many cooks into the kitchen. That’s a condition Emacs suffers quite badly from now. Most of the plug-ins conflict horribly or cause random oddities in unrelated plug-ins. With every plug-in you install it is like tap dancing in a mine field.
Some of the other things off the top of my head:
- Data needed by more than one class/object is now in a singleton named Overlord. Settings, options, themes, syntax highlighting, etc. are all in Overlord.
- Default font is now Monospace. It will still do Courier if it cannot find Monospace. I forget the rest of the fallback patterns. Monospace is everywhere in a post-Java world. It also tends to be far more legible than Courier.
- Can now preload syntax highlight files in Overlord. Editor instances no longer load themes directly. They reference them from overlord so the editor isn’t continually parsing JSON. On slow I/O machines that is significant overhead.
- Lots of source code consolidation. One Class One Source File has been introduced into the code base so methods could be easily found.
- Astyle on Save can now be turned on. One can also Astyle the document they are editing. All of this assumes you actually have Astyle installed on the machine.
- Backup versions with a central backup directory like Emacs using Emacs style naming. Unlike Emacs we can also browse backup versions and open them in ReadOnly mode. Options allows you to enable backups and to set the maximum number for each file. Backups are created on each and every save. Older backup files purged off.
- F12 can send Backspace just like a real VT terminal
- One of the many benefits coming from EDT is that we can now append many cut/copy segments into the system clipboard. To be able to verify this I added a clipboard viewer as well.
- All dictionaries are now deployed with package/install. Dictionary dialog as well as handling still needs a bit of re-architecting. It should just be keeping a reference to the primary language dictionary, not a copy of it. Because of the way it works now you still can’t “switch” dictionaries without manually copying them into the .config/diamond directory.
Developer documentation
A completely new directory tree within the project named dev_doc. It is a place to store RTF formatted developer documentation as well as hand holding tutorials for noobs and non-developers alike. Files “Getting-Started.rtf” and “Rules-and-Goals.rtf” are living documents that will evolve as the project evolves. “Getting-Started.rtf” includes many ways for noobs and non-developers to contribute in a very meaningful way right out of the gate. They don’t have to know a single thing about C++ or CopperSpice.
The OS_setup directory includes step-by-step instructions for setting up both development and test virtual machines under Oracle Virtualbox. This makes the project far more accessible to non-experts and an OpenSource editor should never be an expert-friendly project. There are far too many of those projects already.
Probably forgot hundreds of other little things. Now is the time to see if this was going to be rolled into the base Diamond project or if it would have to be forked into its own project. The instructions I have for snap creation were rather repository specific. Did not want to go down that rabbit hole if things were going to need a different project name.
No matter which way this goes, the next set of changes will make these look small. Need to have a solid baseline either as part of Diamond or a new project before doing them.
