[xiphos-devel] that blasted editor
greg.hellings at gmail.com
Fri Apr 17 16:32:31 MST 2020
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?
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
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.
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
I would strongly suggest considering that.
On Fri, Apr 17, 2020, 16:39 Karl Kleinpaste <karl at kleinpaste.org> wrote:
> 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
> 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
> 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.
> xiphos-devel mailing list
> xiphos-devel at crosswire.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xiphos-devel