Eldoc integration in Sage fails on functions in catalogs

[johanrosenkilde]

This is quite likely not at all the fault of sage-shell-mode, but I'm reporting this unwanted behaviour here, and we can see if something can be done about it.

Eldoc is a nice minor mode for showing the signature of functions in the minibuffer while writing:

sage: matrix(<wait a moment>
<minibuffer prints: "matrix(ring=None, nrows=None, ncols=None, sparse=None, *Args)"

This works for methods on classes as well and for functions/class constructors in modules. But it doesn't seem to work for the Sage catalogs:

sage: codes.GeneralizedReedSolomonCode(<waiting a long while>
<nothing prints in minibuffer>

Explicitly importing the functions into the namespace fixes things

sage: from sage.coding.codes_catalog import *
sage: GeneralizedReedSolomonCode(<wait>
<minibuffer prints signature>

[johanrosenkilde]

Actually I have other problems with Eldoc as well:

sage: LinearCode(<no Eldoc>)
sage: sage.coding.linear_code.LinearCode(<Eldoc info>

[stakemori]

Thank you for reporting. I think it is a problem of sage-shell-mode. Because sage.misc.sageinspect.sage_getdef(codes.GeneralizedReedSolomonCode.__init__) returns the following.

'(evaluation_points, dimension, column_multipliers=None)'

I will fix it.

[johanrosenkilde]

Awesome!

[johanrosenkilde]

You are so fast! Thanks -- I'll try it out tomorrow.

[stakemori]

I thought I had posted a comment when closing this. It seems that my comment was gone by a mistake.

Eldoc strings for those objects were not displayed, because they use "LazyImport" (i.e. both isinstance(codes, sage.misc.lazy_import.LazyImport) and isinstance(LinearCode, sage.misc.lazy_import.LazyImport) return True).

Objects using LazyImport were ignored by sage-shell-mode, they are no longer ignored (d0e2b1b447258e27c0c79f1cfe15f15251fd23a1).

[johanrosenkilde]

I confirm that Eldoc tips now works in sage-shell-mode on everything I've tried it on.

But in sage-shell:sage-mode then I get Eldoc tips for e.g. Algebra (not LazyImport), and for LinearCode (LazyImported), but not for codes.CyclicCode or graphs.PetersenGraph.

A related small thing I noticed: in sage-shell:sage-mode, even though Eldoc is activated immediately when visiting the file, Eldoc tips do not work before I've popped to the shell once and go back. It seems it is not properly registered to use the running shell before doing this?

[stakemori]

@jsrndk, thank you for testing. It seems that I tried to disable eldoc for attributes for some reason. I will fix it.

If sage-shell:process-buffer is not set, then sage-shell-edit:eldoc-function returns nil. I will set it in the function if there is only one Sage process running.

[stakemori]

I fix it (b8ec25c688e37c141073406bbef4d143c8476904). If there are multiple processes, sage-shell-edit:eldoc-function still does not set sage-shell:process-buffer automatically.

[johanrosenkilde]

I now have trouble with by sage-mode buffers not being able to find the Sage process again. Doing C-c C-z, I get: setq: Wrong type argument: processp, "Sage".

If I close my running Sage, I get the following in *Messages*:

error in process filter: save-current-buffer: Selecting deleted buffer
error in process filter: Selecting deleted buffer
error in process filter: save-current-buffer: Selecting deleted buffer
error in process filter: Selecting deleted buffer

Starting Sage again, gives no errors, but then standing in a sage-mode buffer and doing C-c C-z gives me the aforementioned error. Consequently, a lot of stuff (e.g. Eldoc) doesn't work in the sage-mode buffer.

[johanrosenkilde]

Restarting Emacs completely and the problem goes away. The problem comes again if I kill the Sage process buffer, and the run-sage again. Doing sage-restart gives no problems.

On a clean Emacs, before I get the above problem, sage-mode buffers can find the Sage process beffer. But still Eldoc doesn't work at all in the sage-mode the buffers! It works correctly in the Sage process buffer.

[stakemori]

Sorry. I've pushed fixes to fix-branch. By the way, how do you kill the process? Just kill-buffer?

[johanrosenkilde]

Don't worry. Yes, (ido-kill-buffer) to be precise, but I assume it calls kill-buffer in the background.

[stakemori]

Sometimes, even if the process buffer is killed, the process itself may not be killed (see the output of (list-processes)). It may cause a problem. Could you use sage-shell:send-eof or quit instead?

[johanrosenkilde]

You're right, this was the problem: when doing quit or C-c C-d, there's no problem. Doing kill-buffer the problem appears. list-processes reveals the Sage process is still alive. After delete-process on the headless Sage process, the problem is gone when restarting a new Sage. So in a way it's definitely a user-error. But is there anything you can do to detect it? The errors printed in Messages indicate that you should be able to catch the behaviour somewhere. I'm pretty sure sage-mode handled this elegantly (which is why I have the nasty habit of killing the Sage buffer).

[stakemori]

So in a way it's definitely a user-error. But is there anything you can do to detect it? The errors printed in Messages indicate that you should be able to catch the behaviour somewhere. I'm pretty sure sage-mode handled this elegantly (which is why I have the nasty habit of killing the Sage buffer).

If use-prompt-toolkit is nil, then kill-buffer also kills the Sage process (though sage-shell:process-exit-hook causes an error). So it seems that it depends on how process was started. Emacs info of "process buffers" says "Killing the associated buffer of a process also kills the process". So this might be a bug of Emacs. I will report it.

[stakemori]

This may be a bug of Sage 7.4. If I send SIGHUP (this is sent when the process buffer is killed) to a Sage 7.4 process by the following code:

(signal-process (get-buffer-process sage-shell:process-buffer) 'SIGHUP)

Sage crashes, but the process still remains.

If I do the same thing for Sage 7.2, then the process is killed.

[stakemori]

I close this issue and open a new one.

[johanrosenkilde]

OK, well bug-tracked.