julia-snail icon indicating copy to clipboard operation
julia-snail copied to clipboard

Compilation mode in REPL buffer

Open martinbiel opened this issue 4 years ago • 7 comments
trafficstars

Could an option be added to enable the functionality implemented in https://github.com/gcv/julia-snail/pull/12 also to the snail REPL buffer? I like the ability to follow error links when testing my packages interactively.

I tried to just manually enable this in a hacky hook:

:hook ((julia-snail-repl-mode . (lambda()
                                  (with-current-buffer julia-snail-repl-buffer
                                    (setq-local compilation-error-regexp-alist-alist
                                                julia-snail--compilation-regexp-alist)
                                    (setq-local compilation-error-regexp-alist
                                                (mapcar #'car compilation-error-regexp-alist-alist))
                                    (compilation-shell-minor-mode 1)
                                    (setq-local basedir (gethash julia-snail-repl-buffer julia-snail--cache-proc-basedir))
                                    (setq-local compilation-search-path (list basedir))
                                    (message basedir)
                                    ))))

which appeared to enable the feature I am asking for. Error links became clickable and correctly pointed to my package code. However, Emacs crashed at one point when clicking one of the error links, so this temporary solution is not the way to go :slightly_smiling_face:

martinbiel avatar Jan 14 '21 16:01 martinbiel

Your approach seems fine overall, though it should be moved out of a use-package hook when we merge it into Snail. The crash must have come from vterm. Do you think you can reproduce it well enough to open a ticket there?

gcv avatar Jan 14 '21 17:01 gcv

I modified the hook into

:hook ((julia-snail-repl-mode . (lambda()
                                  (with-current-buffer julia-snail-repl-buffer
                                    (setq-local compilation-error-regexp-alist-alist
                                                julia-snail--compilation-regexp-alist)
                                    (setq-local compilation-error-regexp-alist
                                                (mapcar #'car compilation-error-regexp-alist-alist))
                                    (compilation-shell-minor-mode 1)
                                    (setq-local compilation-search-path (list (julia-snail--capture-basedir julia-snail-repl-buffer)))
                                    ))))

and it now works without crashing. I am not sure I retrieved the cached basedir correctly earlier, so that was probably the reason for the (SIGSEGV) crash. It should work without problems if implemented in Snail :slightly_smiling_face:

martinbiel avatar Jan 14 '21 22:01 martinbiel

Looks good, thanks!

gcv avatar Jan 14 '21 23:01 gcv

Of note, the original functionality in the error buffer appears like this: image while the same error link in the julia-snail-buffer (using the use-hook above) appears like this image In other words, it show the full path for some reason. Also, this particular error link is not clickable, which also seem to happen at times. I am not that confident in Elisp, so I cannot really suggest any reason for this discrepancy, or why the links are sometimes not clickable, but I thought it could be worthwhile to point out.

martinbiel avatar Jan 15 '21 15:01 martinbiel

@martinbiel: Looking to merge this suggestion. I can't get clickable links in vterm buffers at all. Can you confirm that it worked intermittently for you? I'm wondering if vterm behavior with regard to allowing links changed between the time you opened this ticket and now.

gcv avatar Jul 29 '21 19:07 gcv

@martinbiel: Take a look at this branch which essentially copies your hook: https://github.com/gcv/julia-snail/tree/compilation-mode-in-repl

It doesn't seem to make the REPL clickable for me.

gcv avatar Jul 30 '21 02:07 gcv

This would be a very useful feature. Unfortunately, it doesn't seem to be able to find the path of the currently edited file for some reason.

prittjam avatar Oct 07 '21 12:10 prittjam