Nah, I've seen people downloading their preferred configs right to the production server, because they, understandably, feel more comfy with that.
But, it may not be for everyone.
Where I work, we are in the process of reaching some compliance targets, and all this downloading unknown stuff from unknown servers is out the window. For the best, I think.
Wouldn't this represent 0.1% of your usage? Meanwhile the thinking portion is 99% of the job and the act of using the UI to enact the changes on any editor is the other 1%.
Making 1% of 1/10 of 1% more effecient seems like a curious optimization.
Honestly, if you have to hop on production to debug a crazy error, you have two bugs. The infrastructure being so different on production compared to development or local is a fixable issue. As are any other differences between production and local that make difficult to debug in these special cases. It takes a long time. It's a substantial effort. But it is worth while.
It may seem that way, but no I've crossed that chasm long ago. I've debugged on production more than I would ever care to remember. But in all honesty it is easier than ever to stay completely off of production. It's also extremely cost effective. It's not simple and it is work, but it has never been easier to actually be successful at staying off if production.
People need to stop editing directly on servers. Vim's netrw can write out over scp, use your configured vim on your desktop to edit the files on the server.
The problem is browsing files, for me. I can't use fzf, nerdtree, nnn.vim, whatever. I much prefer sshfs and treating the remote file system like a local one.
But I'm not really familiar with netrw other than just:
This is one of the reasons my preferred implementation of Vi is Evil -- the TRAMP network layer in Emacs does exactly what you want: let you treat any remote file system as local. It even does multi-hop access through e.g. bastion machines. It is great.
