adityam / filter

ConTeXt module to process contents of a start-stop environment through an external program
45 stars 10 forks source link

Reference Code Lines by number #29

Closed hernot closed 4 years ago

hernot commented 4 years ago

When line Numbering is on it would be nice to have some means to be able to refer to tagg a specific line an refer to it in captions and text using standard refernce commands like \in producing the number of the line the tag was placed on

\start<vimcode>[..., numbering=yes,...]
\linetag[code:someexample:line:veryimportant]
\stop<vimcod>

So one could write [...] as can be deduced from \in{line}[code:someexample:line:veryimportant] in \in{Example}[code:someexample] [...]

It would be for a start perfectly OK if \linetag command would have to be placed inside comment to be properly processed as long as it would not appear in output

In case that would be already be possible by other means built in in context or t-filter pleas point me to proper search terms and manual sections.

Thanks ps: this i meant as a feature request

adityam commented 4 years ago

This might be possible using escape=on and adding \macro-for-line-ref[label] in the comment.

hernot commented 4 years ago

hm just browsing the sources trying to figure how vimtyping does line numbering. See that it uses \startlinenumbering \stoplinenumbering built in to context. Thus \someline[label] and \startline[label] \stopline with as you suggest escape=on could work already out of the box in conjunction with \inline[ref], \inlinerange[ref] and \in[ref]. I'll try the next days and let you know. thanks for your hints.

hernot commented 4 years ago

Ok testet it works out of the box inside comment when escape is on Will try the next weeks to find some time to test some suggestion on how to extend 2context.vim script (still need to test) that \someline , \startline, \stopline would also work when escape is off and how comments which just contain these tags nothing else could be made invisible if not explicitly requested by option. Will not be the most perfect solution but should work most time

adityam commented 4 years ago

Any particular reason you want to avoid using escape=on? In principle, it is possible to parse context tags in comments, but this will mean that you need to adapt how the syntax file for each language.

One of my motivations for writing the module was lazyness. Instead of writing syntax files for each language, I simply wanted to leverage pre-existing syntax files from an editor. If one has to understand and tweak syntax files, then one might as well write a parser for the language for context's \starttyping environment. Depending on the language, it might be easy to adapt one of the existing parsers.

On Mon, 24 Feb 2020, hernot wrote:

Ok testet it works out of the box inside comment when escape is on Will try the next weeks to find some time to test some ideas on how to extend 2context.vim script that \someline , \startline, \stopline would also work when escape is off and how comments which just contain these tags nothing else could be made invisible if not explicitly requested by option. Will not be the most perfect solution but should work most time

-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/adityam/filter/issues/29#issuecomment-590450271

hernot commented 4 years ago

I'm fully with you writing own syntax files for each language would be completely foolish, as, as you say, vim does it all for you. Thus Tags will in any case stay inside comments to be considered. Comments which are empty exempt for line tags on the other hand look strange and unmotivated randomly placed by author of the typeset code snippets . Therefore hiding them unless explicitly requested to be shown in typeset result makes sense to me.

Based on this the only things which i will add is, that the vim script 2context.vim after identifying a comment will 1) extract from comment string the aforementioned \someline, \startline and \endline tags 2) either remove them from comment string or replace them by their escaped version if showtags parameter is set to true disregarding whether escapecomments parameter is set to true or not 3) append the string containing the extracted tags only at the end of the output string before writing to outputbuffer and and after highlighting string as comment by enclosing within \SYN macros. Thereby hiding of tags only comments would happen only if and only if showtags is off by clearing variable naming string as comment and variable containing comment string to empty string. Thus lines which in the sources host line tags only comments would appear to be empty in output.

And knowing whether comment is empty besides line tags or not does not mean to reinvent whole syntax file again for each language. Vim provides everything including tools properly predefined to identify empty comments for each file type individually.

That is all. Anything else i too consider foolish.

adityam commented 4 years ago

There may be a simpler method to do so, but it requires a bit of digging into how vim syntax files work (there was a time when I knew that like the back of my hand, but not anymore).

Basically, we can add a local .vimrc file and this file could specify a new syntax group, say LineIgnore which identifies \someline[..], \startline[...], and \stopline[...]. Then when the syntax highlighting is done, they will come out as \SYN{LineIgnore}{\someline[...]}, and we could simply read it using standard catcodes.

On Mon, 24 Feb 2020, hernot wrote:

I'm fully with you writing own syntax files for each language would be completely foolish, as, as you say, vim does it all for you. Thus Tags will in any case stay inside comments, but comments which are empty exempt for line tags look strange and randomly placed isnide the typeset code. Therefore hiding them unless explicitly requested to be shown in typeset result makes sense.

Bases on this the only things which i will add is, that the vim script 2context.vim after identifying a comment will 1) extract from comment string the aforementioned \someline, \startline and \endline tags 2) either remove them from comment or replace them by their escaped version if showtags parameter is set to true disregarding whether escapecomments parameter is set to true or not 3) append the string containing the extracted tags only at the end of the output string before writing to outputbuffer and and after highlighting string as comment by enclosing within \SYN macros. Thereby hiding of tags only comments would happen only if and only if showtags is off by clearing variable naming string as comment and variable containing comment to empty string. Thus lines which in the sources host tags only comments would become empty in output.

That is all. Anything else i too consider foolish.

-- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/adityam/filter/issues/29#issuecomment-590713773

hernot commented 4 years ago

Hm would be an option but would require to tinker with users vimrc files, not knowing what other side effects hide there. Thus imho a bit of overkill just for figuring whether comment string would only contain whitespace if any after removing trailing and leading comment symbols. The latter vim stores for each filetype in the &comments string and for checking if nothing than white space if any a simple regular expression is sufficient. Would not make things to fancy. If sombody really thinks to code nested comments or other fancy stuff into comments they simply are not considered empty after removing the tags. And if comments are empty not even containing the tags, than i would let them appear in output anyway as they might be there by purpose.

Suggestion: to shorten discussion, i will test the next days and when lecture notes are finished or at least far enough advanced i will create and link a pull-request for initial review and further discussion.

EDIT: just opened the promised pullrequest: #32

hernot commented 4 years ago

Hm I think we forgot to close this when releasing #33 #32 i close it now it should be solved.