all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
@ 2017-07-27 13:08 Dani Moncayo
  2017-07-27 17:25 ` Eli Zaretskii
  2017-07-27 18:00 ` Drew Adams
  0 siblings, 2 replies; 8+ messages in thread
From: Dani Moncayo @ 2017-07-27 13:08 UTC (permalink / raw)
  To: 27847

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-27 13:08 bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally) Dani Moncayo
@ 2017-07-27 17:25 ` Eli Zaretskii
  2017-07-27 20:44   ` Dani Moncayo
  2017-07-27 18:00 ` Drew Adams
  1 sibling, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2017-07-27 17:25 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 27847

> From: Dani Moncayo <dmoncayo@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-27 13:08 bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally) Dani Moncayo
  2017-07-27 17:25 ` Eli Zaretskii
@ 2017-07-27 18:00 ` Drew Adams
  1 sibling, 0 replies; 8+ messages in thread
From: Drew Adams @ 2017-07-27 18:00 UTC (permalink / raw)
  To: Dani Moncayo, 27847

> 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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-27 17:25 ` Eli Zaretskii
@ 2017-07-27 20:44   ` Dani Moncayo
  2017-07-28  2:44     ` Alexis
  2017-07-28  5:28     ` Nick Helm
  0 siblings, 2 replies; 8+ messages in thread
From: Dani Moncayo @ 2017-07-27 20:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27847

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-27 20:44   ` Dani Moncayo
@ 2017-07-28  2:44     ` Alexis
  2017-07-28  6:46       ` Eli Zaretskii
  2017-07-28  5:28     ` Nick Helm
  1 sibling, 1 reply; 8+ messages in thread
From: Alexis @ 2017-07-28  2:44 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 27847


Dani Moncayo <dmoncayo@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-27 20:44   ` Dani Moncayo
  2017-07-28  2:44     ` Alexis
@ 2017-07-28  5:28     ` Nick Helm
  1 sibling, 0 replies; 8+ messages in thread
From: Nick Helm @ 2017-07-28  5:28 UTC (permalink / raw)
  To: 27847

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.







^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-28  2:44     ` Alexis
@ 2017-07-28  6:46       ` Eli Zaretskii
  2017-07-28  8:07         ` Alexis
  0 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2017-07-28  6:46 UTC (permalink / raw)
  To: Alexis; +Cc: 27847

> From: Alexis <flexibeast@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 27847@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?





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally)
  2017-07-28  6:46       ` Eli Zaretskii
@ 2017-07-28  8:07         ` Alexis
  0 siblings, 0 replies; 8+ messages in thread
From: Alexis @ 2017-07-28  8:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 27847


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alexis <flexibeast@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 27847@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-07-28  8:07 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-27 13:08 bug#27847: 26.0.50; mode-line-percent-position: line-based instead of char-based (optionally) Dani Moncayo
2017-07-27 17:25 ` Eli Zaretskii
2017-07-27 20:44   ` Dani Moncayo
2017-07-28  2:44     ` Alexis
2017-07-28  6:46       ` Eli Zaretskii
2017-07-28  8:07         ` Alexis
2017-07-28  5:28     ` Nick Helm
2017-07-27 18:00 ` Drew Adams

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.