| Age | Commit message (Collapse) | Author |
|---|
|
... even if that protocol is unwritten (note to self: write it already) and
nobody till now was being a good citizen (chez is becoming one).
|
|
|
|
- geiser-log: Obsoleting some -p flags and lexical binding
- geiser-eval: Ensuring logs for asynchronous retorts
- geiser-debug: don't bail on no output with errors
|
|
|
|
Seems to be addressing the sea of blue issue (#39)
|
|
So that now all start with *Geiser (and a space for hidden ones) and
use consistent capitalization (see issue #38).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Set to nil by default, which might surprise some users, if we had
enough :)
|
|
We were always displaying the debug buffer, regardless, which is not
what we want: upon entering a debugger, we switch to the repl, and all
the needed info is already there.
|
|
|
|
See discussion in issue #21.
|
|
|
|
|
|
This is controlled by the new customizable variable
geiser-debug-treat-ansi-colors, which can be set to either nil (do
nothing), 'colors (fontify colors) or 'remove (just strip all ANSI
codes).
|
|
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.
|
|
|
|
When evaluating expressions in a Scheme buffer, display the error
of an evaluation in the minibuffer regardless of whether
`geiser-debug-show-debug-p` or `geiser-debug-jump-to-debug-p` are
set or not.
|
|
|
|
|
|
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.
|
|
Thanks a lot Sean Delvin for a great bug report which, moreover,
contained the solution to the problem! (even though i'm risking a
small modification).
|
|
Let's see if i finally got this right...
|
|
I wonder if this has ever worked fine: geiser-debug--display-retort was
a little mess. It should be a bit better now, but Guile is still
displaying funny messages.
|
|
|
|
Mainly by reordering definitions so that functions are not used before
defined. There are a couple of places where the compiler and I
disagree (it complains withing eval-after-load), and a valid complain
about functions defined via geiser-popup--define that should be
addressed).
|
|
It's now possible to control whether we jump to the debug window on
evaluation errors (geiser-debug-jump-to-debug-p) and whether we show it
all (geiser-debug-show-debug-p).
|
|
|
|
Use a prefix before pressing C-x C-e to print the result of evaluating
the expression before mark to the current buffer.
|
|
|
|
|
|
This bugs was exposed by using rackunit, where all the output of, say,
check-eq? was lost for good (it was being sent to the stderr black
hole).
Hat tip Grant Retkke.
|
|
The message and the evaluated expression where getting mixed for Guile.
|
|
|
|
This is Emacs, after all.
|
|
You won't believe it, but people write procedures spanning several
pages, even in Scheme. Where's the art and the poetry of programming?
|
|
This allows the implementation decide the concrete structure of the
code sent to the REPL. For instance, it doesn't need to be a single
s-expression, and argument order can be re-arranged.
|
|
|
|
|
|
|
|
|
|
|
|
|
