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.
|
|
|
|
We add the paths in geiser-guile-load-path also to %load-compiled-path,
and new directories added to the load path via geiser-add-to-load-path
are added to both %load-path and %load-compiled-path.
Here's hope Ludovic will like all these additions!
|
|
We add the paths in geiser-guile-load-path also to %load-compiled-path,
and new directories added to the load path via geiser-add-to-load-path
are added to both %load-path and %load-compiled-path.
Here's hope Ludovic will like all these additions!
|