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: problem of display property [Re: list-charset-chars and unicode-bmp] Date: Wed, 29 Jan 2003 16:39:59 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200301290739.QAA17357@etlken.m17n.org> References: <87u1g3atvf.fsf@mimuw.edu.pl> <200301210831.RAA03126@etlken.m17n.org> <871y35kej4.fsf@mimuw.edu.pl> <200301281129.UAA16158@etlken.m17n.org> <868yx5jvuf.fsf@gerd.free-bsd.org> 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 1043826583 17475 80.91.224.249 (29 Jan 2003 07:49:43 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2003 07:49:43 +0000 (UTC) Cc: jsbien@mimuw.edu.pl Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18dmyb-0004Xj-00 for ; Wed, 29 Jan 2003 08:49:41 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18dn3f-000395-00 for ; Wed, 29 Jan 2003 08:54:55 +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 18dmxq-000317-00 for emacs-devel@quimby.gnus.org; Wed, 29 Jan 2003 02:48:54 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18dmuJ-00026U-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 02:45:15 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18dmtf-0001rE-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 02:44:35 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18dmpM-0001lR-00 for emacs-devel@gnu.org; Wed, 29 Jan 2003 02:40:09 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h0T7e0k20778; Wed, 29 Jan 2003 16:40:00 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h0T7dxR02341; Wed, 29 Jan 2003 16:39:59 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id QAA17357; Wed, 29 Jan 2003 16:39:59 +0900 (JST) Original-To: gerd.moellmann@t-online.de In-reply-to: <868yx5jvuf.fsf@gerd.free-bsd.org> (gerd.moellmann@t-online.de) 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: d.love@dl.ac.uk Original-cc: emacs-devel@gnu.org 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:11184 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:11184 In article <868yx5jvuf.fsf@gerd.free-bsd.org>, gerd.moellmann@t-online.de (Gerd Moellmann) writes: > When current glyphs are reused, their positions are adjusted for the > changes in the buffer since the glyphs were made current. The > function try_window_id is one such example. I didn't see this being > done for the new slot you added to struct glyph. (Insofar, the > comment of struct glyph doesn't appear to be that devious :).) Ah, thank you! That explains the strange behaviour I noticed after I applied my patch, and is fixed by adjusting buf_charpos in increment_row_positions. But... > Be it as it may, I think I'd rather try to avoid enlarging struct > glyph. Instead, I'd try using the function string_buffer_position in > the cursor position computation. Strings aren't displayed frequently, > so the additional function calls shouldn't matter, and anyway, > enlarging glyphs costs performance too, and that in all cases. Oops, I didn't know about string_buffer_position. You are right. By using it, we can confine the change to set_cursor_from_row as attached. The change was not that straight, but I think it is better than the previous one. The reason why the change looks complicated is to correctly handle this kind of case where string_buffer_position is confused by the same string used in display properties. (setq s1 "") (setq s2 "") (setq c1 (propertize "." 'display s1)) (setq c2 (propertize "," 'display s2)) (insert c1 c2 c1 c2 c1 c2) Could you check the change and comment again? --- Ken'ichi HANDA handa@m17n.org *** xdisp.c.~1.729.2.12.~ Thu Nov 7 15:24:40 2002 --- xdisp.c Wed Jan 29 15:54:27 2003 *************** *** 9369,9374 **** --- 9369,9382 ---- { struct glyph *glyph = row->glyphs[TEXT_AREA]; struct glyph *end = glyph + row->used[TEXT_AREA]; + /* The first glyph that starts a sequence of glyphs from string. */ + struct glyph *string_start; + /* The X coordinate of string_start. */ + int string_start_x; + /* The last known character position. */ + int last_pos = MATRIX_ROW_START_CHARPOS (row) + delta; + /* The last known character position before string_start. */ + int string_before_pos; int x = row->x; int pt_old = PT - delta; *************** *** 9384,9396 **** ++glyph; } while (glyph < end && !INTEGERP (glyph->object) && (!BUFFERP (glyph->object) ! || glyph->charpos < pt_old)) { ! x += glyph->pixel_width; ! ++glyph; } w->cursor.hpos = glyph - row->glyphs[TEXT_AREA]; --- 9392,9454 ---- ++glyph; } + string_start = NULL; while (glyph < end && !INTEGERP (glyph->object) && (!BUFFERP (glyph->object) ! || (last_pos = glyph->charpos) < pt_old)) { ! if (! STRINGP (glyph->object)) ! { ! string_start = NULL; ! x += glyph->pixel_width; ! ++glyph; ! } ! else ! { ! string_before_pos = last_pos; ! string_start = glyph; ! string_start_x = x; ! /* Skip all glyphs from string. */ ! do ! { ! x += glyph->pixel_width; ! ++glyph; ! } ! while (glyph < end && STRINGP (glyph->object)); ! } ! } ! ! if (string_start ! && (glyph == end || !BUFFERP (glyph->object) || last_pos > pt_old)) ! { ! /* We may have skipped over point because the previous glyphs ! 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); ! } } w->cursor.hpos = glyph - row->glyphs[TEXT_AREA];