[NTG-context] Re: Most recent context doesn't like synctex?

15 Apr 2024

      Hi Mikael (and other synctex users),

On Sat, Apr 13, 2024 at 22:28 (+0200), Mikael Sundqvist wrote:
...
Hi,
...
On Sat, Apr 13, 2024 at 7:54 PM Jim  wrote:
...
...
Thanks for the quick reply.
...
...
On Sat, Apr 13, 2024 at 09:18 (+0200), Hans Hagen wrote:
...
...
...
On 4/13/2024 12:39 AM, Jim wrote:
...
Hi,
...
...
...
...
I have both TeXlive 2024 and the stand-alone ConTeXt distribution on my
system.
...
...
...
...
Recently, the stand-alone ConTeXt distribution seems to not create a
synctex file any more.  Specifically,
...
...
...
...
/usr/local/context/tex/texmf-linux-64/bin/context --once --texutil --synctex=1 --nonstop file.tex
...
...
...
...
does not create a .synctex file (and deletes it, if it is there), whereas
the TeXlive version
...
...
...
...
/usr/local/texlive/2024/bin/x86_64-linux/context --once --texutil --synctex=1 --nonstop nwg_newsletter_2024_04.tex
...
...
...
...
does create the .synctex file.
...
...
...
...
The ConTeXt distribution version *does* create the file if --nonstop is
*not* used.  Knowing that, I can work around this for now, although
emacs+auctex probably won't be happy without --nonstop.
...
...
...
...
I updated the stand-alone ConTeXt a few minutes ago, so I'm up to date on
that.
...
...
...
...
Is this a bug introduced by some recent change?
...
...
...
it's more a feature
...
...
I guess one person's bug is another person's feature.  :-)
...
...
...
- Mikael S and i spend some time with editor/viewer combinations on linux in
order to find ways around the different synctex libs that they use
...
...
...
- as a result we could make most work ok
...
...
Are these recent changes?  And should emacs+auctex+PDFview work now?
...
What will work will depend on the viewers.  We noticed a few weeks ago
that synctex (pdf -> editor) was not working in a few viewers (okular)
while it was working in others.  After some debugging, our conclusion
was that different versions of the library/application were used, or
different approaches.  We found a way to generate the stuff in the pdf
to make it work for the failing viewers we had.  Hans did then not
replace this with the old approach, since then the previously working
viewers might break.  He therefore added repeat as a key, so
\setupsynctex[state=repeat] will use the new approach.
Thanks for that clarification.
...
...
...
- we assume that synctex is set up in the document with
...
...
...
\setupsynctex[state=start]
    \setupsynctex[state=repeat] % less efficient but gets around issue
...
...
I haven't been using either of those, since auctex does The Right Thing for
me.  Or, at least, it used to.
...
...
...
- when context is run 'headless' (on a server) it's often done in
batchmode because one knows that the style works and in that case synctex
makes no sense so we disable it; this avoids the need to patch the style
...
...
I (think I) see what you are saying, but if one explicitly uses --synctex
on the command line, should that not over-ride the over-ride?  Or, put
another way, would the following not make sense:
if --synctex is used on the command line
create synctex file
else if --nonstop is used on the command line
do not create the synctex file
else if \setupsynctex[...] is used in the source file
create the synctex file
else
do not create the synctex file
...
...
...
- the manual has been updates
...
workflows-synctex.tex now suggests:
...
"When your viewer doesn't return to the editor, you can try
...
\starttyping
\setupsynctex[state=repeat]
\stoptyping
...
or
...
\starttyping
context --synctex=repeat somefile.tex
\stoptyping
...
This will give a bit larger file that tries to fool the areas resolver in the
library that the viewer uses."
Looking at two synctex files, it would seem that the state=repeat version
creates a synctex file that has syntax matching the "original" synctex
format.  And you are right, the file is bigger.

In any case, now that I know what is going on, I have convinced auctex to
play nicely with the new way of doing things, and so all is now good.

Question for anyone who made it down this far:
Is there a mailing list or other way that a ConTeXt user can find out about
non-backward-compatible changes like this?  I wasted a fair amount of time
tracking this problem down (*), and if there is some other mailing list I
should be subscribed to, I'd love to know about it.

(*) Unfortunately, this change to ConTeXt happened around the same time I
upgraded emacs from 27.2 to 29.3, and when things didn't work I upgraded
auctex from 13.<n> to 14.0.4, and it took me a while to find out where the
problem originated.

Cheers.

                                Jim