| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This change to `geiser-repl--superparen-function' improves
compatibility with electric-pair-mode, as the procedure will no longer
add too many parentheses.
|
|
Don't autoeval lines that have already been evaluated.
Don't keep highlighting parens after the line is auto-evaluated.
Don't highlight if show-paren-mode is not enabled.
|
|
|
|
|
|
Fixes issue #68.
|
|
That results in less code and less confusing indirection.
|
|
`geiser-doc--xbutton' will be tackled in the next commit.
|
|
- Avoid defining autoload definitions in a central location.
Instead add autoload cookies to the forms/definitions that should
be autoloaded, in the locations where the actual definitions are
located.
- Do this for `geiser-mode', `turn-on-geiser-mode',
`geiser-mode--maybe-activate' (including adding that to
`scheme-mode-hook'), `geiser', `geiser-connect',
`geiser-connect-local' and `geiser-repl-switch'.
- Also do this for `run-geiser', even though it is only an obsolete
function alias for `geiser', which might make it desirable to drop
the autoload altogether.
Some unusual autoload definitions remain in "geiser.el", see below.
- One issue with defining autoloads in a central location is that it
is easy to forget to remove such autoloads when the real definition
is removed.
No longer autoload `geiser-version' because since [1: 847d2ad]
there no longer exists a proper definition of that function.
- No longer autoload `geiser-unload', `geiser-reload' and
`turn-off-geiser-mode', because they are only useful if Geiser has
already been loaded, at which point any autoloaded definitions are
no longer relevant.
However,
- Keep autoloading `geiser-activate-implementation' and
`geiser-implementation-extension', even though I doubt that this
is actually useful.
- Keep using `custom-add-load' to specify dependencies of Custom
groups and keep autoloading that. I don't know if this is actually
necessary, and while it seems really weird, it might served a legit
purpose, that I am not aware of.
1: 2020-07-19 847d2ad4c6da462c26c50af1ef7d9cd697f3a5d2
scheme and autotools removals
|
|
- In the summary line, use three dashes to separate the file name
from the summary. That is the convention, which some tools depend
on, and for some libraries we already did it here too.
- Capitalize the first word in the summary. That is the convention,
and for some libraries we already did it here too.
- For libraries that have a commentary, make sure it is placed in a
"Commentary:" section.
- Make sure the "Code:" heading, which separates the header from the
code part of the library, exists in all files.
|
|
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
|
|
|
