| Age | Commit message (Collapse) | Author |
|---|
|
Generated by simply copying README.org. The trick of making README a
symbolic link was, well, a trick, and seems to confuse poor Gitlab.
|
|
Probably not a totally smart move, since sooner or later gitlab's
going to fall as github did (for a fruity company would be my bet).
But oh well, at least we can export a CSV of the issues!
|
|
And we also take the chance to let add-to-list do its job of not
adding duplicates.
|
|
|
|
|
|
|
|
|
|
and make github happier in the process (cf. github issue #243)
|
|
And thus avoiding having to generate markdown (cf. github issue #243)
|
|
Okay, i must confess it's sometimes handy to restart the REPL before
compiling a file (the proverbial clean slate and all). And we already
have geiser-restart-repl, so combining the two things when C-u happens
was not really difficult.
|
|
Savannah downloads is often broken, and the news page doesn't really
add any value.
|
|
|
|
|
|
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!
|
