[NTG-context] TikZ modules are missing \startmodule
Hi, Since a module nesting check has been introduced in file-mod.mkvi, the TikZ modules provoke "module wrapping error" messages in the log file. May I kindly ask the maintainer of the TikZ modules to insert the missing \startmodule command in the following files: \tex\texmf-modules\tex\context\pgf\basiclayer\t-pgf.tex \tex\texmf-modules\tex\context\pgf\basiclayer\t-pgfbim.tex \tex\texmf-modules\tex\context\pgf\basiclayer\t-pgfcor.tex \tex\texmf-modules\tex\context\pgf\frontendlayer\t-tikz.tex \tex\texmf-modules\tex\context\pgf\math\t-pgfmat.tex \tex\texmf-modules\tex\context\pgf\systemlayer\t-pgfsys.tex \tex\texmf-modules\tex\context\pgf\utilities\t-pgfcal.tex \tex\texmf-modules\tex\context\pgf\utilities\t-pgffor.tex \tex\texmf-modules\tex\context\pgf\utilities\t-pgfkey.tex \tex\texmf-modules\tex\context\pgf\utilities\t-pgfmod.tex \tex\texmf-modules\tex\context\pgf\utilities\t-pgfrcs.tex Kind regards, Christoph ___ 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] WYSIWYM editor on top of ConTeXt / Lout
Mentioned on their wiki at: https://wiki.lyx.org/FAQ/ImportExport On Thu, Dec 7, 2017 at 8:55 AM, William Adamswrote: > Is it not an option to use LyX, and then pandoc to convert to ConTeXt? > > http://pandoc.org/ > > On Thu, Dec 7, 2017 at 7:42 AM, Roger Mason wrote: > >> Hello Jonas, >> >> Jonas Baggett writes: >> >> > Thank you for the suggestion. I was first thinking about incrementally >> > creating a custom format that evolves as features are implemented. And >> > for translating the custom format into a backend format, I was >> > thinking of creating files with translations rules for each backend so >> > that anyone can add support for a new backend or update an existing >> > backend to add more feature or to make it compatible with a newer >> > version of the backend, without needing to modify the editor code. A >> > translation rule is e.g. start_section[title=, >> > back_ground_color=] => @startsection(title -> >> > {}, bg_color -> {}) which will convert a start >> > section command of the document format into the same command for a >> > backend format. >> >> Skribilo uses an abstract syntax internally and the different output >> engines process that into the target language. In essence each engine >> is the collection of rules appropriate to that target. >> >> > At first glance that way seems to be the easiest way for me, but >> > Skribilo looks interesting as a fallback option, although I find its >> > syntax to be weird, if I find out that the idea with translation rules >> > isn't working as expected. >> >> There are two input syntaxes, a simple one a bit like Emacs' outline >> mode and the more Scheme-like syntax. The former has limitations >> documented on the Skribilo web-site, the latter is far more complete. I >> an guessing it is the Scheme-like syntax that you find weird. I have >> played around a a little this week on using Wisp >> (http://www.draketo.de/proj/wisp/) and Readable >> (http://readable.sourceforge.net/) to write Skribilo in a less >> parenthesis rich style. Although not able to complete the work owing to >> time constraints, it looks acheivavble. >> >> Cheers, >> Roger >> >> Off topic >> >> >> My goal would be to have an output ConTeXt (or Lout) document, with >> fallback to LaTeX or XML if a publisher insists. If this could be >> combined with Emacs org-mode to document, store and run (or compile-run) >> source code, then a very complete and versatile system for reproducible >> reasearch could be constructed. >> >> >> >> ___ >> 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/list >> info/ntg-context >> webpage : http://www.pragma-ade.nl / http://context.aanhet.net >> archive : https://bitbucket.org/phg/context-mirror/commits/ >> wiki : http://contextgarden.net >> >> ___ >> > > ___ 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] WYSIWYM editor on top of ConTeXt / Lout
Is it not an option to use LyX, and then pandoc to convert to ConTeXt? http://pandoc.org/ On Thu, Dec 7, 2017 at 7:42 AM, Roger Masonwrote: > Hello Jonas, > > Jonas Baggett writes: > > > Thank you for the suggestion. I was first thinking about incrementally > > creating a custom format that evolves as features are implemented. And > > for translating the custom format into a backend format, I was > > thinking of creating files with translations rules for each backend so > > that anyone can add support for a new backend or update an existing > > backend to add more feature or to make it compatible with a newer > > version of the backend, without needing to modify the editor code. A > > translation rule is e.g. start_section[title=, > > back_ground_color=] => @startsection(title -> > > {}, bg_color -> {}) which will convert a start > > section command of the document format into the same command for a > > backend format. > > Skribilo uses an abstract syntax internally and the different output > engines process that into the target language. In essence each engine > is the collection of rules appropriate to that target. > > > At first glance that way seems to be the easiest way for me, but > > Skribilo looks interesting as a fallback option, although I find its > > syntax to be weird, if I find out that the idea with translation rules > > isn't working as expected. > > There are two input syntaxes, a simple one a bit like Emacs' outline > mode and the more Scheme-like syntax. The former has limitations > documented on the Skribilo web-site, the latter is far more complete. I > an guessing it is the Scheme-like syntax that you find weird. I have > played around a a little this week on using Wisp > (http://www.draketo.de/proj/wisp/) and Readable > (http://readable.sourceforge.net/) to write Skribilo in a less > parenthesis rich style. Although not able to complete the work owing to > time constraints, it looks acheivavble. > > Cheers, > Roger > > Off topic > > > My goal would be to have an output ConTeXt (or Lout) document, with > fallback to LaTeX or XML if a publisher insists. If this could be > combined with Emacs org-mode to document, store and run (or compile-run) > source code, then a very complete and versatile system for reproducible > reasearch could be constructed. > > > > ___ > 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 > > ___ > ___ 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] WYSIWYM editor on top of ConTeXt / Lout
Hello Jonas, Jonas Baggettwrites: > Thank you for the suggestion. I was first thinking about incrementally > creating a custom format that evolves as features are implemented. And > for translating the custom format into a backend format, I was > thinking of creating files with translations rules for each backend so > that anyone can add support for a new backend or update an existing > backend to add more feature or to make it compatible with a newer > version of the backend, without needing to modify the editor code. A > translation rule is e.g. start_section[title=, > back_ground_color=] => @startsection(title -> > {}, bg_color -> {}) which will convert a start > section command of the document format into the same command for a > backend format. Skribilo uses an abstract syntax internally and the different output engines process that into the target language. In essence each engine is the collection of rules appropriate to that target. > At first glance that way seems to be the easiest way for me, but > Skribilo looks interesting as a fallback option, although I find its > syntax to be weird, if I find out that the idea with translation rules > isn't working as expected. There are two input syntaxes, a simple one a bit like Emacs' outline mode and the more Scheme-like syntax. The former has limitations documented on the Skribilo web-site, the latter is far more complete. I an guessing it is the Scheme-like syntax that you find weird. I have played around a a little this week on using Wisp (http://www.draketo.de/proj/wisp/) and Readable (http://readable.sourceforge.net/) to write Skribilo in a less parenthesis rich style. Although not able to complete the work owing to time constraints, it looks acheivavble. Cheers, Roger Off topic My goal would be to have an output ConTeXt (or Lout) document, with fallback to LaTeX or XML if a publisher insists. If this could be combined with Emacs org-mode to document, store and run (or compile-run) source code, then a very complete and versatile system for reproducible reasearch could be constructed. ___ 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] WYSIWYM editor on top of ConTeXt / Lout
On Thu, 7 Dec 2017, Floris van Manen wrote: it might be simpler to have a ‘watch’ option for the context compiler combined with an ‘open result’. e.g. the coffeescript compiler allows for a ‘-w’ option, it will keep the compiler running in the background and start compiling the file(s) as soon as it detects any changes. i guess such feature might already exist in the rich mtx context tools environment. not sure where to look though … I use atchange perl script for such tasks: https://schneider.ncifcrf.gov/atchange.html 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] WYSIWYM editor on top of ConTeXt / Lout
it might be simpler to have a ‘watch’ option for the context compiler combined with an ‘open result’. e.g. the coffeescript compiler allows for a ‘-w’ option, it will keep the compiler running in the background and start compiling the file(s) as soon as it detects any changes. i guess such feature might already exist in the rich mtx context tools environment. not sure where to look though … .F > On 7 Dec 2017, at 07:42, Jonas Baggettwrote: > > >> While not an editor, but rather a language, Skribilo >> (http://www.nongnu.org/skribilo/) can output documents in various >> formats, including Context and Lout. I have worked a bit on getting >> better Context output from it and last tinkered with the math output >> about a year ago. Such a system might form the output engine on which >> an editor could be built. The same might be said for Pandoc, in which >> case perhaps one of the existing Haskell editors could be used as the >> basis for a specialised text processing system. For non-technical >> documents SiSU (http://www.jus.uio.no/lm/toc.html) offers various output >> formats, but again it is not an editor. >> >> While your concept is interesting, I'm an Emacs user, and unlikely to >> switch to anything else. >> >> Cheers, >> Roger > -- > > Hi Roger, > > Thank you for the suggestion. I was first thinking about incrementally > creating a custom format that evolves as features are implemented. And for > translating the custom format into a backend format, I was thinking of > creating files with translations rules for each backend so that anyone can > add support for a new backend or update an existing backend to add more > feature or to make it compatible with a newer version of the backend, without > needing to modify the editor code. A translation rule is e.g. > start_section[title=, back_ground_color=] => > @startsection(title -> {}, bg_color -> {}) which will > convert a start section command of the document format into the same command > for a backend format. > > At first glance that way seems to be the easiest way for me, but Skribilo > looks interesting as a fallback option, although I find its syntax to be > weird, if I find out that the idea with translation rules isn't working as > expected. > > Cheers, > Jonas > ___ > 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 > ___ signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] LuaTeX: Weird GC behaviour
On 12/7/2017 12:40 AM, Shreevatsa R wrote: (Hope this gets threaded with the previous two messages...) I was the one who asked the question (https://tex.stackexchange.com/questions/404617). Another thing I'd like to mention is that after a while `io.lines` simply returned nil, and the second and third return values (error message and error code) that io.lines is supposed to return in case of error were also nil. Even if this issue is not perfectly fixed (i.e. even if io.lines cannot be made to close the file descriptor when it reaches the end of file), I think it would be preferable to throw a clear error when there's a failure to open a new file, instead of silently (and in a not 100% reproducible way) returning nil. Ok, we can quit with an error but the message will be a bit different (as we have different code). The file gets now closed explicitly which doesn't guarantee collection but it looks ok so far. I never use io.lines so I can't really test in practice. 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 ___