From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11199: 24.0.95; killing right-to-left text at eob leads to inconsistent state Date: Mon, 09 Apr 2012 12:10:09 +0300 Message-ID: <83d37h8e4u.fsf@gnu.org> References: <83bon2ad9z.fsf@gnu.org> <8762dacc3w.fsf@maru.md5i.com> <831uny9ekk.fsf@gnu.org> <87ty0uasiq.fsf@maru.md5i.com> <83y5q67z7h.fsf@gnu.org> <87lim6as39.fsf@maru.md5i.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1333962800 19120 80.91.229.3 (9 Apr 2012 09:13:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 9 Apr 2012 09:13:20 +0000 (UTC) Cc: 11199@debbugs.gnu.org To: Michael Welsh Duggan Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 09 11:13:19 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SHAev-0006Mg-OW for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Apr 2012 11:13:13 +0200 Original-Received: from localhost ([::1]:36506 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHAev-0003hX-1w for geb-bug-gnu-emacs@m.gmane.org; Mon, 09 Apr 2012 05:13:13 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHAer-0003gm-If for bug-gnu-emacs@gnu.org; Mon, 09 Apr 2012 05:13:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SHAep-00018a-9b for bug-gnu-emacs@gnu.org; Mon, 09 Apr 2012 05:13:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SHAep-00018W-5d for bug-gnu-emacs@gnu.org; Mon, 09 Apr 2012 05:13:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1SHAfh-00019W-H9 for bug-gnu-emacs@gnu.org; Mon, 09 Apr 2012 05:14:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Apr 2012 09:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11199 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11199-submit@debbugs.gnu.org id=B11199.13339627854332 (code B ref 11199); Mon, 09 Apr 2012 09:14:01 +0000 Original-Received: (at 11199) by debbugs.gnu.org; 9 Apr 2012 09:13:05 +0000 Original-Received: from localhost ([127.0.0.1]:46238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SHAel-00017m-UW for submit@debbugs.gnu.org; Mon, 09 Apr 2012 05:13:04 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:48503) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SHAei-00017K-L6 for 11199@debbugs.gnu.org; Mon, 09 Apr 2012 05:13:02 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M2700500G51IG00@a-mtaout22.012.net.il> for 11199@debbugs.gnu.org; Mon, 09 Apr 2012 12:12:04 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.57.204]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M27005MRG839040@a-mtaout22.012.net.il>; Mon, 09 Apr 2012 12:12:04 +0300 (IDT) In-reply-to: <87lim6as39.fsf@maru.md5i.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:58625 Archived-At: > From: Michael Welsh Duggan > Cc: mituharu@math.s.chiba-u.ac.jp, 11199@debbugs.gnu.org > Date: Sun, 08 Apr 2012 16:25:46 -0400 > > Eli Zaretskii writes: > > >> From: Michael Welsh Duggan > >> Cc: mituharu@math.s.chiba-u.ac.jp, 11199@debbugs.gnu.org > >> Date: Sun, 08 Apr 2012 16:16:29 -0400 > >> > >> (gdb) up > >> #4 0x080a82f0 in try_window_id (w=0x88e30d0) at xdisp.c:17140 > >> (gdb) pgrowx last_unchanged_at_beg_row > >> TEXT: 68 glyphs > >> 0 0: CHAR[ ] pos=237 blev=0,btyp=L w=8 a+d=12+3 MB > >> [...] > >> 67 536: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 MB > >> (gdb) prowlims last_unchanged_at_beg_row > >> edges=(237,305),r2l=0,cont=0,trunc=(0,0),at_zv=0 > >> (gdb) > > > > And what does the following produce in this frame? > > > > (gdb) p row->end > > (gdb) p row->end > $8 = { > pos = { > charpos = 309, > bytepos = 313 > }, I cannot figure out where these two numbers, 309 and 313, come from. If I repeat the recipe and look at the glyph matrix _before_ C-k, there are no such buffer positions anywhere in sight there. Which is what I'd expect, since after "C-x C-e", the buffer has only 308 characters. The fact that you see positions beyond that means that, at some point, the buffer was larger than that by 4 more characters. Can you figure out how this happened? Also, please verify that you see the same buffer positions in the glyph matrix as I do. Here's a GDB session I used to this end: (gdb) break Fredraw_display Breakpoint 3 at 0x10947df: file dispnew.c, line 3188. (gdb) r -Q Starting program: D:\gnu\bzr\emacs\trunk\src/./oo/i386/emacs.exe -Q Now repeat the recipe, up to and including the "C-x C-e" command. After that, type "M-x redraw-display RET", and GDB will kick in. Breakpoint 3, Fredraw_display () at dispnew.c:3188 3188 FOR_EACH_FRAME (tail, frame) Then: (gdb) break set_cursor_from_row Breakpoint 4 at 0x1180953: file xdisp.c, line 13663. (gdb) c Continuing. Breakpoint 4, set_cursor_from_row (w=0x38eea00, row=0x3873400, matrix=0x3840b80, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663 13663 struct glyph *glyph = row->glyphs[TEXT_AREA]; (gdb) bt 6 #0 set_cursor_from_row (w=0x38eea00, row=0x3873400, matrix=0x3840b80, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663 #1 0x011954e9 in display_line (it=0x82dcd0) at xdisp.c:19574 #2 0x01189a65 in try_window (window=59697669, pos=..., flags=0) at xdisp.c:16013 #3 0x01175146 in display_echo_area_1 (a1=59697664, a2=53667866, a3=0, a4=0) at xdisp.c:10035 #4 0x01173ef2 in with_echo_area_buffer (w=0x38eea00, which=0, fn=0x1175052 , a1=59697664, a2=53667866, a3=0, a4=0) at xdisp.c:9820 #5 0x01175021 in display_echo_area (w=0x38eea00) at xdisp.c:9996 (More stack frames follow...) (gdb) c Continuing. Breakpoint 4, set_cursor_from_row (w=0x38eec00, row=0x39254b4, matrix=0x3840400, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663 13663 struct glyph *glyph = row->glyphs[TEXT_AREA]; (gdb) bt 6 #0 set_cursor_from_row (w=0x38eec00, row=0x39254b4, matrix=0x3840400, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13663 #1 0x011954e9 in display_line (it=0x82ca40) at xdisp.c:19574 #2 0x01189a65 in try_window (window=59698181, pos=..., flags=1) at xdisp.c:16013 #3 0x0118731d in redisplay_window (window=59698181, just_this_one_p=0) at xdisp.c:15538 #4 0x01180908 in redisplay_window_0 (window=59698181) at xdisp.c:13637 #5 0x01033d9b in internal_condition_case_1 ( bfun=0x11808d6 , arg=59698181, handlers=53652222, hfun=0x11808b5 ) at eval.c:1553 (More stack frames follow...) The first time the breakpoint in set_cursor_from_row breaks is not of interest: as you see from the backtrace, Emacs is updating the echo area, not the *scratch* buffer which we are interested in. So I typed "continue". The second time it breaks _is_ of interest. To make sure this is our buffer, type: (gdb) pp w->buffer # (If what you see at this point is not *scratch*, keep typing "continue" until you hit the breakpoint when *scratch* is the current buffer.) Then: (gdb) until 13696 set_cursor_from_row (w=0x38eec00, row=0x39254b4, matrix=0x3840400, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:13696 13696 if (row->displays_text_p) (gdb) pmtxrows w->current_matrix 0: edges=(1,78),r2l=0,cont=0,trunc=(0,0),at_zv=0 1: edges=(78,141),r2l=0,cont=0,trunc=(0,0),at_zv=0 2: edges=(141,191),r2l=0,cont=0,trunc=(0,0),at_zv=0 3: edges=(191,192),r2l=0,cont=0,trunc=(0,0),at_zv=0 4: edges=(192,199),r2l=0,cont=0,trunc=(0,0),at_zv=0 5: edges=(199,237),r2l=0,cont=0,trunc=(0,0),at_zv=0 6: edges=(237,305),r2l=0,cont=0,trunc=(0,0),at_zv=0 7: edges=(305,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 8: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 9: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 10: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 11: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 12: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 13: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 14: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 15: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 16: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 17: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 18: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 19: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 20: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 21: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 22: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 23: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 24: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 25: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 26: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 27: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 28: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 29: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 30: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 31: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 32: edges=(309,309),r2l=0,cont=0,trunc=(0,0),at_zv=1 33: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0 34: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0 35: edges=(0,0),r2l=0,cont=0,trunc=(0,0),at_zv=0 pmtxrows shows all the glyph_row structures in the glyph matrix, including the buffer positions covered by each glyph row (== screen line). The last position of a row should always be equal to the first position of the next row (except when lines are reordered and continued, which is not the case here). As you see, the largest buffer position known to display engine at this point is 309, and the last line 7 has its ends_at_zv_p flag set, as I would expect. Do you see exactly the same contents of w->current_matrix, or do you see something different? Thanks.