Native Windows Emacs w/o WSL or Cygwin?

Are there any resources (aside from the docs) or blogs out there where I can read up on this? I'm moving to a new role where my machine will be a fairly locked down Windows setup and from what I can tell they're not allowing WSL or Cyg but I can have native emacs. Go figure. Anyway, I've only ever run Emacs on Linux so I am not sure what all I'm in for. I realize some functionality is just not on the menu but hopefully that's not a show stopper for all development.

[deleted]

Quick question, did you know about this caveat before accepting the new role? Curious about your chain of reasoning. Backstory; I took a job thinking it would it wouldn’t matter without a “proper” eMacs environment… eventually I was job seeking because I couldn’t accept my loss of productivity. Spoke with my boss about it and now I’m happy-ish on a Mac.

More backstory and lessons learned; eMacs is very, very subpar on windows without wsl 2. More so With windows defender and the other agents hogging io. If you must, consider leaving behind favorite packages… such as those that use many small files.

I have no resources to help, but I've been running Emacs like this for a few years. Chocolatey and Microsoft terminal have helped greatly with required packages, and a straightforward doom setup runs pretty easily. I don't use a lot of features of emacs compared to a lot of people here though, so there still might be rough edges as you get more involved.

Try using MSYS2 instead. I have a similar situation. This did not require admin rights and you can install several nix packages and add them to your PATH, including Emacs. General performance, say that of Riprep do not feel as fast as Linux/Mac and may have some quirks but is fairly acceptable.

I recently took my config from Mac to windows (native) and literally everything worked.

I've had problems with ssh with native Emacs on Windows which I couldn't solve, so I switched to Cygwin. Apart from that it did run fine.

I ran emacs like this on windows but switched to WSL lately. Emacs runs fine on windows, but getting software is a bit complicated. Always fiddling around with $PATH, compiler doesn't work etc. pp. Then there is the problem that most Linux packages and some other programs expect Linux paths. I don't know how many times I fiddled around with Windows paths, escaped \ with \\ etc etc. Clangd (but this is not emacs specific) is notorious about that. Took me days to figure out the include paths. It's easier in WSL, where every thing works automated.

don't know of any resources. i just know Emacs on Windows is great. i use it every day

How great? Do you use vanilla or doom? Do you use magit? My latest experience with emacs on Windows 10 was not very satisfactory... long start time, magic was veeeery slow... how did you installed it? I would be interested in knowing more, thx

i downloaded it from the official GNU ftp site. i have WSL installed (Ubuntu), so i have an Ubuntu shell at my disposal, along with the normal windows shell (all in Emacs). I start Emacs up when i log in. i don't care that it takes a few seconds. `alt`, `super`, and `hyper` work well, and all my f keys work well (F1 to F24), and that i do care a lot about. that's #1 for me

