Hi, I have implemented a passable solution to more accurate forward search that should be better in most of normal usage, no worse than the current situation in the majority of rest but worse than the current in some rare situations.
Please see https://github.com/aikrahguzar/pdf-tools/commit/e25ae22a93283e61eaf14c9fce614cd571a3f6b3 if anyone is interested in trying it out and let me know how it fares. See also https://github.com/vedang/pdf-tools/issues/244#issuecomment-1817646093 Rahguzar Rahguzar <rahgu...@zohomail.eu> writes: > Hi, > I have been looking to improve the synctex experience with `pdf-tools` > and `auctex` especially with my preferred way of writing every paragraph > on one line and using `visual-line-mode` for reflowing the text. Fixing > backward search turned out not to be too difficult see > https://github.com/vedang/pdf-tools/issues/242 but it seems like making > forward text search more accurate is harder. > > Basically the situation seems to be that although synctex is > theoretically capable to providing an accurate column number, it needs > tex engines to provide this information which none of them do. So it > only provides line level information. However a given source line can > correspond to multiple lines in pdf (and vice versa) and I in that case > synctex provides multiple results about the query asking editors to > somehow chose the best one. > > However `pdf-tools` only gives access to first result of synctex forward > search. I don't know `c` but I think that is happening here, > https://github.com/vedang/pdf-tools/blob/c69e7656a4678fe25afbd29f3503dd19ee7f9896/server/epdfinfo.c#L3188C21-L3188C21 > This seems to correspond to only to a single or occasionally two pdf > lines corresponding to the same source line but not all of the lines. Is > someone who knows `c` and wants better forward search willing to either: > > 1) Change `cmd_synctex_forward_search` in `epdfinfo.c` so that it > returns the edges corresponding to the bounding box of the whole region > of pdf corresponding to the source line? My guess is (I am not sure) > that this would simply be the union of all the rectangles in individual > search results. Some care would be need when the paragraph get split > across pages. > > 2) Probably easier and backward compatible. Add a new function to > `epdfinfo.c` that returns the whole list of search results and expose > that to lisp so that the region can be determined from lisp. > > With this change in `c` code, I think I can use techniques similar to > those used for backward search and those in `pdf-isearch` for > highlighting to get word level accuracy. But without a good bound on the > pdf region to search, it is hard to get good enough performance. > > I have also posted the same message on pdf-tools repo: > https://github.com/vedang/pdf-tools/issues/244 > > Thanks, > Rahguzar
