I currently use MINGW64 (Git Bash) as my terminal on my Windows 10 machine. It works great, I like it, but it only has Vim installed as an editor and I prefer Emacs. I'm unfortunately having a really awful time getting it to work in my terminal.
What's weirder still is that I have Emacs working in Cygwin64; but I don't like using that as my terminal. The most logical fix is simply that it Emacs to my Path ENV, however that doesn't seem to help (perhaps I'm doing that wrong?). I just get bash: emacs: command not found. I found a command to install it, using Pacman, however the Pacman command cannot be found either (which is weird because I thought that was installed by default with MINGW64.
Would love any and all help on this.
A couple of options:
Use Cygwin and the Cygwin emacs. Consider your Cygwin environment completely separate from Windows, so set your PATH from within the .bashrc, not within Windows. Launch emacs from the bash command-line.
Use the Emacs Windows binary distribution, but point to the utilities within Cygwin (there's an emacs package to help with this). Again, launch from the bash command line to inherit the bash environment within emacs.
Use the Windows Subsystem for Linux, with a Linux installation, and stick with emacs from there. You get the best of the Linux world, and access to the Windows directories and files as well.
My goto choice for MANY years was the Emacs Windows binary in conjunction with Cygwin. Once I started using the WSL, however, it just worked a lot better, in a clean Linux environment, and I could get terminal and GUI emacs (and other apps) running using the VcXsrv X Server. WSL has a version that directly supports X Windows, but I don't care for the windowing environment it uses, so I stick with VcXsrv.
Related
Usually, on Windows, I use PowerShell (default shell) to call a Bazel command such as bazel build. As far as I understand Bazel makes use of MSYS2 to call and execute commands such as curl, zip or git for instance. Therefore, I wonder if I should use the MSYS2 bash terminal instead of PowerShell. Can there be any problems when using Powershell instead of the MSYS2 bash terminal? Or doesn’t it matter?
As its mentioned here by developers of bazel, using MSYS or MSYS2 is the best choice. Personally I prefer MSYS* over cmd or PowerShell for any thing.
In the current master there was recently an update of the documentation exactly about this issue:
As of 2020-01-15, we do not recommend running Bazel from bash – either
from MSYS2 shell, or Git Bash, or Cygwin, or any other Bash variant.
While Bazel may work for most use cases, some things are broken, like
interrupting the build with Ctrl+C from MSYS2). Also, if you choose to
run under MSYS2, you need to disable MSYS2’s automatic path
conversion, otherwise MSYS will convert command line arguments that
look like Unix paths (e.g. //foo:bar) into Windows paths. See this
StackOverflow answer for details.
I just started with VS Code today as I have to prepare to port some of my code to Linux and I noticed that in the Terminal section there is the option of having a WSL bash, so I thought I could use this to compile my projects with gcc right there. I already installed Ubuntu for Windows 10 from the MSFT Store some time ago an installed several packages there. The thing is that the Ubuntu bash doesn't seem to share to the Linux workspace with the bash I see in VS Code, since in the latter I am lacking all those packages I already installed; it seems to be a completely different installation. Also, I noticed that the bash in the VS Code terminal uses German language while the Ubuntu App's bash is in English. (I have no idea why this is since Windows as well as VS Code is English.)
I'm quite confused about these differences, how do ubuntu.exe and bash.exe relate to each other? Can anybody shed some light on this? Obviously, it would be preferrable to to have only ONE Linux workspace in WSL so I don't have to have duplicates (of my data and also the installed packages) at different places.
To use WSL bash in VS Code integrated terminal, you need to add/change setting:
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\bash.exe",
Restart VS Code or integrated terminal.
If two or more WSL distro are installed, then you need to specify the path to the desired distro.
For example you can find it by running: where ubuntu, where ubuntu1604 or where ubuntu1804. And change the settings to the desired ones. For example:
"terminal.integrated.shell.windows": "C:\\Users\\USERNAME\\AppData\\Local\\Microsoft\\WindowsApps\\ubuntu1604.exe",
I've been using the CoqIDE plugin for Vim on Linux machines for editing Coq files. Now I'm trying to install it on Windows 8. But when I try to source the plugin, I get
Your vim doesn't support Perl. Install it before using CoqIDE mode.
which is strange, because with :version I clearly see +perl/dyn included. Is this different from the +perl that I need?
I heard somewhere that you need to have Perl installed before Vim to get a Perl-enabled Vim, so I tried that as well. I uninstalled Vim, installed Strawberry Perl 5.18.2.2 (64bit), and reinstalled Vim. Still the same problem.
If the solution involves manually compiling binaries, I would really appreciate detailed instructions as I don't have any experience with it.
+perl/dyn just specifies that Vim has been compiled with dynamic Perl support; it doesn't yet check that the Perl library can be loaded successfully. To do that, try executing a Perl command, e.g.:
:perl VIM::Msg("Hello")
This probably yields on your system:
E370: Could not load library perl510.dll
Sorry, this command is disabled: the Perl library could not be loaded.
Next, you'd then have to investigate whether a proper Perl version has been installed and the DLL is accessible (though the PATH).
Download DWIMPerl for windows. I'm running win7 64 and gvim 7.4.2. Using strawberryperl and activeperl resulted in :echo has('perl') to yield 0. By switching to DWIMPerl (and ensuring my PATH env variables are proper) :echo has('perl') now yields 1 using the standard gvim distribution. This is important for vim extensions like dbext which require proper support for perl interfaces.
I have recently installed cygwin as I want to use (and learn) emacs and make it my regular text editor (as I use Notepad++ now).
The motivation for this comes from some sites like this:
http://batsov.com/articles/2011/08/19/a-peek-at-emacs24/
Also, I want to learn the internals of linux. I tried vi but its too CUIish for my taste. So I installed cygwin (with it's default emacs 23.3). But I wanted to try emacs 24 too so I want to install it side by side with cygwin's emacs 23.3. This can be done in a linux distro by installing emacs in /opt and making symlinks. But how do I install emacs binaries in cygwin?
From where do I get such binaries.
Currently I am using 'Emacs for Windows' seperately from cygwin, but it is hard to get it in a portable format. If I manage to install it in cygwin then my whole cygwin environment can be portable.
I generally try to install softwares so that they are portable as far as possible.
You can use the setup.exe that you used to install cygwin, to install Emacs as well.
I can't figure out why this isn't easy to find on Google, but after searching for about 10 minutes, I just decided to give up and post here.
The subject basically says it all. I'm running MinTTY as a cygwin terminal on a Windows XP desktop. All I want to do is have emacs open up in a new window rather than inside my terminal. What would be best is a switch for this, so I could toggle it depending on my current needs. This seems like something that would be useful to a lot of people, and I know I've done it before on Linux boxes, so I imagine there must be a way to do this in cygwin too. Anyone know how?
Just start a new mintty, telling it to invoke emacs:
mintty emacs
There are a couple of scenarios that you might clarify:
Running the cygwin version of emacs within a standard windows environment will call emacs within the current shell
If the Cygwin X-Windows server (i.e., “XWin Server”) has been started and the DISPLAY environment variable has been set in the mintty terminal (e.g., export DISPLAY=":0"), calling emacs will start it in its own window.
running the Windows version of emacs within the cygwin terminal should launch the new frame you are seeking.
If you want a separate emacs 'window', you would be best served by installing the Windows native version of emacs (I use the gnu emacs precompiled binaries), and calling it from the cygwin terminal.