Henning and Hans, thanks for the replies. I have two follow-up questions below, as well as some other comments which other synctex users might find useful. On Sun, Nov 12, 2023 at 10:26 (+0100), Henning Hraban Ramm wrote:

Am 12.11.23 um 00:59 schrieb Jim:

...

Hi,

...

I've read the wiki, looked at workflows-synctex.tex, searched the web, and scratched my head, all to no avail. So here I am, cap in hand...

...

When I run context, I get a .synctex file which has some information in it, but I can't find any invocation of synctex to return anything useful. Nor does the okular example in the wiki (https://wiki.contextgarden.net/SyncTeX) work for me. Ocular starts, but always on the first page, regardless of what line number I give it.

...

On the other hand, pdftex creates a .synctex file which my copy of synctex find useful.

...

I am using the synctex from the current version of texlive: This is SyncTeX command line utility, version 1.5

...

Can anyone either (a) enlighten me on what I am doing wrong; or (b) definitively confirm that context is not currently playing nicely with synctex (the wiki notwithstanding) and I should give up this quest for now.

ConTeXt doesn’t work with the synctex binary, but with mtxrun --script synctex

Thanks for that pointer. Q1: Should that be in the wiki (https://wiki.contextgarden.net/SyncTeX) somewhere? When I try that out, for example with mtxrun --script synctex --edit --name=a.tex --line=222 a.tex I am rewarded with sandbox | variable 'linenumber' has no checker (I tried various variations on that line I won't bore you with, but I keep getting that error message.) I also tried mtxrun --script synctex --goto --page=4 --x=100 --y=100 a.synctex and that silently returns without apparently doing anything. (While I don't have a 'scite' editor, I created a program called 'scite' that pops a message up on the screen if it is called.) Similar to --edit, mtxrun --script synctex --goto --page=19 --x=400 --y=180 --tolerance=99 --editor=scite a.synctex complains sandbox | variable 'tolerance' has no checker Although I don't know lua, the code is easy enough to read, but a short dive in to mtx-synctex.lua did not enlighten me. Q2: any enlightening comments on why I am getting these complaints. In any case, --find and --report (appear to) give meaningful results, so I can work with those.

Unfortunately, it’s not a drop-in replacement, so it doesn’t work with most editors. (I was thinking about a translating wrapper script, but didn’t do anything yet.)

So much code to write, so little time ... :-) My immediate concern is forward search (i.e., editor tells viewer which page to display) and that one should be easy for me to create a wrapper. (I use emacs + auctex, which calls the synctex program, so writing my own synctex wrapper looks easy. Hopefully I won't regret using the word "easy" later.)

AFAIK TeXshop (MacOS) is the only TeX editor that supports ConTeXt’s workflow.

I've been thinking of patching some of evince's more annoying features, if I do, maybe I should look into making it work with context.

ConTeXt’s synctex format is much simpler than the “standard” LaTeX one and should be at least as good, but alas it needs support from the editors.

Indeed! On Sun, Nov 12, 2023 at 12:00 (+0100), Hans Hagen wrote:

On 11/12/2023 10:26 AM, Henning Hraban Ramm wrote:

...

Am 12.11.23 um 00:59 schrieb Jim:

...

Hi,

...

...

<second copy of my text elided>

...

ConTeXt doesn’t work with the synctex binary, but with mtxrun --script synctex

afaik there is no binary ... there is a library that has to be compiled into a pdf viewer that intercept some 'goto the text file' command and then launches an editor (afik the library has some heuristics build in wrt boxes and nesting and so); at the tex end there is also a library that kicks in addiional code for nodes and the backend (which is why enabling synctex will have an impact on runtime)

wrt the synctex file, that one is generated by context (so we don't use the synctex code in luatex and as luametatex has no backend there it's even completely absent ... context generates the file itself which is also a bit more efficient)

...

Unfortunately, it’s not a drop-in replacement, so it doesn’t work with most editors. (I was thinking about a translating wrapper script, but didn’t do anything yet.)

...

AFAIK TeXshop (MacOS) is the only TeX editor that supports ConTeXt’s workflow.

indeed texshop uses the approach that avoids the library and just calls mtxrun to figure out the file/line that relates to the position; this is more reliable because there is no need to recompile a viewer when synctex updates

I just looked at the code of evince, and there is a fair bit of code there to parse synctex files. The virtue of just calling mtxrun is clear to me.

you can run

mtxrun --script synctex

on the synctex file and check what areas are there

...

ConTeXt’s synctex format is much simpler than the “standard” LaTeX one and should be at least as good, but alas it needs support from the editors.

simpler in the sense that we only output what is needed for the synchronization to work reliable; fwiw, my collegue already for many years uses context with synctex enabled with sumatra pdf in pretty complex setups: a mix of tex and xml files with deeply nested inputs and it works ok (so we also get to the right spot in an (included) xml file)

for synctex to work one has to call context with --synctex or put a directive on the topline of the file. Otherwise you won't get the right jobname. Of course it then still depends on the pdf viewer + lib used if things work out as expected.

there isn't much we can do about the viewer part unless tit is not locked into the binary but as flexible like the texshop viewer is

Thanks for your comments as well. It seems evince has a compile-time option to either build its own internal synctex or to use an external one. With the latter and a wrapper script (or maybe even an option to evince to use some alternate program to get synctex info) it might not be too hard (*cough*) to get evince to play nicely with context. Cheers. Jim