Escape html special characters in completions

[holgerschlegel]

The cell renderer used for the completion popup window and the code to set the content of the description window should mask/escape characters that are special to html.

I'm using the RSyntaxTextArea with AutoComplete for a Java-like language and created a CompletionProvider that can return type strings with generic parameters. For example the property type of a VariableCompletion can be List<String> or something similar.
In such cases, both the cell renderer and the description window, the characters < and > has to be escaped by the corresponding html entities < and >. Otherwise the html renderer interprets it as tag and simply does not output the string between those characters.
So far I'm working around this by escaping the strings before filling the VariableCompletion. But I thing that is something that should be done by the view layer and not by the model elements.

Would be nice to add this to those classes - and other places that I might not have found yet.

[FrancescoGallucci]

I'm working around this by escaping the strings before filling the VariableCompletion

Hi, can I ask you how? I tried putting string like "\\<" but doesn't works.

[holgerschlegel]

You have to replace the special characters by corresponding html entities. For examlpe < is escaped as <.
I'm simply let Apache Commons StringEscapeUtils method escapeHtml3 do the work.

[FrancescoGallucci]

You have to replace the special characters by corresponding html entities. For examlpe < is escaped as <.

Ok thanks, it works on choices list but the autocomplete string now is "& l t ;" instead of "<"

[bobbylight]

Yeah, I doubt I wrote this down anywhere but most/all of the completion cell renderers and popup windows default to HTML input. It's expected that you supply HTML content to the API to facilitate structured content in e.g. the description window (lists, tables, etc.).

As for the cell renderers, I believe you can override this HTML behavior. It's been a while but I believe you can supply any CellRenderer you want. One supporting HTML is used by default but in my experience that renderer performs quite poorly for huge completion lists (due to Swing's HTML rendering and sizing calculations). I think I do this somewhere - let me dig up an example.

All that said, if there are ways the API can be improved let me know. I'm not necessarily against letting consumers specify a content type for e.g. the description window (text/plain vs. text/html for example), but I don't want to pollute the API unnecessarily. Suggestions welcome.

[holgerschlegel]

My goal is to let the completions (like FunctionCompletion) be a model that just contain the plain text, not the html encoded strings. That way it is easier to build those instances. And one could argue that view stuff (like encoding strings for display) should be done in the UI layer and not in the model/data layer.

In my opinion this string encoding is mainly needed for variable types, function parameter types, and function result types. I am already using a CompletionCellRenderer and peeked into its code to check if a custom subclass can do what I want.
That class contains method for each type of completion that compose the html string to display. And I can't simply overwrite those methods and mask the build string because it contains html tags to set text colors. So the only way to properly escape the type strings (other than my workaround) is to fully copy over those methods to the subclass to change its code. And that is something I would like to avoid.
In my opinion, as the CompletionCellRenderer always generates html string for rendering, it should always encode all string get from models (like name or type of completion).

And the second affected class is the AutoCompleteDescWindow. If the cell renderer auto-encodes model string values for html, that class must do so too. That class and its construction is private and thus I can't create my own subclasses.
And the text is sets to the UI in build by the completions getSummary() method. Which always generated html but does not correctly encode values like the type strings.

In the end, I'm not sure what the best solution would be if you do not want to include the html entity encoding into your code in an always-on way. And that solution may not be backwards compatible with the way the classes are currently used in the world.

I can live with my workaround. This was mainly meant as a improvement suggestions. Mainly because generating html without escaping special characters in the raw source strings is "an error".

[bobbylight]

Yeah I get it, thanks for the suggestions. I'll ponder this when I get some time.