[RFC][PATCH] Improved synctex support

Pavel Sanda sanda at lyx.org
Thu Aug 11 12:05:46 UTC 2022


On Thu, Aug 11, 2022 at 12:37:50PM +0200, Stephan Witt wrote:
> >> 1)
> >> AFAICS the synctex activation is possible for more than pfdlatex output only. I???ve tried dvi, luatex and xetex and all of them work for me. So I???ve changed the check in BufferParams::writeLaTeX to use OutputParams::isLaTeX. Is someone to tell if this change is the right one? Perhaps it???s superfluous in BufferParams::writeLaTeX at all and one can output it w/o the check for the flavor here?
> > 
> > This is very long time ago and my memory might be failing, but I think the disctinction between srcltx vs synctex was there because srcltx was working for dvi.
> > So perhaps enabling synctex for luatex and xetex is a safer than testing that without srcltx dvi works on other platforms?
> 
> Hmm. I wanted to say to use a simple else instead on another if statement with the check for isLaTeX() or for pdflatex. The test for LaTeX with the srcltx if should remain. 
> 
> That would be:
> 
> 	if (output_sync) {
> 		if (!output_sync_macro.empty())
> 			os << from_utf8(output_sync_macro) +"\n";
> 		else if (features.runparams().flavor == Flavor::LaTeX)
> 			os << "\\usepackage[active]{srcltx}\n";
> 		else
> 			os << "\\synctex=-1\n";
> 	}

Sounds reasnoable to me.

> >> 2)
> >> The LFUN_FORWARD_SEARCH implementation relies on the correct check in getStatus. The patch adds the explicit check for presence of current buffer and active output_sync state. Regarding the latter I???m not sure if someone is unhappy with it. In case of preamble code to activate synctex the LFUN_FORWARD_SEARCH would work but LyX doesn???t know that and it???s disabled. What is your opinion here?
> > 
> > - I would naively expect that check for buffer is enforced by dispatch (unless NoBuffer flag for lfun is specified, which won't be in this case). But I might miss something.
> 
> You???re right. But there is the check for a valid buffer in many (most?) other cases and the comment in dispatch claims that getStatus checks it. So one should at least change the comment? :)

Dunno, I would need to carefully study the code to have real opinion about the necessity of buffer check there.

> > - It did not happen to me that I needed direct preamble editing for sync so it seems we are rather on the safe side to check output_sync state. On the other hand what is the drawback of allowing the lfun regardless of output_sync state?
> 
> The drawback for users is the missing visual feedback that w/o active output_sync state the forward search is not possible.

I see, we can try. I do not expect that ppl are using fwd search via preamble...
Pavel


More information about the lyx-devel mailing list