As maintainer, I strive to preserve the following:
Backward compatibility of byte-code. I.e. you should be able to take your .elc file compiled with Emacs-19 and run it in Emacs-27 successfully. Of course, in practice it doesn't always work, because backward incompatibilities are introduced either by accident or consciously (tho these are usually not ...
Edit: Woo! I found a function that will take either the normal argument list, or the integer version and return somewhat of a signature: byte-compile-arglist-signature in bytecomp.el!
(byte-compile-arglist-signature 1283) ;; => (3 . 5)
I hope someone else can chime in on whether or not this is documented somewhere but this is what I ...
The Emacs manual node on byte compilation explains that elisp
... has a compiler that translates functions written in Lisp into a special representation called byte-code that can be executed more efficiently. The compiler replaces Lisp function definitions with byte-code.
These byte-codes are basically numeric codes that are not human readable (byte-car, ...
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 ...
You should not expect bytecode files to be compatible between different Emacs versions. The actual bytecode format is mostly upwards compatible, but you will run into trouble with expanded macros.
Let me explain. When the byte-compiler encounters a macro, it computes the macro's expansion and compiles the result. If the macro expanded to a call to a ...
With cl-print.el (builtin as of Emacs 26), this is actually pretty easy to do almost perfectly:
(defun disassemble-file (filename)
(let ((inbuf (find-file-noselect filename)))
(with-current-buffer (get-buffer-create "*file disassembly*")
* 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.
Looks perfectly "normal" to me: the \NNN you see are bytes in the bytecode of the functions that have been used to run your code.
It's somewhat annoying to see them in the backtrace, indeed, so after a few decades of living with it, Emacs-26 finally changed to provide a prettier representation.
By request, here's my implementation of function-argspec and function-arity. I used Jordon Biondo's original solution for Emacs 24 bytecode.
(defalias 'emacsen-compiled-function-arglist 'compiled-function-arglist))
;; GNU Emacs
(defun emacsen-make-up-number-arglist (start end tail)
Someone (possibly you; but maybe org-mode itself -- I've seen it in the past) is adding lambda forms to a hook variable.
What you're seeing is the byte-code for the compiled function. This makes the hook var horrible to read, which is one of the many reasons why you shouldn't put lambdas in hooks (and should instead create named functions and add the ...
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))
There is byte-recompile-directory, but it does not produce a single .elc.
Consider putting the files in the same, dedicated directory; using byte-recompile-directory (after compiling each file once); and zipping the directory into a .zip archive or similar.
One command to byte-compile everything, one command to zip it all up, and one to unzip it at the ...