Multi-format text editor with chain-of-command processing
A while back I developed a desktop-based text editor (Scrivenvar) that uses the Chain-of-Responsibility design pattern to help me author fairly involved text documents. The editor's high-level architecture resembles the following diagram:
https://i.imgur.com/8IMpAkN.png
Am I reinventing the wheel here? Are there any modern, cross-platform, liberal open-source (LGPL, MIT, Apache 2), text editor frameworks (such as xi or Visual Studio Code), that would enable (re)development of such a tool?
Scrivenvar is written in Java, but to my chagrin, Java 9+ no longer bundles JavaFX. The text editor was based on MarkdownWriterFX, itself based on JavaFX. This means there's no easy upgrade path, so I'm looking to rebuild the editor either as a cross-platform desktop application or as a web application.
I mean, you don't have to rebuild anything, you could either use OpenJFX as a Maven dependency (which is the simplest route), or you could bundle stripped down version of JDK from Bellsoft/AdoptOpenJDK/Other_vendor_who_is_not_Oracle which does bundle JavaFX. Just find out which modules you depend on with
jdeps
and usejlink
to make your own JRE. That's what I do for my app at work.In both cases you're still going to have some work to do updating your code, but I was able to run it on Bellsoft's Java 11 just by bumping versions of ControlsFX and FontAwesomeFX (since they relied on com.sun classes that were changed/removed in newer versions of OpenJFX and had to add support to Java 9+ anyway)
(Also not sure if you've noticed, but while your screenshot at GitHub shows $application.title$ being transformed to Scrivenvar, the actual title of README.MD is still, in fact, $application.title$)
It's not pure GPL, it's GPL with Classpath Exception, just like OpenJDK itself. That "classpath" part is important, it means that GPL license does not contaminate your application. Specifically,
You still need to test everywhere, releasing the jar won't relieve you of that. But if you're bundling JDK you at least know with what version of Java user will be running it, so you actually have more control that way (and trust me, different vendors do have different bugs).
That part is cumbersome, yes. That's why for your use-case adding Maven dependency to build.gradle would be more than enough. No separate downloads, same fat jar in the output.
May not be quite what you're looking for, but I get a lot out of vim+pandoc 1. Pandoc is a little bit magic and handles transforming text with templates and variables etc very cleanly. I just like vim and a few choice plugins go a long way.
Plus I like separating out editing from processing; it's more intuitive to me, and allows a great deal of flexibility.
If you do want to go down this path, consider Qt. The QTextArea widget can display html and rich text.
1 Vim config here.
Mmm, ok I see what you mean. In principle you could extend pandoc to do that sort of thing, as the pandoc-moustache example does, but I think what you want is quite a different tool. pandoc simply translates text from one format to another based on templates (already a serious task) which is actually quite different to interpolation. I'm not aware of any tools which do this perfectly generically.
Having put no thought into this, the direction I would go for would be to just embed lisp phrases in my documents and then write a small compiler to process everything. This keeps everything integrated in my text-based workflow. And as a lisp, I can do everything. One approach would be a header defining global variables and various metaprocessing characteristics. Each lisp phrase would accept some input, process it as required, and return a string. Tie it all together by defining how each phrase interacts and how to pass input to each phrase and the whole thing could fall it fairly neatly.
Mmm, I see. Any solution that's simple for non devs but still more powerful than s/.../.../g is challenging.
Working with pandoc seems sensible, and lua is nice too. With pandoc you have the ast so you can do anything, although details may be difficult.
Because Lisps have very little syntax you can get creative and strip out a lot of complexity. For example,
$(foo)
could be for a simple find and replace.$(foo > bar > baz)
could access children in the input/ast.$(fn (foo))
could further process foo with fn. Maybe it's useful to be able to set and reference variables in the document? I think some structured input makes more sense. Key value pairs, flow control, and hierarchy (or namespaces) should go most of the way. So you could invent a dsl for this, but with a nice grammar you can now take yaml, toml whatever defining variables and have a really slick structured interpolation system.It's certainly the sort of thing where I'd want a corpus of examples to influence and constrain design. It's hard for me to imagine any serious details. (e.g. Keep everything in one doc and process that vs combining arbitrary input with a template.)