I've been running Emacs on Windows natively for years and it's not that bad. IO can be slow at times though. I got used to it but it can still be a bit annoying. Not sure if you would be allowed to use it at your job but I install and update all my tooling through [Scoop](https://scoop.sh/). It also handles the PATH for you most of the time. Magit is quite a bit slower on windows so I've learnt to use the built-in vc-mode a lot for basic operations and it's been serving me well. Overall, I recommend you leverage caching as much as possible to avoid fetching stuff from the filesystem. Use Emacs daemon for sure because you really want to avoid restarting Emacs often. Keep the buffers you need open but don't have too many org buffers open at a time, I've found it can really slow things down. Also limit your org agenda to only a few files to keep it fast. If you run shell command, use async-shell-command. Well, use async stuff wherever it is possible.

I use a Linux setup at home and a native Emacs Windows setup at the office, with about 70 packages. Overall most features/packages work out-of-the-box on the Windows setup, a few need customizations that can take some time to achieve depending on your experience with Emacs and your Google-fu. Native Windows Emacs is significantly slower at startup than on Linux (like 2-5x). Running is slightly less smooth than on Linux, except with Magit which is very slow on this Emacs’ version but the reason is documented. No such slowness under WSL. * PATH: Emacs will need to read the Windows’ PATH value for some packages. So the package `exec-path-from-shell` may find itself useful. It’s probably possible to use a small Lisp code instead. * Tramp: needs some tweaking to make it work. It took me a long time to figure out a setup that works. I never managed to have it work with the Windows 10 built-in OpenSSH client. So I suggest you install plink.exe first (with Putty package for instance). Then you can put the following code in your init file: `(setq tramp-default-method "plink")` `(setq tramp-persistency-file-name nil) ;; without this, makes the system buggy` `(setq tramp-use-ssh-controlmaster-options nil)) ;; I don’t remember why it is needed, but heh...` Remember that all the SSH configuration will need to be done at Plink/Putty level, instead of the usual \~/.ssh folder * Magit: you will need Git for Windows for it to do anything useful. * diff/ediff: you will need diff.exe in your Emacs’ PATH to have it work. This executable is provided by Git for Windows so you won’t need Cygwin/Msys2. `(setq ediff-diff-program "c:/Program Files/Git/usr/bin/diff.exe")` * pdf-tools: you will need Msys2 to have it work, which may not be possible in your case * flycheck: not supported on Windows but works anyway with Python * lsp-mode: works fine but you will need to install npm or python to instal the LSP servers, which may not be possible in your case * elfeed: works with the following code: `(setq elfeed-curl-program-name "c:/Windows/System32/curl.exe")` * el-get: was unable to make it work Beyond those above, most things work quite well.

Just install the Hyperbole package. It recognizes whether you are running under native Windows or WSL and can interpret Windows paths and POSIX paths under either environment when typed in a buffer, double quoted if they contain spaces. Then just press M-RET to jump to the path, including Windows shares. There is also a command, hpath:substitute… something to toggle a path between the two formats. Make your life easy.

"very, very subpar on windows without wsl 2"? This is the opposite of my experience on all versions of Windows up to the current release of Windows 10 and, I would suspect, the opposite of the experience of the thousands of users who upgrade the native Windows distributions of Emacs with each new Emacs release. If anything, the added overhead of WSL is what would slow down the overall system, not a lean and mean app like Emacs. Windows Defender is an "agent hogging IO"? That would surprise Microsoft. Do you have benchmarks for this assertion? What is the hardware configuration of your system? Is it reasonably modern? When you examine the processes in Resource Manager, which ones are consuming the most RAM, CPU, and disk IO? I doubt it's either Emacs or Windows Defender. Meanwhile, the original poster should follow the tried-and-true instructions in the official GNU docs here: 1. Appendix G Emacs and Microsoft Windows/MS-DOS: "https://www.gnu.org/software/emacs/manual/html\_node/emacs/Microsoft-Windows.html 2. GNU Emacs FAQ for MS Windows: https://www.gnu.org/software/emacs/manual/html_mono/efaq-w32.html Download the ready-to-install binaries here: https://ftp.gnu.org/gnu/emacs/windows/emacs-28/. Emacs has worked very well on Windows for many years. A quick search of the Web will show plentiful advice for the edge cases, advice on . . . r/emacs itself, i.e. right here, and on StackExchange, and plentiful blog posts. Relatedly, I do not understand the obsession some have with "Emacs start-up time." I restart Emacs only when I must restart Windows itself, which isn't often. I run an instance of Emacs for weeks at a time. BTW, I actually run multiple Emacs instances at at time, usually three, each in its own memory space of course: one for my production work, one for the Elisp development environment, and one for testing new packages and custom code. My own system is: Dell XPS 8940 Processor: 11th Gen Intel(R) Core(TM) i9-11900K @ 3.50GHz Intalled RAM: 64.0 GB (63.6 GB usable) System Type: 64-bit operating system, x64-based processor Windows Edition: Windows Pro, v. 21H2

| Windows Defender is an "agent hogging IO"? That would surprise Microsoft. Do you have benchmarks for this assertion? I'm not sure if your serious but I'm not spending time on this as I don't expect any help from microsoft on software such as emacs. Here was a discussion i started regarding my experience 2 years ago: [https://www.reddit.com/r/emacs/comments/ikvqcs/emacs\_on\_windows\_what\_packages\_to\_avoid\_to\_stay/](https://www.reddit.com/r/emacs/comments/ikvqcs/emacs_on_windows_what_packages_to_avoid_to_stay/) I came across a fix somewhere suggesting disabling windows defender... folks talk about it [here](https://www.reddit.com/r/emacs/comments/bii2xl/hot_tip_for_windows_10_users/). My enterprise workstation (64gb memory) was running multiple agents in addition to defender, and i don't even know what they were. (Didn't have access to interrogate things like this...) Probably every corporate spyware you could imagine.... ​ Just sharing my experience. Not trolling, if you need benchmarks to hear my comments then just disregard everything i've said. Maybe this is helpful for the Op or future me trying to remember how i got windows authentication to work on wsl to access resources (it included NAT to pull a kerberos ticket, ensuring my user was in alignment with the windows profile, etc. etc. ) Other absolute garbage user experience (my opinion, sorry if this comes as a surprise to microsoft): 1. windows authentication and emacs on wsl2 (a sep. container, different user, NAT, kerberos, have fun.) 2. Windows fork and small-files in magit, especially on wsl1 3. anything terminal related, obviously. Put time aside to fix \`ls\` with things like dired. 4. If you have a man-in-the-middle enterprise SSL sort of thing like palo alto/etc on your network... more pain exacerbated by windows. Maybe this is helpful for the op. I'm glad your windows emacs experience has been very well, hopefully this dialog is informative to OP as thats not always the case. My company is extremely locked down (to the point i was about to quit), and in these days of ransomeware/etc. I wouldn't be surprised to know if many are.

more surprises for microsoft: https://www.reddit.com/r/emacs/comments/g4x2gz/why\_the\_hell\_is\_magit\_so\_slow\_on\_windows/

I believe Doom Emacs have decent install guides for Windows - both for WSL and without it. Check out if they have anything helpful to you.

I run Emacs on a secure machine at work, here’s a few tips: - ask IT which users in your org have Emacs installed. You most likely have proprietary systems and want to make packages so you can interact with them in Emacs. Sharing code with your fellow Emacsen is a great way to cut down duplicate work and enhance your workflow. You can also set up a leaderboard for Tetris and such ;) - get used to vanilla. It is unlikely you will be allowed to install 3rd party packages or a distro like Doom. Make sure you’re comfortable basing your config on built-ins only. - make sure you understand the security requirements of your org. If they don’t want you to run code from the internet, don’t. If you really need something, read the code, understand it, then write it yourself. Never share your config on the internet. - if you want to use latex functionality (export PDFs) you will likely need to request a latex distribution. Same goes for other programs that Emacs calls (OpenPGP is another) - codify your org’s style/formatting conventions. Orgs are built on standards. You should spend some time making sure any output from Emacs, whether it be an email, a report or code reflects these standards. Think org-export setup files, auto-insert file headers/license, indentation/format functions

I doubt WSL (at least wsl2) has much overhead. I dev via Xming + ssh X-forwarding emacs from hyper-v on the regular, and it's identical to native linux perf. If you are using native linux FSes, you should be fine. The thing to worry about perf-wise is going to be I/O overhead when accessing windows files from linux.