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

Emacs 26 xref window management broke code1 #127

Closed
wyuenho opened this issue May 30, 2018 · 9 comments
Closed

Emacs 26 xref window management broke code1 #127

wyuenho opened this issue May 30, 2018 · 9 comments
Labels

Comments

@wyuenho
Copy link
Collaborator

wyuenho commented May 30, 2018

screen capture

Steps to reproduce

  1. Install Emacs 26.1 (I've tested on the NS and the Mituharu Mac port)
  2. Call (purpose-x-code1-setup) in .emacs
  3. Visit an ELISP file that has a symbol that will pop up an xref buffer for selection after (xref-find-definitions) (I visited company.el)
  4. Adjust the edit window's width to something "small enough" (the screen cap edit window has a 93 (window-total-width)
  5. Move point to the symbol (I moved to company-backends)
  6. Press M-.
  7. The window showing the xref buffer is covered with an extra dired buffer
  8. Press q exits the dired buffer
  9. Press q again to exit the xref buffer
  10. Now we are back to the dired buffer we just quit and buried.
  11. Press q twice to exit the dired buffer
  12. Now there are 2 windows showing the file we visited.

Expected behavior

The extra dired window should never show up to begin with.

I've git-bisected this issue to be caused by this commit to Emacs 26, all subsequent commits shows the same behavior.

I'm not exactly sure what's going on here, does this have something to do with some weird interaction with #98 ?

P.S. I have pop-up-frames set to nil.

@wyuenho wyuenho changed the title Emacs 26 xref broke code1 Emacs 26 xref window management broke code1 May 30, 2018
@bmag
Copy link
Owner

bmag commented May 30, 2018

Couldn't reproduce it locally with, but did encounter some weirdness when using code1 while purpose-mode is disabled (which I think is to be expected).

Your repro steps don't mention if purpose-mode is enabled or not. Does this bug happen with or without purpsoe-mode?

@bmag bmag added the bug label May 30, 2018
@wyuenho
Copy link
Collaborator Author

wyuenho commented May 30, 2018

I have purpose-mode enabled.

@wyuenho
Copy link
Collaborator Author

wyuenho commented May 30, 2018

I was able to reproduce this with open -a emacs --args -Q and just window-purpose and company installed. I then M-x purpose-mode and followed up with M-x company-mode to warm up xref, and then tried M-. on one of the backend symbols on company-backends again.

@bmag
Copy link
Owner

bmag commented May 30, 2018

I think I found the bug, will fix tomorrow or the day after.

@bmag
Copy link
Owner

bmag commented May 31, 2018

Should be fixed by a393b85

@bmag bmag closed this as completed May 31, 2018
@wyuenho
Copy link
Collaborator Author

wyuenho commented May 31, 2018

This fix made things much worst. Now a dired buffer will pop open and take over the edit buffer whenever I visit a file. The post-command-hook that updates the dired buffer also put it onto the edit buffer after every command

@bmag
Copy link
Owner

bmag commented May 31, 2018

Reverted for now.

@bmag bmag reopened this May 31, 2018
@wyuenho
Copy link
Collaborator Author

wyuenho commented May 31, 2018

Actually my mistake, the buffer does display at the correct window with this fix and the xref problem is gone, but hide-details mode did not take effect because that mode is buffer-local you have to wrap it in a with-current-buffer. I'll submit a fix now.

wyuenho added a commit to wyuenho/emacs-purpose that referenced this issue May 31, 2018
…cs 26, this fix lets purpose handle displaying it
@bmag bmag closed this as completed in 8737c5d May 31, 2018
@bmag
Copy link
Owner

bmag commented May 31, 2018

Ah, ok. Merged the fix, thanks.

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

No branches or pull requests

2 participants