<div dir="auto">If formatting is really our concern, maybe we abandon HTML editing altogether? Perhaps a MarkDown compatible editor that will wriggle back and forth to the HTML displays in a text?<div dir="auto"><br></div><div dir="auto">It gives the full power of most formatting choices people would want while not limiting the full power of HTML (you can include HTML in line in a MarkDown document and it "just works" because md has a completely different set of special characters but spits out HTML without escaping special characters).</div><div dir="auto"><br></div><div dir="auto">It's also very easy to convert and to read. I imagine it would be easy to whip up an editor. And a "preview" is as easy as running text through the processing lib and dropping it into a WebKit viewer. Observe comments on Github that have an edit and a preview pane that are just a click apart. </div><div dir="auto"><br></div><div dir="auto">It's also much more "casual user" friendly than popping open vi/vim (default value of $EDITOR on most Linux systems). You keep consistency of UX with the current built in editor. Libraries are very minimal and so likely to be cross platform compatible. You can bake an editor right into a GtkTextView or GtkSourceView with a few triggers for bold/italics/list/quote.</div><div dir="auto"><br></div><div dir="auto">I would strongly suggest considering that.</div><div dir="auto"><br></div><div dir="auto">--Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020, 16:39 Karl Kleinpaste <<a href="mailto:karl@kleinpaste.org">karl@kleinpaste.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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" rel="noreferrer">xiphos-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/xiphos-devel" rel="noreferrer noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/xiphos-devel</a><br>
</blockquote></div>