Fix for Issue 3339

[WebsiteDeveloper]

Fix #3339

[WebsiteDeveloper]

Also added fixes for two other cases @peterflynn mentioned.

[WebsiteDeveloper]

@peterflynn also added code to replace the entire token, when invoking the in hints inside a token.

[WebsiteDeveloper]

unit tests will be added in a separate pull after this got merged.

[peterflynn]

We should really add unit tests here too -- both for some entity hinting cases and for the tag hinting cases that are currently broken (and which the existing tag hinting tests haven't caught).

[peterflynn]

Oops sorry, just saw the above note about adding unit tests later. Ideally we like to do it all in one pull request, but this seems ok since we definitely need to get the fix part landed ASAP before sprint end.

[WebsiteDeveloper]

thats what i thougth ;)

[redmunds]

This method now returns query !== null in all cases, so remove this block:

    if (implicitChar === null) {
        return query !== null;
    }

[WebsiteDeveloper]

Fixed.

[redmunds]

Sorry, but now that you made that change, I can see that you don't need query var, and this can simply be:

        return this._getQuery() !== null; 

[redmunds]

The variable name lineContent should be more accurate so code is easier to understand, so rename to something like lineContentBeforeCursor.

[WebsiteDeveloper]

Fixed.

[redmunds]

Although you haven't changed it in this pull request, I just noticed this function:

    function _encodeValue(value) {
        return (value.indexOf("#") === -1) ? value.replace("&", "&") : value.replace("&", "&").replace("#", "#");
    }

There's no need to search for "#" because replace will do nothing if it's not found:

    function _encodeValue(value) {
        return value.replace("&", "&").replace("#", "#");
    }

Question: Why is the semi-colon (;) not also encoded since it is decoded in the associated _decodeValue() function? In general, encode/decode functions should do the exact opposite of each other.

[redmunds]

Please don't push any changes until I say "review is complete". I'm looking at the code in both the github pull request diff and in Brackets, so it's making it difficult for me to keep them in sync. Thanks.

[WebsiteDeveloper]

sorry i'll certainly do so.
As to your question, encoding the semi-colon also would break things because of the order of replacements.
With something like that:

function _encodeValue(value) {
        return value.replace("&", "&").replace("#", "#").replace(";", "&#59;");
}

we would break the whole functionality because the replace would replace the semi-colons from the previous entities.
If we would reverse the order like:

function _encodeValue(value) {
        return value.replace("&", "&").replace(";", "&#59;").replace("#", "#");
}

the hash of the semi-colon entity would be replaced.

[redmunds]

The logic here needs some cleanup:

        if (endChar < startChar) {
            query = this.editor.document.getRange({
                line: cursor.line,
                ch: startChar
            }, cursor);
        }

        if (endChar < startChar) {
            return query;
        }

        return null;

1. No need to check for (endChar < startChar) twice.
2. The (endChar < startChar) condition relies on the fact that "not found" is represented by -1 so it seems a bit cryptic. Please reverse the logic and add a comment.
3. There was a check that startChar was found that got dropped. Maybe that was (cryptically) handled by the endChar === startChar case, but I think you need it here:

        // If no startChar, or endChar is found after startChar, then not in an entity
        if (startChar === -1 || endChar > startChar) {
            return null;
        }

        query = this.editor.document.getRange({
            line: cursor.line,
            ch: startChar
        }, cursor);

        return query;

[WebsiteDeveloper]

you're right thats much more understandable.

[redmunds]

Regarding "encoding the semi-colon": Unfortunately, it's not easy to do, but, if it's required, you just have to be smarter about it. In this code, I don't think it's required because _encodeValue() is only used to encode query strings. If so, then give it a slightly different name such as _encodeQueryValue() and add a comment explaining why it's not an exact match for _decodeValue().

[redmunds]

Done with initial review.

[WebsiteDeveloper]

actually _encodeValue() is used elsewhere to encode the ui string, but encoding the semi-colon is actually not needed as far as i can see. I have no idea why i did need it once ^.
So i'll just get rid of it.

[WebsiteDeveloper]

@redmunds fixes pushed.

[redmunds]

In the sorting function, I noticed this after I merged the original code: this line of code:

            return (num1 === num2) ? 0 : (num1 > num2) ? 1 : -1;

Can be simplified to:

            return (num1 - num2);

This is because sort functions aren't limited to returning only -1, 0, or 1. They just need to return 0 if equal, or a positive or negative number to indicate greater than or less than.

[redmunds]

match.indexOf(";") is called twice, so it should be put in a var.

[redmunds]

Done with second review.

[WebsiteDeveloper]

@redmunds changes pushed.

[redmunds]

Looks good. Merging.