Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SyncTeX binary precedence over synctex.js? #4186

Closed
James-Yu opened this issue Mar 2, 2024 · 2 comments
Closed

SyncTeX binary precedence over synctex.js? #4186

James-Yu opened this issue Mar 2, 2024 · 2 comments
Labels
dev Development discussions

Comments

@James-Yu
Copy link
Owner

James-Yu commented Mar 2, 2024

[Internal Discussion]

As per #4181 (comment) and #4168, I did not find the column-locating code for synctexjs we have been using. I also backtrace a few years code in the past and did not find that. Strangely both you @jlelong and I seem to have an impression on the feature.

I also checked (roughly) the code on invoking SyncTeX binary and figured that the binary indeed returns with a column index:

if (key === 'line' || key === 'column') {
record[key] = Number(value)
continue
}

instead of the 0-column of synctexjs:
return input ? { input, line: record.line, column: 0 } : undefined

But now we have latex-workshop.synctex.synctexjs.enabled defaults to true:

LaTeX-Workshop/package.json

Lines 1682 to 1687 in 6c63cc3

"latex-workshop.synctex.synctexjs.enabled": {
"scope": "window",
"type": "boolean",
"default": true,
"markdownDescription": "Enable using a builtin synctex function. The command set in latex-workshop.synctex.path will not be used."
},

What about we return to first try the binary, if anything went wrong (not found, non-zero return), we fallback to the javascript implementation to balance the utility and availability? We may also remove this config if so, or change the purpose of it to be overriding this new logic. May I� have your thoughts? @jlelong

@James-Yu James-Yu added the dev Development discussions label Mar 2, 2024
@jlelong
Copy link
Collaborator

jlelong commented Mar 2, 2024

I have good news: we are not crazy yet! I have managed to trace back to the column-locating code. It was introduced in #1161. It is still alive

function getRowAndColumn(doc: vscode.TextDocument, row: number, textBeforeSelectionFull: string, textAfterSelectionFull: string) {
let tempCol = getColumnBySurroundingText(doc.lineAt(row).text, textBeforeSelectionFull, textAfterSelectionFull)
if (tempCol !== null) {
return [row, tempCol]
}
if (row - 1 >= 0) {
tempCol = getColumnBySurroundingText(doc.lineAt(row - 1).text, textBeforeSelectionFull, textAfterSelectionFull)
if (tempCol !== null) {
return [row - 1, tempCol]
}
}
if (row + 1 < doc.lineCount) {
tempCol = getColumnBySurroundingText(doc.lineAt(row + 1).text, textBeforeSelectionFull, textAfterSelectionFull)
if (tempCol !== null) {
return [row + 1, tempCol]
}
}
return [row, 0]
}

Ctrl-clicking inside the pdf calls

void lw.locate.synctex.toTeX(data, uri.fsPath)

If I understand correctly, synctex does provide a column number but it can be quite inaccurate. The function getRowAndColumn tries to fix it.

@James-Yu
Copy link
Owner Author

James-Yu commented Mar 2, 2024

Thats awesome! I will look into the implementation c.f. #4181 #4168

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
dev Development discussions
Projects
None yet
Development

No branches or pull requests

2 participants