* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error @ 2011-06-13 22:21 Glenn Morris 2011-06-13 22:23 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-13 22:21 UTC (permalink / raw) To: 8857 Package: emacs With the current trunk: ./src/emacs -Q -batch README INSTALL Makefile Loading vc-bzr... Unknown terminal type (exits with status /= 0) OK, this is not a very sensible example, but it illustrates the point. It's caused by display-buffer trying to pop-up a frame in batch-mode and is very recent. Emacs 23 does not have this problem by default, but the following shows the same issue: emacs-23.3 -Q -batch --eval '(setq pop-up-frames t)' README INSTALL Makefile ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-13 22:21 bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error Glenn Morris @ 2011-06-13 22:23 ` Glenn Morris 2011-06-14 9:16 ` martin rudalics 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-13 22:23 UTC (permalink / raw) To: 8857 PS I forgot to say that I think display-buffer should not try to pop-up frames (or do anything at all?) in batch-mode. Or if it must give an error it should try to give a more helpful one than "Unknown terminal type". ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-13 22:23 ` Glenn Morris @ 2011-06-14 9:16 ` martin rudalics 2011-06-14 16:19 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-14 9:16 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 > OK, this is not a very sensible example, but it illustrates the point. > It's caused by display-buffer trying to pop-up a frame in batch-mode and > is very recent. Can you tell me where and why `display-buffer' is called? > PS I forgot to say that I think display-buffer should not try to pop-up > frames (or do anything at all?) in batch-mode. Or if it must give an > error it should try to give a more helpful one than "Unknown terminal > type". In particular not with emacs -Q. But I have no experience debugging emacs with the batch option. So before delving into this maybe you could give me more information? Note that while `pop-up-frames' has the optional value graphic-only which should prevent Emacs from popping up frames on non-graphic systems, that value is consistently overridden by applications that bind `pop-up-frames' to t. But I don't think that's related. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 9:16 ` martin rudalics @ 2011-06-14 16:19 ` Glenn Morris 2011-06-14 17:14 ` martin rudalics 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-14 16:19 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics wrote: >> OK, this is not a very sensible example, but it illustrates the point. >> It's caused by display-buffer trying to pop-up a frame in batch-mode and >> is very recent. > > Can you tell me where and why `display-buffer' is called? I don't know. From `find-file' I guess. I noticed because of this: http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00004.html (which was due to custom-make-dependencies leaving files on the command-line so they were processed as normal file arguments) >> PS I forgot to say that I think display-buffer should not try to pop-up >> frames (or do anything at all?) in batch-mode. Or if it must give an >> error it should try to give a more helpful one than "Unknown terminal >> type". > > In particular not with emacs -Q. But I have no experience debugging > emacs with the batch option. So before delving into this maybe you > could give me more information? Maybe display-buffer should just be a no-op in batch-mode, since it's impossible (?) to display anything then (except via the echo area). (defun display-buffer () "" (unless noninteractive ...)) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 16:19 ` Glenn Morris @ 2011-06-14 17:14 ` martin rudalics 2011-06-14 17:20 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-14 17:14 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 >> Can you tell me where and why `display-buffer' is called? > > I don't know. From `find-file' I guess. I noticed because of this: > > http://lists.gnu.org/archive/html/emacs-buildstatus/2011-06/msg00004.html > > (which was due to custom-make-dependencies leaving files on the > command-line so they were processed as normal file arguments) I see. But I wonder why this wasn't a problem before (that is, the idea of popping up a new frame). > Maybe display-buffer should just be a no-op in batch-mode, since it's > impossible (?) to display anything then (except via the echo area). > > (defun display-buffer () "" > (unless noninteractive > ...)) That would be trivial to do. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 17:14 ` martin rudalics @ 2011-06-14 17:20 ` Glenn Morris 2011-06-14 17:56 ` martin rudalics 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-14 17:20 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics wrote: > But I wonder why this wasn't a problem before (that is, the idea of > popping up a new frame). I guess because pop-up-frames defaults to nil in Emacs 23. But in the trunk, a default Emacs may now pop-up a frame if it thinks it necessary. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 17:20 ` Glenn Morris @ 2011-06-14 17:56 ` martin rudalics 2011-06-14 18:25 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-14 17:56 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 > I guess because pop-up-frames defaults to nil in Emacs 23. Emacs 23 could pop up new frame provided the selected frame isn't "usable". > But in the trunk, a default Emacs may now pop-up a frame if it thinks it > necessary. I only tried to mimic Emacs 23 here. So if the original frame cannot be used it does try to pop up a new one. Doesn't Emacs make an invisible frame in batch mode? Maybe the problem happens because I now load window.el _before_ files.el. So in Emacs 23 files.el maybe tried to display a buffer but failed silently. What happens generally in batch mode when you call `display-buffer', for example, during a backtrace? martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 17:56 ` martin rudalics @ 2011-06-14 18:25 ` Glenn Morris 2011-06-14 19:09 ` martin rudalics 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-14 18:25 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics wrote: >> I guess because pop-up-frames defaults to nil in Emacs 23. > > Emacs 23 could pop up new frame provided the selected frame isn't > "usable". I confess I did not look into precisely what Emacs 23 does, I just saw that pop-up-frames defaults to nil there. (See below.) >> But in the trunk, a default Emacs may now pop-up a frame if it thinks it >> necessary. > > I only tried to mimic Emacs 23 here. So if the original frame cannot be > used it does try to pop up a new one. Doesn't Emacs make an invisible > frame in batch mode? > > Maybe the problem happens because I now load window.el _before_ > files.el. So in Emacs 23 files.el maybe tried to display a buffer but > failed silently. I don't think that can be it. Here's what the addition of a simple: (message "%s:%s" buffer-or-name method) to display-buffer in the trunk shows: ./src/emacs -Q -batch README INSTALL BUGS INSTALL:reuse-window INSTALL:pop-up-window BUGS:reuse-window BUGS:pop-up-window BUGS:pop-up-frame Unknown terminal type Adding similar stuff to emacs-23, I see that display-buffer's cond tries the special-display-function branch (no match), the pop-up-windows branch (no window-to-use), and ends up in the last branch, where it finds a window-to-use every time. So it never tries to pop-up a frame. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 18:25 ` Glenn Morris @ 2011-06-14 19:09 ` martin rudalics 2011-06-15 7:29 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-14 19:09 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 > Adding similar stuff to emacs-23, I see that display-buffer's cond tries > the special-display-function branch (no match), the pop-up-windows > branch (no window-to-use), and ends up in the last branch, where it > finds a window-to-use every time. So it never tries to pop-up a frame. Emacs 23 tries to pop up a frame only when the selected frame is a minibuffer frame. I shall add an appropriate condition in Emacs 24. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-14 19:09 ` martin rudalics @ 2011-06-15 7:29 ` Glenn Morris 2011-06-15 8:01 ` martin rudalics 2011-06-15 14:36 ` Stefan Monnier 0 siblings, 2 replies; 31+ messages in thread From: Glenn Morris @ 2011-06-15 7:29 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 In addition I still think it might be worth explicitly making display-buffer a no-op in batch mode, unless someone can think of something it can actually do in such cases. I think this could only be by side effect. Eg, can it run hooks, and can those hooks be expected to do anything when there isn't actually a display? If not then it seems simpler and more efficient to not even try displaying buffers in batch mode (and less confusing, since it can give unclear errors trying to do something that cannot work). ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 7:29 ` Glenn Morris @ 2011-06-15 8:01 ` martin rudalics 2011-06-15 16:17 ` Glenn Morris 2011-06-15 17:01 ` David Engster 2011-06-15 14:36 ` Stefan Monnier 1 sibling, 2 replies; 31+ messages in thread From: martin rudalics @ 2011-06-15 8:01 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 > In addition I still think it might be worth explicitly making > display-buffer a no-op in batch mode, unless someone can think of > something it can actually do in such cases. I think this could only be > by side effect. Eg, can it run hooks, and can those hooks be expected to > do anything when there isn't actually a display? > > If not then it seems simpler and more efficient to not even try > displaying buffers in batch mode (and less confusing, since it can give > unclear errors trying to do something that cannot work). There's a silent convention that `display-buffer' _always_ returns a window. If it doesn't in batch mode, code relying on that convention might break. I don't know how realistic such a scenario is, though. Meanwhile I checked in two fixes that should assure that `display-buffer' doesn't try to pop up a frame with emacs -Q. If they work, you should be able to remove your earlier hack. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 8:01 ` martin rudalics @ 2011-06-15 16:17 ` Glenn Morris 2011-06-15 17:01 ` David Engster 1 sibling, 0 replies; 31+ messages in thread From: Glenn Morris @ 2011-06-15 16:17 UTC (permalink / raw) To: 8857-done Stefan Monnier wrote: > "batch mode" and "server mode" are *very* closely related. So I'd stay > away from any attempt to special case "batch mode". martin rudalics wrote: > There's a silent convention that `display-buffer' _always_ returns a > window. If it doesn't in batch mode, code relying on that convention > might break. I don't know how realistic such a scenario is, though. OK, no problem, let's not bother with it then. > Meanwhile I checked in two fixes that should assure that > `display-buffer' doesn't try to pop up a frame with emacs -Q. If they > work, you should be able to remove your earlier hack. If you mean the cus-dep thing, then it was a correct change, independent of this issue, and should remain. I'll close this, thanks. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 8:01 ` martin rudalics 2011-06-15 16:17 ` Glenn Morris @ 2011-06-15 17:01 ` David Engster 2011-06-15 17:45 ` martin rudalics 2011-06-16 9:23 ` martin rudalics 1 sibling, 2 replies; 31+ messages in thread From: David Engster @ 2011-06-15 17:01 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics writes: > Meanwhile I checked in two fixes that should assure that > `display-buffer' doesn't try to pop up a frame with emacs -Q. If they > work, you should be able to remove your earlier hack. Is this supposed to also fix the problem for batch mode? Because I still see this error with revno. 104589: --> emacs --batch foo bar baz Unknown terminal type Actually, this currently breaks the CEDET build, because it uses a hack to provide arguments for functions called with the "-f" switch... -David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 17:01 ` David Engster @ 2011-06-15 17:45 ` martin rudalics 2011-06-15 18:09 ` Glenn Morris 2011-06-15 18:30 ` David Engster 2011-06-16 9:23 ` martin rudalics 1 sibling, 2 replies; 31+ messages in thread From: martin rudalics @ 2011-06-15 17:45 UTC (permalink / raw) To: David Engster; +Cc: 8857 > Is this supposed to also fix the problem for batch mode? Because I still > see this error with revno. 104589: It was supposed to fix that, yes. > --> emacs --batch foo bar baz > Unknown terminal type Can you check whether `display-buffer' tries to pop up a new buffer? I don't have the slightest experience running Emacs in batch mode. > Actually, this currently breaks the CEDET build, because it uses a hack > to provide arguments for functions called with the "-f" switch... Maybe Glenn can tell us what's going on? martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 17:45 ` martin rudalics @ 2011-06-15 18:09 ` Glenn Morris 2011-06-15 18:13 ` David Engster 2011-06-15 18:30 ` David Engster 1 sibling, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-15 18:09 UTC (permalink / raw) To: martin rudalics; +Cc: David Engster, 8857 martin rudalics wrote: > Maybe Glenn can tell us what's going on? Haha, nope, except to point out that you said: > Meanwhile I checked in two fixes that should assure that > `display-buffer' doesn't try to pop up a frame with emacs -Q. whereas the quoted recipe: >> --> emacs --batch foo bar baz >> Unknown terminal type does not use -Q. (Therefore I guess it would fail in the same way for anyone using Emacs 23 who happens to have set pop-up-frames = t in their .emacs.) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 18:09 ` Glenn Morris @ 2011-06-15 18:13 ` David Engster 2011-06-15 19:16 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: David Engster @ 2011-06-15 18:13 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 Glenn Morris writes: > martin rudalics wrote: > >> Maybe Glenn can tell us what's going on? > > Haha, nope, except to point out that you said: > >> Meanwhile I checked in two fixes that should assure that >> `display-buffer' doesn't try to pop up a frame with emacs -Q. > > whereas the quoted recipe: > >>> --> emacs --batch foo bar baz >>> Unknown terminal type > > does not use -Q. It also fails with "-Q" (and "--batch" implies "-q", at least). Cheers, David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 18:13 ` David Engster @ 2011-06-15 19:16 ` Glenn Morris 0 siblings, 0 replies; 31+ messages in thread From: Glenn Morris @ 2011-06-15 19:16 UTC (permalink / raw) To: David Engster; +Cc: 8857 David Engster wrote: > It also fails with "-Q" (and "--batch" implies "-q", at least). Oh, I forgot that batch implies -q. Yes, it's still trying to pop-up frames for me too. ./src/emacs -Q -batch BUGS README INSTALL README:reuse-window README:pop-up-window INSTALL:reuse-window INSTALL:pop-up-window INSTALL:pop-up-frame Unknown terminal type ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 17:45 ` martin rudalics 2011-06-15 18:09 ` Glenn Morris @ 2011-06-15 18:30 ` David Engster 2011-06-15 19:32 ` martin rudalics 1 sibling, 1 reply; 31+ messages in thread From: David Engster @ 2011-06-15 18:30 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics writes: >> Is this supposed to also fix the problem for batch mode? Because I still >> see this error with revno. 104589: > > It was supposed to fix that, yes. > >> --> emacs --batch foo bar baz >> Unknown terminal type > > Can you check whether `display-buffer' tries to pop up a new buffer? I > don't have the slightest experience running Emacs in batch mode. I don't know if this is what you're looking for, but when I run this: --> emacs --batch -Q --eval "(debug-on-entry 'display-buffer-pop-up-window)" foo bar baz I get this: Debugger entered--entering a function: display-buffer-pop-up-window(#<buffer bar> ((largest) (lru)) ((pop-up-frame) (reuse-window other other visible) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (reuse-window other other nil) (reuse-window-even-sizes . t) (reuse-window nil same visible) (pop-up-window (largest) (lru)) (pop-up-frame) (pop-up-frame-alist (height . 24) (width . 80) (unsplittable . t)) (reuse-window nil other visible) (reuse-window-even-sizes . t))) * display-buffer(#<buffer bar> other-window nil) pop-to-buffer(#<buffer bar> other-window nil) switch-to-buffer-other-window(#<buffer bar>) find-file-other-window("/home/void/bar") command-line-1(("--eval" "(debug-on-entry 'display-buffer-pop-up-window)" "foo" "bar" "baz")) command-line() normal-top-level() Cheers, David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 18:30 ` David Engster @ 2011-06-15 19:32 ` martin rudalics 2011-06-15 19:42 ` David Engster 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-15 19:32 UTC (permalink / raw) To: David Engster; +Cc: 8857 > I don't know if this is what you're looking for, but when I run this: More or less so, thanks. Putting the debug-on-entry on `display-buffer-pop-up-frame' would have been more indicative. > --> emacs --batch -Q --eval "(debug-on-entry 'display-buffer-pop-up-window)" foo bar baz > > I get this: > > Debugger entered--entering a function: > display-buffer-pop-up-window(#<buffer bar> ((largest) (lru)) ((pop-up-frame) (reuse-window ... ^^^^^^^^^^^^^^ `display-buffer-pop-up-window' likely fails here to produce a window and next `display-buffer' tries to pop up a new frame. > * display-buffer(#<buffer bar> other-window nil) > pop-to-buffer(#<buffer bar> other-window nil) > switch-to-buffer-other-window(#<buffer bar>) > find-file-other-window("/home/void/bar") > command-line-1(("--eval" "(debug-on-entry 'display-buffer-pop-up-window)" "foo" "bar" "baz")) > command-line() > normal-top-level() The problem is that `switch-to-buffer-other-window' has to use "another" window. If it can't pop up a window on the selected frame it tries to pop up a new frame :-( As Glenn remarked - you can get the same problem by setting `pop-up-frames' to t. What shall I do? martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 19:32 ` martin rudalics @ 2011-06-15 19:42 ` David Engster 0 siblings, 0 replies; 31+ messages in thread From: David Engster @ 2011-06-15 19:42 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics writes: > The problem is that `switch-to-buffer-other-window' has to use "another" > window. If it can't pop up a window on the selected frame it tries to > pop up a new frame :-( As Glenn remarked - you can get the same problem > by setting `pop-up-frames' to t. What shall I do? I'm a bit confused. Yes, Emacs23 shows the same error with pop-up-frames to 't'. However, if I explicitly set it to 'nil' for Emacs24, I still get the same error: --> emacs --batch -Q --eval "(setq pop-up-frames nil)" foo bar baz Unknown terminal type If the issue is really just the changed default for `pop-up-frames', I'd say the default should be again changed to 'graphic-only instead of 'unset. -David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 17:01 ` David Engster 2011-06-15 17:45 ` martin rudalics @ 2011-06-16 9:23 ` martin rudalics 2011-06-16 10:04 ` David Engster 1 sibling, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-16 9:23 UTC (permalink / raw) To: David Engster; +Cc: 8857 > Is this supposed to also fix the problem for batch mode? Because I still > see this error with revno. 104589: > > --> emacs --batch foo bar baz > Unknown terminal type > > Actually, this currently breaks the CEDET build, because it uses a hack > to provide arguments for functions called with the "-f" switch... My earlier fix wasn't rigid enough. Please try again. Thanks, martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 9:23 ` martin rudalics @ 2011-06-16 10:04 ` David Engster 2011-06-16 13:01 ` martin rudalics 0 siblings, 1 reply; 31+ messages in thread From: David Engster @ 2011-06-16 10:04 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics writes: >> Is this supposed to also fix the problem for batch mode? Because I still >> see this error with revno. 104589: >> >> --> emacs --batch foo bar baz >> Unknown terminal type >> >> Actually, this currently breaks the CEDET build, because it uses a hack >> to provide arguments for functions called with the "-f" switch... > > My earlier fix wasn't rigid enough. Please try again. Works for me. Thanks! BTW, but I think related to this, I don't really understand the new default for pop-up-frames. The doc-string says: "If this is the symbol unset, the option was not set and is ignored." Sorry, but I think this is a bit of a cop-out. You can't really ignore a boolean option - you either pop up a new frame or you don't; it all just depends on how you handle "unset", and this introduces ambiguity in the code. A quick grep shows me that pop-up-frames is either tested with (if (memq pop-up-frames '(nil unset)) ... which means 'unset is actually handled as "not set", or it is simply tested with (if pop-up-frames ... which means 'unset is handled as "set". I would vote for setting the default to 'graphic-only. (Maybe this is the wrong place to discuss this - please let me know if I should file another bug-report or bring this to emacs-devel). -David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 10:04 ` David Engster @ 2011-06-16 13:01 ` martin rudalics 2011-06-16 13:57 ` David Engster 2011-06-16 14:17 ` Stefan Monnier 0 siblings, 2 replies; 31+ messages in thread From: martin rudalics @ 2011-06-16 13:01 UTC (permalink / raw) To: David Engster; +Cc: 8857 > BTW, but I think related to this, I don't really understand the new > default for pop-up-frames. The doc-string says: > > "If this is the symbol unset, the option was not set and is > ignored." 'unset stands for "nobody bothered to set or bind this". > Sorry, but I think this is a bit of a cop-out. You can't really ignore a > boolean option - you either pop up a new frame or you don't; it all just > depends on how you handle "unset", and this introduces ambiguity in the > code. A quick grep shows me that pop-up-frames is either tested with > > (if (memq pop-up-frames '(nil unset)) > ... > > which means 'unset is actually handled as "not set", Because it's the same for `display-buffer'. > or it is simply > tested with > > (if pop-up-frames > ... I can't find this anywhere :-( > which means 'unset is handled as "set". But an application should be allowed to test whether the user or the calling application has set this option in some way or the other before possibly (re-)binding it. If the value is still 'unset, no one bothered about it. If it is nil, someone up there explicitly doesn't want to pop up buffers. If it's graphic-only, someone up there wants to pop them up on graphic systems only. Any other value means that someone wants to pop up frames anywhere. Not that applications care that much ... > I would vote for setting the default to 'graphic-only. IIRC the default was nil. 'graphic-only was IMHO a not very well-conceived idea because it didn't inhibit applications to rebind this to t. I've never seen a `pop-up-frames' rebinding function care about this issue. Personally, I'd prefer such an option to affect the behavior of the frame creation functions rather than that of display-buffer. But I don't recall the reason that lead to the introduction of graphic-only. In any case, we could conceive an additional variable (not necessarily an option), say `display-buffer-pop-up-frame-graphic-only', which, if non-nil, effectively inhibits popping up a new frame on non-graphic systems, overriding any value calculated from buffer display specifiers and `pop-up-frames'. > (Maybe this is the wrong place to discuss this - please let me know if I > should file another bug-report or bring this to emacs-devel). Please do what you find more convenient ;-) BTW, Drew started a related discussion in another thread. I asked him to join us. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 13:01 ` martin rudalics @ 2011-06-16 13:57 ` David Engster 2011-06-16 15:08 ` martin rudalics 2011-06-16 14:17 ` Stefan Monnier 1 sibling, 1 reply; 31+ messages in thread From: David Engster @ 2011-06-16 13:57 UTC (permalink / raw) To: martin rudalics; +Cc: 8857 martin rudalics writes: >> BTW, but I think related to this, I don't really understand the new >> default for pop-up-frames. The doc-string says: >> >> "If this is the symbol unset, the option was not set and is >> ignored." > > 'unset stands for "nobody bothered to set or bind this". > >> Sorry, but I think this is a bit of a cop-out. You can't really ignore a >> boolean option - you either pop up a new frame or you don't; it all just >> depends on how you handle "unset", and this introduces ambiguity in the >> code. A quick grep shows me that pop-up-frames is either tested with >> >> (if (memq pop-up-frames '(nil unset)) >> ... >> >> which means 'unset is actually handled as "not set", > > Because it's the same for `display-buffer'. I see. > >> or it is simply >> tested with >> >> (if pop-up-frames >> ... > > I can't find this anywhere :-( Sorry, I should have been more explicit: There are places in the Emacs sources which only test pop-up-frames for being non-nil, usually with 'and'/'or': calendar/diary-lib.el: (let* ((pop-up-frames (or pop-up-frames (window-dedicated-p (selected-window)))) mail/rmail.el: (and pop-up-frames (one-window-p)) progmodes/inf-lisp.el: (let ((pop-up-frames ;; Be willing to use another frame ;; that already has the window in it. (or pop-up-frames (get-buffer-window inferior-lisp-buffer t)))) vc/pcvs-util.el: (let ((pop-up-windows (or pop-up-windows pop-up-frames)) ... just to mention a few. >> which means 'unset is handled as "set". > > But an application should be allowed to test whether the user or the > calling application has set this option in some way or the other before > possibly (re-)binding it. If the value is still 'unset, no one bothered > about it. If it is nil, someone up there explicitly doesn't want to pop > up buffers. If it's graphic-only, someone up there wants to pop them up > on graphic systems only. Any other value means that someone wants to > pop up frames anywhere. Not that applications care that much ... OK, I think I understand the motivation behind 'unset now. However, this effectively means that there really is no default value for pop-up-frames, and every application can decide how they will deal with that. The snippets above will see it as non-nil and will now create frames. >> I would vote for setting the default to 'graphic-only. > > IIRC the default was nil. 'graphic-only was IMHO a not very > well-conceived idea because it didn't inhibit applications to rebind > this to t. I've never seen a `pop-up-frames' rebinding function care > about this issue. Right, the current code doesn't care about 'graphic-only, but neither does the old code care about 'unset. This can be changed, of course... :-) >> (Maybe this is the wrong place to discuss this - please let me know if I >> should file another bug-report or bring this to emacs-devel). > > Please do what you find more convenient ;-) > > BTW, Drew started a related discussion in another thread. I asked him > to join us. I actually don't feel that strongly about it. It just found it confusing, but I think I understand it better now. I have set this option to nil anyway. :-) Thanks for explaining, David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 13:57 ` David Engster @ 2011-06-16 15:08 ` martin rudalics 2011-06-17 6:49 ` David Engster 0 siblings, 1 reply; 31+ messages in thread From: martin rudalics @ 2011-06-16 15:08 UTC (permalink / raw) To: David Engster; +Cc: 8857 > calendar/diary-lib.el: > > (let* ((pop-up-frames (or pop-up-frames > (window-dedicated-p (selected-window)))) > > mail/rmail.el: > > (and pop-up-frames (one-window-p)) > > progmodes/inf-lisp.el: > > (let ((pop-up-frames > ;; Be willing to use another frame > ;; that already has the window in it. > (or pop-up-frames > (get-buffer-window inferior-lisp-buffer t)))) > > vc/pcvs-util.el: > > (let ((pop-up-windows (or pop-up-windows pop-up-frames)) > > ... just to mention a few. I replaced most of these in my window-pub branch which, however, doesn't care about 'unset value yet. Obviously, all of these don't DTRT in Emacs 23 when a user has set `pop-up-frames' to 'graphic-only and is on a non-graphic system. > OK, I think I understand the motivation behind 'unset now. 'unset was a quick fix to make old code work with the new `display-buffer'. There might be some yet unknown quirks in it. Maybe I even don't need it. > However, this > effectively means that there really is no default value for > pop-up-frames, ... well it's 'unset ... > and every application can decide how they will deal with > that. The snippets above will see it as non-nil and will now create > frames. Yes. Just as they wrongly handled 'graphic-only in Emacs 23. > Right, the current code doesn't care about 'graphic-only, but neither > does the old code care about 'unset. This can be changed, of course... :-) This must be changed, of course :-) > I actually don't feel that strongly about it. It just found it > confusing, but I think I understand it better now. I have set this > option to nil anyway. :-) Me too. That's why I'm not very familiar with the ensuing problems. martin ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 15:08 ` martin rudalics @ 2011-06-17 6:49 ` David Engster 0 siblings, 0 replies; 31+ messages in thread From: David Engster @ 2011-06-17 6:49 UTC (permalink / raw) To: martin rudalics; +Cc: 8857-done martin rudalics writes: >> However, this >> effectively means that there really is no default value for >> pop-up-frames, > > ... well it's 'unset ... Yes. But I think you understand my problem: 'unset doesn't say whether you should pop up a new frame by default or not. It's pretty much what Drew says in #8865, and I tend to agree with him on this issue. I think this special handling of 'unset is cumbersome, and it should simply be a boolean variable with a default of nil or t. Anyway, I don't want to bother you with two threads on the same issue, and the original problem has been solved, so I'm closing this bug and will maybe follow-up on #8865, but I think pretty much everything has been said regarding this issue. -David ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-16 13:01 ` martin rudalics 2011-06-16 13:57 ` David Engster @ 2011-06-16 14:17 ` Stefan Monnier 1 sibling, 0 replies; 31+ messages in thread From: Stefan Monnier @ 2011-06-16 14:17 UTC (permalink / raw) To: martin rudalics; +Cc: David Engster, 8857 > IIRC the default was nil. 'graphic-only was IMHO a not very > well-conceived idea because it didn't inhibit applications to rebind > this to t. I've never seen a `pop-up-frames' rebinding function care > about this issue. graphics-only was a quick fix for people who want to set pop-up-frames in their .emacs but get annoyed when they tty-emacsclient end up popping up frames as well. > In any case, we could conceive an additional variable (not necessarily > an option), say `display-buffer-pop-up-frame-graphic-only', which, if > non-nil, effectively inhibits popping up a new frame on non-graphic > systems, overriding any value calculated from buffer display specifiers > and `pop-up-frames'. More generally we want to specify different display-buffer behaviors for tty (where frames are fully-overlapping) and graphic terminals (where several frames may be visible at the same time). Stefan ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 7:29 ` Glenn Morris 2011-06-15 8:01 ` martin rudalics @ 2011-06-15 14:36 ` Stefan Monnier 2011-06-15 19:40 ` Glenn Morris 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2011-06-15 14:36 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 > In addition I still think it might be worth explicitly making > display-buffer a no-op in batch mode, unless someone can think of > something it can actually do in such cases. I think this could only be "batch mode" and "server mode" are *very* closely related. So I'd stay away from any attempt to special case "batch mode". At best, you could try and check the currently selected terminal and do something special when that terminal is the "initial" terminal (the one bound to stdout/stdin), but I'd rather not obscure the code to "optimize" this case. Stefan ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 14:36 ` Stefan Monnier @ 2011-06-15 19:40 ` Glenn Morris 2011-06-15 21:02 ` Stefan Monnier 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2011-06-15 19:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8857 Stefan Monnier wrote: > "batch mode" and "server mode" are *very* closely related. So I'd stay > away from any attempt to special case "batch mode". FWIW, `noninteractive' is nil in "server mode" (ie --daemon) but t in "batch mode", so the two cases are easily distinguished. Since emacs.c has: if (!noninteractive) init_display (); /* Determine terminal type. Calls init_sys_modes. */ I've gone back to thinking that display-buffer can do nothing useful in batch mode. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 19:40 ` Glenn Morris @ 2011-06-15 21:02 ` Stefan Monnier 2011-06-15 22:13 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2011-06-15 21:02 UTC (permalink / raw) To: Glenn Morris; +Cc: 8857 >> "batch mode" and "server mode" are *very* closely related. So I'd stay >> away from any attempt to special case "batch mode". > FWIW, `noninteractive' is nil in "server mode" (ie --daemon) but t in > "batch mode", so the two cases are easily distinguished. > Since emacs.c has: > if (!noninteractive) > init_display (); /* Determine terminal type. Calls init_sys_modes. */ > I've gone back to thinking that display-buffer can do nothing useful in > batch mode. It might fix it for batch mode, but you may get the same problem in "server mode before opening any display or tty". That's what I mean by the two being closely related. I.e. we need to make it work on the dummy initial terminal. Stefan ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error 2011-06-15 21:02 ` Stefan Monnier @ 2011-06-15 22:13 ` Glenn Morris 0 siblings, 0 replies; 31+ messages in thread From: Glenn Morris @ 2011-06-15 22:13 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8857 Stefan Monnier wrote: > It might fix it for batch mode, but you may get the same problem in > "server mode before opening any display or tty". That's what I mean by > the two being closely related. > > I.e. we need to make it work on the dummy initial terminal. I'm not so sure, because server mode at least _has_ a dummy terminal. Can you give an example of server mode running into the same problem as being discussed for batch mode? ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2011-06-17 6:49 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-13 22:21 bug#8857: display-buffer attempt to pop-up frame in batch mode causes "Unknown terminal type" error Glenn Morris 2011-06-13 22:23 ` Glenn Morris 2011-06-14 9:16 ` martin rudalics 2011-06-14 16:19 ` Glenn Morris 2011-06-14 17:14 ` martin rudalics 2011-06-14 17:20 ` Glenn Morris 2011-06-14 17:56 ` martin rudalics 2011-06-14 18:25 ` Glenn Morris 2011-06-14 19:09 ` martin rudalics 2011-06-15 7:29 ` Glenn Morris 2011-06-15 8:01 ` martin rudalics 2011-06-15 16:17 ` Glenn Morris 2011-06-15 17:01 ` David Engster 2011-06-15 17:45 ` martin rudalics 2011-06-15 18:09 ` Glenn Morris 2011-06-15 18:13 ` David Engster 2011-06-15 19:16 ` Glenn Morris 2011-06-15 18:30 ` David Engster 2011-06-15 19:32 ` martin rudalics 2011-06-15 19:42 ` David Engster 2011-06-16 9:23 ` martin rudalics 2011-06-16 10:04 ` David Engster 2011-06-16 13:01 ` martin rudalics 2011-06-16 13:57 ` David Engster 2011-06-16 15:08 ` martin rudalics 2011-06-17 6:49 ` David Engster 2011-06-16 14:17 ` Stefan Monnier 2011-06-15 14:36 ` Stefan Monnier 2011-06-15 19:40 ` Glenn Morris 2011-06-15 21:02 ` Stefan Monnier 2011-06-15 22:13 ` Glenn Morris
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).