Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Alan Mackenzie]

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).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Paul Eggert]

Thanks, I like this idea.

RE: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Drew Adams]

> Thanks, I like this idea.

+1.  I might not use it, but it sounds useful.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

On Mon, May 15, 2017, 4:45 PM Alan Mackenzie <acm@muc.de> wrote:

>
> What do people say?
>

This is awesome! I like it.

Thanks.

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 645 bytes --]

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Noam Postavsky]

On Mon, May 15, 2017 at 4:44 PM, Alan Mackenzie <acm@muc.de> wrote:
>
> Numerically, "%p" is 100 * a / (a + W + b).
>
> "%o" is 100 * a / (a + b).

Yeah, that makes much more sense, a percentage should range from %0 to
%100, and %p's formula doesn't. I think I've dealt with this mostly by
ignoring the number and looking at the scrollbar instead. With this
patch, I might actually be able to rely on the number.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Clément Pit-Claudel]

On 2017-05-15 20:38, Noam Postavsky wrote:
> On Mon, May 15, 2017 at 4:44 PM, Alan Mackenzie <acm@muc.de> wrote:
>>
>> Numerically, "%p" is 100 * a / (a + W + b).
>>
>> "%o" is 100 * a / (a + b).
> 
> Yeah, that makes much more sense, a percentage should range from %0 to
> %100, and %p's formula doesn't. I think I've dealt with this mostly by
> ignoring the number and looking at the scrollbar instead. With this
> patch, I might actually be able to rely on the number.

I agree. But in that case, wouldn't it be better to change the default, too?
That is, either change %p's meaning (possibly offering the old meaning as %o), or change the default mode line format to use %p.

Clément.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Mon, 15 May 2017 21:15:46 -0400
> 
> On 2017-05-15 20:38, Noam Postavsky wrote:
> > On Mon, May 15, 2017 at 4:44 PM, Alan Mackenzie <acm@muc.de> wrote:
> >>
> >> Numerically, "%p" is 100 * a / (a + W + b).
> >>
> >> "%o" is 100 * a / (a + b).
> > 
> > Yeah, that makes much more sense, a percentage should range from %0 to
> > %100, and %p's formula doesn't. I think I've dealt with this mostly by
> > ignoring the number and looking at the scrollbar instead. With this
> > patch, I might actually be able to rely on the number.
> 
> I agree. But in that case, wouldn't it be better to change the default, too?

Not right away, no.  We should provide a defcustom that would use the
new method, and make it off by default.  Then we should consider
making that the default in some future version.

Just because a few people here like the idea (most probably without
even using it, with the exception of Alan), it doesn't mean the
traditional method can go out the window.  We should be more cautious
about such decisions.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Perry E. Metzger]

On Mon, 15 May 2017 20:38:38 -0400 Noam Postavsky
<npostavs@users.sourceforge.net> wrote:
> On Mon, May 15, 2017 at 4:44 PM, Alan Mackenzie <acm@muc.de> wrote:
> >
> > Numerically, "%p" is 100 * a / (a + W + b).
> >
> > "%o" is 100 * a / (a + b).  
> 
> Yeah, that makes much more sense, a percentage should range from %0
> to %100, and %p's formula doesn't. I think I've dealt with this
> mostly by ignoring the number and looking at the scrollbar instead.
> With this patch, I might actually be able to rely on the number.
> 

I'd like to make two suggestions:

1) I don't see a good reason this shouldn't just be what %p does
(that is, instead of adding %o, perhaps %p should be altered, since
this is more sensible.)

2) If %p is not changed, a knob should be made available to allow
users to invoke the %o in place of %p without having to edit the
modeline specification themselves, which is currently quite messy.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Wed, 17 May 2017 21:15:52 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: Alan Mackenzie <acm@muc.de>, Emacs developers <emacs-devel@gnu.org>
> 
> 1) I don't see a good reason this shouldn't just be what %p does
> (that is, instead of adding %o, perhaps %p should be altered, since
> this is more sensible.)
> 
> 2) If %p is not changed, a knob should be made available to allow
> users to invoke the %o in place of %p without having to edit the
> modeline specification themselves, which is currently quite messy.

I think this was already said a few messages up-thread: we cannot
simply do 1), so we should do 2).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Perry E. Metzger]

On Thu, 18 May 2017 07:28:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Wed, 17 May 2017 21:15:52 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: Alan Mackenzie <acm@muc.de>, Emacs developers
> > <emacs-devel@gnu.org>
> > 
> > 1) I don't see a good reason this shouldn't just be what %p does
> > (that is, instead of adding %o, perhaps %p should be altered,
> > since this is more sensible.)
> > 
> > 2) If %p is not changed, a knob should be made available to allow
> > users to invoke the %o in place of %p without having to edit the
> > modeline specification themselves, which is currently quite
> > messy.  
> 
> I think this was already said a few messages up-thread: we cannot
> simply do 1), so we should do 2).
> 

It occurs to me that there's another possibility, which is to
allow the user to bind a function to do the position calculation so
that everyone can get whatever flavor of calculation they want.

-- 
Perry E. Metzger		perry@piermont.com

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Thu, 18 May 2017 12:01:16 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, npostavs@users.sourceforge.net
> 
> It occurs to me that there's another possibility, which is to
> allow the user to bind a function to do the position calculation so
> that everyone can get whatever flavor of calculation they want.

The mode-line format already supports :eval, so this should already be
possible?

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Perry E. Metzger]

On Thu, 18 May 2017 19:18:12 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 18 May 2017 12:01:16 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: acm@muc.de, emacs-devel@gnu.org,
> > npostavs@users.sourceforge.net
> > 
> > It occurs to me that there's another possibility, which is to
> > allow the user to bind a function to do the position calculation
> > so that everyone can get whatever flavor of calculation they
> > want.  
> 
> The mode-line format already supports :eval, so this should already
> be possible?

I meant just having a knob that could be set to a function that would
run and produce the value for %p rather than changing mode-line-format
with :eval. Though maybe this would be too slow?

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Thu, 18 May 2017 12:45:41 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, npostavs@users.sourceforge.net
> 
> > The mode-line format already supports :eval, so this should already
> > be possible?
> 
> I meant just having a knob that could be set to a function that would
> run and produce the value for %p rather than changing mode-line-format
> with :eval. Though maybe this would be too slow?

I don't mind, I just don't see a lot of difference between having a
knob and using :eval directly, for someone who can write a Lisp
function that would work in this context.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Perry E. Metzger]

