davek@ICASE.EDU (David Kamowitz) (10/26/88)
Greetings! I am not sure if this is an X11 bug or an emacs bug. We are running emacs 18.52 and X11R2 on a sun network running OS-3.5.1 . The synopsis of the problem is that dbx behaves differently before and after emacs is run, from a particular window. Here is a transcript of a typical situation: Script started on Wed Oct 26 11:11:32 1988 work4% cd work/burgers/One_d/FAS work4% dbx main Reading symbolic information... Read 1279 symbols (dbx) run Running: main number of cells 8 lambda? 1 number of time steps 1 epcrt2, epcrt4? 1 0 eps? 0 u= 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 time =.0000e+00 error =.2828e+01 resid =.0000e+00 u= 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 1.000000 time =.1250e+00 error =.2828e+01 resid =.0000e+00 execution completed, exit code is 0 program exited with 0 (dbx) quit work4% emacs new_file work4% dbx main Reading symbolic information... Read 1279 symbols (dbx) run Running: main number of cells 8 signal IO (possible input/output) in read at 0x16612 read+4: trap #0x0 (dbx) unrecognized command/syntax "8 " (Type 'help' for help) (dbx) quit work4% exit work4% script done on Wed Oct 26 11:16:31 1988 script done on Wed Oct 26 11:16:31 1988 Please let me know if I can provide any further information. Thank you, David Kamowitz davek@icase.edu
dash@POLYA.STANFORD.EDU (David Ash) (11/24/88)
To whom it may concern: This may not be a bug, but it my opinion it's pretty close. When I create a new file using emacs and want to exit without saving, two prompts come up: "save file..?" and "modified buffer .. ?". Both are yes/no prompts, and yet the first insists on a y/n response, while the second requires the words to be spelled out yes/no. This inconsistency is very disconcerting. -David
romero@CSSEQ.TAMU.EDU (Ron Romero) (02/13/89)
When I call up the calendar function in horizontal split mode, The mini-buffer expands to about half the screen. Specifically, I type: emacs -q C-x 5 M-x calendar And emacs expands the minibuffer to take up all but the 6 lines needed to display the calendar. The first 6 lines of the screen is split into two horizontal windows; the second contains the calendar, the first contains the *scratch* buffer. The 7th line is the mode line. The 8th line is the mini-buffer line; it says 'loading cal...done' at this point. The rest of the screen is as it was before I called up the calendar (except that the last screen line also says 'loading cal...done'. My Emacs Version is: Gnu Emacs 18.51.1 of Sat Jul 30 1988 on csseq (berkly unix). I am working on a VT220; the computer is a sequent machine. --Ron Romero romero@csseq.tamu.edu
rang@cpsin3.cps.msu.edu (Anton Rang) (02/14/89)
Ron Romero (romero@csseq.tamu.edu) writes: > When I call up the calendar function in horizontal split mode, The >mini-buffer expands to about half the screen. This is caused by the calendar package shrinking the window. There is some code which looks like: (or (one-window-p t) (<= h l) (shrink-window (- h l)))) buried inside cal.el. I'm not sure of the exact logic, but I think its intended use is to handle the case where there are two "normal" windows--the calendar goes in one, which is then shrunk down to size. The shrink-window call seems to make the window smaller, even if only the minibuffer is left to expand--this is why the strange results occur (try eval-ing (shrink-window 10) in one-window mode to see this). I suppose the best fix would be a test to see whether the windows were split horizontally or vertically, but this would get complicated with more than one window. Maybe the semantics of shrink-window should be changed so that the minibuffer doesn't expand? Comments? +---------------------------+------------------------+----------------------+ | Anton Rang (grad student) | Things could be worse. | "Do worry...be SAD!" | | Michigan State University | rang@cpswh.cps.msu.edu | | +---------------------------+------------------------+----------------------+
steve@ASC.SLB.COM (12/07/89)
The following bug has been observed in GNU Emacs version 18.54, on various SUN 3 models (including 3/60 and 3/75) running SUN OS4, with Lucid Common Lisp 3.0 executing as an inferior lisp process. When the Lucid stepper is used, the lisp process will stop with the message "Process lisp stopped (signal)." It turns out to be impossible to restart the lisp process with (continue-process (get-process "lisp")). This typically occurs within the first 20 or 30 commands given to the stepper. We've patched the file src/process.c to fix this. The basis of the fix is the observation that a read call on the pipe connecting the inferior lisp process with Emacs returns with error EWOULDBLOCK, even though a previous select call has indicated that there is data in the pipe. The diff is included below. So it appears that SUN OS4 is the culprit here. The error has not been observed on the SUN4. Thanks for your attention Steve Kaufman Schlumberger Austin Systems Center steve@ASC.SLB.COM Diff File (process.c_orig is the copy of process.c in dist-18.54, process.c is our patched version) argon[steve]6> diff /usr/local/emacs/src/process.c_orig /usr/local/emacs/src/process.c 0a1 > 1289a1291 > int n; 1485c1487 < /* It has ceased to be a command channel! */ --- > /* It has ceased to be a command channel! */ 1498,1501c1500,1502 < < if (read_process_output (proc, channel) > 0) < { < if (do_display) --- > if (n = read_process_output (proc, channel) > 0) > if (n > 0) { > if (do_display) { 1502a1504,1505 > } > break; 1504,1505c1507,1514 < else < { --- > /* The next test is here because the pipe may be empty > even after the select call has returned. If so, simply > break out of the loop to call select again. */ > #ifdef BSD > else if ((n == -1) && (errno == EWOULDBLOCK)) > break; > #endif BSD > else { 1510,1520c1519,1529 < /* < * With ptys: when the parent process of a pty exits we are notified, < * just as we would be with any of our other children. After the process < * exits, select() will indicate that we can read the channel. When we < * do this, read() returns 0. Upon receiving this, we close the channel. < * < * For external channels, when the peer closes the connection, select() < * will indicate that we can read the channel. When we do this, read() < * returns -1 with errno = ECONNRESET. Since we never get notified of < * this via wait3(), we must explictly mark the process as having exited. < */ --- > /* > * With ptys: when the parent process of a pty exits we are notified, > * just as we would be with any of our other children. After the process > * exits, select() will indicate that we can read the channel. When we > * do this, read() returns 0. Upon receiving this, we close the channel. > * > * For external channels, when the peer closes the connection, select() > * will indicate that we can read the channel. When we do this, read() > * returns -1 with errno = ECONNRESET. Since we never get notified of > * this via wait3(), we must explictly mark the process as having exited. > */ 1565c1574 < if (nchars <= 0) return 0; --- > if (nchars <= 0) return nchars; /* 0; */ 1689a1699,1700 > /* for debug */ > fprintf(stderr, "%d %s", count, buf) 2085,2086c2096,2097 < if ((XFASTINT (p->flags) & PROC_STATUS) == SIGNALED) < if (delete_exited_processes) --- > if ((XFASTINT (p->flags) & PROC_STATUS) == SIGNALED) { > if (delete_exited_processes) { 2087a2099 > } 2089a2102 > }
larry@SHARKEY.CC.UMICH.EDU (Larry Siden) (12/07/89)
Hello,
I am running EMACS version 18.52 and I keep encountering the following
bug whenever I attempt one of the functions 'minibuffer-complete-word' or
'minibuffer-completion' while building an argument to a command that takes
a file-name (e.g. 'find-file'). After typing a complete pathname prefix (e.g.
"/users/larry/", a TAB will produce the message "[Complete, but not unique]"
in the minibuffer, and a space will produce a directory listing in the window
*Completions* . But if I type a space after "/users/larry" (sans final '/')
I will get a message that reads (along with dump of backtrace):
Signalling: (wrong-type-argument sequencep #<EMACS BUG: ILLEGAL DATATYPE (#o 57) Save your buffers immediately and please report this bug>)
read-file-name-internal("/users/larry" "~/fsf/" nil)
minibuffer-complete-word()
call-interactively(minibuffer-complete-word)
call-interactively(find-file)shin@sgtp.apple.juice.or.jp (Shinichirou Sugou) (12/09/89)
Hello. I'm not sure whether this is bug or not. Anyway, I'll report it.
Emacs version is 18.55.
[Reproduction]
Open empty buffer, say 'foo', and type the following two line
Hello,
world
Then split 'foo' window into two by
^x 2
The screen looks like this.
+-----------------------+
|Hello, |
|world |
| |
|-----------------------|
|Hello, |
|world |
| |
| |
+-----------------------+
Now, the cursor (the point) must reside in the upper window.
Move the cursor (in the upper window) to the beginning of buffer by
Meta <
And invoke the command 'scroll-other-window' by typing
Meta ^v
Error message appears (it is OK), but, the cursor (in the upper window) has
moved to the end of the buffer!
I think the cursor (the point) in the upper window should not move in this case.
Thank you.
CAUTION: (1) Reply-command in the mail system may NOT generate my address
correctly. Please use the following address instead.
shin%sgtp.apple.juice.or.jp@uunet.uu.net
(2) I have no relation to Apple Computer Inc. :-)
---
S.Sugou