Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Theia – One IDE for Desktop and Cloud

typefox.io

Post reply on HN
Print view View original

21–30 of 61 posts

Re: Theia – One IDE for Desktop and Cloud

#21

Post by fiddlerwoaroof »

hexa00 wrote: post #15
tbirdz wrote: post #14

Earlier quoted context omitted.

How about emacs in tramp mode? Or even mounting the remote file system with sshfs and using whatever editor you had installed locally?

Theia does not only provide remote file access you also have LSP (language server protocol) for code-completion / docs ala eldoc , company) etc.. Almost all of Theia's features are based in the backend. The emacs equivalent would be like having emacs in daemon mode and a tcp based emacsclient locally. (I wish that existed) Also the idea is to have something a bit more modern and appealing to the mass of javascript/we…

Theoretically, couldn't you use socat and ssh tunnels to proxy the emacs server to another machine?

Re: Theia – One IDE for Desktop and Cloud

#22

Post by hexa00 »

stephenr wrote: post #18
hexa00 wrote: post #17

Earlier quoted context omitted.

The problem with the JVM is that the UI toolkits are dying or died already. Having the web as UI layer brings much benefit and reduces the investement needed in the UI. IDEA will most likely hit that problem at some point also...

JetBrains apps look & behave mostly native on macOS. There are some discrepancies, but they're pretty close. Building the entire UI in a webview means you're never going to get platform integration. No standard menu bar, no services integration, no remapping menu shortcut keys, no automatic "find command" in the Help menu. Edit: s/look/look & behave/

That's not entierly true since Electron provides native elements like menus for example. We can hope Electron will get better at a native experience and can contribute to that too. See https://electron.atom.io/docs/tutorial/desktop-environment-i...

Re: Theia – One IDE for Desktop and Cloud

#23

Post by rapala »

simark1 wrote: post #9
michaelbuckbee wrote: post #3

I realize it's super early, and this look interesting, but I'm unable to figure out if "cloud" in this case means: - Runs in a Browser for the purposes of editing files locally or - Runs in a Browser and we have a whole backend way of spinning up a VM/Docker/something for you to do things with as well (The new defunct https://www.nitrous.io/ did this so you could do things like remotely run pg, your Rails stack, etc.…

There's nothing that prevents you from doing the first one, if for some reason you prefer working in the browser rather than in some Electron application. For fully local scenarios, it is expected that it will be able to work like a standard editor: you just launch it and work, you don't have to be aware of this frontend/backend separation. The use case I am interested in is the following: at my company, code has to…

It's off-topic, but I just have to ask. Why? Why would local copies be disallowed?

Re: Theia – One IDE for Desktop and Cloud

#24

Post by hexa00 »

fiddlerwoaroof wrote: post #21
hexa00 wrote: post #15

Earlier quoted context omitted.

Theia does not only provide remote file access you also have LSP (language server protocol) for code-completion / docs ala eldoc , company) etc.. Almost all of Theia's features are based in the backend. The emacs equivalent would be like having emacs in daemon mode and a tcp based emacsclient locally. (I wish that existed) Also the idea is to have something a bit more modern and appealing to the mass of javascript/we…

Theoretically, couldn't you use socat and ssh tunnels to proxy the emacs server to another machine?

So emacsclient/emacs deamon work with a tty, basically emacsclient opens a tty and sends it to the emacs deamon and it uses it to send output/receive input, so you really need to be local there's no way that I know to forward a tty on the network.

The local socket opened is used only for configuration between emacs and emacsclient see: https://github.com/emacs-mirror/emacs/blob/master/lib-src/em...

Re: Theia – One IDE for Desktop and Cloud

#25

Post by romanovcode »

oelang wrote: post #20
romanovcode wrote: post #19

This clearly uses many parts of VS Code source code. So the question is - why bother creating another inferior to VS Code editor? AFAIK you can run VS Code on cloud without problems since it's Electron to the core.

Well you're wrong, you can't run VS Code on the cloud.

https://microsoft.github.io/monaco-editor/

Re: Theia – One IDE for Desktop and Cloud

#26

Post by [deleted] »

rapala wrote: post #23
simark1 wrote: post #9

Earlier quoted context omitted.

There's nothing that prevents you from doing the first one, if for some reason you prefer working in the browser rather than in some Electron application. For fully local scenarios, it is expected that it will be able to work like a standard editor: you just launch it and work, you don't have to be aware of this frontend/backend separation. The use case I am interested in is the following: at my company, code has to…

It's off-topic, but I just have to ask. Why? Why would local copies be disallowed?

[deleted]

Re: Theia – One IDE for Desktop and Cloud

#27

Post by hexa00 »

rapala wrote: post #23
simark1 wrote: post #9

Earlier quoted context omitted.

There's nothing that prevents you from doing the first one, if for some reason you prefer working in the browser rather than in some Electron application. For fully local scenarios, it is expected that it will be able to work like a standard editor: you just launch it and work, you don't have to be aware of this frontend/backend separation. The use case I am interested in is the following: at my company, code has to…

It's off-topic, but I just have to ask. Why? Why would local copies be disallowed?

To prevent someone to copy it all on a laptop and sell it for example.

Re: Theia – One IDE for Desktop and Cloud

#28

Post by hexa00 »

romanovcode wrote: post #25
oelang wrote: post #20

Earlier quoted context omitted.

Well you're wrong, you can't run VS Code on the cloud.

https://microsoft.github.io/monaco-editor/

Theia is using monaco. But there's other reasons for Theia too like the governance of the project, vscode is controlled by Microsoft and they may have conflicts when lets say some feature would compete with their visual studio offering.

Theia wants to be free from those problems.

Re: Theia – One IDE for Desktop and Cloud

#29

Post by hexa00 »

hexa00 wrote: post #24
fiddlerwoaroof wrote: post #21

Earlier quoted context omitted.

Theoretically, couldn't you use socat and ssh tunnels to proxy the emacs server to another machine?

So emacsclient/emacs deamon work with a tty, basically emacsclient opens a tty and sends it to the emacs deamon and it uses it to send output/receive input, so you really need to be local there's no way that I know to forward a tty on the network. The local socket opened is used only for configuration between emacs and emacsclient see: https://github.com/emacs-mirror/emacs/blob/master/lib-src/em...

Just found out http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt

So it seems possible with socat indeed, I'll have to give it a try :)

One problem that I see however is that emacsclient also forwards signals to emacs when the window changes size for example, I don't think that will work with socat

Re: Theia – One IDE for Desktop and Cloud

#30

Post by mixedCase »

hexa00 wrote: post #28
romanovcode wrote: post #25

Earlier quoted context omitted.

https://microsoft.github.io/monaco-editor/

Theia is using monaco. But there's other reasons for Theia too like the governance of the project, vscode is controlled by Microsoft and they may have conflicts when lets say some feature would compete with their visual studio offering. Theia wants to be free from those problems.

Not "may", it's already happened.

There's two versions of VS Code, the "official" one and "Visual Studio Code - Open Source", and the former contains proprietary bits that are kept that way so other people don't use it to compete with VS.

Project Rider from JetBrains accidentally ended up including one of these bits unaware it was part of a proprietary license and had to remove the functionality that depended on it (CoreCLR debugging), later writing a new implementation to put the feature back in.

This blog post by JetBrains includes a few more details: https://blog.jetbrains.com/dotnet/2017/02/15/rider-eap-17-nu...

Post reply on HN