Pascal J. Bourguignon

The error seems to be in `esb:update-definition-buffer` with the use of `make-symbol`: ``` (let* ((definition-properties (slime-eval `(esb:serialize-for-emacs (,definition-function ',(make-symbol (concat package "::" definition)) t)))) ``` ``` (make-symbol (concat "FOO" "::"...

> I can fix that (and I will), but CCL support will remain lacking unfortunately, unless I find a straightforward and portable way of getting the source location of definitions,...

> I've replaced the make-symbol by intern in [eb9931c](https://github.com/mmontone/lisp-system-browser/commit/eb9931cd0d6b9d0d0259bf0e108b1ea889167ae2) > > but don't expect a working version for CCL yet, until I can solve what I mention above. Once you've...

> You'll have to test it because for my configuration it already worked before my change, so I cannot tell whether it made a difference or not. No, I don't...

I will also report an issue to swank about the disconnection upon receiving unparsable "user" message ("#:foo::bar"). We must expect some sturdiness in slime/swank when "user-level" expressions are passed over....

Oops, I attached this Issue to Ceedling instead of CMock. Please, move it over.

> * The string include can be handled be reimplementing `memcpy` I've updated my PR and added tests: https://github.com/ThrowTheSwitch/CMock/pull/454

You may add -I. so that #include "driver/hal/hal_bbb.h" be successful. You can do that in project.yml: ``` :paths: :source: - . - hal # etc ``` But it's strange and...

See https://github.com/ThrowTheSwitch/Ceedling/discussions/803

The problem I was trying to solve was with headers. I had to compile and test system level code, which defined its own version of standard headers such as string.h...