On Thu, 18 May 2017 22:43:08 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 18 May 2017 12:45:41 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: acm@muc.de, emacs-devel@gnu.org,
> > npostavs@users.sourceforge.net 
> > > The mode-line format already supports :eval, so this should
> > > already be possible?  
> > 
> > I meant just having a knob that could be set to a function that
> > would run and produce the value for %p rather than changing
> > mode-line-format with :eval. Though maybe this would be too
> > slow?  
> 
> I don't mind, I just don't see a lot of difference between having a
> knob and using :eval directly, for someone who can write a Lisp
> function that would work in this context.

Perhaps I don't understand the difference. I thought that
mode-line-format required that I specify the entire mode line from
scratch, while I'm just proposing that if a particular function is
bound that %p would override its method of calculating this one
value. Am I mistaken on the former matter?

-- 
Perry E. Metzger		perry@piermont.com

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Thu, 18 May 2017 16:13:04 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, npostavs@users.sourceforge.net
> 
> Perhaps I don't understand the difference. I thought that
> mode-line-format required that I specify the entire mode line from
> scratch, while I'm just proposing that if a particular function is
> bound that %p would override its method of calculating this one
> value. Am I mistaken on the former matter?

Yes, I think you are mistaken.  See bindings.el, the mode line already
has quite a few variables that together create the display.  This
feature will add another variable, or reuse an existing one.  That
variable can be computed using :eval.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Perry E. Metzger]

On Thu, 18 May 2017 23:25:58 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 18 May 2017 16:13:04 -0400
> > From: "Perry E. Metzger" <perry@piermont.com>
> > Cc: acm@muc.de, emacs-devel@gnu.org,
> > npostavs@users.sourceforge.net
> > 
> > Perhaps I don't understand the difference. I thought that
> > mode-line-format required that I specify the entire mode line from
> > scratch, while I'm just proposing that if a particular function is
> > bound that %p would override its method of calculating this one
> > value. Am I mistaken on the former matter?  
> 
> Yes, I think you are mistaken.  See bindings.el, the mode line
> already has quite a few variables that together create the
> display.  This feature will add another variable, or reuse an
> existing one.  That variable can be computed using :eval.
> 

Ah, so you're suggesting that what one could do would be to put
the :eval into one of those variables rather than into
mode-line-format itself.

Perry
-- 
Perry E. Metzger		perry@piermont.com

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Thu, 18 May 2017 16:51:24 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
> Cc: acm@muc.de, emacs-devel@gnu.org, npostavs@users.sourceforge.net
> 
> Ah, so you're suggesting that what one could do would be to put
> the :eval into one of those variables rather than into
> mode-line-format itself.

Yes, that's right.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1668 bytes --]

Hi Alan,

I like this feature. Thanks for implementing it. I like both %o and %q..
not sure which one to pick yet.

I only have comments regarding the variable docstrings.

(1) I suggest adding more detail to the docstring of the new variable along
these lines:

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 0e6ffc275e..2a079000bf 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -366,10 +366,20 @@ column-number-indicator-zero-based
   :version "26.1")

 (defcustom mode-line-percent-position '(-3 "%p")
-  "Specification of \"percentage offset\" of window through buffer
-This option specifies both the field width and the type of offset
-displayed in `mode-line-position', a component of the default
-`mode-line-format'."
+  "Specification of \"percentage offset\" of window through buffer.
+
+This option is a list where the first element specifies the field
+width to space-fill or truncate to, and the second element specifies
+the type of buffer offset to display in `mode-line-position'.
+
+The field width is specified as an integer.  If the integer is
+negative (-N), the width is truncated to N characters, and if it is
+positive (N), padding is added if needed to make the field N
+characters wide.
+
+The buffer offset component can be one of \"%o\", \"%p\", \"%P\" or
+\"%q\". See `mode-line-format' for more information on these %
+constructs."
   :type `(radio
           (const :tag "nil:  No offset is displayed" nil)
           (const :tag "\"%o\": Proportion of \"travel\" of the window
through the buffer"
-- 

(2) The docstring of mode-line-format also needs to be update to explain
the new options %o and %q.

-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2394 bytes --]

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 22 May 2017 02:22:49 +0000
> Cc: emacs-devel@gnu.org
> 
> +This option is a list where the first element specifies the field
> +width to space-fill or truncate to, and the second element specifies
> +the type of buffer offset to display in `mode-line-position'.

Our style for documenting Lisp data structures is less abstract:

  This option's value is a list of the form (WIDTH TYPE),
  where WIDTH specifies ...

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 348 bytes --]

On Mon, May 22, 2017 at 12:14 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Our style for documenting Lisp data structures is less abstract:
>
>   This option's value is a list of the form (WIDTH TYPE),
>   where WIDTH specifies ...
>

Attached patch has docstring updates for both mode-line-percentage-position
and mode-line-format.
-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 706 bytes --]

