Most recent context doesn't like synctex?
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? Thanks. Jim
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
- 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 - we assume that synctex is set up in the document with \setupsynctex[state=start] \setupsynctex[state=repeat] % less efficient but gets around issue - 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 - the manual has been updates - running context in nonstop mode makes little sense (maybe, as power user, Mikael remembers more details) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
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?
- 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
Ummm... I hunted around for a while, but I did not find out which manual was updated. The synctex wiki page has not been updated, nor has the "workflow support in context" manual. Can you tell me which manual I should go look at?
- running context in nonstop mode makes little sense
Guessing wildly, I assume the auctex author(s) didn't want processes sitting there waiting for input on errors, like plain TeX would normally do. But perhaps the addition of --nonstopmode for ConTeXt is incorrect and/or redundant in April of 2024.
(maybe, as power user, Mikael remembers more details)
Mikael? Any thoughts to share? Cheers. Jim
Hi,
On Sat, Apr 13, 2024 at 7:54 PM Jim
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.
- 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." /Mikael
Am 13.04.24 um 22:28 schrieb Mikael Sundqvist:
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.
Could you please tell us which combinations of viewers and editors you checked and how to configure them to make it work? Hraban
Hraban and any emacs users: On Sun, Apr 14, 2024 at 11:56 (+0200), Henning Hraban Ramm wrote:
Am 13.04.24 um 22:28 schrieb Mikael Sundqvist:
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.
Could you please tell us which combinations of viewers and editors you checked and how to configure them to make it work?
The --synctex=repeat option outputs a synctex file that works with auctex' epdfinfo program, so (at least when using PDFview) forward and backward search now work with emacs+auctex, at least when you (a) put (setq ConTeXt-texexec-option-nonstop "") in your ConTeXt mode hook (or some other sensible place), and (b) edit the ConTeXt-expand-options defun in auctex' context.el (or redefine the function in some hook) to replace --synctex=1 with --synctex=repeat I have submitted a bug report to auctex about (b) and another item, but I have no idea if/when the fixes will make it into a new release of auctex. Jim
Hi,
On Sun, Apr 14, 2024 at 12:00 PM Henning Hraban Ramm
Am 13.04.24 um 22:28 schrieb Mikael Sundqvist:
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.
Could you please tell us which combinations of viewers and editors you checked and how to configure them to make it work?
I think you shall test them according to what they specify, that should work. I think at Hans' place sumatra worked already with state=start. Here we tried zathura, okular, they work. I think evince did not really work (maybe with some dbus thing, but we did not really try it out). For qpdfview, mupdf, sioyek and maybe some more I do not remember if it worked in the end. But also the viewers change, so at your place they might have different versions of the libraries, and ... a bit messy. I think one should try state=start, and if that is not working, try state=repeat. If that is not working either, I don't know. It was not so easy to understand the format and how it is supposed to work. /Mikael
I made it work with Pulsar and the pdfjs-viewer plugin: The sourcecode of the plugin is broken but easily fixable: https://github.com/allefeld/atom-pdfjs-viewer/issues/15 Then pdf->tex works with synctex from TeX live, "--synctex=repeat" and a right click in the viewer. Sigh, should I learn TypeScript to adopt the viewer plugin and enable my language-context-lmtx* plugin to run ConTeXt and SyncTeX? (I’ve already too many projects and not enough brain capacity.) Hraban *) https://codeberg.org/fiee/language-context-lmtx
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
participants (4)
-
Hans Hagen
-
Henning Hraban Ramm
-
Jim
-
Mikael Sundqvist