Re: [xiphos-devel] that blasted editor
On 4/18/20 4:14 PM, Greg Hellings wrote: > And adding a MarkDown filter to the engine probably isn't very > difficult at all. I'm not sure you realize how subtly I threw down that gauntlet, or how readily you picked it up. :-D ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] that blasted editor
On Sat, Apr 18, 2020 at 2:40 AM Dominique Corbex wrote: > On Fri, 17 Apr 2020 18:32:31 -0500 > Greg Hellings wrote: > > > 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? > > > I would strongly suggest considering that. > > +1 > > I'm using marker myself > https://github.com/fabiocolacio/Marker I had seen that. It doesn't have any helper buttons, but I imagine we could add one for the most basic things: Going through the editor UI as it currently exists: * Bold/italic/underline/strikethrough are pretty simple in Markdown * Headings are easy * Insert an image is also very straightforward. * Font color/size is a bit harder * Horizontal rule is very simple as well * Links are pretty trivial Tables are the only one that's moderately complex that we currently have but wouldn't have in Markdown. Going from MD to HTML is easy. Lots of markdown libraries exist. CMake seems one that's already packaged for Fedora and has official MinGW build support, so putting together a package for it seems trivial. https://github.com/commonmark/cmark Making the trip back from HTML to MD is a bit more complicated. There is pandoc (https://pandoc.org/) which is written in Haskell and has a C binding that supports ALL THE FORMATS and includes the ability to go both directions. It does build for Windows - there are official builds released by the pandoc folk. There is no reason to suspect a cross-compile chain couldn't be created, but that's a lot of moving parts to put together. Maybe it's best to include a working binary and pass temp files to it, rather than try to include it as a library? --Greg > > > Dom > -- > domcox > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] that blasted editor
On Fri, 17 Apr 2020 18:32:31 -0500 Greg Hellings wrote: > 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? > I would strongly suggest considering that. +1 I'm using marker myself https://github.com/fabiocolacio/Marker Dom -- domcox ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] that blasted editor
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 characters). 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 bold/italics/list/quote. I would strongly suggest considering that. --Greg On Fri, Apr 17, 2020, 16:39 Karl Kleinpaste 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 and so forth, but any editor > that will spit out and and 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? > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
Re: [xiphos-devel] that blasted editor
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 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 and so forth, but any editor > that will spit out and and 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? > ___ > xiphos-devel mailing list > xiphos-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/xiphos-devel > ___ xiphos-devel mailing list xiphos-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/xiphos-devel
