| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Thanks to Denis Golovachev for pointing this out!
|
|
Like quitting a REPL right after opening it, or calling evaluation
functions in the wrong, non-scheme buffer.
|
|
|
|
|
|
|
|
And we still need some fixes here when that's active, specifically for
the case when you travel to a file outside the current project: it
becomes repeless, which is a sad state.
|
|
|
|
|
|
Together with project-current as a default for the project root
function when available, now that Emacs 28 is on the horizon.
|
|
|
|
|
|
|
|
FSVO better, but at least the code is cleaner and prompts regexps more
accurate.
|
|
Useful specially for REPLs including a debugger, where you might want
to exit it from a scheme buffer. Bound by default to C-c C-q.
|
|
It is available since Emacs 24.3 and we already depend on Emacs 24.4.
|
|
* elisp/geiser-repl.el(geiser-repl--sentinel): Use `substitute-command-keys'.
|
|
The whole first sentence should fit on the first line. If that makes
the line a bit long then that is unfortunate but better than wrapping
it onto a new line. When wrapping onto a new line anyway then the
second line should never be intended. When it can be avoided, then
long first lines should be made shorter.
|
|
This makes it possible to re-evaluate the containing
buffers without user customizations being clobbered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Should close issue #315, where it is pointed out that "sequences
consisting of `C-c` and a letter (either upper or lower case) are
reserved for users; they are the *only* sequences reserved for users,
so do not block them."
|
|
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
The convention doesn't say much about what parts of the code are
supposed to be part of that sections and what parts belong in a
subsequent section. Here we put the `require' forms in this section
and maybe some setup code, that's a popular approach.
In most cases there was " " where we now insert "Code:". They both
serve a similar purpose and we keep the former because some users
depend on that for navigation. We even add this " " in libraries
where it previously was missing.
In some cases the permission statement was followed by a commentary,
which obviously does not belong in the "Code:" section. In such cases
add the conventional "Commentary:" section.
|
|
A similar idea should probably be used with other schemes, but right
now i feel ashamed of having taken so long to fix this one (assuming
it's fixed!), so let's rush this commit for a change.
|
|
Repeat with me: try M-x geiser-reload before pushing to gitlab
|
|
With a hat tip to Mikhail Kryshen, who was wondering in guile-user why
oh why, and rightly so.
|
|
* Renames geiser-repl-context-sensitive-send to
geiser-repl-send-on-return-p. This option's value is now inverted.
* Update documentation accordingly.
|
|
|
|
|
|
This option allows for easier editing of expressions on the REPL
without accidentally sending the input to the inferior Scheme.
When turned on, the REPL behaves similarly to the Chez REPL.
|
|
|
|
|
|
* Narrow font-lock syntax highlighting to only the
active REPL input region.
* Mark REPL output read-only. This can be changed via the
option `geiser-repl-read-only-output-p`.
* Mark REPL output with a user-definable face as
`geiser-font-lock-repl-output`.
Alternatively an option to syntax highlight REPL output
is provided via the option `geiser-repl-highlight-output-p`.
This applies scheme-mode syntax highlighting to any REPL
output. Any additional hooks defined via scheme-mode-hook
are also executed for highlighting this region.
* Remove some unwanted TABs in source files.
|
|
Since this job is done in the process sentinel, the clean up is also
triggered when the Scheme process exits unexpectedly, deleting any
traces the dying guy might have left. I added a flag to control the
behaviour, but upon reflection the old behaviour seems wrong and i've
defaulted to the new one. This one should fix #251.
|
|
|
|
Previously, Geiser added a (field t) property to inputs before adding
them to the REPL history so it can determine what characters in the
buffer belong to old input and yank it when a user pressed
enter (geiser-repl--maybe-send) on it. When users recalled an old
input with "M-p" (comint-previous-matching-input-from-input), the old
input with its (field t) property were inserted after the current
prompt. Since old inputs were not "front-sticky," when point was just
after the current prompt but before the characters of the old input,
Emacs considered point to be outside of the (field t) field; this
prevented users from using some movement commands such as forward-word
to move point into the old input text. Furthermore, when users
inserted text before the old input or yanked other old inputs
afterwards, this new text did not have the field property and so Emacs
restricted point movement to and from the old text with the (field t)
field.
This resolves the issue by not adding the (field t) property to old
inputs and instead leverages comint's ability to assign the output
field to all non-input (by setting comint-use-prompt-regexp to
nil). It should resolve the issue reported in "[Geiser-users] Problem
with prompt at history item" by Hamish Ivey-Law
(https://lists.nongnu.org/archive/html/geiser-users/2014-12/msg00001.html).
|
|
|
|
|
|
|
|
|
|
|
|
When using a prompt regexp, comint's version of these commands
misbehave (they try to reuse forward-paragraph, and that's not quite
it), so we're implemeting our own here in a very straightforward way.
We also bind the usual C-c C-p and C-c C-n to them. It only remains to
b seen whether advising the original ones is worth the trouble.
|
