http://permalink.gmane.org/gmane.emacs.pretest.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.emacs.pretest.bugs/23254 Here are bugs that were reported a year ago which I think should not be forgotten. To: bug-gnu-emacs< at >gnu.org From: Joe Wells <jbw< at >macs.hw.ac.uk> Date: Sat, 20 Oct 2007 06:32:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: two display bugs involving interactions between after-string and display properties of adjacent overlays Here are two more display bugs I found while trying to improve the code in tex-fold.el in AUCTeX. These bugs involve interactions between after-string and display properties of adjacent overlays. I'm assuming this macro in my reproduction code below: (defmacro test-in-fresh-buffer-and-window (&rest body) `(progn (delete-other-windows) (kill-buffer (get-buffer-create "xyzzy")) (let ((xyzzy-buf (get-buffer-create "xyzzy"))) (set-buffer xyzzy-buf) (display-buffer xyzzy-buf) ,< at >body ))) BUG #1: An overlay's after-string property that would appear at the end of the buffer is not displayed, if the Richard Stallman 2008-10-19T05:00:36 http://permalink.gmane.org/gmane.emacs.pretest.bugs/23253 Here's another bug that was reported a year ago which I think should not be forgotten. From: Richard Stallman <rms< at >gnu.org> Content-Type: text/plain; charset=ISO-8859-15 To: emacs-devel< at >gnu.org Subject: Another overlay display bug Reply-To: rms< at >gnu.org Message-Id: <E1IjVDM-0001BJ-AH< at >fencepost.gnu.org> Date: Mon, 10 Dec 2007 10:19:14 -0500 Would someone please fix this, then ack? To: bug-gnu-emacs< at >gnu.org From: Joe Wells <jbw< at >macs.hw.ac.uk> Date: Sat, 20 Oct 2007 06:43:43 +0100 In-Reply-To: <86k5pi9wrg.fsf< at >macs.hw.ac.uk> (Joe Wells's message of "Sat\, 20 Oct 2007 06\:32\:19 +0100") MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Subject: Re: two display bugs involving interactions between after-string and display properties of adjacent overlays Joe Wells <jbw< at >macs.hw.ac.uk> writes: Here is a third such bug. Ditto. Ditto. BUG #3: An overlay's after-string property is not displayed if an immediately following overlay has the empty string as its display property. Reproduce with this ex Richard Stallman 2008-10-19T05:00:55 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19526 Outside Emacs suspending a su'ed bash works fine. Sven Joachim 2007-08-13T13:27:24 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19525 How about outside Emacs? Glenn Morris 2007-08-13T07:55:03 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19524 No, I can't. Surprisingly, you just repeating most of what you said the first time word for word has not helped me to do so. Glenn Morris 2007-08-13T07:54:05 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19523 Yes, I can reproduce this with Emacs 21.4. Sven Joachim 2007-08-13T06:08:29 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19522 Also exiting an emacs that contains such shells still alive (merely sitting at their prompts), sends the signal to them to get wacko. That sounds like a shell bug to me. Does it happen with Emacs 21.4 too? Richard Stallman 2007-08-13T05:00:37 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19521 Also exiting an emacs that contains such shells still alive (merely sitting at their prompts), sends the signal to them to get wacko. jidanni< at >jidanni.org 2007-08-12T20:13:41 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19520 SJ> I have IGNOREEOF=2 in /root/.bashrc. It turns out with greater IGNOREEOF's, and more "fg"'s, the sucker heads straight for the HISTFILE where it proceeds to execute all the commands there faster than you can kill(1) them. "A monster has taken over my '*shell*' buffer and is sending root ^P^O&'s or whatever it takes to replay my HISTORY file faster than I can swat all it is spawning!" Here I fool it with HISTFILE=/dev/null: 02:58 1 tmp$ su Password: root< at >jidanni2:/tmp# IGNOREEOF=11 HISTFILE=/dev/null root< at >jidanni2:/tmp# suspend [1]+ Stopped su 02:59 147 tmp$ fg su root< at >jidanni2:/tmp# Use "exit" to leave the shell. root< at >jidanni2:/tmp# [1]+ Stopped su 02:59 147 tmp$ fg su root< at >jidanni2:/tmp# bash: =/dev/null: No such file or directory root< at >jidanni2:/tmp# bash: syntax error near unexpected token `(' root< at >jidanni2:/tmp# [1] 15423 root< at >jidanni2:/tmp# bash:\350\2600\322: command not found root< at >jidanni2:/tmp# jidanni< at >jidanni.org 2007-08-12T19:12:17 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19519 The fix will be installed soon. Richard Stallman 2007-08-12T17:56:15 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19518 I can reproduce this. Actually, the shell gets an EOF from somewhere, since on my system I get the message "Use 'exit' to leave the shell." I have IGNOREEOF=2 in /root/.bashrc. Regards, Sven Sven Joachim 2007-08-12T17:54:37 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19517 GM> I cannot reproduce this. At least you perhaps can reproduce in an emacs *shell* buffer: --------------- jidanni< at >jidanni2:~$ su Password: root< at >jidanni2:/tmp# suspend [1]+ Stopped su jidanni< at >jidanni2:~$ fg su root< at >jidanni2:/tmp# exit <---I did not type "exit"! jidanni< at >jidanni2:~$ jobs jidanni< at >jidanni2:~$ ---------------- Whereas in xterm one gets ...$ fg su root< at >jidanni2:/tmp# ---------------- i.e., without having the "exit" magically typed in for us ending the su session. jidanni< at >jidanni.org 2007-08-12T15:13:46 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19516 I cannot reproduce this. If you want this investigating, please provide a clear recipe showing the minimum emacs and shell configurations needed to produce the problem. Glenn Morris 2007-08-12T03:16:45 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19515 There have been no changes in lisp/calendar/ in the past two weeks. It works for me. Perhaps there is a problem on your end? Glenn Morris 2007-08-12T02:35:50 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19514 Checking d:/emacs-gbk/lisp/calendar... Compiling d:/emacs-gbk/lisp/calendar/calendar.el... In toplevel form: calendar/calendar.el:2215:1:Error: Symbol's function definition is void: i If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Emacs/etc/DEBUG for instructions. In GNU Emacs 22.1.50.1 (i386-mingw-nt5.1.2600) of 2007-08-04 on BREPHOME modified by Zhangwei <id.brep< at >gmail.com>. Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: CHS locale-coding-system: cp936 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes i Zhang Wei 2007-08-12T01:31:32 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19513 Hello! The compilation in *compilation* can't neither be stopped by C-c C-k nor by the Compile menu entry to stop compilation. *Backtrace* buffer shows: Debugger entered--Lisp error: (wrong-number-of-arguments (lambda nil (byte-code "\300\301!\207" [local-variable-p compilation-locs] 2)) 1) (lambda nil (byte-code "300\301!\207" [local-variable-p compilation-locs] 2))(#<buffer *compilation*>) compilation-find-buffer() kill-compilation() call-interactively(kill-compilation) I first saw it a few days ago. CVS code is from from today, around 16:00 UTC. All Emacsen launched with -Q. In GNU Emacs 22.1.50.2 (powerpc-apple-darwin8.10.0, X toolkit, Xaw3d scroll bars) of 2007-08-11 on localhost Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000 configured using `configure '--without-carbon' '--with-x' '--without- sound' '--without-pop' '--with-xpm' '--with-jpeg' '--with-tiff' '-- with-gif' '--with-png' '--with-x-toolkit=athena' '--enable- locallisppath=/ Peter Dyballa 2007-08-11T17:58:53 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19512 Hello! Since some weeks I can see in *cvs* buffer: In directory lisp/emacs-lisp: Message: cvs update: nonmergeable file needs merge Message: cvs update: revision 1.6 from repository is now in lisp/ emacs-lisp/cl-loaddefs.el Message: cvs update: file from working directory is now in .#cl- loaddefs.el.1.5 Conflict lisp/emacs-lisp/cl-loaddefs.el When I check with diff or ls I get no difference: pete 116 /\ diff lisp/emacs-lisp/cl-loaddefs.el lisp/emacs-lisp/.#cl- loaddefs.el.1.5 pete 117 /\ ls -l lisp/emacs-lisp/cl-loaddefs.el lisp/emacs- lisp/.#cl-loaddefs.el.1.5 -rw-r--r-- 1 pete admin 41962 4 Aug 13:41 lisp/emacs-lisp/.#cl- loaddefs.el.1.5 -rw-r--r-- 1 pete admin 41962 11 Aug 17:26 lisp/emacs-lisp/cl- loaddefs.el In GNU Emacs 22.1.50.2 (powerpc-apple-darwin8.10.0, X toolkit, Xaw3d scroll bars) of 2007-08-04 on localhost Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000 configured using `configure '--without-carbon' Peter Dyballa 2007-08-11T15:52:39 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19511 Richard Stallman skrev: Done. Jan D. Jan Djärv 2007-08-10T05:48:05 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19510 I notice in the *shell* buffer, suspend/fg acts funny. sh-3.1$ su Password: root< at >jidanni1:/tmp# suspend [1]+ Stopped(SIGSTOP) su sh-3.1$ fg su root< at >jidanni1:/tmp# exit <--I did not type "exit". God did for me apparently. I also notice that if I do the above experiment without doing # mv .bash* /somewhere/other/than/root's/home/dir first, apparently the .bash_history file starts getting munched, with all kinds of wacko commands getting executed or something with multiple kill(1)'s needed to stamp out the frenzy. In GNU Emacs 22.1.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-07-07 on raven, modified by Debian Dan Jacobson 2007-08-09T23:46:57 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19509 Tested with three manpages that used to trigger the error, all work fine now. Thank you. :-) Sven Joachim 2007-08-08T20:12:09 http://permalink.gmane.org/gmane.emacs.pretest.bugs/19508 Can you confirm that the patch below fixes the problem for you? I've installed it in the 22 branch, Stefan --- man.el26 jui 2007 14:47:54 -04001.169 +++ man.el08 aoû 2007 15:24:45 -0400 < at >< at > -975,7 +975,7 < at >< at > (Man-next-section 1) (point))) (goto-char (point-min)) - (point-max)))) + nil))) (while (re-search-forward regexp end t) (make-text-button (match-beginning button-pos) < at >< at > -1291,14 +1291,17 < at >< at > (defun Man-next-section (n) "Move point to Nth next section (default 1)." (interactive "p") - (let ((case-fold-search nil)) + (let ((case-fold-search nil) + (start (point))) (if (looking-at Man-heading-regexp) (forward-line 1)) (if (re-search-forward Man-heading-regexp (point-max) t n) (beginning-of-line) (goto-char (point-max)) ;; The last line doesn't belong to any section. - (forward-line -1)))) + (forward-line -1)) + ;; But don't move back from the starting point. + (if (< (point) start) (goto-c Stefan Monnier 2007-08-08T19:52:14 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.emacs.pretest.bugs