A solution to this is to delete all compiled EmacsLisp files in the user's Emacs directory
find . -name "*.elc" -type f
Once you are satisfacted by what the find command returns (it should only return .elc files), delete them with the -delete option:
find . -name "*.elc" -type f -delete
Then restart Emacs and they will ...
* 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.
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 ...
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")
Find full directory path where emacs expects ditaa.jar to be located.
This code is copied from ob-ditaa.el
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%\...
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 ...
One way to handle this is to have dedicated package directories for each Emacs version. You can do this by placing the following in your init file:
(setq package-user-dir (concat "~/.emacs.d/elpa/" emacs-version))
I am (almost exclusively) using Emacs on WSL1.
I've got X11 support by VcXsrv. It is very stable.
You can mount Windows paths as drvfs. No problem there! My $HOME is my %USERPROFILE%. You can even mount windows network paths and usb drives.
File access is much faster under WSL1 and even once more faster under WSL2. It is even possible to use magit under WSL....
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.
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!