| Age | Commit message (Collapse) | Author |
|---|
|
Defining it as a macro, as it was done from the start, is just
weird.
|
|
This makes it possible to `eval-buffer' the buffer defining this
constant. Not that doing so makes all that much sense, but I tried
doing it before reading its content, because generally speaking that
is a sensible thing to do, at least for someone working on the code.
|
|
Right above the changed lines we require `ring'. It is therefore not
necessary to delay evaluation until `ring' has been loaded; we know it
has already been loaded.
|
|
A note on why we won't use the mapatom trick to make geiser-custom--defcustom
obsolete while still preserving geiser-reload functionality (cf. !22).
|
|
In particular, removing a misleading FIXME comment that led to merge proposal
!22, and adding comments explaining why those changes would alter
geiser-reload's behaviour.
|
|
|
|
|
|
|
|
When a transmission queue request successfully completes and the REPL prints a
return value, it skips over unexpected and potentially meaningful output. Given
that geiser:eval captures standard out, this output may contain warning or error
messages. This PR captures and logs this extra output instead of discarding it.
|
|
Fixes issue #20
|
|
|
|
|
|
|
|
Some projects use λ, some use lambda, and it is convenient to be able to use the
same mapping engraved into muscle memory for both. Therefore this commit adds a
new variable that allow geiser-insert-lambda to do both, depending on the value.
* elisp/geiser-edit.el (geiser-insert-actual-lambda): New variable.
(geiser-insert-lambda): Respect it.
|
|
|
|
|
|
|
|
`dotimes' has a defect (and a fixme which is over a decade old) that
causes a bogus (though technically correct) warning about VAR being
unused, if RESULT is not omitted but does not use VAR.
|
|
In Emacs 30:
lib/geiser/elisp/geiser-compile.el:19:11: Warning:
‘make-network-process´ called without required keyword argument :service
This seems to be a false-positive, but I am not sure.
|
|
Emacs 30.0.50 has started to warn when this variable isn't set,
presumably so that the default can be changed from nil to t in
a few years.
I see no reason not to use lexical-binding.
|
|
|
|
|
|
|
|
|
|
The bytecode compiler complains because delete-backward-char is an interactive
function.
|
|
|
|
Disabled by default. Adds new custom variables
"geiser-repl-superparen-character" and "geiser-repl-superparen-mode-p".
|
|
|
|
|
|
|
|
Warning: ‘backward-delete-char’ is for interactive use only;
use ‘delete-char’ instead.
|
|
"geiser-repl-autoeval-delay" should be "geiser-repl-autoeval-mode-delay".
|
|
|
|
Disabled by default. Adds new custom variables
"geiser-repl-autoeval-mode-delay" and "geiser-repl-autoeval-mode-p".
|
|
|
|
Fixes #60, as diagnosed and solved by Fabian Brosda: if an implementation is
fast enough, new evaluations can override the result of eval/wait before it is
used (this seems to be the case during completion).
|
|
Should provide a better fix for extended issue #58.
|
|
This should take care of the problem reported in issue #58.
|
|
* geiser-compile-file
* geiser-compile-current-buffer
* geiser-load-current-buffer
* geiser-add-to-load-path
|
|
|
|
Fixes #57.
|
|
|
|
Thanks to Stefan's patience and actual implementation, we now don't load all
of geiser-impl.el and its dependencies just because there's a call
geiser-activate-implementation in geiser-<impl>-autoloads.el.
|
|
|
|
See issue #47.
|
|
|
|
|
|
|
|
|
|
|
