| Age | Commit message (Collapse) | Author |
|---|
|
Actually, programming-musings.org is no longer a domain i pay for, and
the "canonical" reference to my blog post is in jaortega.wordpress.com.
|
|
|
|
After evaling the last expression, if not inserting its value into
buffer, leave (point) at its original position.
|
|
Scan for beginning and end of a sexp, instead of using (point) as the
end.
Previously, if (point) was after a comment character, the REPL would
freeze.
|
|
|
|
Previously, Geiser added a (field t) property to inputs before adding
them to the REPL history so it can determine what characters in the
buffer belong to old input and yank it when a user pressed
enter (geiser-repl--maybe-send) on it. When users recalled an old
input with "M-p" (comint-previous-matching-input-from-input), the old
input with its (field t) property were inserted after the current
prompt. Since old inputs were not "front-sticky," when point was just
after the current prompt but before the characters of the old input,
Emacs considered point to be outside of the (field t) field; this
prevented users from using some movement commands such as forward-word
to move point into the old input text. Furthermore, when users
inserted text before the old input or yanked other old inputs
afterwards, this new text did not have the field property and so Emacs
restricted point movement to and from the old text with the (field t)
field.
This resolves the issue by not adding the (field t) property to old
inputs and instead leverages comint's ability to assign the output
field to all non-input (by setting comint-use-prompt-regexp to
nil). It should resolve the issue reported in "[Geiser-users] Problem
with prompt at history item" by Hamish Ivey-Law
(https://lists.nongnu.org/archive/html/geiser-users/2014-12/msg00001.html).
|
|
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.
|
|
|
|
And, on reflection, it's better we do the same thing with the ERROR
insertion...
|
|
|
|
|
|
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.
|
|
Emacs trunk does not support arguments list like (lambda (&rest) nil)
anymore, which breaks geiser and errors with "Invalid function: "
|
|
An attempt to address #194.
|
|
|
|
|
|
|
|
|
|
Should fix #188, and i'm not generating a new version for this unless
some distribution maintainer is asking.
|
|
At least by default.
|
|
|
|
|
|
|
|
`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.
|
|
|
|
- Also cleaned up the namespace a little.
|
|
C-h P (`display-package') can make use of it.
|
|
|
|
|
|
... so that we don't interfere with other active backends, and following
the same policy as in the rest of company-mode geiser methods. See also
the discussion in github's #173.
|
|
As requested in github issue #173. Seems it's confusing people, which
is exactly the problem it was originally trying to avoid!
|
|
-This causes chicken to fail to run if it cannot find the required
modules for Geiser; and will tell the user that the module is missing.
|
|
This was causing significant typing delay with little to no benefit.
Disabled until a better solution can be found.
|
|
This was causing confusion and bug reports on a semi-regular
basis. Disable it for now until a better solution is made.
|
|
|
|
|
|
|
|
Avoid redefining font-lock-ensure, so that haskell-mode doesn't get mad
at us. Should close github's #164.
|
|
|
|
|
|
|
|
|
|
|
|
When using a prompt regexp, comint's version of these commands
misbehave (they try to reuse forward-paragraph, and that's not quite
it), so we're implemeting our own here in a very straightforward way.
We also bind the usual C-c C-p and C-c C-n to them. It only remains to
b seen whether advising the original ones is worth the trouble.
|
|
|
|
This one should fix github's issue #132. There's still the glitch that
scheme strings are fontified without taking into account extra keywords.
|
|
Addresses github's #158, and its implementation is really easy (kudos to
fice-t, also for telling me about bound-and-true-p).
|
|
|
|
We were adding only the scheme-specific ones.
|
|
We were doing it before the buffer's implementation, and the
implementation-specific keywords were not found. Should fix github's
issue #159.
|
