From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Titus von der Malsburg Newsgroups: gmane.emacs.bugs Subject: bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width Date: Tue, 16 Dec 2014 19:28:45 -0800 Message-ID: <87bnn39cpe.fsf@posteo.de> References: <87vblbnz2u.fsf@posteo.de> <83k31rwe55.fsf@gnu.org> <87lhm772o2.fsf@posteo.de> <83h9wvwbux.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418787046 31577 80.91.229.3 (17 Dec 2014 03:30:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2014 03:30:46 +0000 (UTC) Cc: 19395@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 17 04:30:39 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 1Y15Jg-00043D-KU for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Dec 2014 04:30:24 +0100 Original-Received: from localhost ([::1]:47736 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y15Jg-0006Rs-7C for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Dec 2014 22:30:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y15JR-0006DZ-KL for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 22:30:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y15JL-0000S5-Gd for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 22:30:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y15JL-0000RM-EL for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 22:30:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y15JK-00021W-PL for bug-gnu-emacs@gnu.org; Tue, 16 Dec 2014 22:30:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Titus von der Malsburg Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Dec 2014 03:30:02 +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.14187869497686 (code B ref 19395); Wed, 17 Dec 2014 03:30:02 +0000 Original-Received: (at 19395) by debbugs.gnu.org; 17 Dec 2014 03:29:09 +0000 Original-Received: from localhost ([127.0.0.1]:48299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y15IS-0001zt-Co for submit@debbugs.gnu.org; Tue, 16 Dec 2014 22:29:08 -0500 Original-Received: from mx02.posteo.de ([89.146.194.165]:47046) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y15IC-0001zD-6K for 19395@debbugs.gnu.org; Tue, 16 Dec 2014 22:29:06 -0500 Original-Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id E0F1625A2100; Wed, 17 Dec 2014 04:28:50 +0100 (CET) Original-Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3k2MJ20NKSz5vN3; Wed, 17 Dec 2014 04:28:49 +0100 (CET) In-reply-to: <83h9wvwbux.fsf@gnu.org> 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:97428 Archived-At: On 2014-12-16 Tue 12:58, Eli Zaretskii wrote: >> 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". I see, thanks for explaining. Perhaps it would make sense to amend the documentation of `window-width' because this is easy to misunderstand and I suspect that I'm not the only one who consults window-width in order to determine how much columns are available for text display. In term.el, I found a function that does what I want (`term-window-width') but requiring term.el only to use this function seems inappropriate. Duplicating this function is not perfect either. Titus >> 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.