Re: [NTG-context] Synctex + Sumatra + TextPad

[Hans Hagen]

On 8/21/2018 9:23 PM, Procházka Lukáš Ing. wrote:

Hello,

this question extends the "[NTG-context] future versions - synctex" thread.

I'm using TextPad for editing Ctx source files, PdfXChange Viewer to 
view PDFs, both on Windows.


After reading some recent posts and after studying some web sources - 
especially


 [a] https://www.sumatrapdfreader.org/docs/DDE-Commands.html for 
SumatraPDF viever and


 [b] 
https://tex.stackexchange.com/questions/116981/how-to-configure-texniccenter-2-0-with-sumatra-2013-2016-version/116994#116994 
for inspiration how to make TXC interoperate with Sumatra,


dunno

I would like to provide "click-in-PDF-go-to-source" functionality - be 
Sumatra the viewer for this case.


Questions are:
 
1. How to run Sumatra so that it opens a PDF file AND reacts somehow to 
a mouse click, in order to provide a command to get to the corresponding 
place in the source file?


 (IIUC, Sumatra provides such functionality, as e.g. TeXnic Center 
use it. [b].)


I guess that I have to configure Sumatra somehow, or to launch Sumatra 
with some command line parameters, so that when I click a point in the 
PDF (maybe while also holding CTRL or something - but it is a detail), a 
command is launched to open the source file in the editor and go to a 
particular line.


from the workflow manual:

Of course you need to configure the viewer to respond to the request for 
editing. In Sumatra combined with SciTE the magic command is:


c:\data\system\scite\wscite\scite.exe "%f" "-goto:%l"

2. What should be the command line parameters passed to Sumatra to 
provide the linkage "open PDF-source at line"?


config file

I deduce also that such command should call "mtxrun --script synctex" 
somehow (which will call 
"...\tex\texmf-context\scripts\context\lua\mtx-synctex.lua") as the 
"mtx-synctex" is able to read the .synctex produced during compilation 
of .tex files.


no, because the lib is hard coded in the sumatra bin so you need to 
cross your fingers


I deduce also that "mtx-synctex" calls the editor (which the user uses 
to edit source files) in the manner that it tells the editor "open file 
(...) and go to line (...).
Existing "mtx-synctex" is "aware" of "scite" editor, which is - next to 
"console" - the only editor pre-configured.


pdf viewers use the lib .. what we're discussing is hwo to make them 
call a program instead


3. What code should be added into "mtx-synctex" in order to make TextPad 
an editor known to "mtx-synctex"?


dunno, i never used textpad  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
___

[NTG-context] Synctex + Sumatra + TextPad

[Procházka Lukáš Ing .]

Hello,

this question extends the "[NTG-context] future versions - synctex" thread.

I'm using TextPad for editing Ctx source files, PdfXChange Viewer to view PDFs, 
both on Windows.

After reading some recent posts and after studying some web sources - especially

[a] https://www.sumatrapdfreader.org/docs/DDE-Commands.html for 
SumatraPDF viever and

[b] 
https://tex.stackexchange.com/questions/116981/how-to-configure-texniccenter-2-0-with-sumatra-2013-2016-version/116994#116994
 for inspiration how to make TXC interoperate with Sumatra,

I would like to provide "click-in-PDF-go-to-source" functionality - be Sumatra 
the viewer for this case.

Questions are:


1. How to run Sumatra so that it opens a PDF file AND reacts somehow to a mouse 
click, in order to provide a command to get to the corresponding place in the 
source file?

(IIUC, Sumatra provides such functionality, as e.g. TeXnic Center use 
it. [b].)

I guess that I have to configure Sumatra somehow, or to launch Sumatra with 
some command line parameters, so that when I click a point in the PDF (maybe 
while also holding CTRL or something - but it is a detail), a command is 
launched to open the source file in the editor and go to a particular line.


2. What should be the command line parameters passed to Sumatra to provide the linkage 
"open PDF-source at line"?

I deduce also that such command should call "mtxrun --script synctex" somehow (which will call 
"...\tex\texmf-context\scripts\context\lua\mtx-synctex.lua") as the "mtx-synctex" is able 
to read the .synctex produced during compilation of .tex files.

I deduce also that "mtx-synctex" calls the editor (which the user uses to edit 
source files) in the manner that it tells the editor "open file (...) and go to line 
(...).
Existing "mtx-synctex" is "aware" of "scite" editor, which is - next to 
"console" - the only editor pre-configured.