[-- Attachment #2: 0001-Add-detail-to-mode-line-percentage-position-and-mode.patch --]
[-- Type: application/octet-stream, Size: 2762 bytes --]

From 3c5dd77ad2c59c64e96456c2629c446f3a8c4107 Mon Sep 17 00:00:00 2001
From: Kaushal Modi <kaushal.modi@gmail.com>
Date: Sun, 21 May 2017 22:16:57 -0400
Subject: [PATCH] Add detail to mode-line-percentage-position and
 mode-line-format doc

* lisp/bindings.el (mode-line-percent-position): Mention that this
  variable requires a 2-element list.  Also add detail about what
  those elements should be.

* src/buffer.c (syms_of_buffer): Add description for the new %o and %q
  constructs in `mode-line-format'.
---
 lisp/bindings.el | 17 +++++++++++++----
 src/buffer.c     |  5 +++++
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 0e6ffc275e..895faa8a7e 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -366,10 +366,19 @@ column-number-indicator-zero-based
   :version "26.1")

 (defcustom mode-line-percent-position '(-3 "%p")
-  "Specification of \"percentage offset\" of window through buffer
-This option specifies both the field width and the type of offset
-displayed in `mode-line-position', a component of the default
-`mode-line-format'."
+  "Specification of \"percentage offset\" of window through buffer.
+
+This option's value is a list of the form (WIDTH TYPE) where
+WIDTH specifies the field width to space-fill or truncate to,
+and TYPE specifies the type of buffer offset to display in
+`mode-line-position'.
+
+WIDTH is specified as an integer.  If the integer is negative (-N),
+the width is truncated to N characters, and if it is positive (N),
+padding is added, if needed, to make the field N characters wide.
+
+TYPE can be one of \"%o\", \"%p\", \"%P\" or \"%q\".  See
+`mode-line-format' for more information on these % constructs."
   :type `(radio
           (const :tag "nil:  No offset is displayed" nil)
           (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"
diff --git a/src/buffer.c b/src/buffer.c
index 80dbd3318d..9fd39c5fb4 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -5496,6 +5496,11 @@ A string is printed verbatim in the mode line except for %-constructs:
   %p -- print percent of buffer above top of window, or Top, Bot or All.
   %P -- print percent of buffer above bottom of window, perhaps plus Top,
         or print Bottom or All.
+  %q -- print percentages of buffer above both the top and the bottom
+        of the window, separated by -, or All.
+  %o -- print percent of buffer above top of window vs the total buffer
+        content excluding the text visible in the window, or Top, Bot
+        or All.
   %n -- print Narrow if appropriate.
   %t -- visited file is text or binary (if OS supports this distinction).
   %z -- print mnemonics of keyboard, terminal, and buffer coding systems.
--
2.13.0

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Alan Mackenzie]

Hello, Kaushal.

Thanks for taking on the task of finishing up the documentation of this
new facility.

On Mon, May 22, 2017 at 13:38:51 +0000, Kaushal Modi wrote:
> On Mon, May 22, 2017 at 12:14 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Our style for documenting Lisp data structures is less abstract:

> >   This option's value is a list of the form (WIDTH TYPE),
> >   where WIDTH specifies ...


> Attached patch has docstring updates for both mode-line-percentage-position
> and mode-line-format.

I'm not completely happy with these changes, because I think they're a
bit misleading.  Primarily, mode-line-percent-position _DOESN'T_ require
a 2-element list - just that that's what's most likely to be used.  It
could also be nil, or (I think) a bare "%o", etc., or any other valid
mode line format fragment.

> From 3c5dd77ad2c59c64e96456c2629c446f3a8c4107 Mon Sep 17 00:00:00 2001
> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Sun, 21 May 2017 22:16:57 -0400
> Subject: [PATCH] Add detail to mode-line-percentage-position and
>  mode-line-format doc
>
> * lisp/bindings.el (mode-line-percent-position): Mention that this
>   variable requires a 2-element list.  Also add detail about what
>   those elements should be.

How about: "Also add detail about what these elements typically are."

>
> * src/buffer.c (syms_of_buffer): Add description for the new %o and %q
>   constructs in `mode-line-format'.
> ---
>  lisp/bindings.el | 17 +++++++++++++----
>  src/buffer.c     |  5 +++++
>  2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/bindings.el b/lisp/bindings.el
> index 0e6ffc275e..895faa8a7e 100644
> --- a/lisp/bindings.el
> +++ b/lisp/bindings.el
> @@ -366,10 +366,19 @@ column-number-indicator-zero-based
>    :version "26.1")
>
>  (defcustom mode-line-percent-position '(-3 "%p")
> -  "Specification of \"percentage offset\" of window through buffer
> -This option specifies both the field width and the type of offset
> -displayed in `mode-line-position', a component of the default
> -`mode-line-format'."
> +  "Specification of \"percentage offset\" of window through buffer.
> +
> +This option's value is a list of the form (WIDTH TYPE) where
> +WIDTH specifies the field width to space-fill or truncate to,
> +and TYPE specifies the type of buffer offset to display in
> +`mode-line-position'.
> +

Or: "The option's value is typically a list of the form (WIDTH TYPE)
where WIDTH specifies the field width ... to display in
`mode-line-position' (see ....).  It could be nil, or any other valid mode
line format construct."

> +WIDTH is specified as an integer.  If the integer is negative (-N),
> +the width is truncated to N characters, and if it is positive (N),
> +padding is added, if needed, to make the field N characters wide.
> +

Here, I'm a bit bothered that we'd be documenting something which
doesn't really belong here.  This meaning of an integer applies
throughout the whole of the mode line format, not just in
mode-line-percent-position.

> +TYPE can be one of \"%o\", \"%p\", \"%P\" or \"%q\".  See
> +`mode-line-format' for more information on these % constructs."
>    :type `(radio
>            (const :tag "nil:  No offset is displayed" nil)
>            (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"

or ... "TYPE is typically  one of \"%o\", ...."

> diff --git a/src/buffer.c b/src/buffer.c
> index 80dbd3318d..9fd39c5fb4 100644
> --- a/src/buffer.c
> +++ b/src/buffer.c
> @@ -5496,6 +5496,11 @@ A string is printed verbatim in the mode line except for %-constructs:
>    %p -- print percent of buffer above top of window, or Top, Bot or All.
>    %P -- print percent of buffer above bottom of window, perhaps plus Top,
>          or print Bottom or All.
> +  %q -- print percentages of buffer above both the top and the bottom
> +        of the window, separated by -, or All.
> +  %o -- print percent of buffer above top of window vs the total buffer
> +        content excluding the text visible in the window, or Top, Bot
> +        or All.

This description of %o seems a bit clumsy and unintuitive, even though it
is accurate.  What was wrong with my phrase "the proportion of
\"travel\" of the window through the buffer".

The last clause should be "or Top, BotTOM, or All".  %o, %p, and %P
actually output "Bottom"; it is only the field width (-3) which
truncates it to "Bot".  (I just learned that over the weekend.  ;-)

>    %n -- print Narrow if appropriate.
>    %t -- visited file is text or binary (if OS supports this distinction).
>    %z -- print mnemonics of keyboard, terminal, and buffer coding systems.
> --
> 2.13.0

> -- 

> Kaushal Modi

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 3700 bytes --]

On Mon, May 22, 2017 at 2:21 PM Alan Mackenzie <acm@muc.de> wrote:

> Thanks for taking on the task of finishing up the documentation of this
> new facility.
>

Sure. I was just attempting to clarify things that were not clear to me as
the mode-line-format is not very familiar to me.


> I'm not completely happy with these changes, because I think they're a
> bit misleading.  Primarily, mode-line-percent-position _DOESN'T_ require
> a 2-element list - just that that's what's most likely to be used.  It
> could also be nil, or (I think) a bare "%o", etc., or any other valid
> mode line format fragment.
>

When I saw the defcustom options for mode-line-percent-position, it wasn't
evident to me why %q had 6 as the first element and why the rest had -3.


> How about: "Also add detail about what these elements typically are."
>

Sure. I was just reverse-engineering your patch, and documenting for my
future-self :)


> Or: "The option's value is typically a list of the form (WIDTH TYPE)
> where WIDTH specifies the field width ... to display in
> `mode-line-position' (see ....).  It could be nil, or any other valid mode
> line format construct."
>

Same as above.


> > +WIDTH is specified as an integer.  If the integer is negative (-N),
> > +the width is truncated to N characters, and if it is positive (N),
> > +padding is added, if needed, to make the field N characters wide.
> > +
>
> Here, I'm a bit bothered that we'd be documenting something which
> doesn't really belong here.  This meaning of an integer applies
> throughout the whole of the mode line format, not just in
> mode-line-percent-position.
>

I wasn't aware of that. Being not acquainted to mode-line-format. I thought
that the the reason for -3 and 6 as first elements needed to be explained.
mode-line-format docstring has this:

> A list whose car is an integer is processed by processing the cadr of
> the list, and padding (if the number is positive) or truncating (if
> negative) to the width specified by that number.

But I wanted the integer element description to be made even clearer.  May
be the mode-line-format docstring should be improved?


> > +TYPE can be one of \"%o\", \"%p\", \"%P\" or \"%q\".  See
> > +`mode-line-format' for more information on these % constructs."
> >    :type `(radio
> >            (const :tag "nil:  No offset is displayed" nil)
> >            (const :tag "\"%o\": Proportion of \"travel\" of the window
> through the buffer"
>
> or ... "TYPE is typically  one of \"%o\", ...."
>

OK.


> This description of %o seems a bit clumsy and unintuitive, even though it
> is accurate.  What was wrong with my phrase "the proportion of
> \"travel\" of the window through the buffer".
>

At first, I could not understand what that meant. But the analogy of
a/(a+b) earlier in the thread made complete sense to me. So I just spelled
that out in English, while also stealing the verbiage used in the Info
manual text.

The last clause should be "or Top, BotTOM, or All".  %o, %p, and %P
> actually output "Bottom"; it is only the field width (-3) which
> truncates it to "Bot".  (I just learned that over the weekend.  ;-)
>

I learned that just now :)

So in summary I was just attempting to explain the defcustom values of
mode-line-percent-position better, by reverse-engineering. I had to refer
to the initial discussion in this thread, docstring of mode-line-format and
parts from the Info manual changes made by your commit to completely
understand these options. So then I distilled all of that into the
mode-line-percent-position docstring.

Can you please rephrase the mode-line-format and mode-line-percent-position
docstrings taking that into account?
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 5586 bytes --]

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Mon, 15 May 2017 20:44:17 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Numerically, "%p" is 100 * a / (a + W + b).
> 
> "%o" is 100 * a / (a + b).

Isn't it better to display 100 * (a + W/2) / (a + W + b) instead?

This shows the portion of buffer before the window-center.  It will
show 50% in the first use case and 73% in the second.  IMO, showing
98% in the second case sounds misleading, not unlike the current 49%,
because it effectively disregards the text inside the window, and thus
can lead to skewed estimations when the part inside the window is
non-negligible relative to the part that outside.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Noam Postavsky]

On Mon, May 15, 2017 at 11:00 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> Numerically, "%p" is 100 * a / (a + W + b).
>>
>> "%o" is 100 * a / (a + b).
>
> Isn't it better to display 100 * (a + W/2) / (a + W + b) instead?

I don't think so, this formula also never reaches 100%.

> This shows the portion of buffer before the window-center.  It will
> show 50% in the first use case and 73% in the second.

Jumping from 73% to "Bot" is less wrong than jumping from 50%, but 98%
being the last number before "Bot" makes more sense to me.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Alan Mackenzie]

