[xiphos-devel] that blasted editor
defsyn at gmail.com
Fri Apr 17 16:31:04 MST 2020
I don't use the editor that much. I prefer to use my own. What's most
important to the typical bible scholar is to have access to the books,
commentaries, translations, dictionaries, etc.
I would say. At least to me.
On Fri, Apr 17, 2020 at 4:39 PM 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