bug#22763: 25.1.50; Feature Request -- A faster method to obtain line number at position.

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  22763@debbugs.gnu.org,  esq@lawlist.com
>> Date: Sun, 07 Feb 2021 21:42:30 +0100
>> 
>> Why does display_count_lines (with no cache) exist, then?
>
> It exists to support the line-number display on the mode line.  That
> display has its own cache, as part of the window object, so
> display_count_lines very rarely needs to count from the beginning of
> the buffer, it usually counts from the last place it stopped the
> previous time for the same window.  This is why it has the signature
> that it has.

But these are the signatures:

ptrdiff_t
find_newline (ptrdiff_t start, ptrdiff_t start_byte, ptrdiff_t end,
              ptrdiff_t end_byte, ptrdiff_t count, ptrdiff_t *counted,
              ptrdiff_t *bytepos, bool allow_quit)


static ptrdiff_t
display_count_lines (ptrdiff_t start_byte,
                     ptrdiff_t limit_byte, ptrdiff_t count,
                     ptrdiff_t *byte_pos_ptr)

So they seem very similar...

Anyway, here's something that just occurred to me: It's still the plan
to have so-long-mode on by default, right?  Which means that
'buffer-line-statistics' will be called when opening a file, which means
that we know whether there are any long lines in the buffer.

Could we use this info to switch between cached and non-cached action
for find_newline?  (I.e., just set 'cache-long-scans'.)

Conversely, could we use find_newline to trigger so-long-mode?  Today,
so-long-mode isn't able to step into the fray when something plops a
long line into the buffer (in shell-mode, for instance).  If
find_newline finds a long line, it could switch 'cache-long-scans' on,
and also (on perhaps a different threshold) notify so-long-mode?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no