From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org
Subject: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".
Date: Mon, 15 May 2017 20:44:17 +0000 [thread overview]
Message-ID: <20170515204416.GA7349@acm.fritz.box> (raw)
Hello, Emacs.
I've always been annoyed by the percentage output by the mode-line
construct "%p" - so much so that I patched my personal copy of
`decode-mode-spec' in xdisp.c over ten years ago (thanks for the tip
then, Eli!).
What I don't like about it is that is indicates the wrong thing, i.e.
the relative position of the top of the window in the buffer. What I
want is the degree of travel of the window through the buffer, for which
I propose "%o".
To illustrate the difference, in the following diagrams, the letters a,
W, and b will make up the entire (visible portion of) a buffer, with a
being the part above the window, W being the window itself, and b the
part below the window.
So, if we have a buffer which is twice as big as the portion which fits
into the window, and the window is in the middle of the buffer, we have:
aaaaaaaaaaaaaaaaWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWbbbbbbbbbbbbbbbb
. In this configuration, "%p" reports 25%. The new "%o" would be 50%
As the window approaches the end of the buffer:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWb
, "%p" reports 49%. I find this disconcerting, since that 49% suggests
to me we should be near the middle of the buffer, although we're almost
at its end. "%o" here would report 98%.
Numerically, "%p" is 100 * a / (a + W + b).
"%o" is 100 * a / (a + b).
Here is (the code part of) a patch which implements this "%o":
diff --git a/src/xdisp.c b/src/xdisp.c
index cdea20993c..f1236e1583 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -23870,6 +23870,26 @@ decode_mode_spec (struct window *w, register int c, int field_width,
return " Narrow";
break;
+ /* Display the "degree of travel" of the window through the buffer. */
+ case 'o':
+ {
+ ptrdiff_t toppos = marker_position (w->start);
+ ptrdiff_t botpos = BUF_Z (b) - w->window_end_pos;
+ ptrdiff_t begv = BUF_BEGV (b);
+ ptrdiff_t zv = BUF_ZV (b);
+
+ if (zv <= botpos)
+ return toppos <= begv ? "All" : "Bottom";
+ else if (toppos <= begv)
+ return "Top";
+ else
+ {
+ sprintf (decode_mode_spec_buf, "%2d%%",
+ percent99 (toppos - begv, (toppos - begv) + (zv - botpos)));
+ return decode_mode_spec_buf;
+ }
+ }
+
case 'p':
{
ptrdiff_t pos = marker_position (w->start);
What do people say?
--
Alan Mackenzie (Nuremberg, Germany).
next reply other threads:[~2017-05-15 20:44 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 20:44 Alan Mackenzie [this message]
2017-05-15 23:27 ` Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer" Paul Eggert
2017-05-15 23:29 ` Drew Adams
2017-05-15 23:54 ` Kaushal Modi
2017-05-16 0:38 ` Noam Postavsky
2017-05-16 1:15 ` Clément Pit-Claudel
2017-05-16 2:47 ` Eli Zaretskii
2017-05-18 1:15 ` Perry E. Metzger
2017-05-18 4:28 ` Eli Zaretskii
2017-05-18 16:01 ` Perry E. Metzger
2017-05-18 16:18 ` Eli Zaretskii
2017-05-18 16:45 ` Perry E. Metzger
2017-05-18 19:43 ` Eli Zaretskii
2017-05-18 20:13 ` Perry E. Metzger
2017-05-18 20:25 ` Eli Zaretskii
2017-05-18 20:51 ` Perry E. Metzger
2017-05-19 6:17 ` Eli Zaretskii
2017-05-22 2:22 ` Kaushal Modi
2017-05-22 4:13 ` Eli Zaretskii
2017-05-22 13:38 ` Kaushal Modi
2017-05-22 18:20 ` Alan Mackenzie
2017-05-22 18:55 ` Kaushal Modi
2017-05-16 3:00 ` Eli Zaretskii
2017-05-16 3:35 ` Noam Postavsky
2017-05-16 20:37 ` Alan Mackenzie
2017-05-17 2:30 ` Eli Zaretskii
2017-05-17 21:32 ` Alan Mackenzie
2017-05-18 19:16 ` Dani Moncayo
2017-05-18 21:22 ` Alan Mackenzie
2017-05-19 5:32 ` Yuri Khan
2017-05-16 7:22 ` Andreas Schwab
2017-05-16 10:05 ` Dani Moncayo
2017-05-16 13:31 ` Drew Adams
2017-05-16 18:59 ` Toon Claes
2017-05-16 20:56 ` John Yates
2017-05-20 10:34 ` Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch] Alan Mackenzie
2017-05-21 15:55 ` Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..) Kaushal Modi
2017-05-21 16:04 ` Noam Postavsky
2017-05-22 1:19 ` Kaushal Modi
2017-05-22 2:35 ` Noam Postavsky
2017-05-21 16:08 ` Difficulty applying multi-file patches from within emacs Alan Mackenzie
2017-05-21 17:20 ` Philipp Stephani
2017-05-21 17:39 ` Alan Mackenzie
2017-05-22 1:21 ` Kaushal Modi
2017-05-22 1:23 ` Kaushal Modi
2017-05-23 11:21 ` Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..) Tino Calancha
2017-05-23 8:00 ` Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch] Dani Moncayo
2017-05-23 20:24 ` Alan Mackenzie
2017-05-24 10:45 ` Dani Moncayo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170515204416.GA7349@acm.fritz.box \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).