My fork of julia-repl

This is my fork, mainly to use comint and add additional utilities to send code blocks. The original README is README.orig.md.

Compare julia-repl with Juno

• Atom does not support full emacs bindings with reasonable effort. After all, Atom is not Emacs.
• Juno cannot evaluate arbitrary inner block. It will always evaluate the whole block up to the top-level. E.g. in the following code, I can evaluate at any block level using C-c C-c. However, C-enter will always evaluate the whole function defintion. To evalute a custom region using Juno, you have to select the region, which is not convenient.

function test()
    for i=1:10
        for j=2:8
            println("hello")
        end
    end
end

New Features

These are not submited to julia-repl because they are not mature enough, and the change is not small, and might not suit anyone.

comint-mode by default

comint-mode is better than term in the sense that:

• you can freely move around the buffer without switching char/term state (C-x C-j in term-mode)
• you can implement more functionalities, e.g. replacing images

There’s also a WIP pull request by @dellison tpapp#51

send by block

C-c C-c will recognize open block, and send until the matched closing block.

viewing images in repl

Install:

using Pkg;
Pkg.add(PackageSpec(url="https://github.com/lihebi/julia-repl", rev="master"));

or

] add https://github.com/lihebi/julia-repl

Usage:

using EmacsREPL
viewrepl(img)

comint term auto complete

This is a must have.

how elpy works?

elpy is not implementing this itself. It is using python.el’s. The function is python-shell-completion-at-point. Basically it sends a python code wrapper to print out possible completion to the inferior python process, and parse the output, and build the completion list.

This function is added to completion-at-point-functions, so that completion-at-point can pick it up. In Python buffer, it eavlautes to

(python-shell-completion-at-point comint-completion-at-point t)

elpy also has comint-completion-at-point in this list, but that seems to be very much just completion-at-point.

And in the define-derived-mode inferior-python-mode comint-mode definition, add the hook:

(add-hook 'completion-at-point-functions
            #'python-shell-completion-at-point nil 'local)

As a side note, there is one weird thing about elpy: it has RPC and backend server in python. But looks like it only talk to the inferior python process. How the RPC process is using? If both processes are used, the send code function should send to both side? I only see code sending to inferior python process. Also, it is quite impossible to keep both process consistent, because user can execute arbitrary code in REPL.

My plan about julia-repl

I will need to write a Julia code wrapper for querying the information. Now the question is what API to use.

To send string to inferior and hijack the output, the python.el is implementing some awkward code. In a nut shell, I’ll need to

1. set comint-preoutput-filter-functions, to a list of functions, which accepts output and should return “”, so nothing is inserted.
2. To capture the output, this function should save the output somewhere. Then I’ll read that, and clean it before returning it.
3. In addition, since this function is run async, I’ll need to wait for it to complete.
4. Do the call to send-string, and wait until filter function gets all output.

To implement all these, python.el is keeping multiple variables to sync with functions and get results, and using loops to accept-process-output and check finish flag. This is not elegent.

Instead, I found I can probably just use comint-redirect-results-list-from-process, which roughly implement the same logic in a more elegent way, and of course more elegent on the user side.