So:


3. What code should be added into "mtx-synctex" in order to make TextPad an editor known 
to "mtx-synctex"?

I found and tried that command e.g. 'C:\Program Files\TextPad 7\system\ddeopn32.exe" 
TextPad.dde Test.mkiv(40)' successfully opens "Test.mkiv" (being open before) and 
scrolls to line #40.

(TextPad location may vary - depending on version installed - can be e.g.:

C:\Program Files\TextPad 7
C:\Program Files (x86)\TextPad 7
C:\Program Files\TextPad 8
...
)

Any idea would be appreciated...

Best regards,

Lukas


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

[NTG-context] Spurious breaks in export when blank line ends paragraph

[Rik Kabel]

List,

My understanding of start/stop macros such as 
\startparagraph...\stopparagraph has been that blank lines are allowed 
between the block of text and the macros, as


   \startparagraph

   This is the text of the paragraph

   \stopparagraph

However, in xml exports the blank line before \stopparagraph leads to 
spurious break elements in some circumstances, as shown in the following:


   \setupbackend [export=yes,xhtml=yes]
   \starttext
   \startsection[title=trailing blank line]
   \startparagraph
  Xxx xxx xx x xx xxx  xx xx
  xx. Xxx  x, \inleft{z} x  xx x
  xx  x xx xxx  xx x, xxx   xx
  xxx xxx xxx xx  xxx  xx Xxxx , xxx
    x xx  x xx . Xxx x
  xxx xxx xxx xx xx   xxx,x
  xx x xx,  xxx xxx xxx x . Xxxx xxx
  xx xx xxx xxx ,    xxx x xx
  x x, xxx xxx x xxx xxx xx xx xx
  \inleft{zz}. Xxxx  x xx   (x, xxx,
  xx xxx xx).

   \stopparagraph

   \stopsection

   \startsection[title=no blank line]

   \startparagraph
  Xxx xxx xx x xx xxx  xx xx
  xx. Xxx  x, \inleft{z} x  xx x
  xx  x xx xxx  xx x, xxx   xx
  xxx xxx xxx xx  xxx  xx Xxxx , xxx
    x xx  x xx . Xxx x
  xxx xxx xxx xx xx   xxx,x
  xx x xx,  xxx xxx xxx x . Xxxx xxx
  xx xx xxx xxx ,    xxx x xx
  x x, xxx xxx x xxx xxx xx xx xx
  \inleft{zz}. Xxxx  x xx   (x, xxx,
  xx xxx xx).
   \stopparagraph

   \stopsection

   \startsection[title=Another section]

   \startparagraph

  This is here to show the bottom of the previous section.

   \stopparagraph

   \stopsection

   \stoptext

Note that the pdf output does not display the problem, but the pdf 
output is not why one runs an export. The breaks disappear in shorter 
paragraphs, and disappear when the margintext is not present, but appear 
when margintext is present and the paragraph exceeds some length which I 
have not worked to determine.


Is my understanding of the space rules incorrect, or is this a bug?

Since some breaks perhaps should be present, it is difficult to remove 
these with CSS, or XSLT. One thing that might help is to add a class 
identifier to breaks indicating what lead to their creation. Of course, 
not generating these would be better still.


--

Rik

___
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] scite

[cryo shock]

Hi again,
this is the reply of Mitchell:

"Hi Lars,

On Tue, 21 Aug 2018, cryo shock wrote:

> Hi Mitch, hi readers,
>
> do you happen to know where one can download a SciTE / Scintilla v3.8.0
> long term stable release? Or is it only available for users who compile it
> themselves?
> This is everything I found:
> https://sourceforge.net/projects/scintilla/files/scintilla/3.8.0/

Scintilla long term 3.x releases are source releases. There are no SciTE
long term 3.x releases.

Note: the latest long term 3 release is 3.10.0.

Cheers,
Mitchell"

I hope that helps. Cheers, Lars.

Am Di., 21. Aug. 2018 um 18:43 Uhr schrieb cryo shock :

