Forum moved here!

Home / Latex integration with jEdit

Moti_Ben-Ari

Hello, I want to use Sumatra to view pdflatex output from within the jEdit editor. I managed to call Sumatra from the editor and I want to use forward and inverse sync. The documentation says to use DDE, but apparently jEdit doesn’t support it. Is there any other way? Thanks, Moti

kjk

http://william.famille-blum.org/blog/static.php?page=static081010-000413 describes how to use -inverse-search cmd-line argument.

Moti_Ben-Ari

Thanks, Krzysztof.

I see that I don’t have to use DDE, just to set the inverse search command. However, that webpage says to set command at ‘File\Set inverse search command line’, whereas I found that it has moved to ‘Settings\Options’.

Moti_Ben-Ari

Me again …
The inverse search command is not saved when I exit Sumatra.
When I invoke Sumatra again from the editor,
the inverse search command is replace with the name of the file.
An additional tab is opened with a number like 460 and
an error message that it could not open the file.

What parameters should I add to
“C:\Program Files\SumatraPDF\SumatraPDF.exe”
if the editor doesn’t support DDE?

GitHubRulesOK

-inverse-search should only be used ONCE to set up the association
only a portable user or person switching from editor to editor would need to call it again and again

Your editor is not one I am familiar with but the return (inverse) path needs to be exactly the same as if called manually. I note from Tex stackexchange it states SyncTeX : NO

IF that is true you have a problem since the key to forward & inverse search is the use by the editor of a synctex file. I see no reason why an editor with latex tools could not generate a synctex file since it is the tex distro that preps the file. so it may be the lack of a valid CLI response mechanism that would stop it from accepting an inverse search.
however checking online it looks like the call would look like

jedit "%f" +line:%l

note the last character is lowercase L
so whatever would open the editor at a given page
say c:\program path\jedit filenametoken pagenumbertoken
is the inverse-search command that should be stored in the settings.txt file ONCE
One thing to note is that java based editors on windows are often driven by jars called from javaw.exe which makes them unwieldy beasts to pass commands to

these are my old notes for testing several editors a year or two back ( but jedit was not tested) it may help to skim read the differences.

There are sample test files linked at bottom of page 2 to try out with known behaviours

Moti_Ben-Ari

Thanks. I got the inverse search to work by editing settings.txt.

I also asked about the forward search:
What parameters should I add to
“C:\Program Files\SumatraPDF\SumatraPDF.exe”
in the editor if the editor doesn’t support DDE?
SumatraPDF opens the correct file,
but I want it to go to the current line in the editor.

GitHubRulesOK

@Moti_Ben-Ari
Always pleased to hear how it works. What was your final working inverse command ?

The editors generally have tokens for the filenames so it varies from one to the other but preview commands generally follow the patern

"path to \sumatraPDF.exe" -forward-search "path to Current.tex" LinenumberToken "path to \compiled.pdf"

but its down to how the latextools will structure it that way

If you have downloaded the sample files even without latex you can test SumatraPDF is working for Forward Search
First I always suggest editing Settings > Advanced Options to change the false to true as here

ForwardSearch [
	HighlightOffset = 0
	HighlightWidth = 15
	HighlightColor = #6581ff
	HighlightPermanent = true
]

Permanent is NOT permanent in the PDF it means highlight on screen until another command is received. Save that setting with CTRL S

Now in the folder with sync.pdf sync.synctex and sync.tex
open Sync.tex in notepad and note that Hello World is on line 9

Unfortunately without some scripting Microsoft Notepad cant run a command for you but you can run manually from a command prompt

"C:\Program Files\SumatraPDF\SumatraPDF.exe" -forward-search sync.tex 9 sync.pdf

and bingo that line will light up proving the files and command are valid

Now the trick is how does your editor pass the current line number to SumatraPDF with those file names

Try any odd number 11 13 … 21 23 and most will work as expected
try 17, 19, and you should note they don’t both go where you might expect. With 24 or 25 you should see a thin blue line near the top of the page, again not what may be expected.

RULES
Don’t try to be clever the editor should tell pdfLaTeX to put the .synctex and .pdf in the same folder as the current.tex file, sub folders may work for a time but with other more complex calls later you WILL hit time-consuming problems. Avoid remote folders such as cloud or network drives.
The synctex and pdf should have similar timestamps, That is a .synctex file is only valid for the compiled.pdf generated at the same time. If the times differ suspect one of the two is not valid.
If all is well only one copy of SumatraPDF should open with the same file compiled in turn.
If a second SumatraPDF window opens on each compile then first check that ReuseInstance = true in the settings file (this ensures that when NOT using tabs then the legacy action previously provided by -reuse-instance is in force) It is generally not needed if Use Tabs is active but its easier to play safe…

Note that new pre-release allows you to have multiple windows with the same compiled PDF file I have not tested since then however it is generally only the first window that will update on forward search but you may find a double click in either will perform an inverse search :slight_smile: and pressing R after selecting the second copy would reload if it did not refresh.

Moti_Ben-Ari

Sorry for not replying sooner.
I haven’t been able to get a response from the jEdit mailing list,
so I’m leaving it for now.
If anyone ever gets around to working with that editor,
I would appreciate any advice.

GitHubRulesOK

@Moti_Ben-Ari
If Sumatra is working well with the return call to the line in your compiled files or the sample ?
Then certainly the remaining issue is with either how jEdit OR any LaTeX tools type enabler/add-in is configured to call SumatraPDF straight after a recompile.
Sometimes you can find online a similar configuration e.g. for calling any other viewer such as Evince Ocular or even Acrobat if so then it may be simple to change such settings to call SumatraPDF