home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / alt / lucidem / help / 249 next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.0 KB

  1. Path: sparky!uunet!mcsun!uknet!edcastle!aifh!aifh!tfb
  2. From: tfb@aisb.ed.ac.uk (Tim Bradshaw)
  3. Newsgroups: alt.lucid-emacs.help
  4. Subject: Re: 2 questions
  5. Message-ID: <TFB.92Aug12134552@eagle.aisb.ed.ac.uk>
  6. Date: 12 Aug 92 12:45:52 GMT
  7. References: <9208112202.AA03604@maestro.mitre.org>
  8.     <9208112232.AA14929@thalidomide.lucid>
  9. Sender: news@aifh.ed.ac.uk (Network News Administrator)
  10. Organization: Not
  11. Lines: 32
  12. In-Reply-To: jwz@lucid.com's message of 11 Aug 92 22:32:44 GMT
  13.  
  14. >>>>> On 11 Aug 92 22:32:44 GMT, jwz@lucid.com (Jamie Zawinski) said:
  15.  
  16. > In message <9208112202.AA03604@maestro.mitre.org> Michael Lamoureux wrote:
  17. >>
  18. >> I was trying to get get-screen-for-buffer to work as documented.  I did a
  19. >> grep through the source, and I determined that get-screen-for-buffer never
  20. >> get's called.
  21.  
  22. > It's called by virtue of begin the value of pre-display-buffer-hook, which 
  23. > is called from display-buffer.  The problem is that there are several other
  24. > ways that buffers can get displayed besides calling display-buffer.  If you 
  25. > do find-file, it just calls switch-to-buffer, meaning reuse the current 
  26. > window. If you do find-file-other-window, it uses display-buffer, so it
  27. > should pop up in another screen.
  28.  
  29. >> I don't know why it works at all, and I don't know why, if it works at all,
  30. >> that it doesn't work as documented.  
  31.  
  32. > I think it does work as documented, but it's not clear that what it does is
  33. > all that useful.
  34.  
  35. I think that get-screen-for-buffer works correctly.  However I am
  36. fairly sure that the code that drives it is broken in some way.  I
  37. have code that uses it to display manual pages in their own screens &
  38. quite often but in some unpredictable way, the wrong buffer ends up in
  39. the newly created screen.  I looked at what get-screen-for-buffer was
  40. doing and it creates & returns the correct screen, but somewhere after
  41. then the buffer-screen correspondence is lost.  I couldn't really work
  42. out what was doing this but it seemed to be obscure, and I'm still not
  43. 100% sure it's not my misunderstanding of what is meant to happen.
  44.  
  45. --tim
  46.