From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nljlistbox2@gmail.com (N. Jackson) Newsgroups: gmane.emacs.bugs Subject: bug#20569: 24.5; Vertical scroll bar is shorter than frame in info buffer Date: Thu, 28 May 2015 16:09:11 -0300 Message-ID: <871ti0ldt4.fsf@moondust.localdomain> References: <87lhgs3s10.fsf@moondust.localdomain> <6763ACD5-57CB-4F90-ABDB-FF9BE7322FC1@swipnet.se> <87d223476s.fsf@moondust.localdomain> <83wq0bi423.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432840230 29206 80.91.229.3 (28 May 2015 19:10:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2015 19:10:30 +0000 (UTC) To: 20569@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 28 21:10:20 2015 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 1Yy3C7-0006At-Ix for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 May 2015 21:10:19 +0200 Original-Received: from localhost ([::1]:60412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy3C6-0002vc-MT for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 May 2015 15:10:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45711) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy3Bx-0002ji-0U for bug-gnu-emacs@gnu.org; Thu, 28 May 2015 15:10:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yy3Bt-00057k-Gi for bug-gnu-emacs@gnu.org; Thu, 28 May 2015 15:10:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy3Bt-00054w-Bl for bug-gnu-emacs@gnu.org; Thu, 28 May 2015 15:10:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Yy3Bs-0004xK-MO for bug-gnu-emacs@gnu.org; Thu, 28 May 2015 15:10:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: nljlistbox2@gmail.com (N. Jackson) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 May 2015 19:10:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20569 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20569-submit@debbugs.gnu.org id=B20569.143284016118993 (code B ref 20569); Thu, 28 May 2015 19:10:04 +0000 Original-Received: (at 20569) by debbugs.gnu.org; 28 May 2015 19:09:21 +0000 Original-Received: from localhost ([127.0.0.1]:59799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yy3BA-0004wG-TO for submit@debbugs.gnu.org; Thu, 28 May 2015 15:09:21 -0400 Original-Received: from mail-qk0-f182.google.com ([209.85.220.182]:35716) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Yy3B9-0004w3-EQ for 20569@debbugs.gnu.org; Thu, 28 May 2015 15:09:20 -0400 Original-Received: by qkhq76 with SMTP id q76so3539485qkh.2 for <20569@debbugs.gnu.org>; Thu, 28 May 2015 12:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=jwrnWzh0vIvBWjoDnNioxDWjfuxiQEIVWny0IUuXltU=; b=Lck4/tbSiWFPYVIfZE91hnx1PMMBxtv8z1hjm0IVubb4IMsVbsSddFVo25j/HUw5Hl ltBS6ZEXjhfTRe3ZqrBk701L5K+SPp1ptPpBZKR8rhuU71reiR9vtbbuRzV7U4L8jqBD 36Q6h4MEPVptf8QfcPfmX1/vH2z185K0m0QFouApNlT6MSFDeeWs620e5oYnSzFKJTEd R6550/jeUDtrgnEahf//eqHYH/OXaYx30B7P9QfRISkA7R+IGEEJ+A7USx498WSqYz57 LmZj043rgpkGNpmjxwDXgSLWPXkXUkjtjGK3UXkKGswzP5bNIG52fA0Ev//0mpYCoJNb 60Cw== X-Received: by 10.229.249.137 with SMTP id mk9mr2415234qcb.21.1432840153976; Thu, 28 May 2015 12:09:13 -0700 (PDT) Original-Received: from moondust.localdomain.nodomain.none (hlfxns0163w-142177117108.pppoe-dynamic.High-Speed.ns.bellaliant.net. [142.177.117.108]) by mx.google.com with ESMTPSA id f15sm1490529qkh.23.2015.05.28.12.09.12 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 May 2015 12:09:13 -0700 (PDT) In-Reply-To: <83wq0bi423.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 14 May 2015 18:15:00 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) 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:103282 Archived-At: At 12:15 -0300 on Thursday 2015-05-14, Eli Zaretskii wrote: > If the scroll bar extended past the header line, users would expect > that line to scroll, which it doesn't. Well, the scroll bar extends past the header line in the other programs I mentioned (Spreadsheets, file managers) but those header lines don't scroll. > Anyway, this is how the header line was designed and implemented in > Emacs. We have tabulated-list-mode for the other kind. The Info > reader uses the header line for a good reason: it shows there stuff > that needs to be always visible, so it cannot be the first line of the > buffer, or behave like one. Fair enough. It is a very minor blemish, and obviously not worth the investment of effort to fix (if "fix" is even the right word). In the game of Mah Jong, one must take the most scrupulous care while building the wall to ensure that all four sides meet exactly and there are no gaps. Otherwise it's terribly bad luck or evil spirits will get in or something. (I forget exactly.) It is in a similar vein of superstition, perhaps laced with a touch of compulsiveness, that it disturbs me seeing a gap in the border of a window/frame! I would like to work around the problem in my personal settings -- I feel that should be possible by simply changing the colour of the header line to match the colour of my windows -- but after some attempts at this I was not completely successful. I customised some faces to use the same background colour as my windowing system widgets (gray94) (with readable foreground colours): (custom-set-faces '(header-line ((t (:inherit mode-line :background "grey94" :foreground "black" :box nil)))) '(info-header-node ((t (:inherit info-node :background "gray94" :foreground "black")))) '(info-header-xref ((t (:inherit info-xref :background "gray94" :foreground "navy"))))) So far so good. Now I don't have a disturbing gap in my window/frame in Info which is great. (Not sure if there'll be a problem with the header line in other modes, but I can tweak those as I notice problems.) Unfortunately, another issue arises. The breadcrumbs at the top of the Info buffer now have the wrong background colour! The breadcrumbs seem to also use Info Header Node face and the Info Header Xref face. It seems inappropriate that they should use Header faces since they are not in the header. Is there a way to prevent them from doing so? Thanks.