Using Emacs to start a project build within a Windows VM.

This video covers an elisp snippet that starts its evaluation life cycle by yanking the entire current buffer and then proceeding to call a bash script that runs xdotool operations to find and bring to focus a QEMU/KVM Windows 10 guest, thereafter it continues to send the following key combos: Ctrl+A (Select all - presumably the source text in your editor within the Win10 VM) Backspace (Delete all the old text) Paste (It pastes the previously yanked contents) Finally the script sends the F11 key which executes a compile and run command within the IDE that I am using (Dev-C++). This workflow is extremely idiosynratic - you need to be unhealthily obsessed with Emacs to want to use it as your editor when you require a proprietary compiler & environment for your coursework but, alas it is necessary and so I thought I would make the workflow slightly frictionless with a smidge of elisp and some xdotool magic. The script has some hard dependencies on a QEMU/KVM Windows 10 LTSC VM (It's the leanest SKU in my opinion) running under X11 and your Window Manager (in this case; IceWM) being EWMH compliant enough to allow switching to the QEMU/KVM window and activating it (bringing it to the front), additionally you must ensure that your editor source page is left focused in the VM otherwise when the script switches to the VM it will paste the clipboard contents into whatever else was left focused prior. Links: elisp snippet: [https://github.com/DiamondBond/emacs/blob/master/config.org#switch-to-qemu--paste](https://github.com/DiamondBond/emacs/blob/master/config.org#switch-to-qemu--paste) bash xdotool script: [https://github.com/DiamondBond/bin/blob/master/stqap.sh](https://github.com/DiamondBond/bin/blob/master/stqap.sh)

> This workflow is extremely idiosynratic - you need to be unhealthily obsessed with Emacs to want to use it as your editor when you require a proprietary compiler & environment for your coursework but, This is not particularly idiosyncratic or obsessive. That "the industry" does now generally accept that APIs and CLI tools is more-or-less required is great and welcome … but you're going to be interacting with various closed and proprietary tools /forever/. Getting your preferred tools or languages or platform or whatever to interact with proprietary environments is a constant, really.