foo.bar results in <foo class="bar"></foo>

[Moonsword22]

There's some more quirks going on here with other tags embedded inside a function tag now. <cfscript> tags are behaving correctly, though.

Note that <cf_customJsTag> is not a <script> block in the example below, nor am I expecting the parser to treat it as one. (If I want that, I'll copy the text out into another pane and set the syntax to JavaScript while I work.) It's not supposed to be handled like HTML, either, and previously wasn't - this is text content inside the body of a custom tag. JavaScript is one use case we have in a particular situation but we do have others.

<cfcomponent>
    <cffunction output="true" name="functionGoesHere">
        <cfquery name="local.qBar">
            -- Autocomplete works without any qualifying text in front
            SELECT function
            FROM function
            WHERE
                nFunctionId = @nFunctionId

            SELECT *
            FROM foo.bar h
            WHERE
                h.nId = 1

            -- Autocomplete after the period results in:
            <foo class="bar"></foo>
            <h class="nId"></h>
        </cfquery>

        <cf_customJsTag>
            var fooVar = "",
                barObject = {};

            <!--- Autocomplete works here because there's no object in front --->
            fooVar = "Hello world!";

            barObject.fooVar = fooVar;

            <!--- Autocomplete results in: --->
            <barObject class="fooVar"></barObject>
        </cf_customJsTag>

        <!--- Autocomplete works exactly as it should inside <cfset> --->
        <cfset local.qBar.nFunctionId>
    </cffunction>
</cfcomponent>

I'll try to keep an eye on this thread if you need me to provide more testing and feedback.

EDIT: All Autocomplete bypasses this issue, by the way, and I've reinstalled it for the time being on my office workstation. I have another PC using Sublime that won't have it installed to use for testing.

[jcberquist]

This is also due to the HTML completions - you are encountering the completion snippet from the HTML completions that imitates emmet completions (e.g. div.foo expands to <div class="foo"></div>).

There isn't going to be a perfect solution to this, as there is no way to determine in the syntax when the cursor is inside of a custom tag body. However, I might try removing the text.html.cfml scope entirely from HTML inside of <cffunction> tags and then adding in HTML completions by sub-classing the HTML completions. That would let me retain the HTML completions and also keep them from triggering in CFScript and SQL contexts. However if they are there and enabled there is no way to keep them from triggering inside of a custom tag.

What I can do is add a setting that would allow you to turn off these completions altogether, so if you don't mind losing the HTML tag completions in <cffunction> bodies you could go that route.

[Moonsword22]

Like I said, in the interim, All Autocomplete is a functional solution. If it takes some time to solve this, it'll take some time.

We do use <cffunction> to wrap HTML output in many cases, so a setting likely wouldn't work out that well because developers inevitably wouldn't turn the setting on and off appropriately. It may be we're reaching the point of diminishing returns on chasing this problem and I just need to roll out All Autocomplete to the rest of the team.

Can you unscope the HTML completions inside <cfquery> tags very easily? I can deal with this in a custom tag or function body but it can be jarring in <cfquery> when a programmer is thinking in SQL, not CFML, or HTML.

[jcberquist]

With this latest update, I think we have reached the point of what can be done (at least easily) with this package. It should now avoid offering HTML completions in CFScript and in <cfquery> tags. The one place where you are still going to get them (where it is undesired) is inside of your custom tags. Unfortunately, as mentioned earlier, that is one place where a straightforward fix is not possible.

[Moonsword22]

Thanks for your assistance on this. Myself and another developer are using All Autocomplete to patch the holes, but I appreciate you taking the time to address these things.

[jcberquist]

Thanks for raising the issue and improving the out of the box experience with this package. I am glad there is a workaround for the tags.