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

Previous Next

Package: emacs;

Reported by: Dani Moncayo <dmoncayo <at> gmail.com>

Date: Thu, 27 Jul 2017 13:09:01 UTC

Severity: wishlist

Found in version 26.0.50

Full log


View this message in rfc822 format

From: Nick Helm <nick <at> tenpoint.co.nz>
To: 27847 <at> debbugs.gnu.org
Subject: 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.






This bug report was last modified 7 years and 323 days ago.

Previous Next


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