microsoft
Add edit to the Linux repos...
This will allow people to type somthing like sudo dnf install microsoft-edit to get the software installed. It should also work with Debian, Arch and Gentoo. This will make it easier to install and set up on a Linux system.
Thanks. 👍
Packaging the software for all Linux distributions is not necessarily the responsibility of the project owner. Community members will usually step up and maintain distribution packages. For Arch Linux this already happened:
https://archlinux.org/packages/extra/x86_64/ms-edit/
But for slower distributions like Debian it definitely would be nice to have an owner-maintained Debian repository, containing the latest version of ms-edit. Like it is done for vscode.
Microsoft packages VS Code for Linux into their repos. Why not do it for 'edit'?
At least for Fedora, we really need Microsoft Edit to switch to stable Rust to package it.
You can build it with stable Rust when setting RUSTC_BOOTSTRAP=1 env variable, as mentioned in the README. Works at least on Arch with rustc 1.87.0. Don't know which version Fedora uses.
it's in terra 40 and terra 41 for fedora, but fedora 42 is already out and it can't be installed there from dnf as far as i know.
I vote against adding this to every package repository. My impression is, there is lots of time wasted, when things are maintained in different places multiple times, makes little sense to me.
I just downloaded the binary from the release page for my Debian Linux and put it in the $PATH, done. I also tend to collect / keep specific executables around in specific folder(s), also added to $PATH. Next Linux just add this folder to $PATH again and roll on.
I am a Windows user though, I don't like Linux package management, because it does not allow to install multiple versions of the same thing and also does not allow me to decide where to put the applications and executables, which results in installing "everything" again and again. Portable and "copy only" is my process of choice! o)
Thank you for this "edit", it still misses some basic things, but it's a blessing already.. o)
@tbone2k-git Maybe you misunderstand how this works on Linux. As Edit is real open source and is a fantastic program it eventually will be packaged in every Linux distribution out there. May take some time (especially for Debian) and for some distributions (again especially Debian) the package will be outdated, but it will happen, no matter if you vote against it. If Microsoft doesn't maintain these packages themselves then the community will do it.
But that does not mean Microsoft has to stop providing a ready-to-download portable Edit binary for Linux. So if you prefer downloading and installing it manually then you are free to do so. Microsoft can additionally also provide self-hosted package repositories to ship the latest Edit version to various Linux distributions, like they do for Visual Studio Code. Still that does not mean that it is no longer possible to provide a Linux binary on Github. So no harm done.
Hello @kayahr, thank you for your response. o) I think I know how it works, I was just thinking maintainers could do something more useful than re-packaging things which can already be downloaded easily.
If there would be more projects releasing binaries with sensible CLIB targets, like Microsoft did here (so the software also works on older Linux installations), a lot of packaging would not be necessary I guess? Time freed up for more important tasks in Linux or life? o)
I just "vote" for more portable kind of "installations" and for less central repo management. I like to store software "for later", download it myself, keep different versions, run it from USB or network and so on. I don't like it when the package managers dissolve applications into "the system". I use Linux because I want to have control over what happens, but if the software installation is done with an equal "high" amount of control (meaning zero.. o), like on a smartphone, I think it misses the point.
That's why I prefer AppImages in general. I can have multiple versions of an application around with these, I can run them from anywhere and they also keep their settings separated. Software distributions and packaging is a complex topic, not sure this is the right place to debate this, I just liked to tell about my opinion. o)
Have a nice day, you and everyone! o) If this is too offtopic, no problem, will shut up. o)
Commenting here after DistroTube made a video of msedit.
I hope the repo in the future will provide an official DNF or RPM package for us to install.
Why not add msedit to the Microsoft Linux Software Repository? https://learn.microsoft.com/en-us/linux/packages
We weren't aware that it existed when we developed msedit, but we've since then considered doing that.
I'm amazed that this can't be installed using apt given how many other odd installation options there are and given how many Debian-based Linux distributions there are out there.
Debian is by far the slowest distribution to get new software. They have a very rigorous process and on top of that, new software does not typically become available to stable releases, only the rolling development version (sid). On top of it, because msedit is written in Rust, it is more complex to package for Debian distributions because all the dependencies need to be evaluated and verified to be available in Debian as well.
This process ensures that their packaging is sustainable and maintainable, but it is slower than most other distributions.
Yeah, I'm aware of that. But what about Ubuntu or other distributions that use apt that are faster to release? Lack of an apt package just seems weird.
Ubuntu can also offer their own packages, they don't have to wait for Debian. But Microsoft could simply deploy their own Debian package on https://packages.microsoft.com/repos/, like they already do for VSCode and Edge. As msedit has no dependencies this will work for all debian-based Linux distributions without waiting for any maintainer to pick it up.
But they will only do that with snaps, not debs. I could see them making a snap for it.
In my opinion Snap makes no sense here because there are no dependencies to package into that Snap package. But sure, Ubuntu can decide to do nonsense like this. Their Snap philosophy is one reason I don't use Ubuntu any more...
I was afraid that Debian wouldn't bundle it due to license restrictions, telemetry, spyware, embedded AI garbage, etc. Let us hope that edit hasn't been poisoned the same way every other Microsoft product has.
Edit is Microsoft product. However yes, it doesn't have all that "shady stuff". However, earlier developers of Edit themselves said that they don't really care about any other OS than Windows. Primary purpose of Edit is to provide simple text editor for Windows console. Windows, not Linux, BSD, MacOS, anything else. So they are unlikely to make any effort to package it for anything else but Windows. Projects like Debian may have someone to create and maintain package based on the source code in the repo, like they do for many other softwares.
If you are looking for Edit analog on Linux, the closest ones (IMO) are nano and micro. I also like mcedit, which is part of Midnight Commander file manager. Just try them out, and you'll see - you don't need Microsoft Edit on Linux at all.
And of course there's vim. It is may seem harder to learn, but actually it is not, if you limit your learning to the extent of basic text editing operations - load/save file, search/replace, insert text, delete text, select/copy/paste. This is, in fact, the functional subset that Edit provides. And in the most cases (unless you are writing code) you'll not need more than these things.
Well, luckily, it looks like it is just one binary with one dependency. The ICU library. So, it doesn't seem like it should be too difficult to create a package.
I've been using nano with the config file configured for Ctrl+C, Ctrl+V, copying etc. You can use the -/ option to enable the "modern bindings." That gets close to how things work in for example Notepad. The main issue with that is that it doesn't use the system copy buffer.
edit appears that it may actually cure that problem.
I had problems with that when I tried micro as well.
Not sure how Microsoft solved that problem, but, it seems to work well, even when running it over SSH. I wasn't sure that was even possible, but, somehow it seems to work. I've only tested it using Windows Terminal, but, it seems to behave exactly how I would want it to in terms of being to copy/paste and be able to exchange data with other apps, and not just have it use it's own internal buffer.
I just found out about edit today. I'm planning on testing it on Debian with Gnome Terminal. I'm hoping the system copy buffer works as well with that as it does with Windows Terminal.
I would consider defaulting to using edit rather than nano if that proves to be true.
But, it would be nice if it were a standard tool included in the repository for distributions such as Debian, Raspberry Pi OS, Ubuntu, etc.
If Microsoft doesn't screw it up with telemetry or some other stupid thing, I could see it taking off and become very popular. I have been wanting exactly this app for decades. I'm glad to see it finally became real.
However, earlier developers of Edit themselves said that they don't really care about any other OS than Windows.
I'd like to clarify that this is strictly due to time constraints on my part. This project is unlikely to receive "funding" the way VS Code gets it for now. If it's worth anything, I can promise that it's in my own best interest that msedit works sufficiently well on Linux. I'll leave it open to interpretation as to why that is. :)
I'm planning on testing it on Debian with Gnome Terminal. I'm hoping the system copy buffer works as well with that as it does with Windows Terminal.
Unfortunately, this won't work, because libvte (the terminal library that underpins Gnome Terminal and many other terminals) do not want to implement support for OSC 52, which we rely on (and many other apps). See #345 for a lengthy discussion. I'm open to accepting PRs for OS clipboard integration in the future, once more important pieces of the application are done (e.g. syntax highlighting, settings, command palette).
If you're using Gnome, I can suggest giving ghostty a try. It's a nice, new terminal.
Another alternative if you run a wayland session is the foot terminal emulator. Implementing custom clipboard backends within edit feels like the wrong approach to me as it would for example break on SSH connections while OSC 52 even works in scenarios like terminal emulator -> ssh -> tmux -> edit. It should be the responsibility of the terminal emulator to integrate into the host clipboard system rather than the responsibility of each single terminal application.
However, earlier developers of Edit themselves said that they don't really care about any other OS than Windows.
I'd like to clarify that this is strictly due to time constraints on my part. This project is unlikely to receive "funding" the way VS Code gets it for now. If it's worth anything, I can promise that it's in my own best interest that msedit works sufficiently well on Linux. I'll leave it open to interpretation as to why that is. :)
I'm planning on testing it on Debian with Gnome Terminal. I'm hoping the system copy buffer works as well with that as it does with Windows Terminal.
Unfortunately, this won't work, because libvte (the terminal library that underpins Gnome Terminal and many other terminals) do not want to implement support for OSC 52, which we rely on (and many other apps). See #345 for a lengthy discussion. I'm open to accepting PRs for OS clipboard integration in the future, once more important pieces of the application are done (e.g. syntax highlighting, settings, command palette).
If you're using Gnome, I can suggest giving ghostty a try. It's a nice, new terminal.
I can say it gives me the warm fuzzies when I use it in Konsole. 😄
I'd like to clarify that this is strictly due to time constraints on my part. This project is unlikely to receive "funding" the way VS Code gets it for now. If it's worth anything, I can promise that it's in my own best interest that msedit works sufficiently well on Linux. I'll leave it open to interpretation as to why that is. :)
That actually sounds very good. You just need to convince MSFT management to invest a bit more into it. Also, think of getting some students-interns working on it (maybe, presented to management as Rust coding practice)... You know, famous vi editor was written by Bill Joy when he was a student...
Another alternative if you run a wayland session is the foot terminal emulator. Implementing custom clipboard backends within edit feels like the wrong approach to me as it would for example break on SSH connections while OSC 52 even works in scenarios like terminal emulator -> ssh -> tmux -> edit. It should be the responsibility of the terminal emulator to integrate into the host clipboard system rather than the responsibility of each single terminal application.
I think, finally, it's just someone has to fund implementation of specifically this particular thing - OCS 52. Would you go for funding it?
Thanks for the info. Yeah, I tried it with Gnome Terminal on Debian 13. Copy/paste didn't work at all.
I don't know what OSC 52 is, but, whatever can be done so that keyboard shortcuts in general and copy/paste work better in terminal applications would be great.
Specifically, I would really like it to get to the point where one could design an application like edit to where it could support all the keyboard shortcuts that Visual Studio has.
I think there are limitations with the way things currently work so that it isn't possible to have keyboard shortcuts like Ctrl+Shift+End, Shift+F3, etc.?
I think there is a limitation to where Ctrl+Shift+keys don't work? Or Shift with function keys?
OK, I see. So, the terminal emulators don't want to implement OSC 52 for security reasons. So, I'm assuming edit will send the sequence regardless of platform, but, the emulator is just ignoring it, so, it doesn't work? If OSC 52 opens up a security problem on Linux, wouldn't it be the same for Windows? I.e. if you SSHed into a compromised system, it could copy bad data to your local system clipboard?