From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Problems with move_it_in_display_line_to X when tabs exist. Date: Mon, 15 Jan 2018 14:06:35 +0200 Message-ID: <83d12bz5pw.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1516017992 31054 195.159.176.226 (15 Jan 2018 12:06:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 12:06:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Keith David Bershatsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 15 13:06:28 2018 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 1eb3X1-0007Zz-3V for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 13:06:27 +0100 Original-Received: from localhost ([::1]:59291 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eb3Yy-0001tN-OD for ged-emacs-devel@m.gmane.org; Mon, 15 Jan 2018 07:08:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eb3XR-0001qM-QJ for emacs-devel@gnu.org; Mon, 15 Jan 2018 07:06:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eb3XM-0003hA-SE for emacs-devel@gnu.org; Mon, 15 Jan 2018 07:06:53 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eb3XM-0003gv-Pv; Mon, 15 Jan 2018 07:06:48 -0500 Original-Received: from [176.228.60.248] (port=3745 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eb3XM-0005A0-Ap; Mon, 15 Jan 2018 07:06:48 -0500 In-reply-to: (message from Keith David Bershatsky on Sun, 14 Jan 2018 21:48:12 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:221970 Archived-At: > Date: Sun, 14 Jan 2018 21:48:12 -0800 > From: Keith David Bershatsky > Cc: emacs-devel@gnu.org > > I am still working on troubleshooting how the value of it->pixel_width is determined. In the current fact pattern, I am using the following settings: > > (setq display-line-numbers t) > (setq buffer-display-table (make-display-table)) > (aset buffer-display-table > ?\t > (vector (make-glyph-code ?\u00BB 'font-lock-warning-face) > (make-glyph-code ?\t 'highlight))) > (setq tab-width 8) > > I am placing a tab at flush-left and some text following the tab, such as: > > Hello-world. > > I am calling interactively (scroll-left 1) to temporarily scroll the text to the left 1 column at a time. > > I believe that x_produce_glyphs sets the it->pixel-width of the stretch tab incorrectly (while scrolling 2 or more columns to the left), which affects the ability to properly move by it.pixel_width when calling move_it_in_display_line_to. As far as I can tell, this problem _only_ happens when displaying native line numbers. As previously, please provide a complete recipe, with text that needs to be inserted into a buffer, and the commands that show why you think the pixel_width is calculated incorrectly. The above Lisp snippet is a good start, but the main part, i.e. the text to insert, the commands to perform, and the values you see produced -- that part is missing. > QUESTION: Is this line of code: > > int next_tab_x = ((1 + x + tab_width - 1) / tab_width) * tab_width; > > the same thing as: > > int next_tab_x = x + tab_width; No, it isn't, see below. > If we add 1 and then subtract 1, we did not do anything meaningful. True. The code does that to make more explicitly clear how the value of 'x + tab_width' was arrived to. Omitting the two 1's could leave the reader wondering where did those one-pixel adjustment disappear. > If we divide something by tab_width and then multiply it by tab_width, then we are back again at where we started. > > EXAMPLE #1: (1 + 11 + 77 - 1) / 77) * 77 = 88 No, this is integer division, so 88/77 yields 1, and the overall result is 77, not 88.