On 9/27/2021 3:53 AM, jbf via ntg-context wrote:
The occasional response to a similar question can be found, e.g. on stackexchange, but none of the responses work for me.
Textadept is very fast at compiling (and does compile correctly). I can certainly open the pdf independently in various pdf viewers, but I cannot get Textadept to automatically open, say, Okular (installed on Linux Mint), at the end of the process.
The last part of the log reads:
mkiv lua stats > runtime: 0.640 seconds, 8 processed pages, 8 shipped pages, 12.492 pages/second mtx-context | pdfview methods: auto default okular pdfxcview sumatra, current method: okular (directives_pdfview_method) pdfview | command: okular --unique "test1.pdf" 1>/dev/null 2>/dev/null & mtx-context | pdfview overhead: 0.001 seconds system | total runtime: 0.649 seconds of 0.701 seconds
exit status: 0
Have tried setting up a custom text editor on okular with: /home/me/.textadept "%f" -e textadept.editing.goto_line(%l-1), as suggested by one response, but to no avail. Current version of ConTeXt is 2021.09.17 10:01
Anyone tried Textadept successfully and might have a suggestion? I tried to launch textadept with the setup that is in the distribution and it worked ok with the textadept version on my machine. There is however a hickup in launching the pdf viewer and then after a while i have to hit escape (windows version of textadept). A second run doesn't work well. So, I guess there is somethign with subprocesses.
The output pane is, as with scite that also uses scintilla, quite fast indeed because it has large refresh delays. For those on windows: the last years the windows terminal (cmd etc run on top of that) is also quite ok. Older versions of cmd had a char-by-char refresh which is not something that goes well with tex logging. On unix one has larger delays so there it's better but tven then font rendering can slow things down. Now to textadept: in order to check this 'launch viewer' delay I installed the latest version and the code that we ship with context no longer runs (quits on some path creation, then when commented on some color/style settings and finally loops in finding a lexer). I know (from scite) that there has been updates to the scintilla lexer interface (again) that I need to look into but in the meantime i wonder if I should do that (although ta is advertised as flexible and configureable it i guess it mostly applies to the code it comes with so maybe it's not meant not be used as i want to, as a framework; get me right: i don't complain about changes: that comes with open source and free and such, it's more about 'should i stick to it and spend time on it'). That said, I do use scite but run our own lexing on top of the derived ta lexing dll (among the reasons for having our own lexing code are 'performance' (large files should load and lex fast), nested lexing, extra features, spell checking etc. Also, we already had lexers. I now wonder if I should not simply roll out my own plugin in scite (which also makes it possible to do some more) instead of relying on ever changing interfaces (changes are fine, but keeping some compatibility would be nice). My backup plan (in case it all stops working) is VScode but even that one keeps changing (e.g. the way extensions are enabled on the command line) and it doesn't have the convenient 'run some program based on suffix' feature that other editors have. So ... the question is: should I waste time on editor support at all, that is: wrt stuff added to the distribution. I'm okay with making things better and have no problem adepting, but we're not talking about it getting better here (e.g. ta already got pretty large wrt to binaries and libraries, so it lost a bit of its charm for me and it's a pitty that the scite lua interface doesn't have lpeg built in natively.) (I might eventually end up running editors in an ancient virtual machine.) 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 -----------------------------------------------------------------