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.
|
|
|
|
|
|
|
|
|
|
|