> From: Stefan Monnier <address@hidden> > Date: Sun, 18 Mar 2018 21:33:05 -0400 > > >> If lsp-mode/lsp-ui needs a fast line counter, one can easily be > >> provided by exposing find_newline to Lisp. IME, it's lightning-fast, > >> and should run circles around count-lines (used by line-number-at-pos). > > Having a fast line counter in Elisp would be terrific. > > It should be pretty easy to provide such a thing by relying on a cache > of the last call. This is already coded, see display_count_lines. That's what the native line-number display uses. Exposing it to Lisp should be easy. But I don't believe it could be orders of magnitude faster than count-lines, even though it doesn't need to convert character position to byte position. I'm guessing something entirely different and unrelated to line-counting per se is at work here. > Tho Sebastian's experience seems to indicate that the > current code doesn't only suffer from the time to count LF but also from > the time to process the markers. Not sure what marker processing did you have in mind. Can you elaborate? > I seem to remember someone else experiencing a similar problem and > suggesting that the problem lies in the charpos_to_bytepos (and/or > bytepos_to_charpos) conversion function, which iterates through all the > markers to try and find a "nearby" marker (because markers keep track > of both their bytepos and their charpos). Looking for a nearby marker > to avoid scanning the whole buffer is a good idea in many cases, but not > if scanning the list of markers takes more time than scanning the > whole buffer. But find_newline doesn't look for markers, and it converts character to byte position just 2 times. Or am I missing something?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4