[xiphos-devel] that blasted editor

[Karl Kleinpaste]

I've been ruminating over the editor problem for a couple days,
especially with regard to Greg's comment, "it's gonna require some
amount of ugly hackery to get that editor working."

And I find I just can't bring myself to address that, straight up.

I have found myself briefly fantasizing over simply inhaling whatever
fraction is needed of the otherwise-outdated gtkhml library directly
into our src/editor area, because quite honestly that editor works just
fine. I've written a few substantial documents using it. I know others
have. It's been a long time since I've polled users for what they want
to see in future work, but a recurring theme over many years was
"authorship improvements." And those requests are why we gained user
annotations and other generative stuff. The editor never got much in the
way of complaints, it already seemed fine to most folks.

But OK, so maybe inhaling some other older library's code isn't such a
hot idea, especially if it would represent a large bulk that isn't
otherwise core to our purpose. We're not so much about editing as we are
providing hooks into reading and cross-referencing. What other good
editors exist, that don't include ... let me find some terminology
suitable for family viewing ... having to put up with the vulgar nature
of what the GTK3 people have done to us in so many other ways?

What if we don't do an editor at all? What if instead we provide a hook
into any external editor the user likes?

It needs to be able to provide HTML content, both because that's what
all instances of editor ever known to Xiphos have produced, and so there
is backward compatibility with which to wrangle, but also because
writing good-looking text requires the kind of control structures that
HTML is for. I don't expect users actually to type <br/> and so forth,
but any editor that will spit out <i></i> and <br/> and <h1></h1> for
Xiphos to absorb will do what we need.

Hooking into an external editor is easy in Linux. How tough is it to do
in Windows?

We could even provide a pseudo-standard set of Xiphos-"preferred"
editors. If the user hasn't set a preference, we walk through the
system, looking for those we like. Pick the best one found. But leave
the user to set that preference, for those who care. We already do
something like this in src/main/url.cc for external display of a clicked
image. There's a short list of a few standard-available image viewers,
most important of which is gnome-open.

Seriously, lots of other applications don't depend on having their own
editing capability. It's properly a subsystem that's farmed out to
something else to do, something else that's good at just that. git forks
$EDITOR (or is it $VISUAL) at the drop of a hat.

I'm thinking I'd rather excise the editor entirely, rather than wade
into that nightmare to fix it.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/xiphos-devel/attachments/20200417/8a21061a/attachment-0001.html>