SyncTex (or pdfsync) and lhs2TeX

[conal]

Is there a way to use SyncTex (or pdfsync) with lhs2TeX to get mapped back from a PDF previewer to a .lhs file rather than to the .tex file that lhs2TeX generates?

[kosmikus]

I've never used these systems, but if it was reasonably easy, I would be happy to add extra info to the generated file. Is there any good documentation available on what lhs2tex would have to support for this to work?

[GitHubRulesOK]

Synctex is at its most basic a set of pointers so in the line editor aan indexed reference is placed in a mini database (the syctex file) it describes the location of that text in the PDF say line one of Haskell will become placed on page 3 of the PDF it is a sycronise TeX thang I see no way lhs2tex can guestimate howmuch title pages or other inserts will be wrapped around its output You would need to build an LHS editor plus pdf output system to beable to controle the relationship Oh yes forgot to say need to call it something like LhTeX

[kosmikus]

If there's no support for handling preprocessors in some way like e.g. Haskell and C support via LINE pragmas, then the only other way I could see is to try to implement a similar construction as synctex between the lhs2TeX source and target files. Certainly, lhs2TeX itself can add info to the generated file (in the form of TeX comments) as to which original position each element is coming from. Then that info could be combined with the synctex info to provide a mapping between the lhs2TeX sources and the target pdf. It doesn't sound trivial though.

[GitHubRulesOK]

With dozens of visual editors between the \includes \imports \ etc. it would certainly not be trivial and possibly low value/usage since the whole aim of the conversion is to "PRE"-process such that the lines are in rational order (thus agree that part is possibly easy) however each editor then needs to remap the reverse call i.e click on page 3 as at present goes to line 65 of editor then goes to line 2 of Lhs inputs.

In short it is down to the user editor applications to marshal the corresponding mapping in both directions. The only viable alternative is to have a PDF editor that controls backwards to latex (and then Lhs) and AFAIK no PDF editor can do that the nearest WYSIWYM are lyx and bakoma both of which fail generally to manage their own TeX import/export well.

Positively the potential editors that may be able to manage the volume of interest are the more commercial teams such as Madoko or Overleaf so it could be worth approaching either of them for the two way management of indexing Lhs line to TeX line to PDF line (or to Html etc.)

[conal]

@kosmikus Having lhs2TeX generate something like LINE pragmas in the generated LaTeX code is exactly what I was thinking as well. I haven't yet found such a mechanism. I'll keep looking.

[conal]

I just skimmed through the paper Direct and reverse synchronization with SyncTEX. Section 5.2 seems to describe the general problem of preprocessors such as lhs2TeX and suggests adding this ability to SyncTEX, so I gather there wasn't a mechanism to handle them at the time of writing (2008).

[GitHubRulesOK]

@conal
Hi section 5.2 is describing all the problems with the auxiliary support file generated by the processor not to mention "pre-processor" however you are right it is at that point the control is gained and more often lost by many tex editors. What usually happens is the inverse search works well from the pdf viewer to the target character in the main.tex assembly but is often not redirected back down to the includes such as lhs or other imports, so many editors do not open the subfile and highlight its line simple stopping and pointing at the location the sub file is included. The sync file is generated by the editor call to pdfLaTeX and even with the same engine (say MiKTeX) you would expect the synctex file for identically visual appearing pdfs generated by two editors to be the same, unfortunately that's not always the case. Equally a good synctex generated alongside a single pdf should appear to go back to the same source in different editors, again unfortunately it does not always happen that way.

The principle is good but with hundreds (nay thousands of user mods) of editor configurations some are more equal than others.

[conal]

@kosmikus: I see how things can get difficult with includes etc. My current wish is something like a LINE pragma that lhs2TeX could sprinkle into the generated .tex and that SyncTeX would incorporate in its .syntex.gz, even without handling includes. On the other hand, were I to have that much convenience, I might just want more.

[GitHubRulesOK]

@conal @kosmikus
Whilst testing some synctex in most recent Lyx for windows I was impressed that it seems to be coping fairly well with some basic tests, Since it is using its own file format to create the pdf It must be reindexing those line number from the tex line number.
As an example line 4 on screen becomes line 10 in tex and synctex then line 4 in pdf.
SO if the input was lhs it would presumably be able to do similar.
It may thus be worth approaching Lyx for what may be done to call the lhs up on screen.