Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error buffer doesn't go away when it should #68

Open
dahtah opened this issue Nov 16, 2021 · 5 comments
Open

error buffer doesn't go away when it should #68

dahtah opened this issue Nov 16, 2021 · 5 comments

Comments

@dahtah
Copy link
Contributor

dahtah commented Nov 16, 2021

This is a really minor annoyance but it should be easy to fix. What typically happens for me when I load a buffer into Julia that has an error in it is that the focus switches to the error buffer (good), then I follow the stack trace from the error buffer to the line that caused the error (still good), I fix the error, hit C-c C-k again, at which point the buffer loads successfully but the error buffer hasn't gone away. I'd suggest killing the error buffer and removing the window automatically whenever julia-snail-send-buffer-file is successful. This more or less does the job:

(defun julia-snail--kill-error-buffer ()
  (set-buffer "*julia* error")
  (kill-this-buffer)
  (if (not (one-window-p))
      (delete-window)))

The problem is that if you have two windows, one with the code and one with the REPL, then the error buffer opens a third, and when it's closed by the function above the code and REPL windows get switched around. I don't know enough about emacs' handling of windows to fix this, I'm afraid.

@gcv
Copy link
Owner

gcv commented Nov 16, 2021

I have some notes about this in the README (https://github.com/gcv/julia-snail#display-buffer-alist-notes) and link to my rant on the subject in the other Emacs package I maintain (https://github.com/nex3/perspective-el/#some-musings-on-emacs-window-layouts). You should try my suggested settings, they really do make Emacs much better-behaved with regard to window handling.

I don’t want to get into the business of saving and restoring window layouts depending on session state. It’s too much work with too many edge and corner cases dependent on user configuration.

@gcv gcv added the discussion label Nov 16, 2021
@dahtah
Copy link
Contributor Author

dahtah commented Nov 18, 2021

OK, thanks. This led me to discover popper which I recommend. I think a good solution would be to add a hook right in julia-snail-send-buffer file (right before "loaded: module %s") so that users can provide custom code. Using popper for instance you get reasonable behaviour with:

(defun julia-snail--tidy-up-error-buffer
    ()
  (popper--bury-all)
  (kill-buffer   "*julia* error")
  )

@gcv
Copy link
Owner

gcv commented Nov 18, 2021

I'm open to adding a hook. Doesn't popper need a bit more configuration than that, though? Something like:

(setq popper-reference-buffers '(julia-snail-message-buffer-mode))

Also, your kill-buffer invocation won't do the right thing if julia-snail-repl-buffer is not the string "*julia*" (as would be required for running multiple REPLs).

@dahtah
Copy link
Contributor Author

dahtah commented Nov 22, 2021

You're right on both counts. With the default config suggested in the popper readme, you get the right behaviour (any buffer with compilation-mode is treated as a popup, including julia-snail's error buffer). On your second point, I personally never use multiple REPLs, so I always forget to check for that. I don't think there's a function yet that returns the appropriate error buffer for a given repl?

@gcv
Copy link
Owner

gcv commented Nov 22, 2021

Unfortunately no, no helper function for getting the right error buffer exists at the moment. Introducing it necessitates a minor refactoring pass, see sample use in julia-snail--response-failure and julia-snail--message-buffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants