GNU bug report logs - #27847
26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)

Previous Next

To reply to this bug, email your comments to 27847 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <bug-gnu-emacs <at> gnu.org>
Subject: 26.0.50; mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Thu, 27 Jul 2017 15:08:18 +0200

Severity: wishlist

Hi,

AFAIK, the percentage(s) shown in the modeline by the variable
"mode-line-percent-position" are all character-based, i.e., the
percentage(s) is (are) computed based on the number of _characters_
before a certain visible character (first visible, last visible, first
in middle line, ...)

I'd prefer this (those) percentage(s) to be based on the number of
_lines_ instead, because that would give me the information I really
want to see: the relative _vertical_ position of the window/viewport
wrt the whole buffer (i.e., the kind of information that a graphical
vertical scrollbar provides visually).

So I'd like I could set some variable for switching to this way of
computing the modeline percentage(s).  I think that many users would
like it.

TIA.

-- 
Dani Moncayo

In GNU Emacs 26.0.50 (build 1, x86_64-unknown-cygwin)
 of 2017-07-24 built on ZVDES404
Repository revision: 6dc5d45c542a6f9cfbcf3e37d597c9e0efb3070d
Windowing system distributor 'Microsoft Corp.', version 6.3.9600

Configured using:
 'configure --with-mailutils --with-w32'

Configured features:
SOUND ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: C.ISO-8859-1
  locale-coding-system: iso-latin-1-unix

Message #8 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 27847 <at> debbugs.gnu.org
Subject: Re: bug#27847: 26.0.50;
 mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Thu, 27 Jul 2017 20:25:15 +0300

> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Thu, 27 Jul 2017 15:08:18 +0200
> 
> I'd prefer this (those) percentage(s) to be based on the number of
> _lines_ instead

What do you want to be displayed in that case when line numbers are
not counted and displayed as "???" ?  Do you want Emacs to count lines
even though the limits which control that are exceeded?

Also note that for your feature to be implemented, Emacs needs to
count lines in the entire buffer each time the buffer is changed, so I
expect this feature to slow down redisplay.

Message #11 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>, 27847 <at> debbugs.gnu.org
Subject: RE: bug#27847: 26.0.50; mode-line-percent-position: line-based
 instead of char-based (optionally)
Date: Thu, 27 Jul 2017 11:00:35 -0700 (PDT)

> AFAIK, the percentage(s) shown in the modeline by the variable
> "mode-line-percent-position" are all character-based, i.e., the
> percentage(s) is (are) computed based on the number of _characters_
> before a certain visible character (first visible, last visible, first
> in middle line, ...)
> 
> I'd prefer this (those) percentage(s) to be based on the number of
> _lines_ instead, because that would give me the information I really
> want to see: the relative _vertical_ position of the window/viewport
> wrt the whole buffer (i.e., the kind of information that a graphical
> vertical scrollbar provides visually).
> 
> So I'd like I could set some variable for switching to this way of
> computing the modeline percentage(s).  I think that many users would
> like it.

