How Can I Get MinTTY (Cygwin Terminal) to Open Emacs in a New Window? - emacs

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.

Related

How to get Emacs on MINGW64 (Windows 10)

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.

VSCode on Linux Mint, integrated terminal not able to type anything

Hi I'm running Linux Mint 19 and I have just installed vscode using the snapd package manager. I've not used vscode on linux before as my usual editor is emacs. However, on a fresh new install of vscode, the integrated terminal does not work, there is just a non blinking cursor in the top left of the screen, but no prompt and no keyboard strokes are registering. This appears to be a common problem as there are a lot of posts about it if googled, but they are all for Windows versions and none of the solutions that I'm able to try do anything. I've tried to open a new terminal window, but the same thing happens I just get two terminal windows that I now cannot use. I've also tried checking the box that says Code-runner: Run In Terminal, but that does nothing either. What can I do to get this to work please, I looks to me like it is just not connected to either a bash or Zsh(which I normally use). Any help on this would be appreciated.
Instead of starting vscode with its default shell script (usually located on /usr/share/code/bin/code), the integrated terminal only works for me when starting it directly from the compiled binary (typically found on /usr/share/code/code, which is the same as the launcher created by the installer:
/usr/share/code/code --no-sandbox --unity-launch %F
While I searched for a solution in the past I've also noticed that lots of folks solved similar problems just by adding --disable-gpu flag, so might be worth checking out as well.

How to use rlwrap in Gauche running on emacs in MinGW?

I am new to Scheme, and using gosh running on emacs buffer, in MinGW on Windows. It seems that people use readline or rlwrap to use history and more, but I still cannot figure out to accomplish the setting. Though it may be easy to run one on Linux using virtual machine, I would stick to Windows for now. Any idea or alternative suggestion?
An Emacs buffer is not a real terminal, and rlwrap will not run in it. However, this is no tragedy: almost all of rlwraps goodness can be had directly from Emacs (you could use one of the existing scheme modes, or even Emacs-gosh-mode)
If you insist, Emacs can provide a terminal emulator for you (M-x term) in which rlwrap will feel right at home.

Emacs on Windows disable cmd

I've always used Emacs under Linux, but now I got a Windows machine and installed it.
However, every time I open Emacs it also opens a terminal (called cmd.exe on Windows, I think). Is there a way I can disable that terminal?
Thank you.
If you got the GNU version of emacs for Windows from here: http://ftp.gnu.org/gnu/emacs/windows/, there is an .exe called runemacs.exe. Use that instead of emacs.exe. "runemacs" will not pop up the annoying cmd window.

Running Emacs Remotely between several machines

I use Emacs remotely using X-Server in a Windows client and Linux server. I noticed that I can halt it using ctrl-z and then type fg 1 to get it working again. Is there some way that I could get it to halt on the machine that I am on, and then log into a different machine and start where I left off? When I start a new ssh session, the emacs job isn't associated to my terminal. There must be someway to "steal" it.
Also, maybe there's an Emacs feature that will do basically the same thing. However, I think closing and re-opening all my files and buffers would take quite a while.
Expanding on the idea of using emacsclient, you can look at what what someone did to solve the problem of editing a file from a different machine than where (s)he started running Emacs.
As of Emacs 23, you can run emacsclient in terminal windows using the -nw option.
Other solutions you might want to try are to use:
gnu screen
vnc
For years I used screen to "attach" and "detach" from a virtual terminal that sounds like your usage model. If you have the ability to use graphics... vnc is really great, just do your work in a vnc session and connect to it any machine.
And your last idea is already implemented by the package desktop (which is bundled with Emacs). Take a look at the wiki page for session management, which includes other alternatives to desktop, as well as add-ons for desktop to lazily load files.
You can run emacs as a server, and use emacsclient to connect to it. You can open multiple connections to the same emacs server, via ttys or X11.
When doing this, C-X C-C will close your connection, and leave the server running.
A simple way to do this by invoking emacs as follows. This will connect to the server if one is running, or create one.
emacsclient --alternate-editor="" -c
Sometimes I will be at work and have to run out the door leaving my Emacs session as it was. Later, I will open an Emacs instance to the same machine (usually using remote SSH) and find that I have files open in Emacs. Now the good news. Emacs allows you to "steal" those files using M-x recover-this-file. I recommend one of Trey's solutions if you can plan ahead. If not, you can use this recover file technique to keep progress moving.