| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Looks like the arity of that function changed at some point between 24
and 25. It also looks like people still use emacs 24 (see issue #236),
so here we go.
|
|
|
|
When constructing the completion table for minibuffer prompts via
`completion-table-dynamic', we were forgetting to tell emacs to
perform the completion lookup with the original (scheme) buffer as its
current buffer. As a result, the actual completion function wasn't
able to find the REPL connection and everything when down in flames
with an exception.
|
|
|
|
For some reason, one of our users is experiencing point jumps when
calling `geiser-set-scheme'. A save-excursion is all that's needed,
even though it *shouldn't* be needed in the first place.
|
|
`install-package` -> `package-install`
|
|
|
|
as per the discussion at: https://github.com/jaor/geiser/issues/183
|
|
|
|
|
|
geiser-mode-eval-to-buffer-transformer will take 2 argments:
errstring and result
when eval-to-buffer, the result will be transformed by this procedure
e.g.
(setq geiser-mode-eval-to-buffer-transformer
(lambda (estring x)
(let ((l (length x))
(p (seq-position x ?\n)))
(if (and p (< (+ 1 p) l))
(format "\n#| %s%s\n |#" estring x)
(format ";;=> %s%s" estring x)))))
|
|
This is still the same license, but now it is closer to the text
expected by tools that automatically extract license information.
|
|
used Emacs Wiki link since it links on to
the code and is likely to be kept relatively up-to-date
|
|
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: "
|
|
|
|
|
|
At least by default.
|
|
|
|
|
|
|
|
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!
|
|
|
|
|
|
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).
|
