From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.devel Subject: Re: Problems with move_it_in_display_line_to X when tabs exist. Date: Sat, 02 Dec 2017 11:52:33 -0800 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1512244383 31462 195.159.176.226 (2 Dec 2017 19:53:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 19:53:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 02 20:52:58 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLDqI-0007fy-Du for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 20:52:55 +0100 Original-Received: from localhost ([::1]:36772 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLDqP-00088g-Dy for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 14:53:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34971) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLDqI-00088a-Cj for emacs-devel@gnu.org; Sat, 02 Dec 2017 14:52:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLDqF-0002Nj-66 for emacs-devel@gnu.org; Sat, 02 Dec 2017 14:52:54 -0500 Original-Received: from gateway20.websitewelcome.com ([192.185.62.46]:14229) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eLDqE-0002Gp-SO for emacs-devel@gnu.org; Sat, 02 Dec 2017 14:52:51 -0500 Original-Received: from cm10.websitewelcome.com (cm10.websitewelcome.com [100.42.49.4]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 11FCC400C46FC for ; Sat, 2 Dec 2017 13:52:35 -0600 (CST) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cmsmtp with SMTP id LDpyeqs5UmFImLDpyeZyBy; Sat, 02 Dec 2017 13:52:35 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:Cc :To:From:Message-ID:Date:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gcyS+r5WJLYl+2JOImwBCcDVCcRsadMy6ZDeIjdX4Ok=; b=m5dvwHjvaRlQnGIqxD/L5OLi1B 1Hx0nv++VeMa8sZPmyz/HsRZQW+ZBV4UGxfOsohJ3jD2HFxlcyQeKpM6ZTxTN2Ps1W3xlGX5UiRGf SzAx8Oh8r4UNIS+XMB7M7a4ZcmGhm4Be4ougcWpxQJsFkm5ZmqC+A4ZqUjsMA7qNG5WfCmjnBMHlb GcmoRYVw8p9CXvMy3wEeFTkQShYfWdUTd5B7TbaeR/kaodKEk36QTxjvlzqAeny5Ilf1lYKhoVhpo 4PNJRD+XOfyWHXyQLQ3FkowKHb60whDEO8graICipRZ8+aonkvq9PcLfq4LMhqB/xN+IMj901teas rpLpuVfw==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:50785 helo=server.private) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eLDpy-003qrE-4v; Sat, 02 Dec 2017 13:52:34 -0600 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Source-L: No X-Exim-ID: 1eLDpy-003qrE-4v X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.private) [45.48.239.195]:50785 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-Local-Domain: yes X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 192.185.62.46 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:220626 Archived-At: The test assumes: * The variable word-wrap is non-nil. * The variable tab-width is 2. * The buffer-display table entry for a tab is: [(187 . 120) (9 . 121)]. * Native line numbers are _not_ enabled. I have a long line that wraps at the window edge and I put a space to sim= ulate a new word that should be wrapped to the following line. To make i= t easier to read, I am using the backslash symbol (below) to signify a wo= rd-wrap with a space at the window edge. The next line has three "x" fol= lowed by a tab and then the word "hello-world". The STRETCH glyph is 22 = pixels wide; however, it.pixel_width is erroneously (?) reporting that it= is 11 pixels wide. I have hard-coded an emacs_abort () when it.c =3D=3D '\t', which means th= at we have just moved passed character 187 (aka "=C2=BB") and we are now = on a STRETCH tab-width. Here is a link to a screen-shot of this particular issue: https://www.lawlist.com/images/pgrowx_a.png What would be the next step(s), please, to continue working on debugging = this particular issue? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \ xxx hello-world (gdb) pgrowx glyph_row [New Thread 0x1c0b of process 16745] TEXT: 18 glyphs 0 0: CHAR[x] pos=3D1197 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 1 11: CHAR[x] pos=3D1198 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 2 22: CHAR[x] pos=3D1199 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 3 33: CHAR[0xbb] pos=3D1200 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 f= ace=3D31 MB 4 44: STRETCH[20+16] pos=3D1200 w=3D22 a+d=3D16+4 face=3D30 MB 5 66: CHAR[h] pos=3D1201 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 6 77: CHAR[e] pos=3D1202 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 7 88: CHAR[l] pos=3D1203 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 8 99: CHAR[l] pos=3D1204 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 9 110: CHAR[o] pos=3D1205 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 10 121: CHAR[-] pos=3D1206 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 11 132: CHAR[w] pos=3D1207 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 12 143: CHAR[o] pos=3D1208 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 13 154: CHAR[r] pos=3D1209 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 14 165: CHAR[l] pos=3D1210 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 15 176: CHAR[d] pos=3D1211 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB 16 187: CHAR[0xb6] pos=3D1212 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 f= ace=3D26 MB 17 198: CHAR[ ] pos=3D0 blev=3D0,btyp=3DUNDEF w=3D11 a+d=3D16+4 MB (gdb) print it.c $1 =3D 9 (gdb) print it.pixel_width $2 =3D 11 Thanks, Keith ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; DATE: [11-29-2017 10:04:14] <29 Nov 2017 20:04:14 +0200> FROM: Eli Zaretskii >=20 > > Date: Tue, 28 Nov 2017 22:12:35 -0800 > > From: Keith David Bershatsky > >=20 > > I can see that X and/or HPOS are wrong when tabs are present on the c= urrent line because I get superimposed letters and double of the same wor= d slightly off to the left and/or the right of where the word should be. > >=20 > > HYPOTHESIS: I would venture to say that what is displayed on screen = does _not_ coincide with what IT reports when running move_it_in_display_= line_to. >=20 > Does this happen only when line numbers are displayed? >=20 > In any case, your description provides a lot of details that are hard > to reason about, because most of the code is not shown. OTOH, if > indeed there's a bug in move_it_in_display_line_to, then presenting > evidence for it is very simple: show a line of text and its line > number, and then show the X and HPOS values for each tab in that line > as calculated by move_it_in_display_line_to vs the same values in a > displayed line. (For the latter, you can use the pgrowx command > defined in src/.gdbinit, or manually display the values using the > debugger.) >=20 > If you do that, any mismatches between displaying a line and moving > through it with move_it_in_display_line_to will be immediately > apparent, and it should be easy to fix them.