> Hi Hans,
>
> I just posted a similar question in the Textadept / Foicica-Code mailing
> list. Maybe Mitchell knows. But since you didn't find it, I think chances
> are rather low...
>
> Cheers, Lars
>
> Am Di., 21. Aug. 2018 um 17:24 Uhr schrieb Hans Hagen :
>
>> Hi,
>>
>> does anyone know where one can download a scite 3.80 (long term stable)
>>
>> https://sourceforge.net/projects/scintilla/files/scintilla/3.8.0/
>>
>> or do we need to start compiling it ourselves
>>
>> 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
>>
>> ___
>
>
___
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] scite

[cryo shock]

Hi Hans,

I just posted a similar question in the Textadept / Foicica-Code mailing
list. Maybe Mitchell knows. But since you didn't find it, I think chances
are rather low...

Cheers, Lars

Am Di., 21. Aug. 2018 um 17:24 Uhr schrieb Hans Hagen :

> Hi,
>
> does anyone know where one can download a scite 3.80 (long term stable)
>
> https://sourceforge.net/projects/scintilla/files/scintilla/3.8.0/
>
> or do we need to start compiling it ourselves
>
> 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
>
> ___
___
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
___

[NTG-context] scite

[Hans Hagen]

Hi,

does anyone know where one can download a scite 3.80 (long term stable)

https://sourceforge.net/projects/scintilla/files/scintilla/3.8.0/

or do we need to start compiling it ourselves

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

[Hans Hagen]

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

[Aditya Mahajan]

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] Textadept with ConTeXt

[Hans Hagen]

On 8/21/2018 3:55 PM, Jan U. Hasecke wrote:

Hi all!

Thank you very much for hinting to Textadept. I'll test the editor.

One question:

If I source "context/tex/setuptex" and start textadept from the shell, I
can build a file with this configuration line in init.lua:

textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
context --autopdf --purge "%f"'

How can I source the standalone installation setup from Textadepts init.lua?

if you install the old version (TA 9) then

textadept-context.cmd

should just work ok



-
  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] Textadept with ConTeXt

[Jan U. Hasecke]

Hi all!

Thank you very much for hinting to Textadept. I'll test the editor.

One question:

If I source "context/tex/setuptex" and start textadept from the shell, I
can build a file with this configuration line in init.lua:

textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
context --autopdf --purge "%f"'

How can I source the standalone installation setup from Textadepts init.lua?

juh

___
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] Migrating ConTeXt's Textadept settings from v9 to v10.

[luigi scarso]

On Tue, Aug 21, 2018 at 12:07 PM Hans Hagen  wrote:

>
> so i need to wrap different i guess (the scite variant is probably not
> affected as i there we don't use the same interface) .. but if the dll
> interface also changes i'll roll out my own (if i can convince luigi to
> join me in that)
>

if portable also to notepad+++...
(I have not said easily portable)
-- 
luigi
___
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

[Hans Hagen]

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

[Aditya Mahajan]

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] Migrating ConTeXt's Textadept settings from v9 to v10.

[Hans Hagen]

