Forum moved here!

Home / Inverse seach with synctex: find word

jcfaria

I have been using reverse search - for file and line - successfully in the editor I use. This is the information I add to: main menu/Settings/Options

C:\Tinn-R\bin\Tinn_R.exe “%f;%l”

In addition to the file and line, is it possible to also find the word in the reverse search? How is it possible?

Best,
J.C.Faria

GitHubRulesOK

short answer is NO
There was an attempt to define character position “%c” along the line but was never working/developed and left at a high default value. (Syctex primarily works on blocks of text, hence sometimes does not “highlight” the expected line)

The Synctex standard has since been expanded to include word “hinting” which some editors had developed either independently or now incorporate and thus use. I see Tinn_R only very recently documented the long time pdf syncing so wonder which format they historically use.

They also include stable 2016 SumatraPDF.exe 3.1.2 in their repo and the latest daily SumatraPDF still uses the same legacy methodology since “if it works don’t fix it”.

The prime (only) current developer is not a LaTeX user, so development would need to be done by someone who understands the many ways that Synctex word search might fail.

jcfaria

OK, I appreciate the information. Having the reverse search working well for file and line in Sumatra is already very useful for my work.

The Tinn-R development team (I am the project leader and main developer) had developed (several years ago) the reverse search engine for “.dvi” files. As there was never any demand for “.pdf”, I had not tested it. Whenever I needed, I used “.dvi”. I recently started a big work (a book) and decided to compile it directly to “.pdf”. The reverse search was needed and I decided to implement it for “.pdf” files as well. To my surprise, the same mechanism made for “.dvi” files worked perfectly for “.pdf” files in Sumatra without any adaptation. This is very rare in programming! :slight_smile:

GitHubRulesOK

Yes I think Laurens had ironed out many bugs on Mac before it was ported to WiNix usage and there was dedicated development 2005 in SumatraPDF by William Blum

As a LaTeX BOOK writer you may find there is a file locking barrier around 10MB which was raised to 32MB in more recent Dailys (cant remember if it was upped in 32bit pre-release)
However several font related features used by LaTeX users have regressed in recent versions due to other third party libs. So its worth keeping both to hand as portables for switch between.
Also if using \include (e)PS via GhostScript there is a problem calling latest GS 9.54 so need to point SumatraPDF to a 9.53.3 version (not easy if 9.54 is installed since SumatraPDF looks into the registry)

jcfaria

Sumatra is all I need as a PDF viewer. Keep up the good work!