AutoComplete and Highlighting for inner/nested modes (mixed by the "xwiki" mode)

Right now, autocomplete in the document content wiki syntax editor works by sending the whole document content to the REST autocompletion service and by specifying the document's syntax.

This means that autocompletion is done only at server side and we can not reuse the client-side JS autocompletions provided by the codeMirror distribution for HTML, Python and JavaScript (for inline scripts in the html macro).

We need to decide how to handle this:

• server-side only or
• client side, the codeMirror way, mixed with server-side where needed (for server-side languages like Velocity, Groovy, etc.)

Pros/Cons

While the client side + server side approach has the advantage of code reusability (using existing implementations), it has the downside that it can be less flexible. Two main limitations would be:

• third party clients of the REST resource would have to rewrite autocompletion implementations for the client-side languages (example: XEclipse would have to re-implement JavaScript, HTML and Python completions if it wants to provide this functionality)
• no communication between nested languages: if the root language is autocompleted by a client-side implementation and a contained/nested languages is autocompleted by a server-side implementation, hints on variables defined in the root language would not be available inside the nested language

Also, while the server side approach would be highly reusable by 3rd party clients, but some client-side languages like javascript would suffer from the lack of context (lack of completions on the "window" object and other such context-dependent things).

Perhaps a solution would be to aggregate completions from all the involved languages, going from a root language down to its nested languages. Example:

{{velocity}}
  #set ($a = "a")               <---- Velocity
  {{html}}
    <div class="$a"/>           <-------------/ HTML
    <script>
      var b = "$a"              <-------------------/ JavaScript
    </script>
    <style>
      .c { color: $a; }         <-------------------/ CSS
    </style>
  {{/html}}
{{/velocity}}

We would first evaluate everything inside the Velocity tag as velocity, then everything inside the HTML tag as HTML and finally everything inside the JS tag as JS (same for CSS), each such evaluation adding to the list of completions together with a marker that states where that completion comes from.

However, normally this would not cause much pollution since velocity completions start with "$" or "#", HTML tags use "<", but there can be cases like HTML attributes and their values where a nested macro would be quite polluted with completions from its parent macro(s). Example:

{{groovy}}
  def class = "a";
  {{html}}
    <div [1]c[2]lass="a[3]"/>
  {{/html}}
{{/groovy}}

In the above example, only the autocomplete position marked as [3] would be a viable candidate, while [1] and [2] would just be pollution.

These would be concerns about a complete implementation. However, until then, we would probably implement limited autocompletion in an iterative manner.

—

Existing client-side implementations:

• HTML: script (JS) and style(CSS) tag contents are not autocompleted the same way they are highlighted (with the "htmlmixed" CodeMirror mode)
• Python

Existing server-side implementations:

• Velocity (in progress)