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#19395: 25.0.50; Setting left fringe to 0 messes up window-width Date: Tue, 16 Dec 2014 22:58:30 +0200 Message-ID: <83h9wvwbux.fsf@gnu.org> References: <87vblbnz2u.fsf@posteo.de> <83k31rwe55.fsf@gnu.org> <87lhm772o2.fsf@posteo.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418763565 11452 80.91.229.3 (16 Dec 2014 20:59:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Dec 2014 20:59:25 +0000 (UTC) Cc: 19395@debbugs.gnu.org To: Titus von der Malsburg Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 16 21:59:18 2014 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 1Y0zDB-0008Bb-4A for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Dec 2014 21:59:17 +0100 Original-Received: from localhost ([::1]:46833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zDA-0002iJ-QJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Dec 2014 15:59:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zD1-0002az-Ez for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 15:59:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0zCw-00050V-7N for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 15:59:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0zCw-00050E-3h for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 15:59:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y0zCv-0007lY-KC for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 15:59:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Dec 2014 20:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19395 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19395-submit@debbugs.gnu.org id=B19395.141876352529828 (code B ref 19395); Tue, 16 Dec 2014 20:59:01 +0000 Original-Received: (at 19395) by debbugs.gnu.org; 16 Dec 2014 20:58:45 +0000 Original-Received: from localhost ([127.0.0.1]:48194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y0zCe-0007l2-Vb for submit@debbugs.gnu.org; Tue, 16 Dec 2014 15:58:45 -0500 Original-Received: from mtaout26.012.net.il ([80.179.55.182]:58062) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y0zCb-0007kr-LR for 19395@debbugs.gnu.org; Tue, 16 Dec 2014 15:58:43 -0500 Original-Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NGP00B00064PP00@mtaout26.012.net.il> for 19395@debbugs.gnu.org; Tue, 16 Dec 2014 22:57:47 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGP00B3O0WBCT30@mtaout26.012.net.il>; Tue, 16 Dec 2014 22:57:47 +0200 (IST) In-reply-to: <87lhm772o2.fsf@posteo.de> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:97410 Archived-At: > From: Titus von der Malsburg > Cc: 19395@debbugs.gnu.org > Date: Tue, 16 Dec 2014 12:36:13 -0800 > > > The n+1st character is usurped for the continuation glyph. This is > > not a bug. > > Sorry, but I don't understand that. If (window-width) says there is > space for 50 characters and I put 50 characters on a line, there > shouldn't be a continuation character in the first place. window-width doesn't report the number of characters a window's line can hold without continuation. It reports the window width in character units. When there's no fringe to display the continuation bitmap, that width includes the space reserved for the continuation glyph, which is the backslash character produced by the display engine on the last column of the line. > Also, I don't see why I should get different behaviour for different > values of left-fringe. When left-fringe is > 0, I get as many > characters on a line as (window-width) reports. But if left-fringe > is 0, I get one character less on the line. As long as the left fringe exists, we can display on it. But once its width is zero, it no longer exists, and so we need to reserve space to display the continuation glyph "by other means". > This behaviour doesn't seem to be consistent with the documentation > of window-width. Quote: > > The return value does not include any vertical dividers, fringes or > marginal areas, or scroll bars. This doesn't say anything about continuation and truncation glyphs, so I see no inconsistency here, perhaps just missing details. > My understanding of this is that the fringes should not matter at > all. If window-with reports n, I should be able to fit n characters on > a line irrespective of what the fringes are. I tried to explain above why this interpretation is incorrect: window-width does not return the number of characters of buffer text that can be displayed on a line. > Moreover, why is this specific to the left-fringe? The value of > right-fringe does not affect influence whether I can get > (window-width) or (window-width) -1 characters on a line. That's not what I see here. Setting any of the fringes' width to zero causes window-width to report 1 more character than you can put on a line without going to a continuation line. IOW, the "penalty" is symmetrical, at least on my machine.