Re: Display problems with 'before-string in overlay
Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:48:34 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] FWIW, I wouldn't touch this so close to the release: if no one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:48:34 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] FWIW, I wouldn't touch this so close to the release: if no one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. At this stage of the release cycle, a grave bug is one that makes Emacs crash, or causes really bad redisplay behaviour. As you said yourself, this is a corner case, so it is not a grave error. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer to was installed to fix a bug, and it
did fix _that_ bug.
Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.
Besides, the ++row seems dangrous to me. Would row+1 do the same?
Index: xdisp.c
===
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1146
diff -c -r1.1146 xdisp.c
*** xdisp.c 10 Apr 2007 15:57:25 - 1.1146
--- xdisp.c 12 Apr 2007 00:40:36 -
***
*** 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT = MATRIX_ROW_START_CHARPOS (row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--- 15859,15865
If the row is continued it doesn't end in a newline. */
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
! || PT MATRIX_ROW_START_CHARPOS (++row));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
--
Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
In a buffer with scheme-mode active, delete-trailing-whitespace treats a traling vertical bar character (|) as trailing whitespace (that is, the character is deleted when invoking delete-trailing-whitespace, either interactively or as a write hook). Other modes (elisp, lisp, c, fundamental) seem to behave correctly. What does `describe-char' say about the character? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Now that I think about it, I realize that many Emacs users have not studied the advanced mathematics where they would encounter the term iff. So I think it is better to avoid that term. (I was the one who introduced it into Emacs doc strings.) I have added this to TODO for fixing post-22 release. ** Avoid using iff in doc strings. Even advanced mathematical textbooks usually explain this in an initial section. Maybe we could add a definition in the manuals. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: edebug-pop-to-buffer fails for dedicated windows
edebug-pop-to-buffer changes the buffer in the next window. However this results in an error, if that window is dedicated. Please try the attached patch. *** edebug.el.~3.96.~ Mon Apr 2 07:45:10 2007 --- edebug.el Thu Apr 12 09:06:24 2007 *** *** 364,389 (defun edebug-pop-to-buffer (buffer optional window) ;; Like pop-to-buffer, but select window where BUFFER was last shown. ! ;; Select WINDOW if it provided and it still exists. Otherwise, ;; if buffer is currently shown in several windows, choose one. ;; Otherwise, find a new window, possibly splitting one. ! (setq window (if (and (windowp window) (edebug-window-live-p window) ! (eq (window-buffer window) buffer)) ! window !(if (eq (window-buffer (selected-window)) buffer) !(selected-window) ! (edebug-get-buffer-window buffer ! (if window ! (select-window window) ! (if (one-window-p) ! (split-window)) ! ;; (message next window: %s (next-window)) (sit-for 1) ! (if (eq (get-buffer-window edebug-trace-buffer) (next-window)) ! ;; Don't select trace window ! nil ! (select-window (next-window ! (set-window-buffer (selected-window) buffer) ! (set-window-hscroll (selected-window) 0);; should this be?? ;; Selecting the window does not set the buffer until command loop. ;;(set-buffer buffer) ) --- 364,394 (defun edebug-pop-to-buffer (buffer optional window) ;; Like pop-to-buffer, but select window where BUFFER was last shown. ! ;; Select WINDOW if it is provided and still exists. Otherwise, ;; if buffer is currently shown in several windows, choose one. ;; Otherwise, find a new window, possibly splitting one. ! (setq window ! (cond !((and (windowp window) (edebug-window-live-p window) ! (eq (window-buffer window) buffer)) ! window) !((eq (window-buffer (selected-window)) buffer) ! (selected-window)) !((edebug-get-buffer-window buffer)) !((one-window-p 'nomini) ! (split-window)) !((let ((trace-window (get-buffer-window edebug-trace-buffer))) ! (catch 'found ! (dolist (elt (window-list nil 'nomini)) ! (unless (or (eq elt (selected-window)) (eq elt trace-window) ! (window-dedicated-p elt)) ! (throw 'found elt)) !;; All windows are dedicated or show `edebug-trace-buffer', split !;; selected one. !(t (split-window ! (select-window window) ! (set-window-buffer window buffer) ! (set-window-hscroll window 0);; should this be?? ;; Selecting the window does not set the buffer until command loop. ;;(set-buffer buffer) ) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: Can you track down the bug report(s) which lead up to the fix I installed, so you can confirm that your change also fixes the old bug(s). It must be close to the date in the ChangeLog. IIRC, there were quite a lot of test cases - combining before and after strings as well as compositions, so I really feel bad about touching this now. Besides, the ++row seems dangrous to me. Would row+1 do the same? Note: You must check that the next row is a valid row. And decide what to do if not? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
display margin errors on a tty
I might have reported this before but display seems all over the place when the buffer has a left margin in a tty. To see this start Emacs in an xterm, debug a program with M-x gdb, set a breakpoint, run and click alternately on the GUD and source buffer, or even repeatedly in the source buffer. The margin appears and disappears, so does the breakpoint symbol, B. Also various source lines get indented. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
On Thu, 12 Apr 2007 10:46:04 +0200 martin rudalics [EMAIL PROTECTED] wrote: Now that I think about it, I realize that many Emacs users have not studied the advanced mathematics where they would encounter the term iff. So I think it is better to avoid that term. (I was the one who introduced it into Emacs doc strings.) I have added this to TODO for fixing post-22 release. ** Avoid using iff in doc strings. Even advanced mathematical textbooks usually explain this in an initial section. Maybe we could add a definition in the manuals. How about in (emacs)Glossary and in (elisp)Documentation Basics ? Steve Berman ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Why does etags ask me if I want to keep the old TAGS - I do not want to load a new
Here is a reproduceable way to trigger the problem I have the emacs source in c:\download\emacs-cvs\emacs\ I have installed emacs to c:\download\emacs-cvs\070410\ C:\cd \download\emacs-cvs\emacs\src C:\download\emacs-cvs\emacs\src\download\emacs-cvs\070410\bin\etags *.* \download\emacs-cvs\070410\bin\etags: skipping bitmaps: it is not a regular file. \download\emacs-cvs\070410\bin\etags: skipping CVS: it is not a regular file. \download\emacs-cvs\070410\bin\etags: skipping m: it is not a regular file. \download\emacs-cvs\070410\bin\etags: skipping oo-spd: it is not a regular file. \download\emacs-cvs\070410\bin\etags: skipping s: it is not a regular file. \download\emacs-cvs\070410\bin\etags: skipping inclusion of TAGS in self. C:\download\emacs-cvs\emacs\src\download\emacs-cvs\070410\bin\runemacs -Q process.c M-x find-tag Lisp_Object RET Change c:/download/emacs-cvs/emacs/src/ to c:/download/emacs-cvs/emacs/Src/ M-x find-tag EMACS_INT RET Since tab completion sometimes takes more than ten seconds in the directories where I work, I often write out the names myself and since letter-case usually does not matter on ms windows, I did not figure out it would matter in this case. On 4/11/07, Eli Zaretskii [EMAIL PROTECTED] wrote: Date: Wed, 11 Apr 2007 07:53:27 +0200 From: Matzi Kratzi [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] The problem appears to be the letter-case. I can repeat this by using etags from the pretest on the files in src in the pretest source. If I load process.c, run find-tag and change the spelling of src to Src, I get the same behaviour the second time I use find-tag. Please give me a complete self-contained test case, starting from emacs -Q. I'd like to see whether some of these problems can be easily fixed before Emacs 22.1 is released. TIA ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I might have reported this before but display seems all over the place when the buffer has a left margin in a tty. To see this start Emacs in an xterm, debug a program with M-x gdb, set a breakpoint, run and click alternately on the GUD and source buffer, or even repeatedly in the source buffer. The margin appears and disappears, so does the breakpoint symbol, B. Also various source lines get indented. I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
misbehaviour of outline-backward-same-level
`outline-backward-same-level' will move from a heading line to a non-heading line when on the first level-1 heading. To reproduce: o Open the attached file o Go to * Head 1 o C-c C-b (which runs the command outline-backward-same-level) o Cursor moved to the first line of the buffer -*-outline-*- This is some random text. * Head 1 * Head 2 ** Item 1 ** Item 2 * Head 3 The bug causes some trouble in org mode (which derives from outline mode). See: http://permalink.gmane.org/gmane.emacs.orgmode/1570 -- Leo ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I got the mouse working, but I still don't see any problems. Notice that _if_ the margin is bound to the window, rather than the buffer, then calling set-window-buffer may clear the margin. Try setting left-margin-width in the buffer to see if it has a healing effect. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote:
Lennart Borgman (gmail) [EMAIL PROTECTED] writes:
Looking at the logic it seems like it perhaps should be like below
instead? This at least works in my case. The current test just seems
useless. Or perhaps I am just very bad at reading C code?
The useless code you refer to was installed to fix a bug, and it
did fix _that_ bug.
The code before my change looked like this:
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
|| PT = MATRIX_ROW_START_CHARPOS (row));
I thought it was useless because it the first test with PT seems to
imply that the second test with PT must be true. I did not look into the
structures and how they are used, only the names of the macros and the
definition of them.
Do you say that the second test actually could fail? I believed it was
perhaps a mis-paste or something.
Now you have found a different bug in the same code, and you propose
a different way to fix _your_ bug.
Indeed your code does look like it could fix the problem - but it
definitely changes the semantics of the test, so there may very well
be other corner casee which are broken by _your_ code.
Can you track down the bug report(s) which lead up to the fix I
installed, so you can confirm that your change also fixes the old bug(s).
I must be close to the date in the ChangeLog.
If you think that the test actually does something I can try.
Besides, the ++row seems dangrous to me. Would row+1 do the same?
Sorry, yes, that is better and my first test now implies it works.
This is the bug I want to have fixed (since it is very visible), but
there are other bugs there too. The first one is for the record, perhaps
you care about the second:
1) In some situations the cursor can still stop at the end of the first
row in the 'before-string. But I have only seen it once and I am not
sure how to reproduce it. (It does not happen when the overlay is at 1-1
or at least I have not seen it then.) Does this imply that some other
test in cursor_row_p may be wrong?
2) If you shrink the window so that the 'before-string fills from top to
bottom the first char after it disappears from the screen. Not extremely
serious in itself, but perhaps easy to fix (and it might also point to
other troubles, of course). To reproduce this eval the code below (same
as before):
(defvar temp-ovl nil)
(defun temp-toggle-ovl()
(interactive)
(if temp-ovl
(progn
(delete-overlay temp-ovl)
(setq temp-ovl nil))
(setq temp-ovl (make-overlay 1 1))
(let ((s A string\nwith several rows\nthat should be at top\n))
(put-text-property 0 (length s)
'face (list (cons 'background-color
yellow))
s)
(overlay-put temp-ovl 'before-string s
The create a new buffer with two rows:
First char may disappear.
But second line is ok.
Do
M-x temp-toggle-ovl
go to char 1 and then shrink the window vertically. When the number of
lines gets down to the height of the 'before-string the char F
disappears. Or the cursor may move to the first line of the 'before-string.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Kim F. Storm wrote: At this stage of the release cycle, a grave bug is one that makes Emacs crash, or causes really bad redisplay behaviour. As you said yourself, this is a corner case, so it is not a grave error. Ok, but with a corner case I meant a logical corner case. Those +-1 you often have to rethink after coding. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: edebug-pop-to-buffer fails for dedicated windows
martin rudalics [EMAIL PROTECTED] writes: edebug-pop-to-buffer changes the buffer in the next window. However this results in an error, if that window is dedicated. Please try the attached patch. It fixes the problem for me. Thank you. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[unicode-2] tmm-menubar breaks in org mode
Here is an easily reproducible bug: o emacs -Q o M-x org-mode o M-x tmm-menubar And backtrace: , | Debugger entered--Lisp error: (wrong-type-argument listp keymap) | tmm-get-keybind([menu-bar]) | tmm-menubar() | call-interactively(tmm-menubar) | execute-extended-command(nil) | call-interactively(execute-extended-command) ` Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes: Can you track down the bug report(s) which lead up to the fix I installed, so you can confirm that your change also fixes the old bug(s). I must be close to the date in the ChangeLog. The original bug report was at http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-06/msg00342.html However, your fix appears to have been unrelated to that original bug report: http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-07/msg00246.html From: Kim F. Storm Subject: Re: Overlays disappearing during line-by-line scrolling Date: Wed, 13 Jul 2005 12:35:42 +0200 I have installed some changes to fix this and other problems related to line-move around such multi-line overlay strings. The changes touches on some tricky low-level move_it_... functions so I may have broken other things... * I also fixed problems with positioning the cursor on (first char of) * such multi-line strings. Finally, I fixed problems related to vertical-motion not moving when point is on an image. The ChangeLog entry says: Row is ok if cursor is at newline from string, but string starts on this line (so we always position cursor at start of string). I think the current code is mistaken. The ChangeLog entry and the comments both say that we want to set cursor_row_p to a non-zero value in the case where the display string starts in this row. But that's not what it's doing; Lennart is correct in pointing out that it's setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: I think the current code is mistaken. The ChangeLog entry and the comments both say that we want to set cursor_row_p to a non-zero value in the case where the display string starts in this row. But that's not what it's doing; Lennart is correct in pointing out that it's setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). Looking at it again I wonder why my test change did not do that too ... ;-) To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? Reverting as you propose seems to at least cure the problem I saw. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong [EMAIL PROTECTED] writes: I think the current code is mistaken. The ChangeLog entry and the comments both say that we want to set cursor_row_p to a non-zero value in the case where the display string starts in this row. But that's not what it's doing; Lennart is correct in pointing out that it's setting cursor_row_p unconditionally, since PT == MATRIX_ROW_END_CHARPOS (row) implies PT = MATRIX_ROW_START_CHARPOS (row). To actually do what the comments and ChangeLog say we want to do, we would have to scan backward in the glyph row for the beginning of the string, which would be significantly more complicated than the current code. For the Emacs 22 release, maybe we should simply revert this change to cursor_row_p = row-continued_p; It does not cause the original 2005 bug report to reappear, and it doesn't seem to affect anything else as far as I can tell. WDYT? IIRC, the original problem I tried to solve is shown by this test-case: (progn (switch-to-buffer (get-buffer-create *test*)) (erase-buffer) (insert .\n\n.\n\n) (goto-char (point-min)) (let ((ov (make-overlay 4 7))) (overlay-put ov 'display Ax\nyB)) (goto-char (point-max))) With my change, moving the cursor places it on the 'A'. Without my change, moving the cursor places it on the 'y'. So my change may be incorrect - but it _does_ solve a real problem. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Crash with slime on WIN32
If slime is up and running and M-x slime is called again you are asked if you want to start an addtional inferior lisp. If this question is answered with n Emacs will crash. The action that triggers the crash is (kill-buffer *cl-connections*) Slime can be found at http://common-lisp.net/project/slime I did not succeed in reporducing the crach without slime. Hope this helps and thanks, Carsten In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-04 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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: DEU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: REPL Minor modes in effect: show-paren-mode: t global-auto-revert-mode: t cua-mode: t iswitchb-mode: t encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: f9 M-x r e p o r t - e m tab return Recent messages: Polling c:/DOCUME~1/zmbf08i/LOCALS~1/Temp/slime.1036.. (Abort with `M-x slime-abort-connection'.) Loading c:/Slime/init.el (source)...done Wrong type argument: listp, t Polling c:/DOCUME~1/zmbf08i/LOCALS~1/Temp/slime.1036.. (Abort with `M-x slime-abort-connection'.) [25 times] Connecting to Swank on port 3508.. [2 times] Loading animate...done Connected. Zmbf08i, this could be the start of a beautiful program. Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
corrected report for Emacs crash on WIN32 with slime
Hi i am sending this report again, because the first version contained in error in it. The buffer's name is *cl-connection* without plural. Sorry for the doubel posting. If slime is up and running and M-x slime is called again you are asked if you want to start an addtional inferior lisp. If this question is answered with n Emacs will crash. The action that triggers the crash is (kill-buffer *cl-connection*) Slime can be found at http://common-lisp.net/project/slime I did not succeed in reporducing the crach without slime. Hope this helps and thanks, Carsten In GNU Emacs 22.0.97.1 (i386-mingw-nt5.1.2600) of 2007-04-04 on LENNART-69DE564 Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' 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: DEU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: REPL Minor modes in effect: show-paren-mode: t global-auto-revert-mode: t cua-mode: t iswitchb-mode: t encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: f9 M-x r e p o r t - e m tab return Recent messages: Polling c:/DOCUME~1/zmbf08i/LOCALS~1/Temp/slime.1036.. (Abort with `M-x slime-abort-connection'.) Loading c:/Slime/init.el (source)...done Wrong type argument: listp, t Polling c:/DOCUME~1/zmbf08i/LOCALS~1/Temp/slime.1036.. (Abort with `M-x slime-abort-connection'.) [25 times] Connecting to Swank on port 3508.. [2 times] Loading animate...done Connected. Zmbf08i, this could be the start of a beautiful program. Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash with slime on WIN32
On 4/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Slime can be found at http://common-lisp.net/project/slime Which CL implementation are you using? Juanma ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Yes, I looked at the code but decided it takes me too long time at the moment. Kim, is this easy for you? Changes to redisplay are NEVER easy ... I made a seemingly trivial change to fix one bug ... and two years later someone finds a problem with it. IMO, this is not the time to try to fix that. This could be a corner case. If so, you could fix it, and things would surely be better even if maybe not perfect. So please try. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
If not, is this documented in PROBLEMS or somewhere suitable? The problem and workaround are documented in PROBLEMS. That is good. It looks like we can't do better than that. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
I wonder if Jose has some obsolete Emacs Lisp code in his load-path. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
On 4/12/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: I wonder if Jose has some obsolete Emacs Lisp code in his load-path. Actually, I've discovered the culprit: it was an old version of quack.el mode for scheme (a third party add-on). I've updated to the last version of quack and the bug is gone (and, of course, it didn't appear without loading quack at all). My apologies for the noise, and thanks. I'll try to be more careful next time. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says. However, it is dangerous
to change string_buffer_position right now, because it's called from
several places in xdisp.c. Changing its behavior runs a serious risk
of introducing subtle bugs.
Thus, I think this issue should be left alone for the Emacs 22.1. It
is easy to work around the affected corner case, by using text
properties or a display property rather an overlay with a
before-string. After 22.1, I can take a look at fixing this along the
lines discussed above.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong [EMAIL PROTECTED] writes: Thus, I think this issue should be left alone for the Emacs 22.1. Agree. It is easy to work around the affected corner case, by using text properties or a display property rather an overlay with a before-string. After 22.1, I can take a look at fixing this along the lines discussed above. Thank you. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Ugly W32 display bug - fontified letters chopped on right
Date: Thu, 12 Apr 2007 07:58:37 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:53:18 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Kim F. Storm [EMAIL PROTECTED] Maybe it would help users and save developers some time if the problems specific to common fonts where mentioned too? What problems are those? I mean those specific cases that has been discussed here lately. AFAIR, they were all related to ClearType, right? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Jose A. Ortega [EMAIL PROTECTED] writes: On 4/12/07, Richard Matthew Stallman [EMAIL PROTECTED] wrote: I wonder if Jose has some obsolete Emacs Lisp code in his load-path. Actually, I've discovered the culprit: it was an old version of quack.el mode for scheme (a third party add-on). I've updated to the last version of quack and the bug is gone (and, of course, it didn't appear without loading quack at all). My apologies for the noise, and thanks. I'll try to be more careful next time. Should we add quack.el to the list of packages which we recommend people to upgrade when using Emacs 22.1 ? (The list is in etc/NEWS). -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Date: Thu, 12 Apr 2007 08:00:37 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Eli Zaretskii wrote: Date: Wed, 11 Apr 2007 22:48:34 +0200 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: Chong Yidong [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] FWIW, I wouldn't touch this so close to the release: if no one noticed this since July 2005, it's hardly a grave bug. How do you know? This just looks so strange so it could well be a grave bug. How do I know what? that it's not grave? But I just explained that! To me it looks more like using a 'before-string of the kind I am using is uncommon. But maybe that is what you mean, that is not grave because it is uncommon. A feature that no one used in almost 2 years is uncommon, yes. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says. However, it is dangerous
to change string_buffer_position right now, because it's called from
several places in xdisp.c. Changing its behavior runs a serious risk
of introducing subtle bugs.
I tested another way that perhaps is in line with Kim's original intent.
Since I do not know this code I had to guess put I put it here so you
can comment:
static int
cursor_row_p (w, row)
struct window *w;
struct glyph_row *row;
{
int cursor_row_p = 1;
if (PT == MATRIX_ROW_END_CHARPOS (row))
{
/* If the row ends with a newline from a string, we don't want
the cursor there, but we still want it at the start of the
string if the string starts in this row.
If the row is continued it doesn't end in a newline. */
fprintf (stderr, cont=%d, start.string_pos=%d, %d, end=%d, %d\n,
row-continued_p,
CHARPOS (row-start.string_pos),
row-start.pos.charpos,
CHARPOS (row-end.string_pos),
row-end.pos.charpos);
if (CHARPOS (row-end.string_pos) = 0)
cursor_row_p = (row-continued_p
||
(
/* If an overlay string starts on this glyph
line, then put the cursor here, but only
if not on the first buffer line and there
are no characters there. */
((CHARPOS (row-start.string_pos)) == -1)
((CHARPOS (row-end.string_pos)) -1)
(row-start.pos.charpos 1)
));
else if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (row))
{
/* If the row ends in middle of a real character,
and the line is continued, we want the cursor here.
That's because MATRIX_ROW_END_CHARPOS would equal
PT if PT is before the character. */
if (!row-ends_in_ellipsis_p)
cursor_row_p = row-continued_p;
else
/* If the row ends in an ellipsis, then
MATRIX_ROW_END_CHARPOS will equal point after the invisible text.
We want that position to be displayed after the ellipsis. */
cursor_row_p = 0;
}
/* If the row ends at ZV, display the cursor at the end of that
row instead of at the start of the row below. */
else if (row-ends_at_zv_p)
cursor_row_p = 1;
else
cursor_row_p = 0;
}
return cursor_row_p;
}
This works for me and for Kim's test case as far as I can see. However
as can be seen from the fprintf output with my test case it starts
looping when I go to the first character and then press left arrow.
Thus, I think this issue should be left alone for the Emacs 22.1. It
is easy to work around the affected corner case, by using text
properties or a display property rather an overlay with a
before-string. After 22.1, I can take a look at fixing this along the
lines discussed above.
Could you please tell me how then? I want to display text at the top of
a buffer, but I do not want to change the users text in the buffer.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) wrote: This works for me and for Kim's test case as far as I can see. However as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
Kim F. Storm wrote: Should we add quack.el to the list of packages which we recommend people to upgrade when using Emacs 22.1 ? (The list is in etc/NEWS). I don't think this was a quack + emacs 22 problem, it was just a problem in older versions of quack, full stop. http://www.neilvandyke.org/quack/quack.el ;; HISTORY: ;; ;; Version 0.29 (2006-11-12) ;; * Fixed `quack-bar-syntax-string', which caused vertical bar ;; characters to be treated as whitespace. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: /* If the row ends with a newline from a string, we don't want the cursor there, but we still want it at the start of the string if the string starts in this row. If the row is continued it doesn't end in a newline. */ if (CHARPOS (row-end.string_pos) = 0) cursor_row_p = (row-continued_p || ( /* If an overlay string starts on this glyph line, then put the cursor here, but only if not on the first buffer line and there are no characters there. */ ((CHARPOS (row-start.string_pos)) == -1) ((CHARPOS (row-end.string_pos)) -1) (row-start.pos.charpos 1) )); This does not solve the underlying problem, because the unexpected cursor position can occur even if the affected overlay is not on the first line. as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. As you can see, tweaking redisplay can have rather non-trivial effects. Could you please tell me how then? I want to display text at the top of a buffer, but I do not want to change the users text in the buffer. Why not just use a header line? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Lennart Borgman (gmail) wrote: This works for me and for Kim's test case as far as I can see. However as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: /* If the row ends with a newline from a string, we don't want the cursor there, but we still want it at the start of the string if the string starts in this row. If the row is continued it doesn't end in a newline. */ if (CHARPOS (row-end.string_pos) = 0) cursor_row_p = (row-continued_p || ( /* If an overlay string starts on this glyph line, then put the cursor here, but only if not on the first buffer line and there are no characters there. */ ((CHARPOS (row-start.string_pos)) == -1) ((CHARPOS (row-end.string_pos)) -1) (row-start.pos.charpos 1) )); This does not solve the underlying problem, because the unexpected cursor position can occur even if the affected overlay is not on the first line. I trust you that it does not solve the underlying problem, but it works in my case and in the test case Kim supplied. That said I of course believe there can be problems with this solution, but I hope for your comments on that. as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. As you can see, tweaking redisplay can have rather non-trivial effects. Yes, I really believe it can, but I was wrong in this case. The problem is there without my changes. A new small bug. Could you please tell me how then? I want to display text at the top of a buffer, but I do not want to change the users text in the buffer. Why not just use a header line? Because I need several lines and I think it is rather necessary that they move together with the buffer contents to save screen estate. I want to put this at the top of the buffer to make it easier for users to understand what is happening. This is part of nXhtml where I try to adopt James Clark's nxml-mode for editing of XHTML files and also files that are not full XHTML, like php, jsp etc. The framework from nxml-mode parses the XML code in the buffer and gives the user the possibility to use completion of tags, attributes and values in accordance with the DTD. Now in the case of php this headers may not be there in the buffer (since they may instead be created dynamically) so I give the framework a starting state instead. To show the user the starting state I want to (optionally) show these lines in the buffer. Even with this feedback it may be difficult to understand what is happening, but hopefully with it users will learn. So at the top of the buffer I am displaying something like this with the help of an overlay and 'before-string: ?xml version=1.0 encoding=iso-8859-1? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html xmlns=http://www.w3.org/1999/xhtml; head titleDummy/title /head body ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: Lennart Borgman (gmail) wrote: This works for me and for Kim's test case as far as I can see. However as can be seen from the fprintf output with my test case it starts looping when I go to the first character and then press left arrow. This was wrong. The looping occurs without my changes. The only thing one has to do is to go to the first character in a buffer and then press left arrow. With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. Could you please recompile with the fprint part of the code I sent before? Then start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 67 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 1 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 cont=0, start.string_pos=-1, 1, end=-1, 20 ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. Could you please recompile with the fprint part of the code I sent before? Then start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It does not loop infinitely, at least for me. The messages stop as soon as Emacs finishes starting up, as expected. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. I can't reproduce this. You probably left some of your code in xdisp.c. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: I trust you that it does not solve the underlying problem, but it works in my case and in the test case Kim supplied. That said I of course believe there can be problems with this solution, but I hope for your comments on that. Like I said, the unexpected cursor position can occur even if the affected overlay is not on the first line, so there's no point introducing a kludge to handle the case where it is on the first line. It is better to wait for Emacs 22.2 to fix it for real. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
BibTeX-mode: bibtex-user-optional-fields: INIT without {}
Hello!
It is possible to define additional fields for BibTeX entries. This is
done with the variable `bibtex-user-optional-fields':
,[ From C-h v bibtex-user-optional-fields RET ]
| Documentation:
| List of optional fields the user wants to have always present.
| Entries should be of the same form as the OPTIONAL and
| CROSSREF-OPTIONAL lists in `bibtex-entry-field-alist' (which see).
`
,[ From C-h v bibtex-entry-field-alist RET ]
| Each element of these lists is a list of the form
| (FIELD-NAME COMMENT-STRING INIT ALTERNATIVE-FLAG).
| COMMENT-STRING, INIT, and ALTERNATIVE-FLAG are optional.
| FIELD-NAME is the name of the field, COMMENT-STRING is the comment that
| appears in the echo area, INIT is either the initial content of the
| field or a function, which is called to determine the initial content
| of the field, and ALTERNATIVE-FLAG (either nil or t) marks if the
| field is an alternative. ALTERNATIVE-FLAG may be t only in the
| REQUIRED or CROSSREF-REQUIRED lists.
`
The problem is with INIT: in Emacs 21.3, setting INIT of an additional
field (here called chrsc) to Summary: created this:
OPTchrsc = {Summary: },
But in Emacs 22.0.97, I get this:
OPTchrsc = Summary: ,
So the curly braces are missing. This is a problem when pressing C-c
C-c (`bibtex-clean-entry'), see below.
Recipe to reproduce the bug:
1. emacs -q --no-site-file
2. Evaluate the following in the *scratch* buffer:
--8---cut here---start-8---
(add-hook 'bibtex-mode-hook
(lambda ()
(add-to-list 'bibtex-user-optional-fields
'(chrsc Personal summary (ignored)
Summary:
--8---cut here---end---8---
(Alternatively, use M-x customize-variable bibtex-user-optional-fields
RET.)
3. C-x C-f foo.bib RET C-c C-e M gives a buffer containing:
@Misc{,
OPTkey = {},
OPTauthor ={},
OPTtitle = {},
OPThowpublished = {},
OPTmonth = {},
OPTyear = {},
OPTnote = {},
OPTchrsc = Summary: ,
OPTannote ={}
}
Write `long long text.' behind `Summary: ' and press C-c C-c. You get
`Syntactically incorrect BibTeX entry starts here.'
A `Misc' entry has no required fields, so nothing is missing *except*
the curly braces around the `Summary: long long text.' entry. Add
these curly braces, and C-c C-c works.
This worked as expected in Emacs 21.3 -- the curly braces were still
inserted in that version of BibTeX mode:
OPTchrsc = {Summary: },
In GNU Emacs 22.0.97.1 (i686-pc-linux-gnu, GTK+ Version 2.10.6)
of 2007-04-08 on whisker
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--prefix=/home/cschl/sw/emacs-22' '--with-gtk''
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: en_GB.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: BibTeX
Minor modes in effect:
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
C-l C-y C-x C-e C-x C-f f o o . b i b return C-c
C-e M M-x r e p o r t tab return
Recent messages:
For information about the GNU Project and its goals, type C-h C-p. [2 times]
Mark set
((lambda nil (add-to-list (quote bibtex-user-optional-fields) (quote ...
(New file)
Loading bibtex...
Loading easymenu...done
Loading regexp-opt...done
Loading bibtex...done
Used for reference key creation if author and editor fields are missing
Loading emacsbug...done
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote: Lennart Borgman (gmail) [EMAIL PROTECTED] writes: With current CVS, I do not observe any infloop for the test case you sent. If you think you have observed one, please send a precise recipe. Could you please recompile with the fprint part of the code I sent before? Then start with emacs -Q. For me a continues output from the frpintf statements starts immediately, something like the below. It does not loop infinitely, at least for me. The messages stop as soon as Emacs finishes starting up, as expected. It stops if I enter some text and continues if I go to the beginning of the buffer and then press left arrow again. I can't reproduce this. You probably left some of your code in xdisp.c. Yes, you are right. it actually stops if you wait a little longer than I did. But it takes 80-100 turns before it does that. And it starts again if you press left or right arrow. And it stops if you press up or down arrow. Something strange perhaps, but nothing to worry about. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Chong Yidong wrote:
[EMAIL PROTECTED] (Kim F. Storm) writes:
IIRC, the original problem I tried to solve is shown by this test-case:
(progn
(switch-to-buffer (get-buffer-create *test*))
(erase-buffer)
(insert .\n\n.\n\n)
(goto-char (point-min))
(let ((ov (make-overlay 4 7)))
(overlay-put ov 'display Ax\nyB))
(goto-char (point-max)))
With my change, moving the cursor places it on the 'A'.
Without my change, moving the cursor places it on the 'y'.
So my change may be incorrect - but it _does_ solve a real problem.
OK, now I see the problem.
I believe the underlying fault is not in cursor_row_p, but in
set_cursor_from_row, on xdisp.c:11948:
pos = string_buffer_position (w, string, string_before_pos);
/* If STRING is from overlay, LAST_POS == 0. We skip such glyphs
because we always put cursor after overlay strings. */
while (pos == 0 glyph stop)
{
string = glyph-object;
The assumption made in the comment is not correct:
string_buffer_position returns non-zero values for overlay strings
with the `display' property. In xdisp.c:4446:
prop = Fget_char_property (pos, Qdisplay, Qnil);
if (!NILP (prop) display_prop_string_p (prop, string))
found = 1;
This suggests that the way to fix this is to change
string_buffer_position to do what that says.
I tested with !display_prop_string_p at the two places in
string_buffer_position where it occurs. That does the correct thing in
my case, but not in Kim's example AFAICS.
In Kim's example the cursor stops after the 'display part when moving
char by char from left or right. It stays on that position for an extra
left or right arrow.
Checking if the string is from 'display at the correct position in
set_cursor_from_row could perhaps cure the problem. There is a test now
for Qdisplay, but it looks like this test might be disabled by the while
loop right above it which skips all overlays.
However, it is dangerous
to change string_buffer_position right now, because it's called from
several places in xdisp.c. Changing its behavior runs a serious risk
of introducing subtle bugs.
Maybe. They are either in set_cursor_from_row or note_mouse_highlight.
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Here is an easily reproducible bug: o emacs -Q o M-x org-mode o M-x tmm-menubar And backtrace: , | Debugger entered--Lisp error: (wrong-type-argument listp keymap) | tmm-get-keybind([menu-bar]) | tmm-menubar() | call-interactively(tmm-menubar) | execute-extended-command(nil) | call-interactively(execute-extended-command) ` It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? I can't find the entries that follow them in the menubar, i.e, Headings, Up, Show All and Hide Leaves which look like they should appear under the Tbl top level menu item. ... (Column menu-item Column ...) ...)) keymap (headings Headings keymap (outline-up-heading Up . outline-up-heading) (outline-next-visible-heading Next . outline-next-visible-heading) (outline-previous-visible-heading Previous . outline-previous-visible-heading) (outline-forward-same-level Next Same Level . outline-forward-same-level) (outline-backward-same-level Previous Same Level . outline-backward-same-level) (outline-insert-heading New heading . outline-insert-heading) (copy menu-item Copy to kill ring outline-headers-as-kill :enable mark-active) (move-subtree-up menu-item Move subtree up outline-move-subtree-up) (move-subtree-down menu-item Move subtree down outline-move-subtree-down) ...) (show Show keymap (show-all Show All . show-all) (show-entry Show Entry . show-entry) (show-branches Show Branches . show-branches) (show-children Show Children . show-children) (show-subtree Show Subtree . show-subtree) Show) (hide Hide keymap (hide-leaves Hide Leaves . hide-leaves) (hide-body Hide Body . hide-body) (hide-entry Hide Entry . hide-entry) (hide-subtree Hide Subtree . hide-subtree) (hide-sublevels Hide Sublevels . hide-sublevels) (hide-other Hide Other . hide-other) Hide)) Carsten, Does this keymap look right to you? -- Nick http://www.inet.net.nz/~nickrob___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Nick Roberts wrote: It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! [...] Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? According to the lispref Inheritance and Keymaps, yes. Eg: (let ((map (make-sparse-keymap))) (set-keymap-parent map text-mode-map) map) So how about this fix: *** tmm.el 3 Apr 2007 10:09:45 - 1.52 --- tmm.el 12 Apr 2007 22:46:20 - *** *** 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car item) globalbind (dolist (item (cdr localbind)) ! (setq globalbind (assq-delete-all (car item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) --- 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind (dolist (item (cdr localbind)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: bibtex-user-optional-fields: INIT without {}
Christian Schlauer wrote: So the curly braces are missing. I think this patch fixes it. *** bibtex.el 21 Jan 2007 13:45:48 - 1.124 --- bibtex.el 12 Apr 2007 22:49:20 - *** *** 1785,1791 (set-mark (point)) (message Mark set) (bibtex-make-field (funcall fun 'bibtex-field-kill-ring-yank-pointer ! bibtex-field-kill-ring) t)) ;; insert past the current entry (bibtex-skip-to-valid-entry) (set-mark (point)) --- 1785,1791 (set-mark (point)) (message Mark set) (bibtex-make-field (funcall fun 'bibtex-field-kill-ring-yank-pointer ! bibtex-field-kill-ring) t nil t)) ;; insert past the current entry (bibtex-skip-to-valid-entry) (set-mark (point)) *** *** 3020,3026 (if comment (message %s (nth 1 comment)) (message No comment available) ! (defun bibtex-make-field (field optional move interactive) Make a field named FIELD in current BibTeX entry. FIELD is either a string or a list of the form \(FIELD-NAME COMMENT-STRING INIT ALTERNATIVE-FLAG) as in --- 3020,3026 (if comment (message %s (nth 1 comment)) (message No comment available) ! (defun bibtex-make-field (field optional move interactive nodelim) Make a field named FIELD in current BibTeX entry. FIELD is either a string or a list of the form \(FIELD-NAME COMMENT-STRING INIT ALTERNATIVE-FLAG) as in *** *** 3028,3034 If MOVE is non-nil, move point past the present field before making the new field. If INTERACTIVE is non-nil, move point to the end of the new field. Otherwise move point past the new field. ! MOVE and INTERACTIVE are t when called interactively. (interactive (list (let ((completion-ignore-case t) (field-list (bibtex-field-list --- 3028,3035 If MOVE is non-nil, move point past the present field before making the new field. If INTERACTIVE is non-nil, move point to the end of the new field. Otherwise move point past the new field. ! MOVE and INTERACTIVE are t when called interactively. ! INIT is surrounded by delimiters, unless NODELIM is non-nil. (interactive (list (let ((completion-ignore-case t) (field-list (bibtex-field-list *** *** 3058,3067 (indent-to-column (+ bibtex-entry-offset bibtex-text-indentation))) (let ((init (nth 2 field))) ! (insert (cond ((stringp init) init) ((fboundp init) (funcall init)) ! (t (concat (bibtex-field-left-delimiter) ! (bibtex-field-right-delimiter)) (when interactive ;; (bibtex-find-text nil nil bibtex-help-message) (if (memq (preceding-char) '(?} ?\)) (forward-char -1)) --- 3059,3073 (indent-to-column (+ bibtex-entry-offset bibtex-text-indentation))) (let ((init (nth 2 field))) ! (insert (if nodelim ! ! (bibtex-field-left-delimiter)) ! (cond ((stringp init) init) ((fboundp init) (funcall init)) ! (t )) ! (if nodelim ! ! (bibtex-field-right-delimiter (when interactive ;; (bibtex-find-text nil nil bibtex-help-message) (if (memq (preceding-char) '(?} ?\)) (forward-char -1)) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
I should also say that the Format of Keymaps section of the lispref has an example (lisp-mode-map) with a keymap sitting there on its own. It looks weird to me too, but there you go. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
- Glenn Morris (2007-04-12) wrote:- Nick Roberts wrote: It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! [...] Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? According to the lispref Inheritance and Keymaps, yes. Eg: [...] Yes, it fixes the bug. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Lennart Borgman (gmail) [EMAIL PROTECTED] writes: However, it is dangerous to change string_buffer_position right now, because it's called from several places in xdisp.c. Changing its behavior runs a serious risk of introducing subtle bugs. Maybe. They are either in set_cursor_from_row or note_mouse_highlight. In the past, we've had point-is-completely-stuck bugs originating from the former code, and crash bugs from the latter. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
So how about this fix: *** tmm.el 3 Apr 2007 10:09:45 - 1.52 --- tmm.el 12 Apr 2007 22:46:20 - *** *** 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car item) globalbind (dolist (item (cdr localbind)) !(setq globalbind (assq-delete-all (car item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) --- 547,555 ;; the global list. (dolist (minor minorbind) (dolist (item (cdr minor)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind (dolist (item (cdr localbind)) ! (setq globalbind (assq-delete-all (car-safe item) globalbind))) (setq globalbind (cons 'keymap globalbind)) (setq allbind (cons globalbind (cons localbind minorbind))) Does it fix the bug, or just mask the error? I mean does the menu on a tty for Org mode look as it should with this change? -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Nick Roberts wrote: Does it fix the bug, or just mask the error? I mean does the menu on a tty for Org mode look as it should with this change? Well, it looks alright to me (at least, it looks the same as it does in 21.3 when I load org-mode), but I don't know what problem your recent change was trying to fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: misbehaviour of outline-backward-same-level
Leo [EMAIL PROTECTED] writes: `outline-backward-same-level' will move from a heading line to a non-heading line when on the first level-1 heading. I checked in a (hopefully pretty safe) fix. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Nick Roberts [EMAIL PROTECTED] writes: I don't see this. But I cannot use the mouse when emacs -nw is running in an xterm (xterm seems to own the mouse) - is it necessary to use the mouse to see the problem? Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I can't seem to reproduce this, even with xterm-mouse-mode enabled. Can you give a more precise recipe? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
I added `iff' to the Glossary. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: edebug-pop-to-buffer fails for dedicated windows
If your patch works, please install it soon! ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
Can you track down the bug report(s) which lead up to the fix I installed, so you can confirm that your change also fixes the old bug(s). It must be close to the date in the ChangeLog. IIRC, there were quite a lot of test cases - combining before and after strings as well as compositions, so I really feel bad about touching this now. If you make a change that only takes action in the bug case, you can be sure you are not breaking any other case. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Display problems with 'before-string in overlay
At this stage of the release cycle, a grave bug is one that makes Emacs crash, or causes really bad redisplay behaviour. I think redisplay bugs are serious bugs. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
I managed to reproduce the bug. emacs -nw M-: (set-window-margins (selected-window) 1) RET C-x 2 C-x ^ Pressing left and right button and inserting text now makes it clear that redisplay is broken. The call to enlarge-window and set-window-margins appears to be essential to producing this bug. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display margin errors on a tty
Yes, that's strange. It seems to have something to do with xterm-mouse-mode being enabled. I can't see any connection between the two, though. I can't seem to reproduce this, even with xterm-mouse-mode enabled. Can you give a more precise recipe? Actually now I can only seem to reproduce it when the xterm has a scrollbar (with or without xterm-mouse-mode). I thought I also saw it in the Linux console but I'm moving between machines/terminal types. It's probably best to disregard this bug report - sorry. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
Does it fix the bug, or just mask the error? I mean does the menu on a tty for Org mode look as it should with this change? Well, it looks alright to me (at least, it looks the same as it does in 21.3 when I load org-mode), but I don't know what problem your recent change was trying to fix. Ok, I've committed this change. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
On Apr 13, 2007, at 0:39, Nick Roberts wrote: Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? I can't find the entries that follow them in the menubar, i.e, Headings, Up, Show All and Hide Leaves which look like they should appear under the Tbl top level menu item. Carsten, Does this keymap look right to you? Well, here is what org-mode does: Org-mode is derived from outline-mode, which means that it also inherits the Show, Hide, and Headings menus. Now, org-mode has much better ways of changing visibility in a buffer, so I want to get rid of these menus, before I install org-mode's own menus (Org and Tbl). Here is the code that does this: (define-key org-mode-map [menu-bar headings] 'undefined) (define-key org-mode-map [menu-bar hide] 'undefined) (define-key org-mode-map [menu-bar show] 'undefined)) (easy-menu-add org-org-menu) (easy-menu-add org-tbl-menu) I always thought that this would get properly get rid of these menus, but looking at the keymap I agree that this does not seem to be done cleanly. If there is a better way to remove the outline-mode stuff from the keymap, I definitely would like to know about it. - Carsten ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: misbehaviour of outline-backward-same-level
- Chong Yidong (2007-04-13) wrote:- `outline-backward-same-level' will move from a heading line to a non-heading line when on the first level-1 heading. I checked in a (hopefully pretty safe) fix. I can confirm it fixes the bug. Thanks. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
