No need to install it on remote systems. I'm more of a Vi guy and I have a decent selection of plugins on my primary system, but I appreciate being able to use the built in Vim features without installing stuff on remote machines.

Though Magit seems maybe a bit of a weird thing to be using on a minimal remote system.

And you can use the built-in emacs features via emacs -nw on a remote system. Core vim doesn't come with a git client I assume? So I'm not seeing the difference.

The other answer is

  apt-get install emacs-core-plus-standard-packages

or

  apt-get install emacs-core emacs-magit emacs-org-mode

i.e. people produce linux packages that set up emacs with its MELPA packages.

If we don't put stuff like org-mode and magit in emacs then the community will produce emacs distributions bundling the standard add-ons.

There's no need to install Magit on remote systems. It works flawlessly over TRAMP and I use it every day like that.

> Why not just install it via MELPA?

Specifically addressing this point (since major distros already package magit):

There are environments where it's not allowed to install software that hasn't been cleared by site/department/company IT, let alone software from a rolling repository where packages aren't signed and upstream maintainers can get code in just by tagging it on GitHub. In such an environment it's a lot easier to say something like "I need Debian 12 with build-essential and emacs26".

As cool and handy as it is, MELPA is kind of scary from a security standpoint.

That's true in terms of many Linux systems being locked down to normal users (no installing in /usr or even /usr/local). But emacs extensions install in your home directory. I've never heard of a system where users couldn't write to their own home directories.

> I've never heard of a system where users couldn't write to their own home directories.

Neither have I, but I have heard of (and been subject to) policies that don't allow installing unapproved 3rd party executable code, and have not seen one that made exceptions based on path.

I've heard of such policies, but only in the context of working for TLAs or certain high-risk positions in financial institutions.

But also, if such policies were based on (for instance) "noexec", you don't have to be able to run executables to install elisp code.

Mine was neither, just a contract gig at a crappy company.

There were no technical measures in place to stop me from compiling my own binaries (that was in part what I was there to do), and bringing my own elisp also would have worked.

Except for the "breaking my contract" part, if it was unapproved 3rd party code. Given that actual FTEs respected the rule, it seemed unwise to test it.