Bug with auto-indent rule: "onEnterRules" + "indentOutdent" + "AppendText" do not insert indentation and string at the END as expected.

[Fast-and-Pythonic]

I'm making Syntax Highlight for the microScript language for microStudio. Not a Semantic Highlight. The syntax of this language is similar to Lua/Pascal. The end of the code block / indent level is indicated by the keyword "end".

The "Language Configuration Guide" says:
"appendText. A string that will be appended after the new line and after the indentation."

In theory, AppendText should add string after the "indent" stage. But it doesn't work as described with indentOutdent.

Therefore, I wanted to make an automatic increase in the indent level, and an automatic insertion of the "end" keyword at the end of the block. But there is a problem with "onEnterRules" + "indentOutdent" + "AppendText". It doesn't work as expected.

Here is an example. That's my rule.:
"onEnterRules": [
{
"beforeText": "\s*(?:if|elsif|else|while|for)\s*.*",
"action": {
"indent": "indentOutdent",
"appendText": "end"
}
}
]

Here is an example of a situation where it should work:

Here's what should happen when you press the "Enter" button:

• Press “Enter”.
• The indentOutdent is executed.
  • The carriage moves to the next line below.
  • On this next line, the indent level should increase.
  • And on the second line, the indent level should decrease again.
• And that's where appendText should work.
  • At the end of this second line, the keyword “end” should be inserted.

---

But for some reason, when pressing "Enter", this rule works like this:

For some reason, when using "onEnterRules" + "indentOutdent" + "AppendText", after pressing "Enter":

• The carriage moves to a new line.
• But on a new line, either the indent level is inserted and immediately replaced by the "end" keyword.
  Or the indent level is not inserted at all, but the "end" keyword is simply inserted instead.
• And at the end, the second line is inserted with the original, unincreased indentation level. Without the keyword “end” at the end.

---

I found this bug only for the rule (“indent”: “indentOutdent”). The rule (“indent”: “indent”) does not have this bug. For the rule (“indent”: “indent”), the indent level is simply incremented on a new line. And after that, the string is added.

Here's an example of how (“indent”: “indent”) + “AppendText” works:

---

Quite a few languages use this approach to designate “code blocks” / “indent levels”. Automatic insertion of such constructions as keyword “end” of a code block, in such languages, unexpectedly and surprisingly increase coding comfort. So I would like this wonderful mechanism to work without such embarrassing surprises.

p.s.: I don't get it, I'm not allowed to delete bug_report_template? What? This strange prohibition is very confusing.
p.p.s.: Ahhh, bug_report_template is hidden in the final message. It's clear now.

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.98.2
• OS Version: Windows_NT x64 10.0.19045

[Fast-and-Pythonic]

Labels:

• editor-autoindent
• bug

[RedCMD]

I would almost just recommend defining for/end and if/end as "brackets"
letting VSCode handle indenting itself

you can define an empty "colorizedBracketPairs" if you don't want the coloured bracket highlighting

[Fast-and-Pythonic]

I would almost just recommend defining for/end and if/end as "brackets" letting VSCode handle indenting itself

you can define an empty "colorizedBracketPairs" if you don't want the coloured bracket highlighting

Ohhhh. It looks like a good idea. Thank you very much. I'll go and try to implement your approach.

upd: And yet, even though your solution (brackets/pairs) is similar to what I was talking about, it's still not quite the same. With your solution, the "end" keyword is inserted immediately after entering the first keyword of the pair. And + you also need to press "Enter" so that the indent level is increased on the next line, and the "end" keyword is transferred to the second line. After that, you need to go back to the line above to add the line with the first keyword of the pair.

Or after the "end" keyword automatically appears, you need to add a line to the left of it. Press "Enter" and the indentation will be done, and the "end" will be moved to its proper place.

Users also need the opportunity to safely write a line with "if" / "for" / "while", etc. After that, the user switches to a new line, and the IDE should automatically increase the indent level and immediately insert the end of the block in the form of the "end" keyword on the line below.

The auto-indentation mechanism for parentheses is well suited specifically for parentheses. But for Lua/Pascal-style code block keywords, this mechanism is worse suited.

Sorry for the unnecessary details and particulars. It's just that the coding flow consists entirely of such details. This whole problem wouldn't have happened if there hadn't been a bug, and the "indentOutdent" + "AppendText" mechanism worked as expected. I hope the developers will fix the "indentOutdent" + "AppendText" mechanism. My knowledge of programming is still far from fixing such problems.

"appendText. A string that will be appended after the new line and after the indentation."

[Fast-and-Pythonic]

By the way, I also found this buggy behavior with “indentOutdent” + “AppendText”.

If there is a line with one of the listed keywords from “beforeText”, and on the next lines press “Tab”, then the indentation is not inserted, but the line specified in “AppendText” (“end”) is inserted.

If you press “Tab” on the lines after the word “end”, then the behavior is normal - indents are inserted as usual.

Likewise, on lines after the keyword from “beforeText”, and before the keyword “end”. If there are spaces on a line, and if you press “Tab” on such a line, the line with spaces is replaced by the keyword “end”. But other characters and text are not replaced by Tab to keyword “end”.

And if you press “Tab” on the line where there is a keyword from “beforeText”, then the behavior I described in the first post works. And by the way, it's funny that if you pass an empty string to "AppendText", then it behaves like just "indentOutdent". That is, the indentation on the first line does not break.

bandicam.2025-03-29.20-45-29-490.mp4

And is this really not a bug????????????????????
Please just fix this buggy behavior of "indentOutdent" + "AppendText".

[Fast-and-Pythonic]

I would almost just recommend defining for/end and if/end as "brackets" letting VSCode handle indenting itself

you can define an empty "colorizedBracketPairs" if you don't want the coloured bracket highlighting

The advice with the brackets is not bad, but I found a better option.

"autoClosingPairs" + "indentOutdent" works better + no problem with colors.

bandicam.2025-03-30.01-18-37-722.mp4

But it would be much better to just fix "indentOutdent" + "AppendText".

[RedCMD]

2nd if is missing || indentAction === IndentAction.IndentOutdent

vscode/src/vs/editor/common/languages/enterAction.ts

Lines 40 to 52 in 52eae26

	// Here we add `\t` to appendText first because enterAction is leveraging appendText and removeText to change indentation.
	if (!appendText) {
	if (
	(indentAction === IndentAction.Indent) ||
	(indentAction === IndentAction.IndentOutdent)
	) {
	appendText = '\t';
	} else {
	appendText = '';
	}
	} else if (indentAction === IndentAction.Indent) {
	appendText = '\t' + appendText;
	}

@aiday-mar description is misleading

nowhere does it state that the appendText will replace the indent whitespace

both descriptions claim the 1st line shall be indented and the appendText be added after that indentation