MSYS Delphi Formatter Installer<\/p>\n","protected":false},"excerpt":{"rendered":"
MSYS Delphi Formatter Installer<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"page.php","meta":{"__wpdm_changelog":[{"id":"cl_new_1789731347107","version":"1.2.0.24","date":"2026-09-18","changes":"
=======================================================================<\/br>\r\n MSys Delphi Formatter 1.2.0.24 \u2014 What's New<\/br>\r\n Maenken Systems \u00b7 https:\/\/maenken.systems<\/br>\r\n Release 1.2.0.24 (from release 1.0.0.23)<\/br>\r\n=======================================================================<\/p>\r\n\r\n\r\n
-----------------------------------------------------------------------<\/br>\r\n 1. Delphi 13.2: the formatter runs on the IDE's own formatter interface<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n
Delphi 13.2 opens the code formatter to third parties, and this release\r\nis the first to use it. On 13.2 the IDE itself owns the command, the\r\nEdit-menu entry, the editor context menu, the What that changes for you is not the look of the menu but what the\r\nformatter is finally allowed to do:<\/p>\r\n All of it sits behind the same safety gates as before: a file that does\r\nnot lex, or whose blocks do not balance, is left exactly as it is.<\/p>\r\n On earlier Delphi versions nothing changes \u2014 the formatter keeps using\r\nthe way it always has, and the options that only work through the new\r\ninterface are not shown there at all rather than offered in vain.<\/p>\r\n\r\n -----------------------------------------------------------------------<\/br>\r\n 2. Fixed<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 3. New<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n Format when the file is saved<\/strong> (General \u2192\r\n Format when the file is saved<\/em>, default off). Saving runs the\r\n formatter over the file \u2014 Two things make this safe to leave on. A file that does not lex or\r\n does not balance is saved unchanged<\/strong>, and the save path\r\n is completely silent<\/strong>: no confirmation, no notice, ever.\r\n Saving must not wait for a click, and a file being written is unfinished\r\n more often than not. And files excluded through\r\n The option is a setting of the IDE integration, not part of a\r\n profile, and it deliberately has no -----------------------------------------------------------------------<\/br>\r\n 4. By design<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 5. Under the hood<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n =======================================================================<\/br>\r\n MSys Delphi Formatter 1.0.0.23 \u2014 What's New<\/br>\r\n Maenken Systems \u00b7 https:\/\/maenken.systems<\/br>\r\n Release 1.0.0.23 (from release 0.7.0.22)<\/br>\r\n=======================================================================<\/p>\r\n\r\n\r\n -----------------------------------------------------------------------<\/br>\r\n 1. Fixed<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 2. New<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 3. Clarified and pinned<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 4. Under the hood<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n =======================================================================<\/br>\r\n MSys Delphi Formatter 0.7.0.22 \u2014 What's New<\/br>\r\n Maenken Systems \u00b7 https:\/\/maenken.systems<\/br>\r\n Release 0.7.0.22 (from release 0.6.0.21)<\/br>\r\n=======================================================================<\/p>\r\n\r\n\r\n -----------------------------------------------------------------------<\/br>\r\n 1. New<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n -----------------------------------------------------------------------<\/br>\r\n 2. Fixed<\/br>\r\n-----------------------------------------------------------------------<\/br><\/p>\r\n Five defects in this release share one trigger: they only appear once\r\nthe reflow of line breaks is switched on, and the standard Delphi 12\r\nconfiguration switches it on. Anyone who imported their existing settings\r\nmet several of them at once, which is why the import had a reputation for\r\nproducing odd results. The import itself turned out to be faithful \u2014 it\r\nwas applying the options exactly as given, and the engine mishandled\r\nthem.<\/p>\r\nCtrl+D<\/code> shortcut\r\nand the confirmation prompt \u2014 the formatter is a formatter, not a program\r\nthat reaches into menus to get called.<\/p>\r\n\r\n
\r\n
end.<\/code>. The same asymmetry had already been fixed\r\n for the older route; both now share one treatment. The growth happened\r\n once, not on every run, which is what made it easy to overlook.<\/li>\r\n<\/ul>\r\n\r\n\r\n
Ctrl+S<\/code>, Save all<\/em>, and\r\n the saves the IDE performs on its own.<\/p>\r\n delphi_format = false<\/code> are not touched here either, so\r\n vendor and generated code stays out of it.<\/p>\r\n .editorconfig<\/code> key: the\r\n IDE asks for it without reference to any one file, so a per-directory\r\n value could not be attributed to anything.<\/p><\/li>\r\n<\/ul>\r\n\r\n\r\n
.editorconfig<\/code> key for\r\n format-on-save.<\/strong> See above: the question the IDE asks carries no\r\n file, so there is nothing to resolve a per-directory setting against.\r\n Guessing one from the current editor window would be wrong the moment\r\n Save all<\/em> writes several files at once.<\/li>\r\n\r\n
\r\n
''''<\/code> \u2014 a regular string\r\n holding a single quote \u2014 may legally stand at the end of a line, for\r\n example in a wrapped concatenation. The formatter misread such a literal\r\n as the start of a multiline string: a file the compiler accepts was\r\n refused with a lexical error, and when the same shape appeared twice,\r\n everything between the two occurrences was silently treated as string\r\n content. Only an odd number of quotes opens a multiline string \u2014 the\r\n formatter now reads it that way too.<\/li>\r\n.editorconfig<\/code> section listing several masks in\r\n braces works.<\/strong> A section such as [{*.pas,*.dpr}]<\/code> \u2014\r\n a standard-conform way to address multiple file types \u2014 broke the\r\n settings resolution outright: on the command line every file under that\r\n .editorconfig<\/code> was skipped with an error, and in the IDE the\r\n format command went silently dead. Wildcards inside the braces are now\r\n understood exactly like outside them.<\/li>\r\ncase<\/code>\r\n or try<\/code> block.<\/strong> The column aligner lost track of\r\n where executable code begins once a case<\/code>, try<\/code>\r\n or repeat<\/code> block closed, and from there on treated\r\n statements as declarations: with the initialization alignment switched\r\n on, a comparison like Ok := A = 1;<\/code> gained stray spaces\r\n before its =<\/code>. Declarations still align; statements are\r\n left alone again.<\/li>\r\narray of record ... end<\/code> keeps its\r\n shape.<\/strong> The anonymous record body in a type like\r\n TItems = array of record N: Integer; end;<\/code> was not\r\n recognized: its fields fell out of the record, its end<\/code>\r\n closed the surrounding type section instead, and every declaration\r\n after it dropped to the left margin \u2014 legal code, visibly torn apart.\r\n The same applies to file of record<\/code>. Both now open a proper\r\n body, and the metaclass form class of X<\/code> stays untouched.<\/li>\r\n{$REGION}<\/code> pair only pairs when it really is\r\n one.<\/strong> The column pairing introduced for region directives\r\n assumed every opener and closer stands alone on its line; an\r\n {$ENDREGION}<\/code> written behind code, or a region inside an\r\n asm<\/code> body, silently derailed the bookkeeping and a later,\r\n unrelated closer inherited the wrong column. Unclean pairs are now left\r\n alone entirely \u2014 they simply follow the surrounding code, as they did\r\n before the pairing existed.<\/li>\r\nprocedure ... of object;<\/code> type.<\/strong> Such a\r\n procedure-type reference (and a generic constraint like\r\n <\/code>) was mistaken for the start of a record\r\n body that never ends, so from there to the end of the unit the constant\r\n and type alignments went silent. Only real bodies count now.<\/li>\r\nthreadvar<\/code> sections wrap like var<\/code>\r\n sections.<\/strong> The one-name-per-line option split var<\/code>\r\n and const<\/code> name lists but silently skipped\r\n threadvar<\/code>, which declares exactly the same lists.<\/li>\r\n$<\/code> with no digits stops the\r\n formatter.<\/strong> A bare dollar sign is not a hex literal and does not\r\n compile; the formatter used to format the file regardless. It now\r\n refuses it untouched, exactly as it does for an unterminated string.<\/li>\r\n--out<\/code> and -r<\/code> all results\r\n land flat in one folder; two same-named units from different subfolders\r\n used to overwrite each other without a word, so the mirror looked\r\n complete when it was not. Each collision now prints a warning naming\r\n both source files; the behaviour itself is unchanged.<\/li>\r\n{$REGION}<\/code> and its {$ENDREGION}<\/code>\r\n stay in the same column.<\/strong> The closer used to follow whatever the\r\n last line of code did, so a region wrapped around a routine whose body\r\n was indented ended up with its two halves two columns apart. A closer\r\n now follows its own opener \u2014 including the other way round, where a\r\n region inside a routine body moves along with it. Nested regions pair\r\n correctly, and a region written inside one branch of a conditional\r\n stays there.<\/li>\r\nelse<\/code> placement had to set it\r\n again after every restart. Two settings that could not be carried in an\r\n exported profile at all \u2014 format on typing, and the alignment at the\r\n opening bracket \u2014 now travel with it, alongside the option that joins a\r\n wrapped assignment.<\/li>\r\nvar<\/code> alone on one line and the\r\n declaration under it, the declaration was pulled back onto the\r\n var<\/code> column \u2014 while the very same declaration under a\r\n routine's var<\/code> section indents. Two spellings of one thing\r\n came out differently, and the one line the author had indented was the\r\n one that moved. The declaration now sits one level under its keyword,\r\n exactly where the routine section would put it; everything after the\r\n closing semicolon stays where it was.<\/li>\r\nend.<\/code>, so a file that was already formatted still came back\r\n changed, and its end drifted further down with each pass. The cause sat\r\n at the boundary to the editor buffer rather than in the formatter\r\n itself: the editor reads the last line break of a file as a terminator\r\n when it loads the file, but as a separator when text is written back\r\n into it, so handing a buffer back unchanged still grew it by one line.\r\n The round trip is exact now \u2014 a file whose end the formatter does not\r\n touch comes back untouched, and a file that genuinely ends in a blank\r\n line keeps it.<\/li>\r\nclass operator\r\n Vector.In(...)<\/code> came out as\r\n class operator Vector. in (...)<\/code> \u2014 the qualified\r\n name pulled apart and the member lowercased. The same happened to\r\n .And<\/code>, .Div<\/code>, .Is<\/code>, .As<\/code>,\r\n .Or<\/code> and .Not<\/code>. Operator overloads are exactly\r\n the code where such names have to appear, so this hit real libraries.<\/li>\r\ncase<\/code><\/strong> kept the inner case's indentation instead of\r\n returning to the label column. Only the first label after the nested\r\n block was affected, which is why it read as a one-off rather than a\r\n pattern.<\/li>\r\nif<\/code> expressions<\/strong> (Delphi 13)\r\n lost every level of indentation: each then<\/code>\/else<\/code>\r\n line fell back to the statement column, so a four-level expression came\r\n out as one flat block. Each level now carries one continuation step,\r\n with then<\/code> and else<\/code> of the same if<\/code>\r\n in one column.<\/li>\r\ninitialization<\/code> or\r\n finalization<\/code> section: with the corresponding option off \u2014\r\n the default \u2014 the statements of such a section were re-indented onto\r\n the keyword's column instead of being left alone. The option is\r\n documented as \"keep as is\", and now it keeps.<\/li>\r\nthen -1<\/code>, else -2<\/code>,\r\n not -Y<\/code> and to -1<\/code> came out as\r\n then-1<\/code>, else-2<\/code>, not-Y<\/code> and\r\n to-1<\/code> \u2014 legal, but they read as a single token.<\/li>\r\nclass procedure<\/code> or class function<\/code>\r\n body directly after a uses<\/code>, const<\/code> or\r\n var<\/code> section is no longer indented like a section\r\n entry.<\/strong> Only the class<\/code> prefix made the difference:\r\n a plain procedure<\/code> in the same spot closed the section and\r\n landed on the routine column, while a class method header was taken for\r\n one more entry of the section and pushed to the entries' column \u2014 even\r\n when it already stood at column 0, with the standard settings, and\r\n stable across runs, so reformatting never repaired it. A comment\r\n standing above such a header shared its fate. The section now ends at\r\n any routine header, prefixed or not. Reported by a user against a unit\r\n whose class-method implementations followed the implementation\r\n uses<\/code> clause; measured against a large open source library,\r\n this moves the headers in twelve units back to the column their authors\r\n wrote.<\/li>\r\nend;<\/code> of a procedure, format, and everything\r\n below it moves one level in \u2014 as it should. Restore the end;<\/code>\r\n and format again, and the routine headers came back to the margin, but\r\n their begin<\/code> and end<\/code> lines stayed where the\r\n slip had put them, stable across runs, so reformatting never repaired\r\n it. The rule that protects a nested routine's own column had been\r\n keeping the outer routine's frame too. It now keeps only what it was\r\n made for; the begin<\/code>, the end<\/code> and a local\r\n var<\/code>, const<\/code> or type<\/code> line are\r\n pulled back under their header again. Reported from the field with\r\n exactly that three-step sequence.<\/li>\r\n<\/ul>\r\n\r\n\r\n
implementation<\/code> introduces\r\n that section, and a local type<\/code>\/var<\/code>\/const<\/code>\r\n belongs to the routine header above it \u2014 both got a blank line pushed\r\n into them. The new option leaves both alone. It is off by default, so\r\n nothing changes unless you ask for it, and a unit-level type<\/code>\r\n following a forward declaration keeps its blank line either way. Only\r\n profiles that have the separators running were ever affected.<\/li>\r\n<\/ul>\r\n\r\n\r\n
case<\/code>-else<\/code>\r\n branch now sit one level under their own else<\/code> by\r\n default.<\/strong> Previously they stayed on the column of the other\r\n alternatives' statements, which left two levels between else<\/code>\r\n and the code belonging to it. The setting has existed for a while; only\r\n its default changed. It has an effect solely in combination with the\r\n RTL-style else<\/code> placement (the else line on the\r\n case<\/code> column) \u2014 with the else line indented, both readings\r\n coincide and nothing moves.<\/li>\r\ncase<\/code>.<\/li>\r\n\r\n
if<\/code>-expressions and the synthesized-space factory each live\r\n in one shared place now, the re-indenter works on its own copy of the\r\n token stream instead of the caller's, and the command-line program calls\r\n the encoding round-trip unit directly. No behaviour change; the test\r\n suite grew by over a hundred checks pinning these and the fixes above.<\/li>\r\n<\/ul>\r\n","timestamp":1789384595},{"id":"cl_new_1786966681443","version":"0.7.0.22","date":"2026-08-17","changes":"\r\n
:=<\/code> if the\r\n whole statement then still fits within the right margin, so\r\n Result :=<\/code> followed by a short expression on the next line\r\n becomes one line again. Like the end\/else option it only ever merges: it\r\n never breaks a line, it only takes a break away. It stays out of the way\r\n where the layout was intentional \u2014 if the statement carries any further\r\n break, or the right-hand side is an anonymous method, it is left\r\n untouched. The statement is measured as though all its breaks were\r\n already gone, so the result does not depend on the current layout and\r\n reformatting again changes nothing. Requested by a user.<\/li>\r\n<\/ul>\r\n\r\n\r\n
var a: Integer := 1;<\/code> was torn in two after the colon,\r\n leaving var a:<\/code> on one line and Integer := 1;<\/code>\r\n on the next. The rule recognised any identifier followed by a colon; it\r\n now requires what a label actually is \u2014 the start of a statement. Real\r\n labels still get their line break, and for I: Integer := 0 to 3\r\n do<\/code> stays in one piece.<\/li>\r\nvar<\/code>,\r\n const<\/code> or type<\/code> \u2014 including an inline variable\r\n in the middle of a routine. In code written for Delphi 10.3 and later\r\n that put a blank line between nearly every statement. The separator now\r\n fires only where a declaration section can actually begin; genuine\r\n sections keep their blank line.<\/li>\r\nvar<\/code>, const<\/code> and type<\/code>\r\n declarations to column 0 \u2014 actively, even when they had been correctly\r\n indented beforehand, while the begin\u2026end<\/code> body kept\r\n indenting normally. Both options now leave the declarations one step\r\n under their keyword, for top-level and nested routines alike.<\/li>\r\nelse{$ELSE}begin{$ENDIF}<\/code> has to stay on one\r\n line \u2014 both passes of the engine depend on it. With Line break after\r\n begin<\/em> active, the begin<\/code> was separated from the\r\n directive behind it, the structural bookkeeping went astray, and the\r\n file ended up with unbalanced blocks. The formatter then refused it\r\n outright, so the affected units silently stayed unformatted. Measured\r\n against a large open source library, six units were affected; now none\r\n are.<\/li>\r\ncase Integer of<\/code> without an end<\/code> of its own)\r\n following a nested var<\/code>, const<\/code> or\r\n type<\/code> section left an open block behind. Every declaration\r\n after that record \u2014 up to and including the final end.<\/code> \u2014\r\n stayed one level too deep and never returned to column 0. Because the\r\n result was stable across runs, reformatting never repaired it.<\/li>\r\nvar<\/code> there was taken for a\r\n declaration section: it pushed every following statement one level\r\n deeper, attracted the blank-line separator meant for real sections, and\r\n had the name list of var a, b: Integer;<\/code> split at its comma.\r\n All three are gone, in both passes. A related case: a declaration\r\n written across two lines \u2014 var<\/code> alone, the name below it \u2014\r\n was read as a goto label and pulled to the label column.<\/li>\r\n{$IFDEF}<\/code> line kept its original column literally. That was\r\n invisible until the block settings moved the code around it \u2014 then the\r\n directive stayed behind and ended up stranded between lines it no longer\r\n lined up with, which reads as if the conditional had not been\r\n understood at all. It now moves with the code, keeping exactly the\r\n distance the author gave it. Where nothing moves, nothing changes.<\/li>\r\nTThread.Queue(nil, procedure begin \u2026 end)<\/code> and every shape\r\n like it \u2014 had its whole contents pulled onto the column of its own\r\n begin<\/code>. A for<\/code> or if<\/code> inside it lost\r\n its level as well, and its local var<\/code>, const<\/code>\r\n and type<\/code> declarations sat on the same column as the\r\n keyword introducing them. The body now sits one step under its\r\n begin<\/code>, and the declarations one step under their section\r\n keyword, while the begin<\/code> itself stays where it belongs \u2014\r\n attached to the call it is an argument of. This is not tied to an\r\n option: it happens with the standard settings, which is why it was\r\n reported from ordinary use. Measured against a large open source\r\n library, every one of the affected places now matches the column its\r\n authors had written by hand.<\/li>\r\ninline<\/code> is a directive in Delphi, not a reserved word \u2014 but\r\n the formatter had it listed among the reserved words, so every\r\n identifier of that name was treated as a keyword and re-cased:\r\n unit Inline;<\/code> came out as unit inline;<\/code>, and the\r\n same happened in a uses clause or a qualified reference. Nothing stopped\r\n compiling, since Delphi does not distinguish case in identifiers, but\r\n the formatter was changing a name that belongs to the author. It is now\r\n handled like every other directive \u2014 overload<\/code>,\r\n stdcall<\/code>,