Right, and last I checked people weren’t remote working too much before the 21st century.

If your job doesn’t want to train you properly that’s on them, but assuming all parties involved are acting in good faith I will always go to the office to train a junior employee.

I work 80 % remotely, I know what I’m talking about. MS Teams is by far the worst latency-wise, but even on the best software you can’t get over the fact that there will be a 200-300 ms jitter buffer.

Ever had the “yeah I- so we - OK go ahea- sorry -”? That’s what I’m talking about.

Good on your daughter if she learns well remotely, but literally everyone I’ve talked to who was in education during COVID had an awful experience. Although I suppose in the school system it doesn’t matter as much since with 20-600 students per teacher there’s not much back-and-forth going on anyway.

Remote work is great for focusing, it’s great for async workflows (slack/discord/email/jira), it’s great for solo work, but it’s just plain inferior for certain highly collaborative workflows like 1-on-1 teaching. There’s enough good reasons to work remotely that we don’t have to lie about the rest.

Yeah sorry but that’s not the same. Efficient teaching is very highly dependent on nonverbal cues to properly align yourself to the person you’re teaching to. On top of that screen sharing software is clunky and necessarily has latency, which makes interrupting much more disruptive which is most detrimental when there needs to be a bidirectional high-throughput stream of information.

Sorry, I didn’t log into this account for a while.

Anyways, I guess in an ideal world the window management could be done fully via the window manager. In practice this doesn’t work too well, because that would require a more complex protocol than currently exists. For VSCode for instance, that would require disabling the native tabbing feature (but keeping the native splitting because otherwise I’ll end up with duplicated panes such as the file list) and implementing something custom to translate tab operations to sway-wm operations (in my case).

I guess it could work but it’s not supported OOTB, and after a lot of work is probably going to end up being a lot more clunkier than what I have going on in vim.

You mean a whole different window at the OS level? That’s just a way inferior hack to the way vim does it by default.

I’ve found an issue from 2017 about it and this related one that focuses more specifically on supporting vim-like behavior. This is just, fundamentally, something that VSCode doesn’t implement simply because of technical limitations. The extensions that attempt to recreate this behavior are apparently all quite janky.

I mean I don’t care, I’m very happy with vim now. But the terribly naive tab support is the reason I left vscode for vim initially. People who have only known “vscode-like” tabs don’t know what they are missing out on.

No, literally have one tab with multiple windows inside it (the default for vim).

  tab 1  |   tab 2   
w1 | w2  | w1 | w2
w3 | w4  |    w3   

Electron has other drawbacks than performance as well.

The big one for me is that my workflow is based on vim, where you split tabs into buffers. There is no way to split a tab into windows in VSCode. Only windows into tabs, which is super dumb and annoying because related files are never shown together unless you click a bunch of tabs. Apparently the reasoning for this insane behavior is “yeah well electron is based on chromium so tough luck we can’t do shit”.