Just encountered this myself today when switching to cygwin.
The reason it didn't work for me was that the python layer in spacemacs only strips \n when looking up the ipython version on init.
The binaries supplied from python.org uses windows line endings to work well with the windows cmd line. This breaks the version check in the setup of the python ...
Well it turns out that the long-complicated-names-with-goobers listed in the "Devices and Printers" "Control Panel" / "Windows Settings" really are the printer names... ick.
(setq printer-name "Microsoft Print to PDF")
does in fact generate a PDF file via Emacs.
The list of names in the "Control Panel" is confirmed by:
Where can I report this problem? Should I report it directly to
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs or rather to
The "true" answer to this depends on where the bug really is. Of course, you don't know where it is yet, so you'll have to guess.
There are a few more things you could do to gather evidence ...
* Incompatible Lisp Changes in Emacs 26.1
** Certain cond/pcase/cl-case forms are now compiled using a faster jump
table implementation. This uses a new bytecode op 'switch', which
isn't compatible with previous Emacs versions. This functionality can
be disabled by setting 'byte-compile-cond-use-jump-table' to nil.
I did this exercise today, and ended up with the following batch file (I named it runemacs.bat):
setlocal enableextensions enabledelayedexpansion
IF "%~1" NEQ "" (
for /f "delims=" %%i in ('%bin%\cygpath.exe %1') do set filepath=%%i
%bin%\run.exe --quote %bin%\emacs-w32 "!filepath!"
) ELSE (
%bin%\run.exe --quote %bin%\...
Find full directory path where emacs expects ditaa.jar to be located.
This code is copied from ob-ditaa.el
I am afraid that moving files manually will mess up my system, confuse my package manager and only work until the next update. Instead, you can simply added the true path for ditaa.jar to your .emacs or .emacs.d/init.el. In my case:
(setq org-ditaa-jar-path "/usr/share/ditaa/lib/ditaa.jar")
Base on Melioratus answer I did this:
cd .emacs.d/elpa && mkdir contrib
cd contrib %% mkdir scripts
which ditaa ## I have mine in /usr/local/bin
ln -s /usr/local/bin/ditaa0_9.jar ditaa.jar
ln -s /usr/local/bin/DitaaEps.jar DitaaEps.jar
Now emacs/ org-babel can find ditaa, success!
I don't use ledger-mode but I am pretty sure that the following advice-add will help you. The code is only partially tested (up to make-process in ledger-flymake). Please test whether it is working for you.
It converts the drive specification \`[[:alpha:]]: in buffer-file-name of your ledger buffer selective for function ledger-flymake into /cygdrive/\1 ...
The path you passed (c:/Users/USERNAME/Dropbox/Priv/2018.ledger) is not a valid cygwin file-path, it is a MS-windows file-path:
It will look like a relative file-path to cygwin, so will be appended to the present working directory. I assume that /cygdrive/c/Users/USERNAME/Dropbox/Priv/ | c:/Users/USERNAME/Dropbox/Priv is your present working directory.
The editor shows a blank buffer because it it trying to open a file
with a cygwin styled path. e.g. /tmp/bash-fc.abcdef which in turn
tries to open C:\tmp\bash-fc.abcdef which doesn't exist, so it opens
a new file. The solution is to define a function which takes a path and uses
cygpath to convert it to a windows path, and opens it with
emacsclient. I ...
From what I've learned WSL currently has limited capabilities to run arbitrary code. All Linux executable is hidden inside %APPDATA% directory and isn't launchable from w32 world.
Special executable c:\windows\system32\bash.exe is a window to Linux word. In other words you need to wrap each call to utility via: bash -c "cmd-here ...".
That mean you won't ...
Solution: cp path/to/eslint.cmd /usr/bin/flake8.cmd, then vim flake8.cmd, edit exe and script names inside.
How I found that: I gave a second thought to "why eslint just works?" Because it's eslint.js? I changed flake8 to flake8.py, no luck. Thanks to everything, I typed eslint. in the search bar, and eslint.cmd stood out. Then I cloned it to flake8.cmd ...
Turns out, I needed to delete the TeXLive distribution which I had installed manually using the TeXLive Windows installer and reinstall TeXLive with the Cygwin setup.exe. This will place everything in the correct places for emacs to be able to see them.