<div dir="ltr">I don't use the editor that much. I prefer to use my own. What's most<div>important to the typical bible scholar is to have access to the books, commentaries, translations, dictionaries, etc.</div><div><br></div><div>I would say. At least to me.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020 at 4:39 PM Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<font face="FreeSerif">I've been ruminating over the editor problem
for a couple days, especially with regard to Greg's comment, "</font><font face="FreeSerif">it's gonna require some amount of ugly hackery to
get that editor working."<br>
<br>
And I find I just can't bring myself to address that, straight up.<br>
<br>
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.<br>
<br>
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?<br>
<br>
What if we don't do an editor at all? What if instead we provide a
hook into any external editor the user likes?<br>
<br>
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.<br>
<br>
Hooking into an external editor is easy in Linux. How tough is it
to do in Windows?<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'm thinking I'd rather excise the editor entirely, rather than
wade into that nightmare to fix it.<br>
<br>
Thoughts?<br>
</font>
</div>
_______________________________________________<br>
xiphos-devel mailing list<br>
<a href="mailto:xiphos-devel@crosswire.org" target="_blank">xiphos-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/xiphos-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/xiphos-devel</a><br>
</blockquote></div>