Hello, Eli.

On Tue, May 16, 2017 at 06:00:12 +0300, Eli Zaretskii wrote:
> > Date: Mon, 15 May 2017 20:44:17 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > Numerically, "%p" is 100 * a / (a + W + b).
> > 
> > "%o" is 100 * a / (a + b).

> Isn't it better to display 100 * (a + W/2) / (a + W + b) instead?

> This shows the portion of buffer before the window-center.  It will
> show 50% in the first use case and 73% in the second.  IMO, showing
> 98% in the second case sounds misleading, not unlike the current 49%,
> because it effectively disregards the text inside the window, and thus
> can lead to skewed estimations when the part inside the window is
> non-negligible relative to the part that outside.

I think the 100 * a / (a + b) is better, but that's likely to be just my
personal preference.  Why can't we have 100 * (a + W/2) / (a + W + b) as
well?  It is easily added.  Maybe we could denote that by %O.

Your other idea, that of having a customizable option for a user to
indicate his preference for how to display the approximate buffer/window
position will, I think, be somewhat more tedious to implement.

How about this as a design?  We introduce a new variable
`mode-line-window-position', which will be a short propertised string
typically holding "%p", "%P", or "%o" (or even "%O") with the properties
currently on the corresponding part of mode-line-position.
The new `mode-line-position' "includes" `mode-line-window-position' in
the standard `mode-line-format' way.

We also introduce a new customizable variable to set it with, which will
take one of these values:
  nil: don't display the window position at all;
  'top: display the window position with "%p";
  'bottom: display it with "%P";
  'middle: display it with (the proposed) "%O";
  'travel: display it with "%o";
  <further possibilities, such as "(23-30%)" mentioned by somebody>.

That new variable will have as a :set value the (new) function
`mode-line-generate-window-position', which will do the obvious thing.

I must admit, I find it a little dispiriting that `mode-line-format',
which used to be a user settable variable isn't really one any more, and
we've got to use defcustoms and such like to make this variable
tractable.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Eli Zaretskii]

> Date: Tue, 16 May 2017 20:37:59 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> How about this as a design?  We introduce a new variable
> `mode-line-window-position', which will be a short propertised string
> typically holding "%p", "%P", or "%o" (or even "%O") with the properties
> currently on the corresponding part of mode-line-position.
> The new `mode-line-position' "includes" `mode-line-window-position' in
> the standard `mode-line-format' way.
> 
> We also introduce a new customizable variable to set it with, which will
> take one of these values:
>   nil: don't display the window position at all;
>   'top: display the window position with "%p";
>   'bottom: display it with "%P";
>   'middle: display it with (the proposed) "%O";
>   'travel: display it with "%o";
>   <further possibilities, such as "(23-30%)" mentioned by somebody>.
> 
> That new variable will have as a :set value the (new) function
> `mode-line-generate-window-position', which will do the obvious thing.

Something like that is what I had in mind, yes.  (Do we really need 2
variables?)

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Alan Mackenzie]

Hello, Eli and Dani.

On Tue, May 16, 2017 at 20:37:59 +0000, Alan Mackenzie wrote:
> On Tue, May 16, 2017 at 06:00:12 +0300, Eli Zaretskii wrote:
> > > Date: Mon, 15 May 2017 20:44:17 +0000
> > > From: Alan Mackenzie <acm@muc.de>

> > > Numerically, "%p" is 100 * a / (a + W + b).

> > > "%o" is 100 * a / (a + b).

> > Isn't it better to display 100 * (a + W/2) / (a + W + b) instead?

> > This shows the portion of buffer before the window-center.  It will
> > show 50% in the first use case and 73% in the second.  IMO, showing
> > 98% in the second case sounds misleading, not unlike the current 49%,
> > because it effectively disregards the text inside the window, and thus
> > can lead to skewed estimations when the part inside the window is
> > non-negligible relative to the part that outside.

Dani Moncayo wrote

