all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* info-look.el bug
@ 2004-02-01 14:48 Stephen Eglen
  2004-02-03  1:25 ` Kevin Rodgers
       [not found] ` <mailman.1759.1075771606.928.bug-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 7+ messages in thread
From: Stephen Eglen @ 2004-02-01 14:48 UTC (permalink / raw)


Hi, 

I think I've found a little bug in info-look.el.  If anyone out there
regularly uses info-look.el, could they please check the following and
get back to me?

% emacs -q

In the *scratch* buffer, type "C-h S defun RET". The frame should divide
into two: the top window shows *scratch* and the bottom window shows
the definition of "defun" from the elisp *info*.

Still in the scratch buffer, type "C-h S setq RET".  This time the
*scratch* buffer disappears and is replaced by another window showing
*info* for setq; so now, both windows are showing an info node, but
the scratch buffer has gone.

I think this behaviour is wrong, and that if the *info* buffer is
already visible, it should not be viewed again in another window.  I
think have tracked down the problem to the call in info-lookup where
it calls Info-goto-node.  

I think this problem can be solved by using save-window-excursion, but
then on the second call to C-h S, the highlighting is not shown.
Anyone have a better idea of how to solve this?

Thanks, Stephen

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
  2004-02-01 14:48 info-look.el bug Stephen Eglen
@ 2004-02-03  1:25 ` Kevin Rodgers
       [not found] ` <mailman.1759.1075771606.928.bug-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 7+ messages in thread
From: Kevin Rodgers @ 2004-02-03  1:25 UTC (permalink / raw)


Stephen Eglen wrote:

> Hi, 
> 
> I think I've found a little bug in info-look.el.  If anyone out there
> regularly uses info-look.el, could they please check the following and
> get back to me?
> 
> % emacs -q
> 
> In the *scratch* buffer, type "C-h S defun RET". The frame should divide
> into two: the top window shows *scratch* and the bottom window shows
> the definition of "defun" from the elisp *info*.
> 
> Still in the scratch buffer, type "C-h S setq RET".  This time the
> *scratch* buffer disappears and is replaced by another window showing
> *info* for setq; so now, both windows are showing an info node, but
> the scratch buffer has gone.
> 
> I think this behaviour is wrong, and that if the *info* buffer is
> already visible, it should not be viewed again in another window.  I
> think have tracked down the problem to the call in info-lookup where
> it calls Info-goto-node.  
> 
> I think this problem can be solved by using save-window-excursion, but
> then on the second call to C-h S, the highlighting is not shown.
> Anyone have a better idea of how to solve this?

I think it is caused by the default value of same-window-buffer-names,

which includes "*info*".  Here's a patch:

