microsoft
Add a settings page
Over time, more and more things may want to be configurable. Today it's:
- Theme colors
- Changing keyboard bindings
- Setting the ruler column for
COMMIT_EDITMSGand others - Enabling/Disabling the margin (line numbers)
- Enabling word-wrap for certain file types
- Cursor style
- Application language
We should use TOML, because JSON is kind of meh. It's also used by Helix.
On top of adding the mere dialog, this feature requires implementing settings persistence. This would mean:
- Windows: A settings file
- BUT: There are concerns about this making GPO more difficult. This needs to be watertight before we ship it.
- Linux: XDG
~/.configdirectory - maybe as a JSON file?- Implementing a JSON parser by hand would be funny
- macOS: Settings file but not sure which path ❔
More wanted options:
- Exit after closing last editor
- Show/Hide statusbar (should be in View menu)
- Persistent "Use spaces or tabs" (this one is driving me crazy!)
- Show/Hide menu (pressing Alt hotkeys should temporarily show menu again)
- Enable/Disable overscroll aka. "scroll past last line"
- Enable/Disable current line highlighting
My 2¢ on settings persistence on Windows:
Having the settings stored in the registry would be very annoying. Being able to copy (or use source control on) a single settings.json file would be very nice. In that case, you could pretty much have the same settings persistence scheme for all OS's (only difference would be file location).
Windows Terminal does this.
Having a settings file could also help with deficiencies in the settings editor. For example, in Windows Terminal, there is not a way to re-order profiles using the GUI, but you can somewhat easily do so by editing the settings file directly
Regarding file format, if you don't want to pull in another dependency for parsing the file, Ghostty went with a very simple key = value format (with comments), with the added feature of every option that can be set in the configuration file can also be set from the command line.
This format could be very nice if all you need are simple key-value pairs (indent-style = space, highlight-current-line = true, color-column = 80)
Key-bindings are a little more tricky, but I think Ghostty handles them pretty well.
keybind = trigger=action
keybind = ctrl+shift+v=select_line
i would prefer settings not stored in the Windows Registry, if possible.
Windows Terminal has a pretty good settings scheme.
JSON or the KV-like table file maybe the best choice. and it should be a standard file format or RFC standard. it should not be a personal preference because the edit will ship with Windows later.
my 2c Maybe make an options menu? (yes it does exist in edit 2.0)
I think this is implied by the title: "Add a settings page"
I assume that would mean that there will be a way to change settings through the TUI
A settings file would allow easier sharing across systems. Considering this is a Rust project, maybe TOML is a better choice than JSON? A potential downside of TOML is it's bad at representing deeply nested data, but I can't imagine this project having much of that. Writing a TOML parser might also be simpler than JSON.
It might also be worth being able to switch between a TUI and editing the settings file from within Edit like VSCode provides.
Additionally, a setting to change the language would be appreciated.
It might also be worth being able to switch between a TUI and editing the settings file from within Edit like VSCode provides.
See, now we're thinking with CLIs! I have a button bound in the editor I use which opens its own settings file. D'oh!
Having the settings stored in the registry would be very annoying.
It would also be painful to port since macOS and Linux, so definintely use .json or .ini. Those can be transfered between operating systems no problemo.
Maybe it would be better to use like %USERPROFILE%/edit.cfg I instead of the registry. Both Vim and git do this. Regarding the system-wide configuration, if interesting, I think C:\Users\All Users\ or C:\ProgramData could be used. A file would be specially nice for moving the configuration around and backing it up. However, would it be a whole directory or one single file? And what if the there are like a 100 settings?
In any case, if you do use JSON, please allow comments.
In conclusion, I think TOML is a good format for the configuration file of edit.
I think INI is a better format for the configuration file than JSON for the following reasons:
editis a simple text editor and the structure of the configuration file is unlikely to be complex enough that JSON would be appropriate.editis homage to the classic MS-DOS Editor.
However, INI has some problems, such as the lack of a formal specification. So I think TOML is a good choice because it's syntax is similar to INI.
I don't think it's necessary to implement the full specification of TOML for the parser. Because implementing unnecessary features for the configuration file would just increase the size of the executable.
macOS: Settings file but not sure which path
Can definitely use ~/.config/appname (same as Linux) which, for example when looking at my own machine, is also used by iterm2, fish, git, vim, nano, micro, darktable, htop, btop. Although the generic app name might be a problem, so perhaps start with ~/.config/microsoft/
Genuine question: Why do you want a configuration files instead of the Windows Registry? Windows Registry is a neat place for storing application configuration and the user-hive can be exported and imported quite nicely.
Maybe it would be better to use like %USERPROFILE%/edit.cfg I instead of the registry.
This is the exact reason why I prefer a central registry. Most applications store their configuration in my home directory. This is not ideal. It should be in %APPDATA% on Windows and in $XDG_CONFIG_HOME (or $HOME/.config if not present) on GNU/Linux.
Not using the registry makes settings portable across platforms. That's actually almost enough reason to not use it IMO.
Yeah but nobody is going to be using rust edit on other platforms. Just use the registry. At least then we can get some GPO capabilities on Windows.
Like literally other teams in Microsoft need to stop avoiding Windows for the sake of avoiding Windows.
It's a remake of edit.com not the next VSCode in console.
It's really not a remake of edit.com and I'm rather weary of people saying that over and over again. If the editor gains abilities that make GPO necessary (e.g. settings that don't just affect appearance and trivialities like line endings), we'll make sure to add GPO checks on Windows.
Yeah but nobody is going to be using rust edit on other platforms.
I donno, I'm primarily following the work on this editor because of support for all 3 major platforms (and the distant future where it may have a plugin system), I'd have no interest otherwise. There's not that many good modalless editors (and probably no great ones?). It's hard to say at this point, if this one will reach that status but it seems worth to cautiously (especially due to this being more of a side project with little funding from MS) follow what's going on here.
Like literally other teams in Microsoft need to stop avoiding Windows for the sake of avoiding Windows.
Just to provide a point of order: this team also owns the entire console subsystem from the kernel driver to the console host. We implement Windows.
Not using APIs that would make it difficult for us--and our users!--to work across different platforms isn't equivalent to avoiding Windows for the mere sake of it.
Evidenced by all the folks who clearly do want to use Edit on Linux, I feel that this was the right call. As the engineering manager I would make the same call a thousand more times, too. 🙂
Like literally other teams in Microsoft need to stop avoiding Windows for the sake of avoiding Windows.
Just to provide a point of order: this team also owns the entire console subsystem from the kernel driver to the console host. We implement Windows.
Not using APIs that would make it difficult for us--and our users!--to work across different platforms isn't equivalent to avoiding Windows for the mere sake of it.
Evidenced by all the folks who clearly do want to use Edit on Linux, I feel that this was the right call. As the engineering manager I would make the same call a thousand more times, too. 🙂
I'm just being realistic here as someone who manages fleets of Windows machines.
Don't confuse random people who are minimally interested because of the novelty of the program's existence to the people who actually could benefit from this tool to help to continue to reduce attack surface on our Windows Server fleet by convincing people to not RDP into Servers (and instead use SSH).
On OSS platforms there are literally dozens of text editors which were all called out in the previous thread that discussed edit's existence in the first place. Windows hasn't had a native console-based file editing platform in decades. So I don't really see the point in catering to or going after this group with yet-another-editor.
For those of us in the Windows world, a first-party, Microsoft-signed binary is going to go a much longer way to being something acceptable on my fleet of systems than an unsigned binary that we have to download, or worst, compile ourselves to avoid potential risks, and still ultimately sign with a CI/CD tool.
Going back to the point here, the value on the Windows platform is substantial relative to the value on OSS platforms. And on Windows, at least today, the best configuration management tool available is still pretty much GPO. Which is universally supported and understood and does a damn good job of maintaining and enforcing settings on the platform.
Inevitably I suspect edit will come to the situation that all Microsoft-born tools are bringing, which is either telemetry or copilot. There are very good reasons to turn these off beyond folks being picky about it, for example, those of us who work in ITAR/Export-controlled environments. And integrating with the registry, which can be managed by GPO, which also just so happens to come along with AD, is a very easy already-existing solution to configuration management in Windows environments.
Environments where reducing attack surface, increasing compatibility, and improving security is critical. And doing it in a way that already implements with the tools many Administrators already have is super critical.
FIDO to SSH to do Windows Server Core management is natively supported and reasonably easy to implement (although I have similar comments there as well, such as pulling from AD for public keys, etc. But I digress). Throw in WDAC/App Control + edit, with Registry+GPO to manage (where we can also build out and include ADMX templates), makes an incredibly powerful platform and boosts security tremendously on Windows for damn near free.
So yeah. I am not too worried about the plight of text editors on Linux. They're a dime a dozen. But what is REALLY needed is this capability on Windows, and manageable at scale.
I see where you're coming from and at the core of it, I agree. This is a Microsoft editor and so proper integration with Windows and its features will be at the forefront of our concerns. This includes GPO and similar management. Whether we use setting files or registry keys is in my opinion a trivial difference in that regard, however. In fact, we could even do both (although I rather wouldn't). Basically, this is important, so no matter what do, it will work correctly.
I'd like to note though, that Microsoft is not a single person. Whether this or that part of the company shipped a bad product at some point is entirely unrelated to whether this team ships good or bad products right now.
I'll be collapsing the discussion as I've noted your concerns for later (see the updated issue description). Until then it's somewhat unrelated to the current discussion of adding any settings at all.
I think something like ~/.mseditrc would be good.
It can also be made compatible with vim.
For the settings path, I think using the Starship.rs model may be helpful: Use a default path, but have it overrideable by a simple terminal variable.
And while JSON may be the standard for other editors, TOML might be easier to read and edit within the application itself.
https://github.com/microsoft/edit/issues/266 was marked as a default of this, but I will explicitly say here (since it's easy for it to get buried, when that was a specific ticket and this is more generally about options).
Ctrl+P is traditionally for print (or CMD P on Mac programs). On CUA (as used on MS Edit for DOS, On Notepad and all Windows Programs).
While VSCode might have done something different, that may be more because of it being an ancestor of Electron, which did a few non standard things, along with Sublime, which has a command bar.
For Linux and other freedesktop based projects there is a standard for settings file locations: a subdirectory of $XDG_CONFIG_HOME and if that's not set a subdirectory of ~/.config
So $XDG_CONFIG_HOME/msedit/ or ~/.config/msedit
And inside there a filename that doesn't start with ..
- An option to disable UI translation, just display the menu items in English, that's what legacy edit did.
- An option to disable UI translation, just display the menu items in English, that's what legacy edit did.
@skywind3000 No need to do that! Edit gets OS language from the system. You can set $LOCALE variable if you need other languages.
@skywind3000 No need to do that! Edit gets OS language from the system. You can set $LOCALE variable if you need other languages.
@clover-yan , Changing the system-wide $LOCALE variable can unexpectedly affect many things. Most editors and IDEs, such as Visual Studio, have local settings that allow you to override this. For example, you can specify your preferred language in the options without altering any system-wide settings.