A lot of these issues can be solved with enough extra work setting everything up - but that completely defeats the point. "no setup, no hassle" is never my experience.
A lot of these issues can be solved with enough extra work setting everything up - but that completely defeats the point. "no setup, no hassle" is never my experience.
Have I got news for you https://code.visualstudio.com/docs/remote/ssh
Funny enough, your description is exactly how I work, except the java part, but then vscode doesn't have an edge with java either.
Maybe, with a lot of effort to set it up like that, and a steep and long learning curve with lots and lots of idiosyncracies, because it's really ancient tech that was made for a completely different kind of computer, and you have to actually like living in a terminal and vim's idiosyncracies in particular.
1. Ability to open up any sized file. Anyone who accidentally clicked on a 15mb log file in the directory know what I'm talking about.
2. commands, specifically %s, norm, etc applied over visual mode. norm is particularly powerful when you want to batch edit.
3. macros, the ability to define macros both beforehand, and on the fly is really useful.
4. Availability. Any linux box I ever sshed into has never failed to have vim.
^^ Those are the features that imo are important and won't be available as a vim plugin to other IDEs. People also don't realize how vim has these feature that matches other IDEs.
1. Plugins, the vim plugin world is as rich as other IDEs like vscode.
2. language servers, these can run in the background and provide autocomplete, code smell, e.g. jedi, tsserver-vim.
There's things to be said about it being closed source, but it _definitely_ also removes, IMO, the pain points of remote editing.
check coc.vim, uses vsc's native LSP, 99% of LSP's features
> delaying keystrokes
I have 16ms latency as my 60hz screen does and def less latency than a local vscode
just use a vps close to where you are
Nothing wrong with that - it's a matter of taste. But personally the reason I often work over ssh connections is that I find the local-only development experience deeply deficient. I package up environments in containers that I can bring up anywhere by dropping in a systemd unit file to pull the images, which means I don't have to worry about whether I have my laptop with me as long as I have ssh access, or about environments changing when I switch laptops. I can also bring those environments up in containers on my laptop, of course. Once I got into the habit of packaging up everything that way it became easy to do, and keep cutting down on the setup effort when I change laptops or make other changes.
The flexibility to be able to access the same environment and editor anywhere is an important reason why I insist on using editors that work in a terminal, because that flexibility is far more important to me than any specific editor features. While most of the time I work locally, when I need to ssh in somewhere, not having to deal with a different environment matters. And ssh vs. entering a container is a close enough equivalent that the same workflows apply for the most part.
Last couple of years I've used my own client-server based editor that holds all the buffers in a separate process (and traps all exceptions and forwards them to the client, and checkpoints its internal state - I have a couple of years worth of open buffers in RAM, but it just adds to ~24M), because I wanted an editor I could get exactly how I wanted in exactly the language I wanted, and it was worth it.
Lag is an issue if on a slow phone connection or something, but you surprisingly quickly get used to working even with ~100ms+ lag, and that's a rare exception. As long as you pick a VPS provider reasonably close 15ms-30ms is not hard. I'm in London, and mostly use Hetzner in Germany, get consistent <20ms to them. It's not noticeable when I log into them. There are few places in the world where you can't find VPS providers close enough. Of course it depends on having decent internet access, so I'm sure there are places that isn't viable. That said, years back I worked over SSH from Beijing to servers in Texas, and even that worked well enough despite the lag.
And if you work on things remotely, you quickly get used to download things straight to the remote machine rather than download and copy over whenever possible, and it usually is possible - wget, curl, lynx and links can take a while to get used to, but it's rare I need to resort to downloading anything locally. Not that it is usually a problem if I do, but of course more dependent on upload speeds.
Pointing a local browser to a remote machine requires no setup, just knowing the IP. If you want an encrypted tunnel, all it takes is a flag to your ssh client to port-forward. First thing I'll do if I need to do work against a remote server regularly is to set up an alias in .ssh/config to pass the right options.
Similarly setting up autossh or similar to automatically re-establish ssh connections (and re-attach to screen or tmux) is a simple one-time affair if you often need to re-attach, but if you run screen or tmux anyway (and I couldn't imagine not doing that on any machines I do actual work on), it's trivial to re-attach to the same state anyway. I run bspwm - a programmable tiling wm, which also means I can easily set up workspaces where it automatically triggers suitable scripts to set up the right windows ssh'd in to the right screen sessions on login, as well.
It's true some of this is extra work, but it's extra work once and you have setups you can copy everywhere, and there's extra work to get used to any new tool, but once you get used to these workflows they are extra-ordinarily flexible, not least because they're also scriptable in ways that allows you to add more and more customised shortcuts for the things you do regularly in a lasting way.
I've carried my current client-side set of configs and convenience-scripts through half a dozen laptops by now.
I find shell environments incredibly limiting, I feel like my visual brain starves when limited to what feels like a visual desert to me for longer durations. Yes, there are a couple of things they absolutely excel at, and I use the shell for those, have one open all the time in a window – but everything else? Not my cup of tea. I'm a fairly visual person and I like manipulating things directly, I like visual cues, I like discoverable software, I'm into well-done(!) motion cues big time. I like using the mouse. I may have to hand in my hacker card after writing this.
I like how IntelliJ shows a million small annotations and cues that terminal just can't possibly support, how I can just stumble over features via the UI. I like how graphical text editors aren't just a featureless wall of text, that there is a UI for the eye to use for structure, that I usually have much more information immediately visible, and that the UI allows me to do things without having everything in my head or looking it up in huge manpages that often as not are hardly fit for for human consumption.
Lots of things I do wouldn't even be possible in a shell, like graphics/design work, 3d modelling, spreadsheets, and the rest wouldn't be much fun. Yes, I'm sure there is a way to do complex 3d modelling in emacs. No, I don't think that will work for me. Yes, I've tried vim and neovim and emacs, and I really don't like their paradigm.
As to what has been lost, I firmly believe I've gained much, much more, and I doubt I personally have actually lost anything substantial, but maybe we won't agree there. Not being bare-metal all the time is an advantage in my book; I've done some bare-metal and it isn't for me, huge respect to those who work with assembly all the time. A shell isn't very close to the metal for me, it's a really heavyweight, very idiosyncractic abstraction over bare metal, once you peel apart all the layers in between, it just makes it easier to manipulate other heavyweight abstractions directly. What I've learned in years of doing lots of work in shells is mostly limited to idiosyncracies of the shell I'm using (so far fish, sh, bash, a bit of zsh) and the various tools involved; especially macOS doesn't expose that much of its internals via the shell, not that much to be learned there.
Why stop at that level of abstraction, though? Why not put something on top that allows me to use all those areas of my brain that do complex visual and motion stuff? I strongly feel those are still way under-utilized, or rather badly over-utilized, or mis-used in general in all current mainstream GUIs; maybe that's why some people prefer theirs to be extremely simplicistic. Better use of motion might involve less motion than e.g. macOS currently has, but applied way more judiciously and effectively, possibly with a solid neuroscientific backing. Reality isn't a solid monochromatic wall of even-sized glyphs, why would UIs have to be?
Sadly, the only place where I feel motion in UIs is done well currently is the very rare game that gets it just right, but those paradigms wouldn't translate well to productivity UIs. But while not ideal by any means, I still find the macOS UI to be way ahead of any terminal UI in that respect; iOS even more so, but I can't use iOS devices for day-to-day work, not yet at any rate. I gather it's the other way around for some people, which is fine of course. You do you, and I stick to my animated GUIs, and I hope someone will figure out why we see these things so very differently some day, and we'll be able to make new things work better for all of us with that knowledge.
Another thing, discoverability and rich input. Take the Touchbar, fantastic thing – I'd absolutely love to have an external one that I can attach to my mechanical keyboard. With the touchbar I can do all sorts of stuff right away (in apps that support it) that I'd have to memorize arcane key combinations for otherwise; I hate doing that. IntelliJ supports the Touchbar pretty well. It can double as a sort-of analog slider, without any finger smudges on my main display like on Surfaces with touchscreens (though that's neat too – love to do this on the iPad). There are menus that contain pretty much everything an app can do, on macOS they're even searchable. I'm sure there are ways to replicate some of that in shell environments, but I doubt it would get very close – and then I wouldn't want to invest hours and hours to set it up like that, because, in the end, my visual brain would still starve. I've toyed with using my iPad and Pencil as a graphics tablet via Sidecar; I'll definitely do a lot more of that in the future. I wish there was a collaborative whiteboard app that supports this really well and also can get approved at my work. That would get close to whiteboarding my thoughs like I do all the time in the physical office, another thing I can't translate to a terminal workflow at all, I can't even translate that to a graphical workflow without a physical pen or similar.
I get that a higher-stimulus, "richer", more immersive, more physical user experience is the opposite of what some desire, but I believe there are lots of people who enjoy that sort of thing, when done well. I realize there are lots of upsides to shell environments as well (super stable software, highly portable, runs everywhere, relatively consistent, highly configurable unless you want anything not made of solid glyphs, etc. pp.) but those just don't rank all that high for me. Like, I have my Macbook set up the way I want it, I can move everything to another one just by restoring from backup, I don't need everything to be highly portable. I rarely work on remote machines – one of the upsides of doing everything as infrastructure-as-code, and when I do, it's via JupyterLab and the like.
I work almost exclusively in a terminal, but I never work in "a solid monochromatic wall of even-sized glyphs". Well, I usually use even-sized glyphs, but certainly not walls of them, and I rely heavily on tools that use unicode creatively to annotate text and colours.
Terminals have been able to handle graphics of various levels for decades (e.g. Sixel and ReGIS), though unfortunately it's not as widely used as it could be. E.g. my repo contains a script in bin/ to spit out images to the terminal using Sixel, which makes it transparent to ssh.
But the point for me at least is not an objection to graphics, but an objection to not having a command line to manipulate everything. Including graphics when I use it. And an objection to being unable to access data and code remotely without taking special steps.
The terminals gives me that.
It's not at odds with graphics at all. But it's add odds with a focus on graphics at the expense of function. And it's at odds with accepting a world where your app and your user interface needs to live on the same machine.
here I agree. these just don't work in the shell. but too many programs are gui-based which shouldn't be. a shell is the foundation for coding and the reason, so many non-tech people think of coding of some wizardry is the lost of the shell. Remember DOS and that .bat files. Latter were not more than some batched commands and eventually a program.
Stuff like settings, task manager, text editors, any kind of servers, should be text based. Everyone is 100x times faster skimming through VSCode's text based settings than Blender's preferences. I am not against GUIs but less of them.