Welcome to CsScintilla - CopperSpice Port of Scintilla

CsScintilla - a CopperSpice port of Scintilla is now available. Currently it only builds for Linux distros. If you wish to take on the task of creating build scripts for Windows/MAC/whatever, please be my guest and issue a pull request.

The only additional restriction the license includes is that you cannot use this library to create an editor/IDE that uses any kind of plug-in/add-on support. Just look at Emacs, Atom, VSCode, insert-editor-using-plug-ins-here. Hundreds of plug-ins/add-ons that do almost the same thing, none of which do it well. Half of the plug-ins conflict with others. Thousands of plug-ins that no longer work at all. A plug-in library littered with landmines that will completely trash your editor installation if you even attempt to install them.

No, I didn't endure all of the pain creating this and all of the example programs so that you can create something that perpetually inflicts pain on others long after your death. You've got to compile & link your features into your editor/IDE.

The Journey

Regular readers of my geek blog are well aware of my CopperSpice journey. Now that Qt really isn't OpenSource anymore (community does not control direction of project and is barred from releasing any LTS version) people are leaving Qt in droves. Debian doesn't even have Qt maintainers anymore. They are relying on whatever KDE provides which isn't everything. Most Linux distros have dropped KDE and many will be dropping all things Qt in the not-too-distant-future. A good number now no longer install anything using Qt by default I'm told.

I started hitting performance walls with CopperSpice QPlainTextEdit and the regular expression based syntax highlighting while creating RedDiamond (initially based on CopperSpice Diamond.) Having started my career on the DEC platforms I have wanted EDT keypad navigation in a PC editor forever. Emacs has almost passing EDT Keypad Navigation, but it fails by not being able to map NumLock as GOLD unless you hack your terminal definition. That's fallout from an age-old feud.

CsScintilla is born

Scintilla is the reason most PC based texted editors and IDEs exist. You can find a partial list here. A better list can be found here. Odds are high one of your favorites is listed. When I started hitting performance problems with source files > 5000 lines reaching for Scintilla was a natural thing. There was already a Qt port of Scintilla. There just wasn't a CopperSpice port and the two projects have forked far enough apart to make it a bit of work.

When you need it, you build it. The Scintilla community was helpful in answering questions but they did not want to add CopperSpice as an officially supported port. Too many still clinging to the dead Qt platform. No problem. CsScintilla is born.

Much Needed Examples

One of the big problems with the Scintilla project is lack of decent examples. Yes, I'm sure they were considered decent at one time. Yes, I use Scite from time to time. The problem is the minimal examples exploded out into "expert friendly" things. There so much extra stuff that someone new to the library simply couldn't get started, especially using a different platform or GUI library.

A big chunk of my time was spent creating a series of examples that build upon one another. Yes, there are some much needed enhancements/extensions for Scintilla in this lib. Yes, they were offered back. CsScintilla appears to be growing into more than just a port.

Example1 - Minimal

An absolute minimal example. It just puts the widget in a QMainWindow with a simplistic menu to Open/Save a file. The constructor for MainWindow shows you just how little you really need.

Technically, if you don't want a menu you don't need the createMenus() or the connect() call. I made certain to put a comment in there too.
If someone takes on the task of building CsScintilla for MAC or Windows, Example1 should build and run just fine. It does as little as possible

Example2 - Tabs

Like I said, baby steps. Example2 just changes Example1 to use tabs instead of a single edit instance.

You will notice there is no syntax highlighting. I did turn on line numbering though.

Example3 - EDT Keypad Support

This is the first to provide some level of EDT Keypad navigation and command support. It adds a Show Clipboard option so you can see what happens to the Clipboard with various EDT Keypad actions. EDT has separate buffers for:

DEL CHAR - UNDEL CHAR
DEL WORD - UNDEL WORD
DEL LINE / DEL EOL - UNDEL LINE / UNDEL EOL

The only one that uses the traditional PC OS Clipboard is CUT/PASTE. Don't worry a big help window is included on the Help menu.

Example4 - Font and Colors

This isn't syntax highlighting font and color selection. Just letting you set something other than your OS UI default. There is not an example showing syntax highlighting font and color. For that you have to wait for the new RedDiamond release. (It's close, just a couple of nit-pick things.) For people who care nothing about syntax highlighting (yes, they exist) and don't need an editor to print, Example4 may be more than enough. It has more capabilities than LeafPad but doesn't go overboard. LeafPad was included with just about every Linux distro until the version of GTK it used was no longer supported.

As more an more Linux distros drop Qt some flavor of Example4 may well become the "minimal" editor. Well, unless they go whole hog and included RedDiamond as the default editor.

Example5 - Show KeyMap

Example5 really exists simply to show one of the major improvements CsScintilla made over base Scintilla.

It generates the keymap text. The Scintilla editor widget has a bunch of built in functions mapped to various keystrokes. For years everyone wanted a "list" function and for years everyone had to roll their own. There are several format flavors one can choose when using the function from within CsScintilla.

Note: This example doesn't go to the level of allowing the user to change keymap for a specific function. Believe it or not, getting a list of all the current key mappings and text of the function associated with them was the hard part. There already was a function to actually map keystrokes.

We need to talk about "minimal"

LeafPad and many other editors of that era have gone away or are going away. Many of them handled only ASCII. For us English users that was great! You could select text from a word processing document, Web page, whatever, and when you pasted into the "minimal" editor you only got the text. You didn't get all of those bizarre unseen formatting characters that could jack things like a compiler up.

Today "minimal" tends to mean at least UTF-8 if not UTF-32 support. You have to now filter stuff out with your paste function.

Very few editors do this. The example editors certainly don't. You need to be aware of it because Scintilla has UTF support. That means you can accidentally paste in non-visible format information from one source that will hose up your compiler or other software parsing your text file.

Another Tweak Worth Mentioning

CsScintillaEditBase.cpp has the following around line 750 or so.

The Qt version has this around line 580 or so

There is no way this works with codeset that exceeds UTF-16. There are a lot of 24-bit and higher Unicode codesets out there. CopperSpice has a QChar32 character type it uses. Yes, this wastes a lot of space when working with just ASCII. When I started with C programming, 640K was the physical maximum we could have in a desktop computer. The machine I'm typing this on has 128GB and God only knows how much "virtual RAM" in the form of a swap file. A 64-bit processor is going to have to transfer two 32-bit values in a register anyway.

Wasting RAM isn't the sin it used to be.