FYI, you can use library `modeline-posn.el' to get what you
want.  In this case you would define a custom behavior (it
is not one of the predefined choices), but that is easy to do.

https://www.emacswiki.org/emacs/modeline-posn.el

Message #14 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27847 <at> debbugs.gnu.org
Subject: Re: bug#27847: 26.0.50; mode-line-percent-position: line-based
 instead of char-based (optionally)
Date: Thu, 27 Jul 2017 22:44:58 +0200

>> I'd prefer this (those) percentage(s) to be based on the number of
>> _lines_ instead
>
> What do you want to be displayed in that case when line numbers are
> not counted and displayed as "???" ?  Do you want Emacs to count lines
> even though the limits which control that are exceeded?

In cases where line numbers are not counted (I didn't know about such
cases, BTW), I guess Emacs could display "??" as the percentage,
meaning that the value is unknown at that moment.

> Also note that for your feature to be implemented, Emacs needs to
> count lines in the entire buffer each time the buffer is changed, so I
> expect this feature to slow down redisplay.

Maybe this computation could be optimized somehow.  In any case, if
someone implements it and the slow down is observable, it could be
advertised in the manual and/or the docstring of the variable which
enables this feature.

-- 
Dani Moncayo

Message #17 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 27847 <at> debbugs.gnu.org
Subject: Re: bug#27847: 26.0.50;
 mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Fri, 28 Jul 2017 12:44:12 +1000

Dani Moncayo <dmoncayo <at> gmail.com> writes:

>>> I'd prefer this (those) percentage(s) to be based on the 
>>> number of
>>> _lines_ instead
>>
>> What do you want to be displayed in that case when line numbers 
>> are
>> not counted and displayed as "???" ?  Do you want Emacs to 
>> count lines
>> even though the limits which control that are exceeded?
>
> In cases where line numbers are not counted (I didn't know about 
> such
> cases, BTW), I guess Emacs could display "??" as the percentage,
> meaning that the value is unknown at that moment.
>
>> Also note that for your feature to be implemented, Emacs needs 
>> to
>> count lines in the entire buffer each time the buffer is 
>> changed, so I
>> expect this feature to slow down redisplay.
>
> Maybe this computation could be optimized somehow.  In any case, 
> if
> someone implements it and the slow down is observable, it could 
> be
> advertised in the manual and/or the docstring of the variable 
> which
> enables this feature.

As a data point, i have this as part of my `mode-line-format` 
setup:

   '(:eval
     (let ((buffer-line-count (count-lines (point-min) 
     (point-max))))
       (number-to-string
        (round
         (* 100 (/
                 (float (count-lines 1 (point)))
                 (if (equal 0 buffer-line-count)
                     1
                   buffer-line-count)))))))
   "%%"

which gives me at least a rough percentage (i.e. 'good enough' for 
my
needs), and i've not noticed any slowdown as a result.


Alexis.

Message #20 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Nick Helm <nick <at> tenpoint.co.nz>
To: 27847 <at> debbugs.gnu.org
Subject: Re: bug#27847: 26.0.50;
 mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Fri, 28 Jul 2017 17:28:13 +1200

On Thu, Jul 27 2017, Dani Moncayo wrote:

>>> I'd prefer this (those) percentage(s) to be based on the number of
>>> _lines_ instead
>>
>> What do you want to be displayed in that case when line numbers are
>> not counted and displayed as "???" ?  Do you want Emacs to count lines
>> even though the limits which control that are exceeded?
>
> In cases where line numbers are not counted (I didn't know about such
> cases, BTW), I guess Emacs could display "??" as the percentage,
> meaning that the value is unknown at that moment.
>
>> Also note that for your feature to be implemented, Emacs needs to
>> count lines in the entire buffer each time the buffer is changed, so I
>> expect this feature to slow down redisplay.
>
> Maybe this computation could be optimized somehow.  In any case, if
> someone implements it and the slow down is observable, it could be
> advertised in the manual and/or the docstring of the variable which
> enables this feature.

As another example, I also wrote something to do this in my mode
line:

  (:eval
  
    (let ((lines (float (+ (count-lines (point-min)
                                        (point-max))
                           1))))
  
      (concat  
  
       ;% of lines above upper edge of window
       (number-to-string (floor
                          (* (/ (- (line-number-at-pos
                                    (window-start))
                                   1)
                                lines)
                             100)))
       " "
  
       ;% of lines above lower edge of window
       (number-to-string (ceiling
                          (* (/ (line-number-at-pos
                                 (window-end))
                                lines)
                             100))))))

With all the calls to count-lines the performance was pretty
rough though, especially near the end of long buffers.

I ended up just learning to live with line-based length. I didn't
notice much difference anyway, unless the line lengths varied a
lot, eg loads of trailing newlines.

Message #23 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexis <flexibeast <at> gmail.com>
Cc: 27847 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#27847: 26.0.50;
 mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Fri, 28 Jul 2017 09:46:51 +0300

> From: Alexis <flexibeast <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 27847 <at> debbugs.gnu.org
> Date: Fri, 28 Jul 2017 12:44:12 +1000
> 
> As a data point, i have this as part of my `mode-line-format` 
> setup:
> 
>     '(:eval
>       (let ((buffer-line-count (count-lines (point-min) 
>       (point-max))))
>         (number-to-string
>          (round
>           (* 100 (/
>                   (float (count-lines 1 (point)))
>                   (if (equal 0 buffer-line-count)
>                       1
>                     buffer-line-count)))))))
>     "%%"
> 
> which gives me at least a rough percentage (i.e. 'good enough' for 
> my needs), and i've not noticed any slowdown as a result.

How large are the files you usually edit?

Message #26 received at 27847 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 27847 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#27847: 26.0.50;
 mode-line-percent-position: line-based instead of char-based
 (optionally)
Date: Fri, 28 Jul 2017 18:07:45 +1000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alexis <flexibeast <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 27847 <at> debbugs.gnu.org
>> Date: Fri, 28 Jul 2017 12:44:12 +1000
>>
>> As a data point, i have this as part of my `mode-line-format`
>> setup:
>>
>>     '(:eval
>>       (let ((buffer-line-count (count-lines (point-min)
>>       (point-max))))
>>         (number-to-string
>>          (round
>>           (* 100 (/
>>                   (float (count-lines 1 (point)))
>>                   (if (equal 0 buffer-line-count)
>>                       1
>>                     buffer-line-count)))))))
>>     "%%"
>>
>> which gives me at least a rough percentage (i.e. 'good enough' 
>> for
>> my needs), and i've not noticed any slowdown as a result.
>
> How large are the files you usually edit?

Good point; usually not that large, maybe only a few thousand 
lines at
most. So i just tried opening xdisp.c, and there's certainly some
movement lag there. Not unusably so for me, but i can imagine it 
would
be for others. This is on a Core i5-6200U running Debian x86_64.


Alexis.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.