Re: [NTG-context] future versions - synctex
On 8/21/2018 4:46 PM, Aditya Mahajan wrote:
Are the x and y values in pts (post script points or big points?)
measured from the top-left corner?
afaik bottom up base points
the script will look into the synctex file and figure out where to go
to. Basically all the viewer needs to do is react to a
click/cursor/key combination and call mtxrun with the page and
positions (basepoints in pdf coordinate space)
How do I configure the editor command, e.g., with VIM, mtxrun will need
to call:
`vim --servername=VIM --remote +{line_number} {filename}`
What should be the value of `editor` in this case?
vim
but we can of course make that configureable (easy in lua) .. see
mtx-synctex.lua
-
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] future versions - synctex
On Tue, 21 Aug 2018, Hans Hagen wrote:
On 8/21/2018 3:04 PM, Aditya Mahajan wrote:
On Tue, 21 Aug 2018, Hans Hagen wrote:
Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex),
namely when user "tunes" the docs to their final stage, would be great.
I think that the current approach to hard code synctex libraries into a
viewer is a limitation (instead an editor should call an external program
with the page and coordinates so that an external program can then look at
the synctex file and decide where to go in the editor. That way more
sophisticated support is possible than the now hard coded heuristics. Keep
in mind that these heuristics are tuned for latex and from context we
generate the real minimal amount of synctex code that works without
clashing with these heuristics. If that were not that case is would be
unuseable.
Anyhow, there's only so much i can do about it (i'm not going to patch
viewers). Currently synctex is mostly working for decent structured source
(can be multiple files).
Which of the existing viewers have this functionality? Last time I tried
using synctex on linux, almost all viewers gave an error that they could
not parse synctex file.
I think that is because the format of the synctex file changed.
Is there some documentation on what is the format of the synctex file
written by ConTeXt and how the external program should be called with page
and coordinates? With that we can try to raise an issue asking the pdf
viewers to support that.
context outputs a bare minimum of synctex info: basically it identifies text
and marks that, so we don't need the whole nested box mess that can confuse
the parser (think of boxes that lap or are moved or lie about dimensions)
is you have a context synctex file you only see a few levels (basically words
/ lines) marked
There is a script:
mtxrun --script synctex
basically all an editor has to do is call:
mtxrun --script synctex
--page=123 --x=400 --y=500
--editor=scite
foo.synctex
Are the x and y values in pts (post script points or big points?)
measured from the top-left corner?
the script will look into the synctex file and figure out where to go to.
Basically all the viewer needs to do is react to a click/cursor/key
combination and call mtxrun with the page and positions (basepoints in
pdf coordinate space)
How do I configure the editor command, e.g., with VIM, mtxrun will need to
call:
`vim --servername=VIM --remote +{line_number} {filename}`
What should be the value of `editor` in this case?
Aditya
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] future versions - synctex
On 8/21/2018 3:04 PM, Aditya Mahajan wrote: On Tue, 21 Aug 2018, Hans Hagen wrote: Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user "tunes" the docs to their final stage, would be great. I think that the current approach to hard code synctex libraries into a viewer is a limitation (instead an editor should call an external program with the page and coordinates so that an external program can then look at the synctex file and decide where to go in the editor. That way more sophisticated support is possible than the now hard coded heuristics. Keep in mind that these heuristics are tuned for latex and from context we generate the real minimal amount of synctex code that works without clashing with these heuristics. If that were not that case is would be unuseable. Anyhow, there's only so much i can do about it (i'm not going to patch viewers). Currently synctex is mostly working for decent structured source (can be multiple files). Which of the existing viewers have this functionality? Last time I tried using synctex on linux, almost all viewers gave an error that they could not parse synctex file. I think that is because the format of the synctex file changed. Is there some documentation on what is the format of the synctex file written by ConTeXt and how the external program should be called with page and coordinates? With that we can try to raise an issue asking the pdf viewers to support that. context outputs a bare minimum of synctex info: basically it identifies text and marks that, so we don't need the whole nested box mess that can confuse the parser (think of boxes that lap or are moved or lie about dimensions) is you have a context synctex file you only see a few levels (basically words / lines) marked There is a script: mtxrun --script synctex basically all an editor has to do is call: mtxrun --script synctex --page=123 --x=400 --y=500 --editor=scite foo.synctex the script will look into the synctex file and figure out where to go to. Basically all the viewer needs to do is react to a click/cursor/key combination and call mtxrun with the page and positions (basepoints in pdf coordinate space) 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] future versions - synctex
On Tue, 21 Aug 2018, Hans Hagen wrote: Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user "tunes" the docs to their final stage, would be great. I think that the current approach to hard code synctex libraries into a viewer is a limitation (instead an editor should call an external program with the page and coordinates so that an external program can then look at the synctex file and decide where to go in the editor. That way more sophisticated support is possible than the now hard coded heuristics. Keep in mind that these heuristics are tuned for latex and from context we generate the real minimal amount of synctex code that works without clashing with these heuristics. If that were not that case is would be unuseable. Anyhow, there's only so much i can do about it (i'm not going to patch viewers). Currently synctex is mostly working for decent structured source (can be multiple files). Which of the existing viewers have this functionality? Last time I tried using synctex on linux, almost all viewers gave an error that they could not parse synctex file. Is there some documentation on what is the format of the synctex file written by ConTeXt and how the external program should be called with page and coordinates? With that we can try to raise an issue asking the pdf viewers to support that. Thanks, Aditya ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] future versions - synctex
On 8/21/2018 10:00 AM, Procházka Lukáš Ing. wrote: When building a document (or more precisely: documentation which consists of many documents), I'm widely referring to other files via \input, \component etc., I'm widely using \defs, \defines and \buffers defined in separate files (as these defs are used at more places - so let them being defined in one source file) and I'm often generating texts by Lua (e.g. tables - being read and parsed from a text in a \start/\stopluacode block or e.g. Excel named range read via LuaXls or from a .xml - and typeset by a Lua function, which allows simply change all \NC into \VL in a particular place). The lengthy process is to EDIT (almost) finished docs/documentation. And at this place, it would be very handy if synctex worked. So I vote for a better click-in-PDF-go-to-source support. in principle you can push / pop input states but for such a variety of input you have to do that yourself in the styles ... and it will quickly become a performance issue then the core will not get that kind of hard coded synctex flip-flopping fwiw, the xml sub mechanism does support that kind of functionality as option (only because a collegue uses xml with deeply nested inclusions spread all over a direcory structure) I don't know anything deep about how sync is provided. But my layman point of view would be that whenever a character (or a "box") is to be placed on the page (or into output stream), ConTeXt should know which is the "deepest - currently read" source file, the line, moreover the column - and that position could result into "pick-and-go" position. only partly ... you don't know where a macro comes from (or what lua code generated something) and it makes no sense either to go bakc to some macro ... in fact, synctex support in context blocks going to styles because those who edit files are not supposed to change styles things like headers and footers come from styles, not user input and even much structure stuff comes from elsewhere (like titles of sections: they go via lua so there we already need to cheat input registration) In this approach - "boxes" generated by Lua-in-ConTeXt should "jump" on \startluacode, \ctxlua, \cldcommand statement... won't happen ... way too much overhead and it would polute the source too (i follow the principle that any new mechanism that gets added will not slow down compilation in a measurable way) Anyway, i can cheat at the tex/lua end if needed and support e.g. titles but i'm not going to pollute the code with every place where we come from lua (also because in most cases there is no relation with the source anyway then). Also, I will not add code that can have an impact on performance when synctex is turned off. Synctex should be turned on/off before source files are compiled into PDF - via command line option "--synctex" or \enabledirectives[system.synctex] before \starttext (\enabledirectives[system.synctex] after \starttext (\startcomponent) should be ignored?) - that could cause hooking picked Lua functions (or taking their "synctex-on" alternatives) - so normally (with synctex off) there wouldn't be any performance impact; worse performance would come only with synctex on - but it's user's choice. But for a subset of constructs that are relatively short in usage it is doable (but doesn't really qualify as fun -- also, i don't use it myself). Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user "tunes" the docs to their final stage, would be great. I think that the current approach to hard code synctex libraries into a viewer is a limitation (instead an editor should call an external program with the page and coordinates so that an external program can then look at the synctex file and decide where to go in the editor. That way more sophisticated support is possible than the now hard coded heuristics. Keep in mind that these heuristics are tuned for latex and from context we generate the real minimal amount of synctex code that works without clashing with these heuristics. If that were not that case is would be unuseable. Anyhow, there's only so much i can do about it (i'm not going to patch viewers). Currently synctex is mostly working for decent structured source (can be multiple files). 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl /
Re: [NTG-context] future versions - synctex
Hello,
a bit later - I was thinking if to react here, after reading all about synctex
and complicated support for complicatedly assembled source files - but my
personal experience/wish...
On 7/24/2018 11:02 PM, Idris Samawi Hamid ادريس سماوي حامد wrote:
Hi Hans, all,
One needed feature that would be of general use is better support for
synctex. Thinking especially of structural elements such as headings,
footnotes, etc. which mostly do not work with synctex - i.e., clicking
on these elements in the pdf do not take one back to the correct
location in the relevant TEX file.
When building a document (or more precisely: documentation which consists of
many documents), I'm widely referring to other files via \input, \component
etc., I'm widely using \defs, \defines and \buffers defined in separate files
(as these defs are used at more places - so let them being defined in one
source file) and I'm often generating texts by Lua (e.g. tables - being read
and parsed from a text in a \start/\stopluacode block or e.g. Excel named range
read via LuaXls or from a .xml - and typeset by a Lua function, which allows
simply change all \NC into \VL in a particular place).
The lengthy process is to EDIT (almost) finished docs/documentation. And at
this place, it would be very handy if synctex worked. So I vote for a better
click-in-PDF-go-to-source support.
On Wed, 25 Jul 2018 01:21:48 +0200, Hans Hagen wrote:
Synctex is a beast. Basically it is not that useable for context which
is why we have a different implementation with a rather clean, minimal,
and predictable output. Unfortunately the usual approahc is to use a
library for interoreting the synctex files which has too much heuristics
built in. More flexible would be to let the viewer cann an external
program which then can interpret the synctex file based on a page and
position. This also would make it possible to have more clever
synchronization and/or adapt to a macro package. Anyway, were sort of
stuck and can only try to make the best of it.
That said, the context generated synctex file is nornally okay unless we
render from lua, which happens for instance with titles. Just try
\ctxlua{context("foo bar")}
and you will also see that there is no line related positioning.
Tweaking luatex for this is not really an options because whatever
decision we make here will backfire at some point. (I can look into some
option later but it needs bit of thinking)
I don't know anything deep about how sync is provided. But my layman point of view would be that whenever a
character (or a "box") is to be placed on the page (or into output stream), ConTeXt should know
which is the "deepest - currently read" source file, the line, moreover the column - and that
position could result into "pick-and-go" position.
In this approach - "boxes" generated by Lua-in-ConTeXt should "jump" on
\startluacode, \ctxlua, \cldcommand statement...
Anyway, i can cheat at the tex/lua end if needed and support e.g. titles
but i'm not going to pollute the code with every place where we come
from lua (also because in most cases there is no relation with the
source anyway then). Also, I will not add code that can have an impact
on performance when synctex is turned off.
Synctex should be turned on/off before source files are compiled into PDF - via command line option
"--synctex" or \enabledirectives[system.synctex] before \starttext
(\enabledirectives[system.synctex] after \starttext (\startcomponent) should be ignored?) - that
could cause hooking picked Lua functions (or taking their "synctex-on" alternatives) - so
normally (with synctex off) there wouldn't be any performance impact; worse performance would come
only with synctex on - but it's user's choice.
But for a subset of
constructs that are relatively short in usage it is doable (but doesn't
really qualify as fun -- also, i don't use it myself).
Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user
"tunes" the docs to their final stage, would be great.
Best regards,
Lukas
(One complication is that for instance fixing it for some constructs
will break it for xml input which also supports synctex.)
Hans
--
Ing. Lukáš Procházka | mailto:l...@pontex.cz
Pontex s. r. o. | mailto:pon...@pontex.cz | http://www.pontex.cz |
IDDS:nrpt3sn
Bezová 1658
147 14 Praha 4
Mob.: +420 702 033 396
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