On 8/21/2018 11:39 AM, cryo shock wrote:
Hi Hans, I'd surely love help you to adapt ConTeXt's settings from v9 to 
v10. I hope that the following quotations will help you enough. I also 
hope that the format doesn't get mixed up when I send this mail.
hm, change in lexer setup again .. this is actually why i stick to scite 
(ta is evolving to a - probably better, as the old method was not than 
nice either which is why i wrapped some of it - interface in the end but 
should not have had the worse one to start with .. alas, such is life


so i need to wrap different i guess (the scite variant is probably not 
affected as i there we don't use the same interface) .. but if the dll 
interface also changes i'll roll out my own (if i can convince luigi to 
join me in that)


imagine that i'd change the way context is configured that drastically 
and then ask users to migrate from \setupfoo[key=value] to a completely 
different syntax ... doesn't work i guess


changes for the better are fine, but changing a user interface is kind 
of blocking (i simply can't afford to waste time on that every few years)


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
___

[NTG-context] Migrating ConTeXt's Textadept settings from v9 to v10.

[cryo shock]

Hi Hans, I'd surely love help you to adapt ConTeXt's settings from v9 to
v10. I hope that the following quotations will help you enough. I also hope
that the format doesn't get mixed up when I send this mail.

- QUOTATION start
source: https://foicica.com/textadept/manual.html#Migration.Guides
Migration Guides Textadept 9 to 10 API Changes
Old API Change New API
*_G*

bit32 Removed N/A *(use bitwise operators)*
*buffer*

brace_match(pos) Changed brace_match
(pos, 0)
*lexer*

_foldsymbols Replaced add_fold_point()

_rules Replaced add_rule()

_tokenstyles Replaced add_style()

embed_lexer(parent, child, …) Renamed parent:embed
(child, …)
_RULES[id] Replaced get_rule
(id)
_RULES[id] = rule Replaced modify_rule
(id, rule)
N/A Added new() 
word_match(list, wchars, icase) Changed word_match
(words, icase)
*ui*

set_theme Renamed buffer.set_theme()

*textadept.editing*

match_brace Replaced N/A *(menu function)*
N/A Added paste()

N/A Added paste_reindents

*textadept.session*

default_session Removed
Configuration Changes

Textadept 10 no longer uses a *~/.textadept/properties.lua* file. Instead,
all buffer settings are made in *~/.textadept/init.lua*, and apply to the
first and any subsequent buffers. (In Textadept 9, any buffer settings made
in *~/.textadept/init.lua* only applied to the first buffer, so a
*~/.textadept/properties.lua* was required in order to define buffer
settings that would affect subsequent buffers.)

Simply copying the contents of your *~/.textadept/properties.lua* into
*~/.textadept/init.lua* should be sufficient.
Lexer Changes

Lexers are now written in a more object-oriented way. Legacy lexers are
still supported, but it is recommended that you migrate them
.
Key Bindings Changes

The terminal version’s key sequence for Ctrl+Space is now 'c ' instead of
'c@'.
Regex Changes

Textadept now uses C++11’s ECMAScript regex syntax
 instead of
TRE .
Mac OSX System Requirements

Textadept now requires Mac OSX 10.6 (Snow Leopard) at a minimum. The
previous minimum version was 10.5 (Leopard).
LuaJIT Changes

The LuaJIT version of Textadept has been removed. Any LuaJIT-specific
features used in external modules will no longer function.

- QUOTATION end

I also found this here:

- QUOTATION start
source: https://foicica.com/textadept/api.html#lexer.Migrating.Legacy.Lexers
Migrating Legacy Lexers

Legacy lexers are of the form:

local l = require('lexer')
local token, word_match = l.token, l.word_match
local P, R, S = lpeg.P, lpeg.R, lpeg.S

local M = {_NAME = '?'}

[... token and pattern definitions ...]

M._rules = {
  {'rule', pattern},
  [...]
}

M._tokenstyles = {
  'token' = 'style',
  [...]
}

M._foldsymbols = {
  _patterns = {...},
  ['token'] = {['start'] = 1, ['end'] = -1},
  [...]
}

return M

While such legacy lexers will be handled just fine without any changes, it
is recommended that you migrate yours. The migration process is fairly
straightforward:

   1. Replace all instances of l with lexer, as it’s better practice and
   results in less confusion.
   2. Replace local M = {_NAME = '?'} with local lex = lexer.new('?'),
   where ? is the name of your legacy lexer. At the end of the lexer,
   change return M to return lex.
   3. Instead of defining rules towards the end of your lexer, define your
   rules as you define your tokens and patterns using lex:add_rule()
   .
   4. Similarly, any custom token names should have their styles
   immediately defined using lex:add_style()
   .
   5. Convert any table arguments passed to lexer.word_match()
    to a
   space-separated string of words.
   6. Replace any calls to lexer.embed(M, child, ...) and lexer.embed(parent,
   M, ...) with lex:embed
   (child, ...)
and parent:embed(lex,
   ...), respectively.
   7. Define fold points with simple calls to lex:add_fold_point()
   

Re: [NTG-context] Textadept with ConTeXt

[Fabrice Couvreur]

Hello,
Thanks for your help !

First, only edit the init.lua in your USER folder, on Win it's
> C:\Users\NAME\.textadept\init.lua. Don't edit the init.lua within TA's main
> folder. In fact, there is no reason to enter TA's main folder after
> extraction unless you want to read other config files like the ConTeXt
> lexer (see below).
>

Of course !



> Second, I am using Win10x64 with SumatraPDF as viewer, it's fast and you
> don't need to close documents to recompile. The biggest disadvantage is,
> that you can't use scripts with SumatraPDF (for forms etc.).
> Furthermore the following line I wrote into my init.lua:
>
> textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
> context --autopdf --purge "%f"'
>
> When I compile the PDF like this, Sumatra opens up as expected. On
> recompile it reloads the PDF. Maybe the spaces within your command are the
> reason:
> synctex = -1  ->synctex=-1
>

 Here is the content of my init.lua
:


textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
context --autopdf --purge "%f"'

textadept.file_types.extensions.tex = 'context'


buffer:set_theme('dark', {font = 'Monospace', fontsize = 14})



When I compile a file test.tex (Maj + Ctrl + R), I get the expected file
test.pdf in my home directory; file that I open with Evince. What I would
like, if possible, is an automatic opening of this file after
compilation. Here's
what I get in the messages tab :

mtx-context | pdfview methods: auto default okular pdfxcview sumatra,
current method: sumatra (directives_pdfview_method)
pdfview | command: wine "sumatrapdf.exe" -reuse-instance -bg-color 0xCC
"wolfgang-1.pdf" 1> / dev / null 2> / dev / null &
system | total runtime: 1.624 seconds

If I compile a second time, still no automatic output from the file
test.pdf.
 On the other hand, if I do Crtl + R test.tex, the file test.pdf opens with
xdg-open :

> exit status: 0
> xdg-open "wolfgang-1.pdf"
File name empty!
The specified Application package is not valid.
/ usr / bin / xdg-open: line 881: x-www-browser: command not found
> exit status: 0


Thanks
Fabrice


Le mar. 21 août 2018 à 02:00, Lars  a écrit :

> Hi there, thanks for your interest in Textadept. It's a great editor and I
> am sure that you won't regret testing it and using it in the future. Just
> have some patience.
>
> I suggest you take a look at my User talk at the wiki, there I explain a
> lot about TA and how to use it with ConTeXt. It's more detailed than the
> Textadept site on the wiki.
>
> http://wiki.contextgarden.net/User_talk:Koenich
> I have to say though that I wrote it with Windows in mind. But TA's config
> files are all written in Lua so the OS should not be a problem.
>
>
> Am 21/08/2018 um 00:55 schrieb Fabrice Couvreur:
>
> Hello,
> In order to use another editor than Emacs and after testing Scite, I
> installed Textadept and modified the init.lua file as follows :
>
> textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
> context --autopdf --purge --synctex = -1 "% f"'
>
>
> First, only edit the init.lua in your USER folder, on Win it's
> C:\Users\NAME\.textadept\init.lua. Don't edit the init.lua within TA's main
> folder. In fact, there is no reason to enter TA's main folder after
> extraction unless you want to read other config files like the ConTeXt
> lexer (see below).
>
> Second, I am using Win10x64 with SumatraPDF as viewer, it's fast and you
> don't need to close documents to recompile. The biggest disadvantage is,
> that you can't use scripts with SumatraPDF (for forms etc.).
> Furthermore the following line I wrote into my init.lua:
>
> textadept.run.compile_commands.tex = 'mtxrun --autogenerate --script
> context --autopdf --purge "%f"'
>
> When I compile the PDF like this, Sumatra opens up as expected. On
> recompile it reloads the PDF. Maybe the spaces within your command are the
> reason:
> synctex = -1  ->synctex=-1
>
> Third, is your ConTeXt folder within Search Path (I better ask)?
>
> *Fourth, did you bind extensions to the context.lua lexer?* In the
> init.lua it should look like this:
>
> textadept.file_types.extensions.tex = 'context'
> % If you're using LaTeX too, you should choose another extension.
> textadept.file_types.extensions.mkii = 'context'
> textadept.file_types.extensions.mkiv = 'context'
>
> *Fifth, is your context lexer loaded when you compile the file?* Check
> the status bar in the lower right corner. If it doesn't say "context" but
> "latex" or "text" or anything like that, then choose the context lexer via
> "Buffer" -> "Select lexer...".
>
> Sixth, make sure that you really have compilable content. Try with code
> which is as minimal as possible. A simple
>
> \starttext Hello World \stoptext
>
> should do.
>
>
> The compilation works but no automatic output in pdf at the end of the
> process (as with Scite !)
>
> What to do with files in /home /aragorn/context/tex
> /texmf-context/context/data /textadept/ context/ 

Re: [NTG-context] Textadept with ConTeXt

[Hans Hagen]

On 8/21/2018 10:33 AM, cryo shock wrote:

You mentioned that before at some point, and I wouldn't argue with that, 
as you surely know best how to use an editor that helps you with your 
work. I don't know enough about Lua programming, so it's hard for me to 
tell whether the realtime console pane is realisable within TA. But I 
will ask Mitchell on TA mailing list what he thinks about it. I think it 
would be great if he could make a console pane possible, as I think that 
there is nothing worse than having to switch between programs because of 
the lack of features.


I must admit that I'm not looking at more advanced editing as normally 
one uses a small subset of what an editor provides anyway. In that sense 
I have no real reason to switch (apart from cross platform editing).


One month or so ago Mitchell released Textadept 10 which comes with some 
API changes. He wrote a Migration Guide from TA9 to 10 which can be 
found in the appendix of the TA online manual:


Hm, I don't look forward to that. Especially because it's kind of hard 
to intercept error messages (on windows) when tweaking.



https://foicica.com/textadept/manual.html#Migration.Guides

So when using the ConTeXt TA package with TA10, TA pops up with many 
errors and is unusable until one deletes the files again. The files work 
with TA v9 without a problem though. Still I'd suggest to users who want 
to use the package to rename the init.lua that comes with CTX and then 
bind it within their own init.lua with


require('context_init')      -- exemplary file name

If anything goes wrong then, users simply have to comment the line with 
Notepad and TA should work again.


I am pretty sure that you know that already, but unexperienced readers 
might want to know that there is a Spell Checking module for TA which 
can be found under Modules in the TA wiki (it comes with only an english 
dictionary though):


I don't now as I don't follow discussions (I'm only on a few context 
related mailing lists). And we need checking for more than english (as 
well as our own lists) + a bit more subtle indication of issues.


True indeed. I like your config settings when it comes to highlighting 
etc. Also they come with a lot of keywords. That's a big plus as well. 
But since the settings change a lot in TA, for example tabulation width, 
they are pretty unfriendly to non-programmers. For example I tried to 
change the behaviour of TA9 to wrap lines when a CTX file is loaded. I 
don't remember in which file I changed the setting, but it didn't make a 
difference. Lines didn't wrap, so I always had to change it manually. In 
the same file I changed tab width, this change on the other hand worked. 
And there comes the next tripping stone. The CTX settings come within 
many files with a strict hierarchy, so that beginners will have a hard 
time to achieve changes. The changes are overwhelming really, but it's 
worth getting used to them.
So please don't get me wrong. I am thankful that CTX comes with settings 
for TA at all. It's ofc better than nothing.


Hm, I never wrap (i.e. I have my sources wrapped already) so I can't 
comment on that.


I just think that Lua makes it worthwhile for users to change settings 
by themselves, so they know how TA works in it's core. I'd love to add, 
that right now I am using one skin file, one custom CTX lexer (mod of 
the original TA lexer), a snippets file and two init.luas of which one I 
only load on my tablet to add some basic functionality to it's digital 
keyboard (which wasn't necessary in SciTE btw.) I think it looks great 
so far, although it surely could use some adjustments.

TAlexed.jpg


All a matter of taste I guess. I mostly ship the lexers because they are 
sort of a reference for how i expect files to be highlighted. Also, the 
same highlighting can be used in typeset form. But every user has 
her/his own preference and "which is the best editor debates" are not 
something I'm interested in.


And I really miss your snippets amongst some other small things, but the 
longer one tries, the further he comes with adjusting TA to his likings.


I never use snippets (assuming they are what i think they are) because i 
can't remember shortcuts and keying in the few commands needed for 
structure can (in my case) be neglected compared to keying in content


Maybe in the future you'll have on horse that you can fully rely on. I 
wish it'd be TA IMHO. :)


Too much a moving (upward imcompatible) target I fear. I can't risk that 
for workflows where authors have to 'just install and run'.


Just wanted to add my ideas to yours. Thanks for CTX, the TA settings 
and for reading this mail.

No problem.

(Maybe you can make a list of relevant differnces between TA 9 and 10 
because otherwise I need a new stack of cd's to motivate me get me 
through the trial and error process (due to lack of lua console output).)


Hans

-
   

Re: [NTG-context] future versions - synctex

[Hans Hagen]

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

[Procházka Lukáš Ing .]

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
___

Re: [NTG-context] Textadept with ConTeXt

[cryo shock]

Thanks a lot!

Am Di., 21. Aug. 2018 um 09:06 Uhr schrieb Hans Hagen :

> On 8/21/2018 1:59 AM, Lars wrote:
> > Hi there, thanks for your interest in Textadept. It's a great editor and
> > I am sure that you won't regret testing it and using it in the future.
> > Just have some patience.
>
> i played with it a few times but its biggest drawback is the lack of a
> fast and realtime console pane like scite has so i keep coming back to
> scite (on the contrary scite has the lpeg lexer extern and its lua is
> not shared with scites lua which is a drawback there) .. so currently i
> see ta as a fallback
>
> in the context distrubution there are actually files for textadept but
> because its (still?) a moving target with a changing interface i'm not
> sure if it works with the latest (it's btw one reason why the files that
> ship with context basically reset a lot of the fetaures because as usual
> with editors, they tend to add lots of key bindings and stuff not needed
> for tex and friends)
>
> anyway,
>
> ../context/data/textadept/context/textadept-context.cmd
> ../context/data/textadept/context/textadept-context.sh
>
> still work on my machine so ... it's kind of providing the same
> functionality as we use in scite.
>
> > *Fifth, is your context lexer loaded when you compile the file?* Check
> > the status bar in the lower right corner. If it doesn't say "context"
> > but "latex" or "text" or anything like that, then choose the context
> > lexer via "Buffer" -> "Select lexer...".
> the lexer that we use in scite and textadept both use the textadept
> lexer dll (which plugs into scintilla) but because the lua code that
> came with it kept changing and i needed way better performance (for
> large files like char-def) than was possible at that time i also rewrote
> that code for our purpose (also because i wanted spell checking, utf
> and such) ...
>
> at some point the ta lexing method changed a bit so it became faster ...
> all such such lexers sort of follow the same approach, mark regions and
> associate them and we already had similar stuff on board in context so i
> could combine things a bit
>
> i think that the scite/ta lexers that we ship are quite ok (i've now
> used them for years) and they are probably better than the context lexer
> that comes with textadept, i.e. the context one supports a mix of tex,
> mp, lua etc, knows primitives, commands, helpers, and follows up on the
> way we have had syntax highlighting for decades which in turn closely
> relates to the way the context user interface evolved
>
> notepad++ does use the same scintilla editing framework but cannot load
> the lexer dll; it does bidi a bit better
>
> anyway, with both scite and ta i can gamble on two horses
>
>
>
> 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] Textadept with ConTeXt

[Hans Hagen]

On 8/21/2018 1:59 AM, Lars wrote:
Hi there, thanks for your interest in Textadept. It's a great editor and 
I am sure that you won't regret testing it and using it in the future. 
Just have some patience.


i played with it a few times but its biggest drawback is the lack of a 
fast and realtime console pane like scite has so i keep coming back to 
scite (on the contrary scite has the lpeg lexer extern and its lua is 
not shared with scites lua which is a drawback there) .. so currently i 
see ta as a fallback


in the context distrubution there are actually files for textadept but 
because its (still?) a moving target with a changing interface i'm not 
sure if it works with the latest (it's btw one reason why the files that 
ship with context basically reset a lot of the fetaures because as usual 
with editors, they tend to add lots of key bindings and stuff not needed 
for tex and friends)


anyway,

../context/data/textadept/context/textadept-context.cmd
../context/data/textadept/context/textadept-context.sh

still work on my machine so ... it's kind of providing the same 
functionality as we use in scite.


*Fifth, is your context lexer loaded when you compile the file?* Check 
the status bar in the lower right corner. If it doesn't say "context" 
but "latex" or "text" or anything like that, then choose the context 
lexer via "Buffer" -> "Select lexer...".
the lexer that we use in scite and textadept both use the textadept 
lexer dll (which plugs into scintilla) but because the lua code that 
came with it kept changing and i needed way better performance (for 
large files like char-def) than was possible at that time i also rewrote 
that code for our purpose (also because i wanted spell checking, utf 
and such) ...


at some point the ta lexing method changed a bit so it became faster ...
all such such lexers sort of follow the same approach, mark regions and 
associate them and we already had similar stuff on board in context so i 
could combine things a bit


i think that the scite/ta lexers that we ship are quite ok (i've now 
used them for years) and they are probably better than the context lexer 
that comes with textadept, i.e. the context one supports a mix of tex, 
mp, lua etc, knows primitives, commands, helpers, and follows up on the 
way we have had syntax highlighting for decades which in turn closely 
relates to the way the context user interface evolved


notepad++ does use the same scintilla editing framework but cannot load 
the lexer dll; it does bidi a bit better


anyway, with both scite and ta i can gamble on two horses



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
___