Those are extremely common in Emacs modes and allow people to
quickly jump to a REPL and back to the last source buffer they
were editing, while using the same keybinding.
I've modeled the implementation here after that of inf-clojure (a similar
mode written by me). I've also implemented a mode menu for
utop-minor-mode, so it's easier for the users to discover its
functionality.
Without those changes you won't get any completion for things like
"List.m". I'm not very familiar with the code, but it seems that the
backend returns the completion candidates without the module prefix
which caused the problem.
I've opted to fix this by handling prefixes with a "." in them specially
and this works fine in the limited testing I conducted locally.
Readme states 'Key bindings in the terminal can be changed by writing a ~/.lambda-term-inputrc file. For example:'
However, after writing this file and exiting utop after it's next restart generates the below warning:
`Warning: it is recommended to move `/home/owen/.lambda-term-inputrc` to `$XDG_CONFIG_HOME`, see:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html`
Add all options as decribed by the output by --help to the manual page.
This was done manually and some automation would be nicer.
Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
In standalone mode, utop returns all the possible completions when no
one matches what the user has typed. This is surprising in emacs
because of the different UI/UX. For this reason, we keep a list of
prefixes for which completion has started and return only the
candidates which match the prefixes.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
The output from the compiler changed and now mentions the line number
(non only the charters, which actually becomes columns). This patch
introduces the idea of a range of lines spanned by an error and
correctly marks the faulty region.
I think a better solution would be to introduce a "point" record of
the form {line:int;column:int}. However, such a change would
reverberate through all the source code and so it is much more
invasive. I can prepare such a patch if desired, after this one, which
fixes the regression.