Because the only autoloaded function is sclang-mode, the sclang file was
not being evaluated. This made it impossible to use-package properly in
order to configure the package. Combining the files makes the most sense
as sclang.el wasn't doing much anyways.
The issue manifests when sclang is compiled. Steps to reproduce in real
emacs config:
1. Install the package and compile it
2. Open a file with a `.sc` or `.scd` extension
3. Witness the error `(void-function sclang-make-buffer-name)`
Steps to reproduce with the test:
0. install [eldev](https://github.com/doublep/eldev#installation)
1. `eldev compile`
2. `eldev test`
Only when compiling with cmake will sclang-vars.el be written. This
commit moves relevant constants into customizable vars. Only if the
`sclang-system-data-dir` exists is it respected, otherwise it will guess
the proper location by looking at the system-type.
The purpose of this is to make it possible to build and distribute a
package independent of the SuperCollider build process, while ensuring
that those users who have become accustomed to the current install
process are not disrupted.
When CMake is run with ninja as the generator, duplicate target names
are generated that cause configuration to fail. This commit fixes that
by adding a "compile_" prefix to each of the byte-compiled target names,
eliminating the naming collision.
`gensym' used to be an alias for `cl-gensym'.
It was replaced with a "native" implementation in subr.el with Emacs 26.1.
Go back to using `cl-gensym' to make sure Emacs 25 still works.
For some reason, these slipped my attention. Sorry about that.
Also:
* `nconc' is more efficient then `append' if destructive modification is not
an issue.
* Emacs 26 actually deprecated `string-as-multibyte' in favour of
`decode-coding-string' since the latter actually forces the user to
specify an encoding.
This is actually pretty boring. It replaces calls to obsolete aliases
with the properly namespaced functions from the cl-lib package.
This raises our minimal Emacs version requirement to 24.3 (2013-03-10).
However, people using earlier versions can install the cl-lib package
from the Emacs package system.
While at it:
* remove function `sclang-document-list' which was really useless.
* fix `sclang-format-pseq' which needed to use `cl-labels'
instead of `cl-flet' to actually work.
* (cl-reduce (lambda (a b) (or a b)) (mapcar function list))
is much better written as (and now properly short-circuits):
(cl-some function list)
* (cl-remove-if 'null list)
should be written as
(remq nil list)
It turns out `file-directory-p' and `file-exists-p' return t when passed
the empty string. This is sort of unexpected, and leads to the logic
in `sclang-make-options' choosing to pass -d and -l with
unpredictable values (default-directory) to sclang.
A default of "" (or -1) is pretty unidiomatic for elisp, so we change
the default of user option `sclang-runtime-directory',
`sclang-library-configuration-file' and `sclang-udp-port' to
nil, and adjust `sclang-make-options' accordingly. While we're here,
we can eliminate the use of `cl-flet'.
Additionally, `sclang-eval-sync' uses `find' which is really an
alias for `cl-find' which and can be replaced with a call to the built-in
function `assoc'. This is faster, and the last dependency on the
cl package, which we can now remove (obsolete since emacs 27).
Symptom: (sclang-eval-sync "\"ö\"") evaluates to "ö"
After this patch: (sclang-eval-sync "\"ö\"") => "ö"
This was tricky to figure out, so here is a bit of background.
scel uses a so-called command FIFO to send (amongst other things) evaluation
results to Emacs. This FIFO uses a pascal-string (32bit string length
followed by character data) to send Lisp to Emacs. The command process
coding system is already set to 'no-conversion on the Emacs side
to avoid crippling the int32 at the beginning of every string.
However, the read-from-string call in sclang-command-process-filter
implicitly converts the unibyte string received from the process to
a multibyte string, without doing proper conversion.
The right function to use here is string-as-multibyte, which does
the correct conversion.
nik gaffney
