Treedown Editing Environment

[jonathanrobie]

In issue #22, Randall envisions a guided editing environment for Treedown, and also makes some suggestions for post-processing that are more closely related to issue #2. I am opening this issue for discussion of the editing environment, and will flesh out ideas on morphology and the treedown utility in #2.

[jonathanrobie]

I'm concerned about scope creep. This kind of environment would be nice to have, but would also require significant programming effort. I think that the Treebank utility described in #2 is much simpler to produce. I also think that we should get more experience creating treebanks using that utility before concluding that we need the more ambitious tool.

Of course, preprocessing texts to provide labels and initial phrasing can be done with much less effort, and might be helpful. But I am not sure how helpful this is, we should try it both ways. There's something to be said for letting the human work top-down, handing off the phrasing and morphology to the phrase parser after the human is done reading the sentence. Let's try various approaches and compare - and let's experiment with light-weight tooling.

[jonathanrobie]

On reflection, I realized there's a middle ground. Programming editors allow you to compile a program and find the errors, and they provide syntax highlighting. We could use the same model for Treedown - use syntax highlighting and formatting support in the editor, run the Treedown utility from within the editor much like compiling a program, check against morphology, etc. The key is to have each function implemented as a command-line program that reports errors in more or less the same way that a compiler does.

[jtauber]

I don't think it's scope creep for Treedown itself any more than text editors, linters, static analyzers, etc., are scope creep for a programming language spec.

There could be a whole ecosystem of tools around Treedown that Treedown itself doesn't need to know about (except the occasional use case for extensions, etc)

[jtauber]

Some of Randall's suggestions also remind me of that web-based semantic structure editor we talked about a while ago, @jonathanrobie. There were some neat UI ideas in that that could be applied here.

[jonathanrobie]

I don't think it's scope creep for Treedown itself any more than text editors, linters, static analyzers, etc., are scope creep for a programming language spec.

Let me be clear what I was thinking. I'm still working on the bare-bones Treedown utility. I definitely see the need for a larger infrastructure of interoperable tools going forward, and integrating them into a programming editor makes all kinds of sense. But I am trying to distinguish "the minimum required to show the usefulness of this approach" from "the environment I would like to be working in a year or two from now". We might use the first to promote and fund the second.

I do think brainstorming and specifying what we want further out is very helpful, I just don't think we're likely to have milestones for them for a while.

[rkjtan]

That's good. The main reason I mentioned this is to make sure we build a framework that supports this type of larger infrastructure further down the road, not that they should be present at the start.