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

Calling help from a popup help window replaces the popup window with a regular window #131

Open
bmag opened this issue Dec 6, 2015 · 5 comments

Comments

@bmag
Copy link

bmag commented Dec 6, 2015

Bug reproduction steps:

    1. start emacs: emacs -Q -l "/path/to/popwin.el"
    1. paste this content to scratch buffer, and load it with M-x eval-buffer:
(setq popwin:special-display-config '((help-mode :position right)))
(popwin-mode)
    1. call help: C-h f popwin-mode RET. my window layout is now this:
+----------+----------+
|          |          |
|          |          |
|          |          |
| scratch  | help     |
|          |          |
|          |          |
|          |          |
+----------+----------+
    1. call help again: C-h f popwin-mode RET. my window layout is now this:
+-----------------------+
|                       |
|     scratch           |
|                       |
+-----------------------+
|                       |
|     help              |
|                       |
+-----------------------+

And pressing C-g doesn't close the help window.

This bug also happens when I press RET on links ("xrefs") inside the help window.

@arunce
Copy link

arunce commented Apr 5, 2016

This happens a lot to me. I have coded this temporary solution that bypass some popwin features, without losing its functions:
https://github.com/arunce/emacs-makesure

@rakete
Copy link

rakete commented Jun 14, 2016

Same problem here, just found this issue via google wondering how to fix it. Also happens when clicking on 'links' in a help buffer.

@arunce could you explain how your emacs-makesure helps bypass this issue?

Is this possibly emacs 25 related? I just upgraded and I don't think I had that problem with 24.5

@arunce
Copy link

arunce commented Jun 15, 2016

@rakete it's mostly a workaround that mitigates some nasty problems between sr-speedbar and popwin, but it works with other windows if you call them with a shortcut.

Like this:
(global-set-key [f4] ( lambda () (interactive) (makesure:it-pops "*shell*" t 'shell)))

"shell" is the window name, t or nil if you want focus or not and the 'shell process/function name which will be called if not active.

Also, it helps with the c-g problem mentioned above.

I'm still using emacs 24.5.

@rakete
Copy link

rakete commented Aug 11, 2016

I never figured out how to apply your solution to this particular problem @arunce. But I did come up with my own workaround in the meantime:

(defadvice display-buffer (around display-buffer-prevent-popwin-split last activate)
  (let* ((buffer (ad-get-arg 0)))
    (if (and (string-equal (buffer-name buffer) "*Help*")
                (get-buffer-window buffer))
        (let ((display-buffer-alist nil))
          ad-do-it)
      ad-do-it)))

The problem is that clicking a button in a help buffer erases the help buffer, fills it with new content and then eventually calls display-buffer on that same already displayed buffer. The display-buffer function examines display-buffer-alist for a matching function and finds the popwin:display-buffer-action and calls it, causing the problem described in this issue.

So my workaround works by changing the display-buffer so that it won't be able to call popwin:display-buffer-action on an already displayed help buffer by setting display-buffer-alist to nil, but only for help buffers that are already displayed, and nothing else.

Since display-buffer is a very important function this workaround may cause some unforseen side issues. Handle with care.

@Compro-Prasad
Copy link

I don't think @m2ym is actively maintaining this repository.

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

No branches or pull requests

4 participants