I recently stumbled on AWS Cloud9 and Spacemacs and genuinely impressed with both of them.
The problem is I cannot make Spacemacs to work properly on remote environment development just like Cloud9, all this time I was using VSCode with Dropbox and sync with local folder.
I tried with ftp, X window, dired remote mode (and similar Remote VSCode in the VSCode extension), none is satisfactory. I need it for all the full-blown features, remote code listing, debugging, versioning (I use mercurial).
Spacemacs is more than ok in the local development and I think VSCode just need to take a liitle more steps to rule them all.
After trying numerous solution, Samba, NFS,etc, the closest thing to Cloud9 is OSXFuse, so you can use both Spacemacs or VSCode and get local development feels. But I haven't found solution for Windows, perhaps will be less complicated.
Related
I am currently trying to set up a new development environment, using VSCode, WSL, and the WSL Remote Extension. The environment will also utilize Git, and will sign commits via a YubiKey.
I initially tested this out the setup on a Windows 10 machine, using wsl2-ssh-pageant, and that worked flawlessly. I could sign commits straight from my WSL environment, and everything was awesome. Then I tried implementing this on my work machine, which is running Windows 11... Nothing is awesome.
Apparently there are a whole bunch of issues getting something like this to work on Windows 11, and the author of that library has abandoned the project. I have tried finding an alternative, testing things like npiperelay, wsl-ssh-agent, and a ton of others (too many to list), but the issue always comes back to Windows 11 (and downgrading is not an option).
Therefore, I decided to try a different approach. I can sign commits from Windows 11, using the Yubikey, without issue. So I wanted to get VSCode to use my local Windows 11 Git installation, rather than the WSL one. However, even when configuring git path in the settings, to use the Windows 11 Git, it seems to be using it inside a WSL container, meaning the Yubikey is unreachable; so all signing fails.
I should probably mention that both WSL and Windows 11 has access to the folder.
My current workaround is to do my development in VSCode, and then do all Git commands in a Windows 11 Terminal, which allows me to do signing, but it skips all the VSCode GUI and fancy tools, so I would like to keep everything in a single place.
So my question is: Is there a way to develop in WSL via VSCode, using the remote extension, while making VSCode do all Git operations on the host system (completely ignoring WSL)?
I have VSCode set up with the "Remote - SSH" extension, and I am able to run a local VSCode window as the face of a full remote environment. Really cool.
However, I would also like to be able to set up a local VSCode environment which loads files from my local filesystem but runs them on a remote Python interpreter (via an SSH connection).
I am hoping I can run all the regular interactive Python REPL stuff using the remote kernel (e.g. show variables, etc). It seems like I should be able to somehow add a remote kernel and then select it via "Python: Select Interpreter", but I can't figure out how.
In the past I was able to configure such a setup in JupyterLab using the "remote_ikernel" package.
Is this possible in VSCode? I've found tons of documentation on the full remote setup, but haven't located information on this hybrid kind of set up.
I found a related bug report which discusses mixing local and remote filesystems (not interpreters).
I suspect that the same difficulties it describes for filesystems may be similar reasons for why local files can not be easily fed into remote interpreters.
The full thread is here for reference:
https://github.com/microsoft/vscode-remote-release/issues/706
The specific quote:
Having a mixed workspace would require that a workspace extension can be active both locally and remotely. Currently an extension can only be active once, either locally or remotely. So this is currently not possible and we have no plans to support this.
The recommendation is to have separate windows open for the local and remote workspace.
So it sound like this is a feature that is not currently supported.
I used to be a comfortable emacs user and for close to 10 years I completely got away from using emacs (I know its a shame) but I have a wage memory of setting something in .emacs to open remote files in a server via local emacs.
Just to make the scenario clear:
Login to a remote server (ssh) -> emacs somefileInRemoreServer.file &
File get open using the local version of emacs.
My questions are:
Is this possible?
how can I accomplish this?
I have both mac and ubuntu on mac I use Aquamacs. It would be a great help if I can get instructions on both versions.
I'm not sure whether you want to ssh prior to using emacs or ssh using (in) emacs.
If you want to let emacs do all the work check out the links added by phils, TRAMP mode is the way to go for remote editing IN emacs.
If you want to use ssh to mount a remote filesystem (resulting in "local" editing with emacs) you should check out sshfs (man, wiki).
I think it comes with pretty much any of the current distros (or can be installed easily otherwise). It is a fuse extension which allows to mount a remote directory to a local one without any further requirements on the remote side than ssh.
I do like TRAMP for editing one or two files but using sshfs is great for working on a whole project directory which is placed remotely and which you do not want to sync using another method.
OK< I know I can use Eclipse for Java programming and such but I work using WAMP for editing PHP, XHTML, JavaScript files... what IDE is best to edit the files and use GitHub? Because I don't know want to go to localhost and then copy my files to my local GitHub repo...
Cloud9 IDE might be what you are looking for! It's an online IDE with out-of-the-box intergration with GitHub, heroku etc. and gives you the ability to share workspaces as well.
Eclipse has the egit plugin that is really nice. You can use aptana which is based around eclipse but includes all the web views. It can basically edit everything you mentioned and really well, while providing a nice wrapper for your git repos
http://aptana.org/products/studio3
http://eclipse.org/egit/
well is not an IDE but vim with some git plugins is the best for me.
Eclipse should have some git plugins also, I think.
The best way to learn git is yo use it from command line!
Emacs + tramp + the command line ?
Update: magit is reported to support tramp
Update:
My experience: I have a distant linux server running a rails app. and private git repositories / apache (using several VirtualHosts with or without ssl). That server runs a ssh server. I use bare ssh session for command line usage (git, nominal admin.) and emacs + tramp to remotely edit the files presents on that server. I you are not rebuked by anti-eye candies tools (as for not-at-all drag'n'drop stuff), I would suggest you to give emacs a try (see EmacsW32 and nXhtml if you are under Windows). I assume you can install a ssh server on your WAMP machine… If this is the case, you could open your file from emacs just by using the following syntax (assuming you would edit the /home/renaud/.bashrc on the distant server):
/ssh:user#obf.uscatedmachine.org:/home/user/.bashrc
With putty on windows: see that and this posts.
It works the same for directories. You shall be prompted for your password once, and then edit the file/directory as if it is just on your machine. For the git part, I have verified myself since I do the git stuff directly from a ssh terminal, but latest magit
is reported to support tramp (i.e. remote git plumbering from my understanding).
If you have never used emacs before, it will not be easy. You will have to learn emacs basics first and customize it to fit you needs. My opinion is that's worth to give it a try. I could help you with basic configuration if needed.
(I use myself emacs almost for everything on my linux box from simple text editing to Java programming.)
Update:
After some testing, magit works very well remotely (tested on linux)! A new mode added to my configuration thanks to your question!
On a daily basis I:
use multiple workstations running either Linux, Windows, or MacOS X
edit files on additional Linux hosts that are not any of the workstations mentioned above
The only common element here is that the internet connects all of these hosts: workstations and servers. I can keep all of the config files in sync on my workstations too and can run an X server on all of them. What's the right way of running emacs? I don't want to sacrifice any features.
In my ideal world I can type 'emacs foo.txt' on a remote host and some magic happens via X forwarding to display the file in my workstation's existing emacs session.
Non-solutions
tramp: when I'm manipulating a remote host an editor is just part of my workflow. I need a terminal open so I can run other commands quickly. tramp is all wrong for this.
ncurses emacs: sucks, I want the graphical kind
If you don't have a positive answer to my question, please don't just guess. Thanks.
Have you tried tramp with eshell? You can "cd /remote.host:/some/path" and edit files from there, and if you type a non-built-in, it fires up a ssh pipe to run it. Quite slick.
I fail to see why tramp is not a solution. You can edit using tramp, and do whatever you need in a terminal using xterm+ssh.
Well, if you can setup X clients on your Windows and OSX boxes, you should be able to run an X version of emacs on any of those platforms and set the display back to your workstation. That would give you your nice WIMP interface.
However there are a couple of solutions to keeping a terminal open to the same box. One is to just telnet into it twice. Once for your emacs session, and once for a shell.
The other option of course is to use meta-x shell to bring up a shell buffer inside of emacs. A true emacs guru prefers to run their OS inside of emacs, rather than the other way around. :-)
The approach I use is based on source controlling the Emacs scripts and important common files (using Git). This gives me a consistent code base so I don't have to remember which host has which script or file (or version of what I'm looking for). Git is particularly well suited to supporting this mechanism and I've pretty much got in the habit of updating the master origin repo daily. Within the scripts (both Emacs and bash shell scripts) I use machine tailored code to handle local requirements. This system has been in place now for well over a year and I find it to be quite effective. This is a technique I've seen recommended for some number of years. I found it clunky with CVS and Subversion but git feels tailored for the job. That said, I like the solution you selected as a complimentary tool and look forward to adding that to the mix.