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: mode-line size and position indicator Date: Thu, 24 Aug 2017 19:55:41 +0300 Message-ID: <83mv6o9a7m.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1503593785 13557 195.159.176.226 (24 Aug 2017 16:56:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2017 16:56:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nick Helm Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 18:56:16 2017 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 1dkvQK-0002UU-HG for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 18:56:04 +0200 Original-Received: from localhost ([::1]:49532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvQR-0005O7-DJ for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2017 12:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvQH-0005MX-Kk for emacs-devel@gnu.org; Thu, 24 Aug 2017 12:56:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkvQC-0001qy-Q2 for emacs-devel@gnu.org; Thu, 24 Aug 2017 12:56:01 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkvQC-0001qs-M2; Thu, 24 Aug 2017 12:55:56 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4486 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dkvQB-0007MI-Rg; Thu, 24 Aug 2017 12:55:56 -0400 In-reply-to: (message from Nick Helm on Wed, 23 Aug 2017 15:20:27 +1200) 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:217769 Archived-At: > From: Nick Helm > Date: Wed, 23 Aug 2017 15:20:27 +1200 > > I've been trying to improve my C skills lately, so I thought I'd take a > crack at adding a small feature to xdisp.c. > > I've written a simple mode-line indicator to visually show the relative > size and position of the window view on the current buffer. It works by > adding a new %-spec construct to decode_mode_spec. > > The result is akin to a vertical scroll-bar, but it appears as a > horizontal mark on the mode-line. It may be useful to terminal users or > those who prefer to run with traditional scroll-bars turned off. I've > attached a screen-grab of what it looks like on my system. > > The indicator is activated by adding %N~ to mode-line-format, where N is > a positive integer that sets the desired width of the indicator in char. > > I'm under no illusions that this should be included in Emacs, and > admittedly, it is a very simple feature, but I'd appreciate any > comments or suggestions to improve the code. Patch attached. Looks good, although there's a fundamental problem with putting on the mode line an indicator that must use a significant part of the screen estate to be useful: the mode line is pretty crowded these days, even in the default configuration. > + /* Indicate the relative size and position of the current window. */ > + case '~': > + { > + ptrdiff_t toppos = marker_position (w->start); > + ptrdiff_t botpos = BUF_Z (b) - w->window_end_pos; > + ptrdiff_t total = BUF_ZV (b) - BUF_BEGV (b) + 1; > + ptrdiff_t open; > + ptrdiff_t close; > + int i; > + char *p = decode_mode_spec_buf; > + > + /* It makes little sense to pad with spaces, so use WIDTH to > + enable the user to specify the size of the indicator. */ > + > + if (width < 3) width = 3; /* Set a minimum indicator size. */ > + width -= 2; /* Reserve space for open and close marks. */ > + > + if (total >= 1000000) > + /* Do it differently for a large value, to avoid overflow. */ > + { > + open = ((toppos - BUF_BEGV (b)) + (total / width) - 1) / (total / width); > + close = ((botpos - BUF_BEGV (b) + 1) + (total / width) - 1) / (total / width); > + } > + else > + { > + open = ((toppos - BUF_BEGV (b)) * width + total - 1) / total; > + close = ((botpos - BUF_BEGV (b) + 1) * width + total - 1) / total; > + } I wonder whether it would have made sense to reuse the code we have for computing the scroll-bar thumb. Also, why two different code fragments? why not use the former for both small and large values of 'total'?