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

[Jim <zlists+context@jdvb.ca>]

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 <zlists+context@jdvb.ca> 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

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki     : https://wiki.contextgarden.net
___________________________________________________________________________________