> FWIW: I'd love to have these placeholders supported in Emacs, so that
> I could show in the modeline the range of text (lines) I'm currently
> seeing in the window.  E.g.: "(15-25%)".

I've hacked these two formulae into xdisp.c, Eli's formula as %O, Dani's
as %q.

For what it's worth, having tried it, I don't think %O is very useful -
it displays a value which (unless it is All, Top, or Bot) ranges
between, say 36% and 64%.

For %q, I haven't included the parentheses Dani suggested, and it's a
bit DWIMy, with things like "All", "Top-5%", "63%-Bot", "15-25%".

Just to save you some work, I found the following useful for trying them
out, by setting the pertinent part of the standard mode-line format.
(i) (For %O): (aset (cadr (car mode-line-position)) 1 ?O)
(ii) (For %q): (aset (cadr (car mode-line-position)) 1 ?q)
      and      (setcar (car mode-line-position) -7)

Thoughts?



diff --git a/src/xdisp.c b/src/xdisp.c
index cdea20993c..a2dc595155 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -23870,6 +23870,48 @@ 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;
+          }
+      }
+
+      /* Display the percentage of the buffer above the middle of the screen. */
+    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 + botpos)/2 - begv, 
+                              zv - begv));
+          return decode_mode_spec_buf;
+          }
+      }
+
+      /* Display percentage of buffer above the top of the screen.  */
     case 'p':
       {
 	ptrdiff_t pos = marker_position (w->start);
@@ -23907,6 +23949,38 @@ decode_mode_spec (struct window *w, register int c, int field_width,
 	  }
       }
 
+      /* Display percentage offsets of top and bottom of the window,
+         using "Top", "Bot" and "All" where appropriate. */
+    case 'q':
+      {
+        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 ((toppos <= begv) && (zv <= botpos))
+          return "All";
+
+        if (toppos <= begv)
+          strcpy (decode_mode_spec_buf, "Beg");
+        else
+          sprintf (decode_mode_spec_buf, "%2d",
+                   percent99 (toppos - begv, zv - begv));
+
+        if (zv <= botpos)
+          strcat (decode_mode_spec_buf, "%-");
+        else
+          strcat (decode_mode_spec_buf, "-");
+
+        if (zv <= botpos)
+          strcat (decode_mode_spec_buf, "Bot");
+        else
+          sprintf (&decode_mode_spec_buf [strlen (decode_mode_spec_buf)],
+                   "%2d%%", percent99 (botpos - begv, zv - begv));
+
+        return decode_mode_spec_buf;
+      }
+
     case 's':
       /* status of process */
       obj = Fget_buffer_process (Fcurrent_buffer ());


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Dani Moncayo]

On Wed, May 17, 2017 at 11:32 PM, Alan Mackenzie <acm@muc.de> wrote:
> Hello, Eli and Dani.

Hi Alan, thanks for working on this.

> For %q, I haven't included the parentheses Dani suggested, and it's a
> bit DWIMy, with things like "All", "Top-5%", "63%-Bot", "15-25%".
>
> Just to save you some work, I found the following useful for trying them
> out, by setting the pertinent part of the standard mode-line format.
> (i) (For %O): (aset (cadr (car mode-line-position)) 1 ?O)
> (ii) (For %q): (aset (cadr (car mode-line-position)) 1 ?q)
>       and      (setcar (car mode-line-position) -7)
>
> Thoughts?

Wrt %q, I find the format to be too irregular.  I'd prefer to stick to
"N-M%" (with no whitespace around the hyphen), even when N is 0 or M
is 100.  The only exception to that format would be when N=0 _and_
M=100, in which case I'd prefer "All" rather than "0-100%".   Also,
I'd like the whole text related to %q to take a constant amount of
space in the modeline, to avoid shifting any text to the right side of
%q.

Thanks.

-- 
Dani Moncayo

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Alan Mackenzie]

Hello, Dani.

On Thu, May 18, 2017 at 21:16:06 +0200, Dani Moncayo wrote:
> On Wed, May 17, 2017 at 11:32 PM, Alan Mackenzie <acm@muc.de> wrote:
> > Hello, Eli and Dani.

> Hi Alan, thanks for working on this.

> > For %q, I haven't included the parentheses Dani suggested, and it's a
> > bit DWIMy, with things like "All", "Top-5%", "63%-Bot", "15-25%".

> > Just to save you some work, I found the following useful for trying them
> > out, by setting the pertinent part of the standard mode-line format.
> > (i) (For %O): (aset (cadr (car mode-line-position)) 1 ?O)
> > (ii) (For %q): (aset (cadr (car mode-line-position)) 1 ?q)
> >       and      (setcar (car mode-line-position) -7)

> > Thoughts?

> Wrt %q, I find the format to be too irregular.

OK.

> I'd prefer to stick to "N-M%" (with no whitespace around the hyphen),
> ....

Er, the WS was unintentional.  Sorry!  I can do a bit of other tidying
up on that code, too.

> .... even when N is 0 or M is 100.  The only exception to that format
> would be when N=0 _and_ M=100, in which case I'd prefer "All" rather
> than "0-100%".

Presumably truncating the number to 99%, except when the window is right
at the bottom of the buffer.  The rounding up to 1% is already done by
the SW.

> Also, I'd like the whole text related to %q to take a
> constant amount of space in the modeline, to avoid shifting any text
> to the right side of %q.

I'm not sure that's the Right Thing.  This would take up 7 characters +
at least one space (compared with the current 3 characters + at least
one space for "%p") for "99-100%".  That's an awful lot of mode-line
space.  I would be tempted to scale it back to 6 characters (for
"54-59%") which is the "usual" maximum width, and take the hit when we
reach "99-100%", by expanding to 7 characters then.

So, the range of formats we'd deal with would be:
"All   "
"0-5%  "
"4-11% "
"31-38%"
"99-99%"
"99-100%"
, the last one happening only when EOB is visible in the window.  This
doesn't take up any more space than my proposed "99%-Bot", which is also
7 characters.

Somehow I think even "100-100%" might be possible, if the window were at
EOB, and the buffer were narrowed to zero characters (if that is
possible - I'm not sure it is).  Or, maybe that would be handled by "All
".

I haven't had time to make any changes this evening - I've been working
on the code to select the "percentage offset" formula by a customisable
variable.  Maybe we can finalise this change by the weekend.

> Thanks.

> -- 
> Dani Moncayo

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Yuri Khan]

On Fri, May 19, 2017 at 2:16 AM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> Wrt %q, I find the format to be too irregular.  I'd prefer to stick to
> "N-M%" (with no whitespace around the hyphen),

Hey! Typographically, that should be a dash, not a hyphen.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Andreas Schwab]

