ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <j.hagen@xs4all.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>,
	Nicola <nvitacolonna@gmail.com>
Subject: Re: How to write readable source files?
Date: Sat, 29 May 2021 19:08:58 +0200	[thread overview]
Message-ID: <d51b0499-900e-b8fb-5abe-398ddeef3edb@xs4all.nl> (raw)
In-Reply-To: <s8tl4b$enp$1@ciao.gmane.io>

On 5/29/2021 5:03 PM, Nicola wrote:
> On 2021-04-25, Hans Hagen <j.hagen@xs4all.nl> wrote:
>>> If there is a way to automatically get a list of all ConTeXt commands
>>> and options (and, ideally, MetaFun defs, types, and other keywords), I'd
>>> be happy to improve omni-completion for ConTeXt in Vim.
>> All is in xml files (i-*.xml) in the distribution maintained by
>> Wolfgang. We ship with this for editors:
>>
>>> dir t:\texmf\context\data
>>
>> 04/21/2021  11:40 AM    <DIR>          scite
>> 04/21/2021  11:40 AM    <DIR>          textadept
>> 04/21/2021  11:40 AM    <DIR>          texworks
>> 04/21/2021  11:40 AM    <DIR>          vscode
>>
>> these lists are generated by mtx-interface so we can add more if needed
> 
> Could you please elaborate on the (automatic?) data flow from ConTeXt's
> source files to data files for each application? Is it:
> 
> source code -> XML -> .lua -> mtx-interface -> data?
> 
> In particular, it is not clear to me how i-*.xml files are related to
> mtx-interface, as the latter does not use them directly, AFAICS.

for sure it does

in the early days of context mkii we had \startsetups kind of 
definitions that got filtered from the source but when xml support was 
built that moved to an xml file

then Wolfgang did an excellent job on checking each xml snippet and 
added many more and these i-* files showed up, we extended the xml a 
bit, redid the rendering of these lists etc

wolfgang is in charge of this so when something specific in the files is 
needed ...

> Anyway, mtx-interface seems exactly what I am looking for, and I would
> like to use it to generate ConTeXt keywords for Vim. Can I patch that
> script?

basically we only need

function flushers.vim(collected)
end

> For MetaFun keywords I don't know yet: do those XML files contain enough
> information about the content of all mp-* source files? E.g., the fact
> that `hlingrid` is a def? Looking at the Scite files, I see only
> internals and commands, and they seem to cover only the "main" MetaFun
> names.

it is still on the agenda to make xml files for metafun but there is no 
timeline for that

now, when it comes to highlighting, the reference is the scite one 
(which supports several of the languages that we use, and also supports 
mixed lua/mp/tex/... lexing) ... right from the start the way it shows 
up in an editor determined how the user interface evolved ... believe it 
or not, but for a long time we used texedit (written in modula, was 
pretty ok in 640K mem, also fast and one could scroll files in the 
sidebar and see them instantly; it used the character based windowing 
i'd written as a student for terminals connected to a dec vax .. just 
for fun ... i'm that old) ... when modula disappeared i actually rewrote 
that one in perl/tk and it still works but then decided to use scite

anyway, so scite is still my reference (i looked to vscode but seeing 
all this extra stuff, the need for 'servers', the lack of simply running 
a command based on suffix ... not now)

that said, we can support whatever editor one uses makes much sense (one 
should really use the editor, word processor, operating system etc one 
feels most comfortable with) so just make a prototype (or tell me what 
kind of lists you need, because it's rather trivial to generate them)

> I have used a custom script in the past for fine-grained keyword
> extraction from MetaFun's source code. By fine-grained, I mean that the
> output contains information about the kind of keyword (def, primary def,
> vardef, constant, variable, etc.) I could update it to Lua and mp-*.mpxl
> if that interests you—unless that has already been done, of course.
just look at the files in the scite path ... much info is available, for 
context it comes from the xml files, for the tex engine and meta* it 
comes from mult* lua files

adding more detail (not sure if distinguishing between def and vardef 
makes sense ... we more use the 'primitive', 'lowlevel', 'interface' 
kind of grouping

let's see what Wolfgang thinks of it ...

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
___________________________________________________________________________________

  reply	other threads:[~2021-05-29 17:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-24  9:45 Jan U. Hasecke
2021-04-24 11:55 ` Henning Hraban Ramm
2021-04-24 13:25   ` Hans van der Meer
2021-04-24 13:45   ` juh
2021-04-24 19:25     ` Nicola
2021-04-25  7:13       ` juh
2021-04-25 12:12         ` Nicola
2021-04-25 12:24           ` Hans Hagen
2021-05-29 15:03             ` Nicola
2021-05-29 17:08               ` Hans Hagen [this message]
2021-05-29 18:29                 ` Nicola
2021-05-29 23:04                   ` Hans Hagen
2021-05-30  8:13                     ` Nicola
2021-04-24 12:12 ` luigi scarso
2021-04-24 15:17 ` Hans Hagen

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=d51b0499-900e-b8fb-5abe-398ddeef3edb@xs4all.nl \
    --to=j.hagen@xs4all.nl \
    --cc=ntg-context@ntg.nl \
    --cc=nvitacolonna@gmail.com \
    /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).