Add replhook() for REPL customization from juliarc

[carlobaldassi]

This brings back a way to customize the REPL by defining and registering hooks in .juliarc.jl.
It does so by exporting a replhook function, which works similarly to the atexit function. However, it could also be left unexported.
Partially addresses #10779.

I wanted to get some feedback before adding documentation etc.

[carlobaldassi]

Travis failure is unrelated (it's in linalg/symmetric).

[blakejohnson]

Seems like a good idea to me.

[jdlangs]

It might be good to keep the name in parallel with atexit, as more 'hook' functions might be introduced later. Maybe something like atreplinit or atreplstart?

[carlobaldassi]

@phobon that's a good point, and in fact I wasn't satisfied with the name replhook. Either of those you proposed sounds good enough to me.

[carlobaldassi]

I went with atreplinit.

[yuyichao]

Is it possible to import a module to REPL with this patch?

[yuyichao]

NVM, I figured that I just need to use eval as what I always do before anyway... i.e.

atreplinit() do repl
    eval(Expr(:using, :Scical))
end

[jdlangs]

Module import doesn't have any connection to the REPL. If that code is in your juliarc.jl file, it would do the same thing to just have using Scical before the atreplinit definition.

The patch was just introduced because now the REPL environment has not yet been created when the juliarc.jl file is first read. So you have to defer any customization of the REPL to a function that will be invoked after it is created.

[yuyichao]

My point was that I only want to do this in a interactive session but not when running a script. And this PR helps to achieve just that. (since isinteractive returns the wrong value at the time .juliarc.jl is sourced.)

[jdlangs]

That issue should probably remain open regarding isinteractive() then. Clearly there are other uses for it in the juliarc.jl file besides the REPL.

[yuyichao]

Is there a interactive shell that doesn't have REPL?

Also note that the command line option -i make isinteractive() return true in .juliarc.jl (AFAIK).

[jdlangs]

I just meant that doing:

if isinteractive()
    using Scical
end

is probably the more ideal way to get that ability rather than using eval

[yuyichao]

Well, IMHO, it's not a big issue because there's not loss in function. (And actually I was using a try block around it so I had to use eval anyway)

Also, I noticed that I can just use @eval so the only difference is adding a @eval which IMHO is really minor.

[yuyichao]

So before I can do (if I don't need try ... catch)

if isinteractive()
    using Scical
end

Now I use

atreplinit() do repl
    @eval using Scical
end

I don't think the difference between the two matters too much.