less offers a way to specify which window position to use as the base
for the percentage (top (%pt), bottom (%pb) or middle (%pm)).  That
works with other formats, too (line number, byte number).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Dani Moncayo]

> less offers a way to specify which window position to use as the base
> for the percentage (top (%pt), bottom (%pb) or middle (%pm)).  That
> works with other formats, too (line number, byte number).

FWIW: I'd love to have these placeholders supported in Emacs, so that
I could show in the modeline the range of text (lines) I'm currently
seeing in the window.  E.g.: "(15-25%)".

-- 
Dani Moncayo

RE: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Drew Adams]

> > less offers a way to specify which window position to use as the base
> > for the percentage (top (%pt), bottom (%pb) or middle (%pm)).  That
> > works with other formats, too (line number, byte number).
> 
> FWIW: I'd love to have these placeholders supported in Emacs, so that
> I could show in the modeline the range of text (lines) I'm currently
> seeing in the window.  E.g.: "(15-25%)".

+1 to this too.  I might not use it (again), but it sounds useful.

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[Toon Claes]

Dani Moncayo <dmoncayo@gmail.com> writes:

> FWIW: I'd love to have these placeholders supported in Emacs, so that
> I could show in the modeline the range of text (lines) I'm currently
> seeing in the window.  E.g.: "(15-25%)".

For quite some time I've been using sml-modeline, it shows the window
position in a scrollbar-like manner in the modeline.
http://emacs-fu.blogspot.be/2010/03/showing-buffer-position-in-mode-line.html

At the moment I am using nyan-mode instead.
https://www.emacswiki.org/emacs/NyanMode
But it also suffers from some problems it's not reaching 100%.

So, there are many options possible. And everyone wants something
different. So I'm not sure if this %o option would provide much added
value for many users?


-- Toon

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer".

[John Yates]

On Tue, May 16, 2017 at 2:59 PM, Toon Claes <toon@iotcl.com> wrote:
> For quite some time I've been using sml-modeline, it shows the window
> position in a scrollbar-like manner in the modeline.

The widget I posted earlier in this thread shares features with sml-modeline.

> But it also suffers from some problems it's not reaching 100%.

My widget has a bracket at either end.  If the beginning of the buffer
is visible I bold the left bracket.  If the end of the buffer is visible I
bold the right bracket.

/john

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch]

[Alan Mackenzie]

On Mon, May 15, 2017 at 20:44:17 +0000, Alan Mackenzie wrote:
> 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!).

[ .... ]

Here is a patch which implements %o and %q.  Feedback would be welcome,
of course.



diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index eb72fcfd36..0e476b47a3 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -1972,6 +1972,14 @@ Mode Line Variables
 line number and the column number.
 @end defvar
 
+@defopt mode-line-percent-position
+This option is used in @code{mode-line-position}.  Its value specifies
+both the buffer percentage to display (one of @code{nil}, @code{"%o"},
+@code{"%p"}, @code{"%P"} or @code{"%q"}, @pxref{%-Constructs}) and a
+width to space-fill or truncate to.  You are recommended to set this
+option with the @code{customize-variable} facility.
+@end defopt
+
 @defvar vc-mode
 The variable @code{vc-mode}, buffer-local in each buffer, records
 whether the buffer's visited file is maintained with version control,
@@ -2147,6 +2155,12 @@ %-Constructs
 @samp{Narrow} when narrowing is in effect; nothing otherwise (see
 @code{narrow-to-region} in @ref{Narrowing}).
 
+@item %o
+The degree of @dfn{travel} of the window through (the visible portion
+of) the buffer, i.e. the size of the text above the top of the window
+expressed as a percentage of all the text outside the window, or
+@samp{Top}, @samp{Bottom} or @samp{All}.
+
 @item %p
 The percentage of the buffer text above the @strong{top} of window, or
 @samp{Top}, @samp{Bottom} or @samp{All}.  Note that the default mode
@@ -2158,6 +2172,10 @@ %-Constructs
 the text above the top), plus @samp{Top} if the top of the buffer is
 visible on screen; or @samp{Bottom} or @samp{All}.
 
+@item %q
+The percentages of text above both the @strong{top} and the
+@strong{bottom} of the window, separated by @samp{-}, or @samp{All}.
+
 @item %s
 The status of the subprocess belonging to the current buffer, obtained with
 @code{process-status}.  @xref{Process Information}.
diff --git a/etc/NEWS b/etc/NEWS
index 9be6ee0f3f..4a8696ace4 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -358,6 +358,16 @@ new mode line construct, '%C', which operates exactly as '%c' does
 except that it counts from one.)
 
 +++
+** New mode line constructs '%o' and '%q', and user option
+'mode-line-percent-position'.  '%o' displays the "degree of travel" of
+the window through the buffer.  Unlike the default '%p', this
+percentage approaches 100% as the window approaches the end of the
+buffer.  '%q' displays the percentage offsets of both the start and
+the end of the window, e.g. "5-17%".  The new option
+'mode-line-percent-position' makes it easier to switch between '%p',
+'%P', and these new constructs.
+
++++
 ** Two new user options 'list-matching-lines-jump-to-current-line' and
 'list-matching-lines-current-line-face' to show highlighted the current
 line in *Occur* buffer.
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 85a5408717..1f5c8b3bbf 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -365,14 +365,32 @@ column-number-indicator-zero-based
   :group 'mode-line
   :version "26.1")
 
