| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
API for test suites is defined by SRFI-64.
|
|
Exceptions are defined by R6RS, SRFI-18 and SRFI-34.
|
|
I kind of dislike completion on symbols, because a quote reads to me as
'stop evaluating', and a symbol per se has infinite possible
conversions. But, on the other hand, not completing has no practical
advantage, and, moreover, we're already completing symbols inside quoted
lists (e.g. try M-TAB next to `'(defi`)), so my prejudices are not even
consistent. So here we go!
|
|
|
|
|
|
- Also adds page breaks to geiser-chicken.el
|
|
Move general indentation rules to "geiser-syntax".
|
|
|
|
|
|
Move general RNRS/SRFI keywords from "geiser-chicken" to "geiser-syntax".
|
|
Use this function instead of repeating the same code in each
implementation.
|
|
Many chickeners use prefixes when importing eggs, which breaks
completions. This commit adds the ability to define custom prefix
delimiters, with : and # pre-defined due to their common usage.
|
|
|
|
|
|
|
|
|
|
Crunch is a subset of R5RS that the crunch egg can heavily optimize via
c++ compilation. This change allows geiser to report to chicken
programmers whether the function is found within that subset, easing
development.
Details on the crunch egg can be found at:
http://wiki.call-cc.org/eggref/4/crunch
|
|
|
|
Soooo, the long delay experienced when evaluating long string lists in
Guile had nothing to do with the time took by emacs to read the response
from the scheme process; that process is always a breeze, no matter or
its format or number of newlines. The delay was provoked by an innocent
looking function that scans the received string (which includes a prompt
at the end as an EOT marker) to check whether Guile (or any other
scheme) has just entered the debugger (that's done inside
`geiser-con--connection-update-debugging`). For some reason,
`string-match` on that kind of string using Guile's regexp for a debug
prompt takes forever. Instead of trying to optimize the regular
expression, i've just applied it to the *second* line of the received
string, which is the one that contains the response's prompt.
|
|
This one should address #79. I'm very surprised this ever worked!
|
|
That way we avoid circularities in the load graph, always a good thing.
|
|
This is gone now, since we're diligent enough to always end our impl
definitions with an explicit provide form. See PR #87 for a bit of
discussion.
|
|
|
|
|
|
Should fix issue #85
|
|
|
|
|
|
We use the same trick as chicken for guile, and pretty-print the
evaluation results before writing them. The trick wasn't working at all
until i specified a value for the undocumented keyword parameter
`#:max-expr-width`, which makes me think i might be missing something.
|
|
|
|
- Now give compile-file a reasonable destination for the output
- Check for aforementioned output and skip the compile if exists
- None of the above happens if the system-type is 'windows-nt,
which may not be a necessary restriction. And, the existing
geiser-chicken-compile-geiser-p var applies.
Resolves jaor/geiser#73 for non-windows system
|
|
|
|
|
|
|
|
This change should fix it for most any input.
|
|
In some instances apropos-information-list returns a string and not a
list of symbols; this is the case for Chicken's builtins, like C_plus.
IE, the following would fail:
(geiser-autodoc #f '(+))
This fixes jaor/geiser#72
|
|
Emacs chokes on buffers with very long lines. Use of pretty-print
instead of write causes most incidents of long lines to be avoided by
use of better formatting.
This fixes jaor/geiser#64 for Chicken, and appears to greatly speed up
completions in the general case for Chicken.
|
|
-:c is required to make csi behave nicely with Emacs on Windows.
This ought to resolve jaor/geiser#67
|
|
Chicken won't become available to Geiser until it's actually done
loading. A number of bugs are related to this, including jaor/geiser#68
but also some quizzically flaky completion behaviour.
The fix is to suppress output to STDOUT until Chicken is ready; output
to STDERR is not suppressed, so if bad things happen it will still
appear in the geiser messages buffer.
This may fix jaor/geiser#68
|
|
xscheme defines its own scheme-interaction-mode that, quite rudely if
you ask me, calls not only its hooks, but also scheme-mode's. Among
them, turn-on-geiser-mode, causing havoc to users of xscheme's
run-scheme function.
We, ahem, fix this problem by checking that we're actually in
scheme-mode when our hook is called.
Thanks to Federico Beffa for his reports.
|
|
Minor and Patch versions are now optional.
|
|
geiser--cut-version only supports single-digit minor versions.
- Improves the regex to support multiple-digit minor versions.
Contributed by @kovrik
|
|
Signed-off-by: Mario Domenech Goulart <mario.goulart@gmail.com>
|
|
- Can now optionally compile Geiser components for enormous speed
improvements; enabled by default
- Apropos was returning many duplicates, which was causing slowdowns;
duplicates are now filtered
- Now check for #<unspecified> results and return something
- Fixed a typo in a comment
- Fixed a typo in calling string-length
|
|
|
|
|
|
For some X faces, a bold string in the modeline causes emacs to widen it
to two lines, which is kind of annoying. The default value of
font-lock-variable-name-face on color/X displays doesn't include any
boldness, and will probably improve the default experience of new users.
Thanks to Mario Domenech Goulart for noticing this and the previous one!
|
|
It should have been geiser-active-implementations since ages ago.
|
|
|
