> From: Sebastian Sturm <address@hidden> > Date: Fri, 23 Mar 2018 11:15:48 +0100 > > > Also, what about my suggestion to count lines in a relative manner, > > using count-lines from a line with a known number? You never replied > > to that suggestion. > > you're right, sorry. In my opinion, a caching mechanism might be a very > useful thing to have if it provides further performance benefits on top > of what the noverlay branch has to offer. However, since count-lines may > not be the only function that has to convert between char and byte > positions (or is it?), and since the noverlay branch seems to resolve > the overlay issue without having to introduce additional complexity in > the elisp layer, implementing a caching mechanism before noverlay is > merged into the master branch seems like a premature optimization to me. It isn't premature optimization, because a buffer could have many markers even if it has no or only a few overlays. > Of course this is a layman's opinion (and maybe the case of "few > overlays but many markers" is not as pathological as it appears to me); > if you think a line number cache should be implemented, I'll go and > discuss that with the lsp-mode maintainers (assuming that they are among > the heaviest users of line-number-at-pos). I think the effect should be at least measured before the decision whether to do that is made.
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