+(defcustom mode-line-percent-position '(-3 "%p")
+  "Specification of \"percentage offset\" of window through buffer
+This option specifies both the field width and the type of offset
+displayed in `mode-line-position', a component of the default
+`mode-line-format'."
+  :type `(radio
+          (const :tag "nil:  No offset is displayed" nil)
+          (const :tag "\"%o\": Proportion of \"travel\" of the window through the buffer"
+                 (-3 "%o"))
+          (const :tag "\"%p\": Percentage offset of top of window"
+                 (-3 "%p"))
+          (const :tag "\"%P\": Precentage offset of bottom of window"
+                 (-3 "%P"))
+          (const :tag "\"%q\": Offsets of both top and bottom of window"
+                 (6 "%q")))
+  :version "26.1"
+  :group 'mode-line)
+
 (defvar mode-line-position
-  `((-3 ,(propertize
-	  "%p"
-	  'local-map mode-line-column-line-number-mode-map
-	  'mouse-face 'mode-line-highlight
-	  ;; XXX needs better description
-	  'help-echo "Size indication mode\n\
-mouse-1: Display Line and Column Mode Menu"))
+  `((:propertize
+     mode-line-percent-position
+     'local-map mode-line-column-line-number-mode-map
+     'mouse-face 'mode-line-highlight
+     ;; XXX needs better description
+     'help-echo "Size indication mode\n\
+mouse-1: Display Line and Column Mode Menu")
     (size-indication-mode
      (8 ,(propertize
 	  " of %I"
@@ -419,6 +437,7 @@ mode-line-position
   "Mode line construct for displaying the position in the buffer.
 Normally displays the buffer percentage and, optionally, the
 buffer size, the line number and the column number.")
+
 (put 'mode-line-position 'risky-local-variable t)
 
 (defvar mode-line-buffer-identification-keymap
diff --git a/src/xdisp.c b/src/xdisp.c
index cdea20993c..27349aeba3 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -23870,6 +23870,27 @@ 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;
+          }
+      }
+
+      /* Display percentage of buffer above the top of the screen.  */
     case 'p':
       {
 	ptrdiff_t pos = marker_position (w->start);
@@ -23907,6 +23928,33 @@ decode_mode_spec (struct window *w, register int c, int field_width,
 	  }
       }
 
+      /* Display percentage offsets of top and bottom of the window,
+         using "All" (but not "Top" or "Bottom") where appropriate.  */
+    case 'q':
+      {
+        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 ((toppos <= begv) && (zv <= botpos))
+          return "All   ";
+
+        if (toppos <= begv)
+          strcpy (decode_mode_spec_buf, "0-");
+        else
+          sprintf (decode_mode_spec_buf, "%d-",
+                   percent99 (toppos - begv, zv - begv));
+
+        if (zv <= botpos)
+          strcat (decode_mode_spec_buf, "100%");
+        else
+          sprintf (&decode_mode_spec_buf [strlen (decode_mode_spec_buf)],
+                   "%d%%", percent99 (botpos - begv, zv - begv));
+
+        return decode_mode_spec_buf;
+      }
+
     case 's':
       /* status of process */
       obj = Fget_buffer_process (Fcurrent_buffer ());


> -- 
> Alan Mackenzie (Nuremberg, Germany).

Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..)

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Sat, May 20, 2017 at 6:35 AM Alan Mackenzie <acm@muc.de> wrote:

> On Mon, May 15, 2017 at 20:44:17 +0000, Alan Mackenzie wrote:
> > 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!).
>
> [ .... ]
>
> Here is a patch which implements %o and %q.  Feedback would be welcome,
> of course.
>

Hello,

I wanted to try out this patch, but I faced issues applying multi-file
patch from within emacs. If this were a git-formatted patch, I would have
tried "git am". But as this is a plain diff patch, that wouldn't work and I
attempted M-x ediff-patch-file.

But then I ended with with an issue which is well-described by Michael
(copied on this email) in a thread on help-gnu-emacs back in Feb this year:
http://lists.gnu.org/archive/html/help-gnu-emacs/2017-02/msg00035.html

It's the same issue that when I specify the root dir for all the patches to
be applied, ediff-patch-file in my case (epatch in the case in that Feb
2017 thread) does not parse the subdirs for the unified diff format headers.

In that thread, Eli suggests using patch utility directly from the
command-line. But I really wished ediff-patch-file/epatch worked correctly
when applying multi-file patches.

So the reason for this thread is:

- Has anyone been able to apply multi-file patches from within emacs? If
so, how?
- If someone has worked out the issues with ediff-patch-file/epatch for
this issue and the solution is lying around in their workarea, it would be
awesome if they provided a patch to fix it upstream :)
- I followed that Feb 2017 help thread, and it wasn't clear if a solution
was reached.. was it?
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2482 bytes --]

Re: Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..)

[Noam Postavsky]

On Sun, May 21, 2017 at 11:55 AM, Kaushal Modi <kaushal.modi@gmail.com> wrote:

> I wanted to try out this patch, but I faced issues applying multi-file patch
> from within emacs. If this were a git-formatted patch, I would have tried
> "git am". But as this is a plain diff patch, that wouldn't work

You can use "git apply" for plain diffs.

Re: Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..)

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

On Sun, May 21, 2017 at 12:04 PM Noam Postavsky <
npostavs@users.sourceforge.net> wrote:

>
> You can use "git apply" for plain diffs.
>

Thanks. I did not know of that. But that too didn't work for this patch.

I get:

error: corrupt patch at line 9
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 694 bytes --]

Re: Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..)

[Noam Postavsky]

On Sun, May 21, 2017 at 9:19 PM, Kaushal Modi <kaushal.modi@gmail.com> wrote:
>>
>> You can use "git apply" for plain diffs.
>
>
> Thanks. I did not know of that. But that too didn't work for this patch.
>
> I get:
>
> error: corrupt patch at line 9

I get that when using the text from
http://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00543.html as
it seems to have been line wrapped, though the original mail in my
inbox seems to work fine (apart from the etc/NEWS hunk not applying, I
didn't go far back enough for that).

Re: Difficulty applying multi-file patches from within emacs

[Alan Mackenzie]

Hello, Kaushal.

On Sun, May 21, 2017 at 15:55:45 +0000, Kaushal Modi wrote:
> On Sat, May 20, 2017 at 6:35 AM Alan Mackenzie <acm@muc.de> wrote:

> > On Mon, May 15, 2017 at 20:44:17 +0000, Alan Mackenzie wrote:
> > > 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!).

> > [ .... ]

> > Here is a patch which implements %o and %q.  Feedback would be welcome,
> > of course.

As a matter of interest, I've committed this patch to master already.
But what you've written is still a matter of interest.

> Hello,

> I wanted to try out this patch, but I faced issues applying multi-file
> patch from within emacs. If this were a git-formatted patch, I would have
> tried "git am". But as this is a plain diff patch, that wouldn't work and I
> attempted M-x ediff-patch-file.

How is it not a git-formatted patch?  I created it with

    $ git diff <filenames> > diff.20170520.diff

, from the top level Emacs directory.

> But then I ended with with an issue which is well-described by Michael
> (copied on this email) in a thread on help-gnu-emacs back in Feb this year:
> http://lists.gnu.org/archive/html/help-gnu-emacs/2017-02/msg00035.html

> It's the same issue that when I specify the root dir for all the patches to
> be applied, ediff-patch-file in my case (epatch in the case in that Feb
> 2017 thread) does not parse the subdirs for the unified diff format headers.

> In that thread, Eli suggests using patch utility directly from the
> command-line. But I really wished ediff-patch-file/epatch worked correctly
> when applying multi-file patches.

> So the reason for this thread is:

> - Has anyone been able to apply multi-file patches from within emacs? If
> so, how?
> - If someone has worked out the issues with ediff-patch-file/epatch for
> this issue and the solution is lying around in their workarea, it would be
> awesome if they provided a patch to fix it upstream :)
> - I followed that Feb 2017 help thread, and it wasn't clear if a solution
> was reached.. was it?
> -- 

> Kaushal Modi

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulty applying multi-file patches from within emacs

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

Alan Mackenzie <acm@muc.de> schrieb am So., 21. Mai 2017 um 18:10 Uhr:

>
> How is it not a git-formatted patch?  I created it with
>
>     $ git diff <filenames> > diff.20170520.diff
>
> , from the top level Emacs directory.
>
>
"Git-formatted patch" means "patch produced by git format-patch". A typical
workflow is:

git checkout -b NEW-BRANCH master  # start new topic branch off master
# make changes
git commit
git format-patch master  # create patch files for all commits since master

The patch files thus produced can be applied using 'git am'. To send them
directly to the mailing list, you can use 'send-email' instead of
'format-patch'.

[-- Attachment #2: Type: text/html, Size: 1068 bytes --]

Re: Difficulty applying multi-file patches from within emacs

[Alan Mackenzie]

Hello, Philipp.

On Sun, May 21, 2017 at 17:20:34 +0000, Philipp Stephani wrote:
> Alan Mackenzie <acm@muc.de> schrieb am So., 21. Mai 2017 um 18:10 Uhr:


> > How is it not a git-formatted patch?  I created it with

> >     $ git diff <filenames> > diff.20170520.diff

> > , from the top level Emacs directory.


> "Git-formatted patch" means "patch produced by git format-patch". A typical
> workflow is:

> git checkout -b NEW-BRANCH master  # start new topic branch off master
> # make changes
> git commit
> git format-patch master  # create patch files for all commits since master

> The patch files thus produced can be applied using 'git am'. To send them
> directly to the mailing list, you can use 'send-email' instead of
> 'format-patch'.

Thanks!  I didn't know that.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Difficulty applying multi-file patches from within emacs

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

Hi Alan,

On Sun, May 21, 2017 at 1:40 PM Alan Mackenzie <acm@muc.de> wrote:

> > The patch files thus produced can be applied using 'git am'. To send them
> > directly to the mailing list, you can use 'send-email' instead of
> > 'format-patch'.
>
> Thanks!  I didn't know that.
>

Can you please re-send the patch created using git format as an attachment
to that thread?
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 843 bytes --]

Re: Difficulty applying multi-file patches from within emacs

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

On Sun, May 21, 2017 at 9:21 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> Hi Alan,
>
> Can you please re-send the patch created using git format as an attachment
> to that thread?
>

Well, I just saw this
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b0b02ca7f3e06d0f092df6f81babd1277bf93b0f
 :)

I'll rebuild emacs and try it out, thanks!
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1043 bytes --]

Re: Difficulty applying multi-file patches from within emacs (Was: Proposal: new mode-line `%'-construct %o ..)

[Tino Calancha]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]



On Sun, 21 May 2017, Kaushal Modi wrote:

> I attempted M-x ediff-patch-file.
> 
> But then I ended with with an issue which is well-described by Michael (copied on this email) in a thread on help-gnu-emacs back
> in Feb this year: http://lists.gnu.org/archive/html/help-gnu-emacs/2017-02/msg00035.html
> 
> It's the same issue that when I specify the root dir for all the patches to be applied, ediff-patch-file in my case (epatch in
> the case in that Feb 2017 thread) does not parse the subdirs for the unified diff format headers.
> 
> In that thread, Eli suggests using patch utility directly from the command-line. But I really wished ediff-patch-file/epatch
> worked correctly when applying multi-file patches.
> 
> So the reason for this thread is:
> 
> - Has anyone been able to apply multi-file patches from within emacs? If so, how?
> - If someone has worked out the issues with ediff-patch-file/epatch for this issue and the solution is lying around in their
> workarea, it would be awesome if they provided a patch to fix it upstream :)
> - I followed that Feb 2017 help thread, and it wasn't clear if a solution was reached.. was it?
Well,  i am not really using `ediff-patch-file' (a.k.a. `epatch') but i 
have an old patch for this issue.  That said, i don't think this patch is 
the ultimate solution, but at least improves the current situation a bit.
I am going to post it in Bug#26028.

Tino

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch]

