| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Fixes emacs-geiser/guile#9
In geiser-eval REPL meta-command:
All `mod`, `form` and `args` are now syntax objects. The
geiser-guile's logic will handle `mod` and `form` as is because
they're just passed to guile's eval and compile procedures.
`args` are processed by geiser-eval meta-command itself, so
it's necessary to convert it back to a datum. We lose some metadata,
but all elements in the `args` list are also syntax objects so I don't
think it's a big deal.
`syntax->datum` was introduced before guile 2 so this change is
backward compatible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See gitlab issue #303, where Sergey Trofimov kindly described not only
the symptons, but this cure.
|
|
|
|
Starting with Emacs 27 cl is fully deprecated, including at
compile-time.
|
|
|
|
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.
|
|
It's the convention and by following it we make a big step towards
supporting outline navigation.
|
|
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.
|
|
And by a new pair of glasses in the process.
|
|
Those two procedures are gone in these 2.2 times, and things like
autodoc and xref were broken as a result. With Andy's help,
apparently good enough approximations of their functionality are now
in place: let's see how they go.
|
|
Those two procedures are gone in these 2.2 times, and things like
autodoc and xref were broken as a result. With Andy's help,
apparently good enough approximations of their functionality are now
in place: let's see how they go.
|
|
* elisp/geiser-guile.el (guile--manual-look-up): Change parameters for
info-lookup-symbol to string and 'scheme-mode. Fixes lookup.
|
|
With that in the documentation, i'd taken less time to remember the
very existence of geiser-guile-load-path, and the fact that paths are
added also to the compiled load path... but then i guess it's nice to
re-read my code once in a while.
|
|
We were expanding the path of files to be loaded at the wrong place in
the wrong way. This should be better and address bug #196.
|
|
An attempt to address #194.
|
|
`shell-command` assumes Bourne-shell-compatible quoting, which
doesn't work when the user isn't using a Bourne-compatible shell.
Instead of futzing about with quoting, we can just use `process-lines`
to execute a process and pass it arguments directly.
|
|
Let's see if i finally got this right...
|
|
We could probably be even more robust, but i am being a bit lazy
instead.
|
|
|
|
Using cond-expand to provide support for the new world of guile 2.2
|
|
Fixes #95. This is @kovrik's patch, with 80-columns max formatting.
|
|
|
|
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!
|
|
Move general indentation rules to "geiser-syntax".
|
|
|
|
Use this function instead of repeating the same code in each
implementation.
|
|
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.
|
|
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.
|
|
Apparently, the nesting level returned by emacs's syntax parser can be
negative (presumably when it gets confused), and we were not avoiding
calling backward-up-list when that happened.
Could or could not address issue #41...
|
|
|
|
Follow the convention for `with-' procedures.
|
|
Guile's `define-once' allows defining a variable only once, but its
syntax is different from `define', so its highlight is different.
|
|
And, if you happen to be launching it all the time, a way of skipping
them via a customizable variable.
Should address issue #15.
|
|
|
