The fact that it is easy to confuse the server with the client in X, it does not change the fact that the XServer and XEmacs are running on different computers, so each interaction is a round-trip.
There’s some confusion in some of the replies here. The point this person is trying to make is that you get the remote machine’s key bindings, not the local’s. That’s an artifact of the experience being a remote desktop.
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
I'm sorry to say I'm as confused as I was before I read these sentences.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
What does it mean "more powerful" ? Do you mean in terms of productivity ? It probably depends on your task anyways. In 2023, it's still a pain to have decent debugging in Vim. For pure text editing, I can believe you, but for software development, I highly doubt it.
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
Emacs can edit files remote to where Emacs runs with e.g. TRAMP. Emacs can also run remote to where the X server runs. Those two are entirely orthogonal to each other.
> This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server
No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.
> You were making a round trip to the server when you moved the cursor or selected text.
Of course this being X, your machine ran the server and the remotes were the clients…
No, as gummy well putted it, all of that was done on the client computer.
The fact that it is easy to confuse the server with the client in X, it does not change the fact that the XServer and XEmacs are running on different computers, so each interaction is a round-trip.
3 replies →
There’s some confusion in some of the replies here. The point this person is trying to make is that you get the remote machine’s key bindings, not the local’s. That’s an artifact of the experience being a remote desktop.
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
You still had to do a roundtrip for every single click though, right? I don't think X Windows has any kind of client side scripting system.
That's better than SSH for sure, but still not as good as the web model.
X Windows server runs on the client machine.
The client is the server application.
The point still stands, though. You need a roundtrip, even if it starts from the X server rather than the X client.
13 replies →
I'm sorry to say I'm as confused as I was before I read these sentences.
Let me try to rephrase: with X Windows, the UI server runs on your local machine, while the UI client runs on the remote machine (e.g. your application's server). Is that correct?
4 replies →
Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.
As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.
What does it mean "more powerful" ? Do you mean in terms of productivity ? It probably depends on your task anyways. In 2023, it's still a pain to have decent debugging in Vim. For pure text editing, I can believe you, but for software development, I highly doubt it.
> Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.
I absolutely agree, assuming you're using "powerful" in the same sense as saying that a Turing machine is more powerful than a MacBook.
Vim is a text editor, not a code editor. It has always been fundamentally designed this way.
Vim has many features that do not belong to a text editor, like `:make`, `gd` or even QuickFix.
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
https://code.visualstudio.com/docs/remote/remote-overview
Emacs can edit files remote to where Emacs runs with e.g. TRAMP. Emacs can also run remote to where the X server runs. Those two are entirely orthogonal to each other.