The current completion scheme in Leo was developed mostly with python in mind. It provides some (most?) of the identifiers in its pool of known identifiers by using loaded modules and namespace dictionaries that are therefore available to provide completion options. The plug-in that provides this is known as the auto-completion plug-in, the auto part of the name is due to taking a typed period as indicating that the coder is going to be making/adding to a qualified identifier which automatically starts the suggestion of possibilities (in the log pane if more than one), plus suggesting required/optional arguments to functions in "tool tips" when the coder type an opening paren.

While very useful as is, there are problems with this auto behavior, and problems generalizing this to other languages where namespace info is not so readily available.

There are a number of completion types, plus a lesser known class of completions that I term expansions that I'd like to tease out and propose for inclusion in Leo.

I'll also go over one of the most powerful forms of templating that I've ever run across in an editor and propose it for inclusion in Leo.

I'm basing most of this out of my experience with another editor. In that editor, there where a few funcitons that got key-bindings, (I'll give them emacs-like names):

invoke-completion take the text to the left and see what the "completion chain" suggests
invoke-expansion take the text to the left and see what the "expansion chain" suggests
next-stop based on where the cursor is currently, go to the next stop in an inserted template
prior-stop based on where the cursor is currently, go to the prior stop in an inserted template

Here, rather than using the auto behavior, completions (or expansions) were explicitly invoked by the key binding set to "fire" the invoking method.

The "... chain"s where set up for each language mode, they were called chains because rather than being one single function to handle all cases, they were an ordered list of simple completion (or expansion) functions that would emit each possible choice (usually shown as hi-lighted text at the proper place in the text), in sequence after each repetition of the invoking keypress. If the coder did not choose any of the results of that function, the next function "registered" in the chain would be invoked, and its "suggestions" would be cycled through by continued invocations. This can continue through the whole chain, until either the coder accepts a suggestion by typing another character (which would move the cursor to the end of the selection before inserting the character, or the coder just gives up on the suggestions and types a backspace or delete, in which case the hi-lighted suggestion was just deleted. If you traveled the whole chain of suggestions, the cursor and text returned to the state they were in before this all began, ready to repeat everything all over again if the coder keeps pressing the invoking key(s).

CPpageTwo