The Gram Code Editor - 2026-05-29

@krig, I have very strong differences with your assessment. Sensible, minimalist defaults, especially ones that are not destructive, would be not only less confusing, but even more importantly, they provide vastly superior usability. The application should not reformat a document unless explicitly instructed, whether through an action invoked directly, or by a chosen configuration setting that enables reformatting automatically on some event, such as saving a file. It is generally not expected, desired, or necessary that an editor automatically reformat an entire document every time any part is edited. Breaking backward compatibility is in general an important concern, but much less so in these early days, before a wide user base has been established for the application. The current behavior of the application is potentially destructive, as complete reformatting is applied in every case of not being explicitly disabled for the particular language. It seems to me as, frankly, quite wrongheaded, and best corrected as early as possible so as to be minimally disruptive. Important issues need to be considered and discussed, but unfortunately the chat format is rather limited.

I do agree with you about that! Mainly I don’t have a good idea for what the settings UI ought to look like. I think the current override model is confusing in general, not just for formatting (and the defaults are also not what I would choose)..

huh I just noticed some inconsistency in the settings schema: ```jsonc { "format_on_save": "on", // why not a boolean here!? "remove_trailing_whitespace_on_save": false, } ``` ✏

probablement too much of a breaking change at this point I guess, unless it's possible to accept a boolean or the "on" or "off" string literals

that’s odd.. unless there’s a third state like ”auto” or something

it's "on", "off" or null

but I guess it could be boolean or null

To me the desired design, in this case, seems quite apparent. Before explaining, I would begin by noting that I have no objection to "format on save" being removed entirely. I feel it is not a sensible or helpful behavior in any case. An action that could be invoked manually, however, to perform the reformatting, would be more sane. Perhaps some day there would be configurable hooks to map actions to events. Regardless, I will assume, for the sake of discussion, that dropping the feature is not the chosen path. My recommendation is as follows: - The global option, for "format on save", would be kept, but the default setting would be disabled. - Any language settings may also include an option called the same. If so, the option should be disabled by default, and the behavior should occur if and only if either the global or language-specific option is enabled. - Language-specific behavior may follow the global option directly if the same option is omitted from the language specific settings. Then, whoever wants to use the feature may opt-in, either globally or casewise.