[FEATURE] - Turn off Auto-closing pair for `<` `>`

[Pontiac76]

I don't know if this is a BUG or a Feature request, but PLEASE OH PLEASE allow us to toggle the Auto Bracket functionality somewhere, somehow, without having to edit code or digging into settings.json for user or workspaces. It's SERIOUSLY annoying when hitting < and you get a forced > right after with no prompting.

I found pascal.configuration.json and will be removing ALL the automatic text functionality. I'm just worried next update to your code, my changes get nuked, so I've disabled the Auto Update on this one specific tool.

Environment/version

• Extension version: 9.8.0
• VSCode version: 1.92.0
• OS version: Win10 Pro

Steps to reproduce

1. Open any .pas file
2. Go to any line
3. Hit <

You'll see a trailing >

That > is distracting and doesn't help at all when attempting to do <= or < or adding info to comments for auto documentation.

[Pontiac76]

I have a very dedicated machine setup for just doing Pascal coding, and absolutely nothing else. It doesn't hook into my VSC configs stored in Github, or anything. It's completely totally 100% "anonymous". I don't even think I've checked my email on this very specific machine. Other than a TO DO plugin, as shown, your two Pascal extensions are all that are in play here.

[alefragnani]

Hi @Pontiac76 ,

VS Code does not (yet) support user defined auto-closing pairs, so each language extension defines its own sets. There is an open issue on their repo, bur no ETA (https://github.com/microsoft/vscode/issues/38352).

The < > pair exists because of generics, and I see your point about using <=, but unfortunately there is no way to combine both. The only feature that could be added would be to make this auto-closing pair disabled on strings or comments, but if you use < on a logical statement, it will still be fired.

You can, however, turn off all autoClosingPairs, simply adding "editor.autoClosingBrackets": "never", on your User Settings. Doing so, none of the 6 (six) rules defined in the language will be applied, In fact, no other auto-closing pair would be applied at all, for any language, unless this setting supports language level configuration, which I'm not aware.

Hope this helps

[Pontiac76]

When and if VSC does support auto-closing pairs, it'd also get disabled.

I ran into this issue when I was working in some comments and making notes about why something was as it was (4am coding trying to keep my mind straight on something that should have been simple) and it was driving me nuts.

I appreciate the option being present for those that want to use that functionality, but I sincerely can't stand it when the IDE tries to "do things" for me. Can the option in the addons config be present to turn off all functionality for all the closing pairs instead of editing? I already deleted the parameters in the json. I'm much happier with that. But that's my style of coding, and yeah, i do understand the reason that it exists for generics. I'd still put in the closing "bracket" myself and not think about it.

[alefragnani]

The "editor.autoClosingBrackets" setting is a feature that VS Code provides, not this extension. If you set to never will turn off all auto-closing pairs, for all languages, so VS Code won't interrupt your workflow.

If you think this setting should have a different default value/behavior, I would suggest you to open an issue at VS Code repo (https://github.com/microsoft/vscode/issues), so the team could evaluate your proposal.

Hope this helps

[vmaskmovps]

@alefragnani

I don't think your default is good, @Pontiac76 is right.

The < > pair exists because of generics, and I see your point about using <=, but unfortunately there is no way to combine both. The only feature that could be added would be to make this auto-closing pair disabled on strings or comments, but if you use < on a logical statement, it will still be fired.

C++ also heavily depends on generics, as you may or may not know, and yet if you look in its language-configuration.json in the corresponding extension, you'll notice it doesn't define that particular pair. Speaking of which, yes, you should disable auto-closing on strings and comments:

"autoClosingPairs": [
      { "open": "[", "close": "]" },
      { "open": "{", "close": "}" },
      { "open": "(", "close": ")" },
      { "open": "'", "close": "'", "notIn": ["string", "comment"] },
      { "open": "(*", "close": "*)", "notIn": ["string", "comment"] },
],

and probably define (* *) as a block comment pair too. I am not sure if " should also be included, since Pascal doesn't use those in any capacity.

[alefragnani]

Hi @overanalytcl ,

I suggested to disable auto-closing pairs on strings and comments, as @Pontiac76 scenario looked like it was being interrupted while adding comments, but it appeared not to be enough. Instead, the request was to remove all auto-closing pairs. This change, I respectful disagree, and will not be made.

If you want to disable all auto-closing pairs from the extension, simply use the VS Code setting that I commented above.

On the other hand, specifically for the < + > pair, personally, I see much more value on it turned on, because of the Generics usage, and prefer VS Code doing its work adding >, instead of myself removing it when I want to type <= for instance.

But, I'll leave it to the community/users. I'll reopen the issue gand If a good amount of users choose to remove it or make it available only for strings and comments, I'll change the extension.

Hope this helps

[alefragnani]

Let's vote...

What would you like to see on auto-closing pair for < + >?

• Remove it completely and don't suggest me anymore 👍
• Disable it only on Strings and Comments 👀
• Keep it as is and suggest me anywhere 👎

Thank you

[Pontiac76]

My vote is to have the ability to specifically CHOOSE which auto-complete function the user wants enabled. (*comments*) I could potentially see a half decent reason to keep that on. When < has multiple functions of use, it shouldn't just assume "Oh, you're using generics, here's the closing bracket" when I'm actually trying to do 20 comparisons. Instead of having a sledge hammer, forced auto-inserted and unneeded content, let me choose how I use the IDE.

Every single one of those fields in that config json can be configured and can be set at script initialization. It doesn't have to be a read-once function. If a change happens, the script can be reloaded fast if that's what it takes.

My solution that I have right now works for me. If you don't want to apply an option to turn off the autogen, I'm perfectly happy with that as well. I'll just leave my side to not update as to not mess with my preferred configuration file. This is your code, this is how you envision and how want to work with it, and I won't make demands and make harassing remarks about it. I'm just explaining my use case, what frustrates me with your solution, and offering the ability to add an enhancement for others who may also find what I'm experiencing to be hugely frustrating.

To be sincerely honest, I was content (but saddened) with having this issue closed. But I'm glad you re-opened to revisit and see what other opinions are. I have other "concerns" in life that can raise my blood pressure. What a stranger does with code they wrote and freely distribute for others to use, I don't have a leg to stand on, nor the right I feel, to make demands for change, other than just offer suggestions to take the rough edges off for my use case.

[Pontiac76]

Oh... By the way... I don't think your earlier solution would have done the trick either. VSC doesn't know what Pascal is by default to generate a generic type of code. This is purely something on your script. I don't have this issue with other languages that I enter code in, like, HTML or PHP. Both languages are HUGE on < and >.

Without looking at code, I suspect you're checking to see if that setting you suggested is on or off and and then having VSC do the inserts? Unless that variable specifically tells VSC to adapt and conform to that function and does its application on its own outside your script, still, it's your script that's feeding VSC to run those commands.

[alefragnani]

There is no way to choose, as VS Code does not support that. The configuration must be upfront, defined solely on package.json, so there is no script to be called that could customize this behavior. At least, not that I'm not aware of.

If you, or anyone knows how to make the extension customizable at this level, using VS Code APIs, feel free to open a PR, and I'll be glad to incorporate in the extension.

On the other hand, if the poll above is not enough, and no PR is about to be open, the issue can be closed again.

[vmaskmovps]

The auto-closing pairs are controlled exclusively by pascal.configuration.json, as can be seen in the package.json:

"languages": [
    {
        "id": "pascal",
        "aliases": [
            "Pascal",
            "pascal"
        ],
        "extensions": [
            ".pas",
            ".p",
            ".dfm",
            ".fmx",
            ".dpr",
            ".dpk",
            ".lfm",
            ".dpr",
            ".lpr"
        ],
        "configuration": "./pascal.configuration.json"
    }
],

The solution, as employed by the JS, C++ and C# extensions (I suppose also by the PHP one, I couldn't find the right file in Intelephense) is to keep <> just as surrounding pairs and leave that out of autoclosing. This is what C# does (from its Razor syntax):

{
    "comments": {
        "blockComment": [ "@*", "*@" ]
    },
    "brackets": [
        ["<!--", "-->"],
        ["<", ">"],
        ["{", "}"],
        ["(", ")"]
    ],
    "autoClosingPairs": [
        { "open": "{", "close": "}"},
        { "open": "[", "close": "]"},
        { "open": "(", "close": ")" },
        { "open": "'", "close": "'" },
        { "open": "\"", "close": "\"" },
        { "open": "@*", "close": "*@" }
    ],
    "surroundingPairs": [
        { "open": "'", "close": "'" },
        { "open": "\"", "close": "\"" },
        { "open": "<", "close": ">" }
    ]
}

and typescript-basics inside the vscode repo (see the full file here):

    "comments": {
        "lineComment": "//",
        "blockComment": [
            "/*",
            "*/"
        ]
    },
    "brackets": [
        [
            "${",
            "}"
        ],
        [
            "{",
            "}"
        ],
        [
            "[",
            "]"
        ],
        [
            "(",
            ")"
        ]
    ],
    "autoClosingPairs": [
        {
            "open": "{",
            "close": "}"
        },
        {
            "open": "[",
            "close": "]"
        },
        {
            "open": "(",
            "close": ")"
        },
        {
            "open": "'",
            "close": "'",
            "notIn": [
                "string",
                "comment"
            ]
        },
        {
            "open": "\"",
            "close": "\"",
            "notIn": [
                "string"
            ]
        },
        {
            "open": "`",
            "close": "`",
            "notIn": [
                "string",
                "comment"
            ]
        },
        {
            "open": "/**",
            "close": " */",
            "notIn": [
                "string"
            ]
        }
    ],
    "surroundingPairs": [
        [
            "{",
            "}"
        ],
        [
            "[",
            "]"
        ],
        [
            "(",
            ")"
        ],
        [
            "'",
            "'"
        ],
        [
            "\"",
            "\""
        ],
        [
            "`",
            "`"
        ],
        [
            "<",
            ">"
        ]
    ],
    "colorizedBracketPairs": [
        [
            "(",
            ")"
        ],
        [
            "[",
            "]"
        ],
        [
            "{",
            "}"
        ],
        [
            "<",
            ">"
        ]
    ],
    // ...