ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen via ntg-context <ntg-context@ntg.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Cc: Hans Hagen <j.hagen@xs4all.nl>
Subject: Re: Getting Textadept to open pdf?
Date: Mon, 27 Sep 2021 10:45:53 +0200	[thread overview]
Message-ID: <394b8cda-4d31-fbb4-1b92-b040ee55648d@xs4all.nl> (raw)
In-Reply-To: <ce323020-bd0f-fb4f-2d4a-8c6111a5ba9a@gmail.com>

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
-----------------------------------------------------------------
___________________________________________________________________________________
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
___________________________________________________________________________________

      parent reply	other threads:[~2021-09-27  8:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27  1:53 jbf via ntg-context
2021-09-27  3:06 ` Jairo A. del Rio via ntg-context
2021-09-27  3:29   ` jbf via ntg-context
2021-09-27  3:41     ` Jairo A. del Rio via ntg-context
2021-09-27  6:05       ` jbf via ntg-context
2021-09-27  8:45 ` Hans Hagen via ntg-context [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=394b8cda-4d31-fbb4-1b92-b040ee55648d@xs4all.nl \
    --to=ntg-context@ntg.nl \
    --cc=j.hagen@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).