bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#27847: 26.0.50; mode-line-percent-position: line-based instead of ch


From: Nick Helm
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (darwin)

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.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]