*** emacs-21.3/lisp/info-look.el.orig	Fri Oct 18 19:21:07 2002
--- emacs-21.3/lisp/info-look.el	Mon Feb  2 18:19:02 2004
***************
*** 338,345 ****
   	  (if (and info-frame
   		   (display-multi-frame-p)
   		   (memq info-frame (frames-on-display-list)))
! 	    (select-frame info-frame)
! 	  (switch-to-buffer-other-window "*info*")))))
       (while (and (not found) modes)
         (setq doc-spec (info-lookup->doc-spec topic (car modes)))
         (while (and (not found) doc-spec)
--- 338,347 ----
   	  (if (and info-frame
   		   (display-multi-frame-p)
   		   (memq info-frame (frames-on-display-list)))
!               (select-frame info-frame)
!             (let ((same-window-buffer-names
!                    (delete "*info*" same-window-buffer-names)))
!               (switch-to-buffer-other-window "*info*"))))))
       (while (and (not found) modes)
         (setq doc-spec (info-lookup->doc-spec topic (car modes)))
         (while (and (not found) doc-spec)

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
       [not found] ` <mailman.1759.1075771606.928.bug-gnu-emacs@gnu.org>
@ 2004-02-03 17:04   ` Kevin Rodgers
  2004-02-05 14:52     ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin Rodgers @ 2004-02-03 17:04 UTC (permalink / raw)


Kevin Rodgers wrote:

> I think it is caused by the default value of same-window-buffer-names,
> which includes "*info*".


BTW, I also tried replacing (switch-to-buffer-other-window "*info*") with
(pop-to-buffer "*info*" t), but both functions let same-window-buffer-names
take precedence over the other-window intent of the programmer.  Is that
correct behavior, or is it a bug?  If it's a bug, I think it could be fixed
simply by let-binding same-window-buffer-names and same-window-regexps to
nil around the call to display-buffer within switch-to-buffer-other-window
and pop-to-buffer (when pop-to-buffer's OTHER-WINDOW arg is non-nil).  What
do you think?

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
  2004-02-03 17:04   ` Kevin Rodgers
@ 2004-02-05 14:52     ` Richard Stallman
  2004-02-06 20:30       ` Kevin Rodgers
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2004-02-05 14:52 UTC (permalink / raw)
  Cc: emacs-devel

When you want to switch to a buffer and let display-buffer choose
where it should appear, you use pop-to-buffer.  I think it is a bug
for switch-to-buffer-other-window to obey same-window-buffer-names
or same-window-regexps.  So I think this change is called for.

However, it may be that some existing calls to
switch-to-buffer-other-window would need to be changed to use
pop-to-buffer.


*** files.el.~1.677.~	Fri Jan 16 12:19:44 2004
--- files.el	Thu Feb  5 01:07:44 2004
***************
*** 850,856 ****
  This uses the function `display-buffer' as a subroutine; see its
  documentation for additional customization information."
    (interactive "BSwitch to buffer in other window: ")
!   (let ((pop-up-windows t))
      (pop-to-buffer buffer t norecord)))
  
  (defun switch-to-buffer-other-frame (buffer &optional norecord)
--- 850,857 ----
  This uses the function `display-buffer' as a subroutine; see its
  documentation for additional customization information."
    (interactive "BSwitch to buffer in other window: ")
!   (let ((pop-up-windows t)
! 	same-window-buffer-names same-window-regexps)
      (pop-to-buffer buffer t norecord)))
  
  (defun switch-to-buffer-other-frame (buffer &optional norecord)
***************
*** 861,867 ****
  This uses the function `display-buffer' as a subroutine; see its
  documentation for additional customization information."
    (interactive "BSwitch to buffer in other frame: ")
!   (let ((pop-up-frames t))
      (pop-to-buffer buffer t norecord)
      (raise-frame (window-frame (selected-window)))))
  
--- 862,869 ----
  This uses the function `display-buffer' as a subroutine; see its
  documentation for additional customization information."
    (interactive "BSwitch to buffer in other frame: ")
!   (let ((pop-up-frames t)
! 	same-window-buffer-names same-window-regexps)
      (pop-to-buffer buffer t norecord)
      (raise-frame (window-frame (selected-window)))))

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
  2004-02-05 14:52     ` Richard Stallman
@ 2004-02-06 20:30       ` Kevin Rodgers
  2004-02-07 19:34         ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Kevin Rodgers @ 2004-02-06 20:30 UTC (permalink / raw)


Richard Stallman wrote:

> When you want to switch to a buffer and let display-buffer choose
> where it should appear, you use pop-to-buffer.  I think it is a bug
> for switch-to-buffer-other-window to obey same-window-buffer-names
> or same-window-regexps.  So I think this change is called for.
> 
> However, it may be that some existing calls to
> switch-to-buffer-other-window would need to be changed to use
> pop-to-buffer.

I agree with your change, but I don't think it goes far enough.  Here's
what pop-to-buffer's doc string says:

| If optional second arg OTHER-WINDOW is non-nil, insist on finding another
| window even if BUFFER is already visible in the selected window.

To me, that means that no calls to (pop-to-buffer BUFFER t ...) should
obey same-window-buffer-names or -regexps, not just those in
switch-to-buffer-other-window and -frame.  And so I think the job of
temporarily binding same-window-buffer-names and -regexps should be done
in pop-to-buffer:

(let ((same-window-buffer-names (if other-window
				    nil
				  same-window-buffer-names))
       (same-window-regexps (if other-window
			       nil
			     same-window-regexps)))
   ...)

Unfortunately, pop-to-buffer is implemented in C and I don't know how to
write that fragment in C.

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
  2004-02-06 20:30       ` Kevin Rodgers
@ 2004-02-07 19:34         ` Richard Stallman
  2004-02-09 20:34           ` Kevin Rodgers
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2004-02-07 19:34 UTC (permalink / raw)
  Cc: emacs-devel

    To me, that means that no calls to (pop-to-buffer BUFFER t ...) should
    obey same-window-buffer-names or -regexps, not just those in
    switch-to-buffer-other-window and -frame.

In fact, that seems to be what the current code does.
So now I don't understand why the bug happens.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: info-look.el bug
  2004-02-07 19:34         ` Richard Stallman
@ 2004-02-09 20:34           ` Kevin Rodgers
  0 siblings, 0 replies; 7+ messages in thread
From: Kevin Rodgers @ 2004-02-09 20:34 UTC (permalink / raw)


Richard Stallman wrote:
 >     To me, that means that no calls to (pop-to-buffer BUFFER t ...) should
 >     obey same-window-buffer-names or -regexps, not just those in
 >     switch-to-buffer-other-window and -frame.
 >
 > In fact, that seems to be what the current code does.
 > So now I don't understand why the bug happens.

Although the original bug report was sent to the emacs-devel@gnu.org
mailing list, it was apparently about Emacs 21.3 (not CVS Emacs):

	From: Stephen Eglen <stephen@inf.ed.ac.uk>
	To: emacs-devel@gnu.org
	Subject: info-look.el bug
	Date: Sun, 1 Feb 2004 14:48:31 +0000
	Message-ID: <16413.4543.492252.351095@bushmills.inf.ed.ac.uk>
	X-Mailer: VM 7.17 under Emacs 21.3.2

I confirmed that the bug is present in Emacs 21.3, so I sent a patch to
the gnu.emacs.bug newsgroup.

-- 
Kevin Rodgers

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-02-09 20:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-01 14:48 info-look.el bug Stephen Eglen
2004-02-03  1:25 ` Kevin Rodgers
     [not found] ` <mailman.1759.1075771606.928.bug-gnu-emacs@gnu.org>
2004-02-03 17:04   ` Kevin Rodgers
2004-02-05 14:52     ` Richard Stallman
2004-02-06 20:30       ` Kevin Rodgers
2004-02-07 19:34         ` Richard Stallman
2004-02-09 20:34           ` Kevin Rodgers

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.