From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#19395: 25.0.50; Setting left fringe to 0 messes up window-width Date: Sat, 20 Dec 2014 19:58:05 +0100 Message-ID: <5495C6BD.1080803@gmx.at> References: <87vblbnz2u.fsf@posteo.de> <83k31rwe55.fsf@gnu.org> <87lhm772o2.fsf@posteo.de> <83h9wvwbux.fsf@gnu.org> <87bnn39cpe.fsf@posteo.de> <83a92mwau9.fsf@gnu.org> <874msu9out.fsf@posteo.de> <83vblauoh6.fsf@gnu.org> <87wq5q864m.fsf@posteo.de> <83tx0uum88.fsf@gnu.org> <87a92lmxy3.fsf@posteo.de> <837fxpue6v.fsf@gnu.org> <54945BCB.8030506@gmx.at> <83tx0rsa9e.fsf@gnu.org> <54954ACE.7050204@gmx.at> <83bnmysi2n.fsf@gnu.org> <549560B9.5070308@gmx.at> <838ui2sd54.fsf@gnu.org> <54958CE0.9060105@gmx.at> <831tnus2gv.fsf@gnu.org> <5495B700.8080403@gmx.at> <83sigaqj8u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1419101970 25588 80.91.229.3 (20 Dec 2014 18:59:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 20 Dec 2014 18:59:30 +0000 (UTC) Cc: 19395@debbugs.gnu.org, malsburg@posteo.de To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 20 19:59:23 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 1Y2PFK-0006rr-FY for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Dec 2014 19:59:22 +0100 Original-Received: from localhost ([::1]:35512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2PFJ-0005El-Vn for geb-bug-gnu-emacs@m.gmane.org; Sat, 20 Dec 2014 13:59:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41756) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2PFA-0005BE-0z for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 13:59:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y2PF1-0002Iu-AM for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 13:59:11 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y2PF1-0002IW-7Y for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 13:59:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Y2PF0-0006lb-D3 for bug-gnu-emacs@gnu.org; Sat, 20 Dec 2014 13:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Dec 2014 18:59: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.141910190025869 (code B ref 19395); Sat, 20 Dec 2014 18:59:02 +0000 Original-Received: (at 19395) by debbugs.gnu.org; 20 Dec 2014 18:58:20 +0000 Original-Received: from localhost ([127.0.0.1]:53300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y2PEK-0006jA-9b for submit@debbugs.gnu.org; Sat, 20 Dec 2014 13:58:20 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:51993) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Y2PEI-0006it-BE for 19395@debbugs.gnu.org; Sat, 20 Dec 2014 13:58:19 -0500 Original-Received: from [188.23.121.89] ([188.23.121.89]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M9vnQ-1YDRrL0LzE-00B6B6; Sat, 20 Dec 2014 19:58:15 +0100 In-Reply-To: <83sigaqj8u.fsf@gnu.org> X-Provags-ID: V03:K0:hIVaqIRbbaH2bdflaSHHwYASVduU4loG8TI8T62Fn5X44ivkd0x 8mQE+cXCrzRJsRdHdxv+0vPjRwhvSTh/YEOfKpwjfRowKazXtB68fXCmO0PMc6vU+wrqfVk wZKSZRQSqmdJAvc5HsxxtOCOahGfk80HvVmefcYBQi+lKlIZT1fousLYQlQGz2bsXTfPKUF 6STuTpKHCa4w9mh5w9opQ== X-UI-Out-Filterresults: notjunk:1; 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:97630 Archived-At: >> If I want to right-adjust the last word of a buffer line I apparently >> have to provide the buffer _and_ the frame in order to know how many >> spaces to insert. > > Yes, and with-current-buffer achieves that, right? Only if the current buffer appears on the selected frame. My original definition was (defun window-char-width (&optional window) "Return default character width for WINDOW. WINDOW must be a live window and defaults to the selected one." (setq window (window-normalize-window window t)) (with-current-buffer (window-buffer window) (let* ((info (font-info (face-font 'default))) (width (aref info 11))) (if (> width 0) width (aref info 10))))) and you can trust me that I would have written it as (defun window-char-width (&optional window) "Return default character width for WINDOW. WINDOW must be a live window and defaults to the selected one." (setq window (window-normalize-window window t)) (with-selected-window window (let* ((info (font-info (face-font 'default))) (width (aref info 11))) (if (> width 0) width (aref info 10))))) if I had known that >> > It replaces the original frame-specific face. is not true. >> IIUC this contradicts an earlier observation by Titus that >> >> if the buffer in the specified window is displayed in two frames, >> the returned character width was always the one used in the current >> frame which is not necessarily the character width in the specified >> window (the window may be in the other frame). This is a problem >> because character width can be different, if the two frames use >> different default fonts. > > I don't see any contradictions. I said nothing about windows, only > about frames and buffers. His last sentence says that the outcome is dependent on the frame. So it does not "replace" the original frame-specific face but "merge" the frame and buffer specific faces. But maybe we are just miscommunicating again. martin