[Dani Moncayo]

> Here is a patch which implements %o and %q.  Feedback would be welcome,
> of course.

I'm thinking of a further refinement for %q: On large enough buffers,
%q may produce things like "43-43%".   In those cases, where both
percentages are the same, it'd be better (nicer, IMO) to just show one
of them (e.g "43%").

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch]

[Alan Mackenzie]

Hello, Dani.

On Tue, May 23, 2017 at 10:00:55 +0200, Dani Moncayo wrote:
> > Here is a patch which implements %o and %q.  Feedback would be welcome,
> > of course.

> I'm thinking of a further refinement for %q: On large enough buffers,
> %q may produce things like "43-43%".   In those cases, where both
> percentages are the same, it'd be better (nicer, IMO) to just show one
> of them (e.g "43%").

OK, how about the following?



diff --git a/src/xdisp.c b/src/xdisp.c
index 0588061738..ef55e0f481 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -23990,21 +23990,18 @@ decode_mode_spec (struct window *w, register int c, int field_width,
         ptrdiff_t botpos = BUF_Z (b) - w->window_end_pos;
         ptrdiff_t begv = BUF_BEGV (b);
         ptrdiff_t zv = BUF_ZV (b);
+        ptrdiff_t top_perc, bot_perc;
 
         if ((toppos <= begv) && (zv <= botpos))
           return "All   ";
 
-        if (toppos <= begv)
-          strcpy (decode_mode_spec_buf, "0-");
-        else
-          sprintf (decode_mode_spec_buf, "%d-",
-                   percent99 (toppos - begv, zv - begv));
+        top_perc = toppos <= begv ? 0 : percent99 (toppos - begv, zv - begv);
+        bot_perc = zv <= botpos ? 100 : percent99 (botpos - begv, zv - begv);
 
-        if (zv <= botpos)
-          strcat (decode_mode_spec_buf, "100%");
+        if (top_perc == bot_perc)
+          sprintf (decode_mode_spec_buf, "%d%%", top_perc);
         else
-          sprintf (&decode_mode_spec_buf [strlen (decode_mode_spec_buf)],
-                   "%d%%", percent99 (botpos - begv, zv - begv));
+          sprintf (decode_mode_spec_buf, "%d-%d%%", top_perc, bot_perc);
 
         return decode_mode_spec_buf;
       }


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new mode-line `%'-construct %o meaning "Degree of travel of window through buffer". [Patch]

[Dani Moncayo]

>> I'm thinking of a further refinement for %q: On large enough buffers,
>> %q may produce things like "43-43%".   In those cases, where both
>> percentages are the same, it'd be better (nicer, IMO) to just show one
>> of them (e.g "43%").
>
> OK, how about the following?

It looks good to me.  Thanks!

-- 
Dani Moncayo