The formatter should match the Intellisense styling so that code is consistent.
i.e. function names such as CALCFIELDS aren't case-corrected to CalcFields based on the Intellisense suggestions.

Another example, is BEGIN END. The intellisense and snippets will always suggest lowercase or title case.
Incidentally, C/SIDE used to do this for you when saving an object. Similar standards would help make public and partner code more consistent and readable.
Formatter is currently only dealing with whitespace, i.e. it will never make character edits, only add or remove whitespace characters.
We are looking at ways of fixing the txt2al converter instead such that the output already matches the formatter and best practices.
Txt2Al does use the capitals, I guess that's a separate issue.
As developers onboard to AL I imagine old habits (such as capitals for constants) will be tricky and time consuming to manually correct.
I guess ultimately the habit should be broken, but having a quick way to cleanup would be nice. As mentioned, C/SIDE did this, and in turn made code more visually consistent. Never thought I'd miss a C/Side feature 馃槣
Yes, precisely, txt2al currently converts using the old casing but we are looking at improving this.
For newly typed code IntelliSense already proposes correct casing so this is mostly a matter of handling converted legacy code correctly.
There will be a TON of code that has already been through an earlier version of Txt2AL that will be in UPPERCASE and I hate to think of the number of hours that it will take to go through this and 'correct it'.
Please add this to the AL language extension for VS Code asap rather than adding to Txt2Al which will only fix new code conversions..
We have it in our backlog to add it to VSCode, but until then, you can find other VSCode extensions built by the community which can fix the casing.
Most helpful comment
Yes, precisely, txt2al currently converts using the old casing but we are looking at improving this.
For newly typed code IntelliSense already proposes correct casing so this is mostly a matter of handling converted legacy code correctly.