The Large Text Editor should prompt me in QL expressions
Summary: When I am writing a long block of complex text that uses a lot of QL (for example, writing character sheets in ARC), much of my time is spent typing that QL. But that's silly: the system should really prompt me usefully, the same way that an IDE would.
This is really an Epic, and will need stories under it. Some of those will involve things like the following. Do this one piece at a time; the whole thing is pretty dauntingly large.
- General: all of this must be regularly tested on mobile touchscreens, not just keyboard and desktop.
- First of all, the Large Text box should become a much, much smarter gadget, akin to a typical WYSIWYG editor in the browser. This is a big change, and should be done first to get it out of the way, even if there is no actual WYSIWYG editing. This is a matter of replacing the existing textareas with a box that looks like a textarea, but is actually a smart div that behaves like one. Code this up as a pluggable gadget, designed specifically for gradual enhancement. Key to it is that it should allow plugins to hook particular key combinations.
- Sadly, the above will probably require rewriting Autosize from scratch, which is annoying.
- Typing [[ should enter QL Mode, inserting a pair of brackets and putting the cursor inside them. While in QL Mode, the system should become highly interactive. There should be a clear notion of the current Context at any given point in the text. (This almost certainly means that we will need to firm up the semantics of QL functions first, so the system can infer types in QL expressions.)
- When I begin to type in QL Mode, the system should do prompting, a la MarcoPolo. It should seek out possible completions of the current typing, favoring Properties of the context link (if there is a context link), then looking for other names in the Space. This must be aggressively cached in the client. (Which probably means reimplementing much of MarcoPolo, yay. Think about these things as reusable libraries.) The completion engine should allow for completions that do not start at the beginning of the word, so I can omit initial underscores from function names. (This presumably means we need to keep a permuted index of names somewhere in the Space.)
- The client offers completions a la Manifest. These completions must include the literal typed text, so I don't wind up unable to type a prefix. (Probably just above the best match.) The user can use arrow keys to navigate among the completions, and press enter to select one. Obviously, the most-probable match should be at the top, pre-selected.
- After I select something, it gets added to the expression, and the system gets ready for me to begin typing the next. If I type (, it adds matched parens, and puts the cursor inside. If I type ", it adds a quoted block, and puts the cursor inside. If I start to type a symbol, it adds a -> and starts prompting again.
- As each term gets added to the expression, the context gets re-calculated. This context should remain attached to the position in the text, for quick lookup.
- When I type ], that moves the cursor after the expression, and probably applies some sort of syntax highlighting so that QL can easily be distinguished from QText.
Overall, the long-term objective is to reach a level of efficiency comparable to an IDE.
Note that this same gadget will also need to support QText WYSIWYG. Ideally, that should get started at the same time, to keep us honest.
This must cope with both Large Texts and Functions. In general, it should switch between QText and QL modes, the same way the parser does.
Keep in mind that this will eventually be supplemented by Querki Explorer, for naive users. This prompting system will live inside of that.
