From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: xdisp.c problem? Date: Fri, 31 Jan 2003 12:58:37 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301310358.MAA21102@etlken.m17n.org> References: <20030129.174125.01368882.Takaaki.Ota@am.sony.com> <200301300351.MAA18471@etlken.m17n.org> <20030130.131322.01368777.Takaaki.Ota@am.sony.com> <20030130.155620.107709347.Takaaki.Ota@am.sony.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1043985493 1459 80.91.224.249 (31 Jan 2003 03:58:13 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2003 03:58:13 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18eSJf-0000NF-00 for ; Fri, 31 Jan 2003 04:58:11 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18eSPd-0002b0-00 for ; Fri, 31 Jan 2003 05:04:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18eSL2-0002vN-04 for emacs-devel@quimby.gnus.org; Thu, 30 Jan 2003 22:59:36 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18eSKe-0002Wo-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 22:59:12 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18eSKO-0001s6-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 22:58:57 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18eSKG-0001Zk-00 for emacs-devel@gnu.org; Thu, 30 Jan 2003 22:58:48 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0V3wbk23145; Fri, 31 Jan 2003 12:58:37 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0V3wbR13305; Fri, 31 Jan 2003 12:58:37 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id MAA21102; Fri, 31 Jan 2003 12:58:37 +0900 (JST) Original-To: Takaaki.Ota@am.sony.com In-reply-to: <20030130.155620.107709347.Takaaki.Ota@am.sony.com> (message from Tak Ota on Thu, 30 Jan 2003 15:56:20 -0800 (PST)) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Original-cc: gerd.moellmann@t-online.de X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:11247 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11247 In article <20030130.155620.107709347.Takaaki.Ota@am.sony.com>, Tak Ota writes: > Here is the complete trace to where unwind_to_catch brings us back to > internal_condition_case and the descending starts all over again. The > function set_cursor_from_row is in the trace. It was not a simple > loop but continuous signal generation caused by the change to > internal_condition_case. [...] > unwind_to_catch() line 1172 > Fsignal(int 0x112b125c, int 0x519a46dc) line 1547 + 12 bytes > args_out_of_range(int 0x00000000, int 0x00000000) line 140 + 35 bytes > validate_interval_range(int 0x41942000, int * 0x0082f024, int * 0x0082f024, int 0x00000000) line 151 + 8 bytes > Ftext_properties_at(int 0x00000000, int 0x41942000) line 585 + 16 bytes > get_char_property_and_overlay(int 0x00000000, int 0x112d38ac, int 0x0082f030, int * 0x00000000) line 688 + 12 bytes > Fnext_single_char_property_change(int 0x00000000, int 0x112d38ac, int 0x11297404, int 0x000006f5) line 802 > set_cursor_from_row(window * 0x019f9400, glyph_row * 0x00000000, glyph_matrix * 0x01a85000, int 0x00000000, int 0x00000000, int 0x00000000, int 0x00000000) line 9527 + 24 bytes It seems that Fnext_single_char_property_change is called with POS == 0 in this code: L9525: pos = make_number (string_buffer_position (w, glyph->object, L9526: string_before_pos)); L9527: pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit); That means string_buffer_position returns 0 in your case. Hmmm, as this function checks only `display' property, that is a likely result if the buffer contains overlay string. I've just installed the attached patch to skip such glyphs that come from overlay string. Please try again. --- Ken'ichi HANDA handa@m17n.org 2003-01-31 Kenichi Handa * xdisp.c (SKIP_GLYPHS): New macro. (set_cursor_from_row): Skip all glyphs that comes from overlay string. *** xdisp.c.~1.803.~ Wed Jan 29 21:55:18 2003 --- xdisp.c Fri Jan 31 11:43:08 2003 *************** *** 9447,9452 **** --- 9447,9465 ---- return Qnil; } + + /* Increment GLYPH until it reaches END or CONDITION fails while + adding (GLYPH)->pixel_width to X. */ + + #define SKIP_GLYPHS(glyph, end, x, condition) \ + do \ + { \ + (x) += (glyph)->pixel_width; \ + ++(glyph); \ + } \ + while ((glyph) < (end) && (condition)) + + /* Set cursor position of W. PT is assumed to be displayed in ROW. DELTA is the number of bytes by which positions recorded in ROW differ from current buffer positions. */ *************** *** 9501,9512 **** string_start = glyph; string_start_x = x; /* Skip all glyphs from string. */ ! do ! { ! x += glyph->pixel_width; ! ++glyph; ! } ! while (glyph < end && STRINGP (glyph->object)); } } --- 9514,9520 ---- string_start = glyph; string_start_x = x; /* Skip all glyphs from string. */ ! SKIP_GLYPHS (glyph, end, x, STRINGP (glyph->object)); } } *************** *** 9517,9544 **** are from string. As there's no easy way to know the character position of the current glyph, find the correct glyph on point by scanning from string_start again. */ ! Lisp_Object pos, limit; ! limit = make_number (MATRIX_ROW_END_CHARPOS (row) + delta); glyph = string_start; x = string_start_x; ! pos = make_number (string_buffer_position (w, glyph->object, ! string_before_pos)); ! pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit); ! while (XINT (pos) <= pt_old) { /* Skip glyphs from the same string. */ ! do { ! x += glyph->pixel_width; ! ++glyph; } - while (glyph < end - && EQ (glyph->object, string_start->object)); - if (glyph == end || !STRINGP (glyph->object)) - break; - string_start = glyph; - pos = Fnext_single_char_property_change (pos, Qdisplay, Qnil, limit); } } --- 9525,9566 ---- are from string. As there's no easy way to know the character position of the current glyph, find the correct glyph on point by scanning from string_start again. */ ! Lisp_Object limit; ! Lisp_Object string; ! int pos; ! limit = make_number (pt_old + 1); ! end = glyph; glyph = string_start; x = string_start_x; ! string = glyph->object; ! 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 < end) ! { ! string = glyph->object; ! SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string)); ! if (glyph < end) ! pos = string_buffer_position (w, glyph->object, string_before_pos); ! } ! ! while (glyph < end) { + pos = XINT (Fnext_single_char_property_change + (make_number (pos), Qdisplay, Qnil, limit)); + if (pos > pt_old) + break; /* Skip glyphs from the same string. */ ! string = glyph->object; ! SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string)); ! /* Skip glyphs from an overlay. */ ! while (glyph < end ! && ! string_buffer_position (w, glyph->object, pos)) { ! string = glyph->object; ! SKIP_GLYPHS (glyph, end, x, EQ (glyph->object, string)); } } }