On 2 July 2010 10:41, Wolfgang Schuster
schuster.wolfg...@googlemail.com wrote:
Am 30.06.10 12:57, schrieb Marius:
Hello,
I think that the best way is to put command syntax description just
before its definition in the context file. This way it will be easier
to keep it always in sync with
Am 05.07.10 12:26, schrieb Taco Hoekwater:
On 07/05/2010 11:44 AM, Marius wrote:
On Fri, Jul 2, 2010 at 1:21 PM, Taco Hoekwatert...@elvenkind.com
wrote:
I think this will be a wasted effort. I predict that any future
version of context that will be able to do syntax checking is going
to be
Wolfgang Schuster wrote:
I'm against storing the command definition in the relevant files because
the definitions are meant for documentation and it's nonsense in this way
because you need sometimes references to other commands and who should
you show a command for spacing which is written in a
On 6-7-2010 8:23, taco wrote:
sorry for delays in responding ... i'm still in the process of fixing
hardware / installations etc
Wolfgang Schuster wrote:
I'm against storing the command definition in the relevant files because
the definitions are meant for documentation and it's nonsense
On Fri, Jul 2, 2010 at 1:21 PM, Taco Hoekwater t...@elvenkind.com wrote:
I think this will be a wasted effort. I predict that any future
version of context that will be able to do syntax checking is going
to be based on lua for the verification process, not tex macros.
There is already an
On 07/05/2010 11:44 AM, Marius wrote:
On Fri, Jul 2, 2010 at 1:21 PM, Taco Hoekwatert...@elvenkind.com wrote:
I think this will be a wasted effort. I predict that any future
version of context that will be able to do syntax checking is going
to be based on lua for the verification process,
Am 30.06.10 12:57, schrieb Marius:
Hello,
I think that the best way is to put command syntax description just
before its definition in the context file. This way it will be easier
to keep it always in sync with the code. And most important point here
is that it must be in sync always. If it is,
On Fri, Jul 02 2010, Wolfgang Schuster wrote:
The idea is not bad but who is going to do this? Hans implemented
in mkiv the function to check assignments list of valid keys but
this function isn't used because nobody writes the necessary lists
which contexts requires to do these checks and
On 07/02/2010 11:28 AM, Peter Münster wrote:
On Fri, Jul 02 2010, Wolfgang Schuster wrote:
The idea is not bad but who is going to do this? Hans implemented
in mkiv the function to check assignments list of valid keys but
this function isn't used because nobody writes the necessary lists
which
On Wed, Jun 16 2010, Wolfgang Schuster wrote:
i plan to update cont-en.xml with changes in mkiv (new keys and commands)
Hello Wolfgang,
Since Hans said documentation about tex can best be done in tex, I've put
my ideas into some files here:
http://pmrb.free.fr/tmp/context-commands/
What do
On Wed, 16 Jun 2010, Wolfgang Schuster wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and commands) but
i'm unsure if it's good to mix mkii and mkiv. I think it's to make a separate
definition file for mkiv which contains the extra keys for the commands (e.g.
On 17-6-2010 3:11, Mojca Miklavec wrote:
On Wed, Jun 16, 2010 at 19:56, Wolfgang Schuster
schuster.wolfg...@googlemail.com wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and commands)
but i'm unsure if it's good to mix mkii and mkiv. I think it's to make a
separate
On Fri, Jun 18, 2010 at 10:58, Hans Hagen wrote:
On 17-6-2010 3:11, Mojca Miklavec wrote:
Even though the fact that mkii is frozen might be true, most of
valid options are still missing in those xml files.
well, 'most' is not fair
I'm sorry, I probably wanted to say that most of
On 16-6-2010 7:56, Wolfgang Schuster wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and
commands) but i'm unsure if it's good to mix mkii and mkiv. I think it's
to make a separate definition file for mkiv which contains the extra
keys for the commands (e.g.
On 16-6-2010 7:56, Wolfgang Schuster wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and
commands) but i'm unsure if it's good to mix mkii and mkiv. I think it's
to make a separate definition file for mkiv which contains the extra
keys for the commands (e.g.
On Wed, Jun 16, 2010 at 19:56, Wolfgang Schuster
schuster.wolfg...@googlemail.com wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and commands)
but i'm unsure if it's good to mix mkii and mkiv. I think it's to make a
separate definition file for mkiv which contains the
Am 17.06.10 15:11, schrieb Mojca Miklavec:
On Wed, Jun 16, 2010 at 19:56, Wolfgang Schuster
schuster.wolfg...@googlemail.com wrote:
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and commands)
but i'm unsure if it's good to mix mkii and mkiv. I think it's to make a
Hi,
i plan to update cont-en.xml with changes in mkiv (new keys and
commands) but i'm unsure if it's good to mix mkii and mkiv. I think it's
to make a separate definition file for mkiv which contains the extra
keys for the commands (e.g. sectionsegments for \setuphead) and use the
current
Patrick Gundlach wrote:
Hi,
(see setupinterlinespace2 for example, it has variant 2 but there is no
setupinterlinespace2 with variant 1).
IIRC, that trailing 2 in setupinterlinespace2 was just added due to my
misunderstanding of how \showsetup works.
Best wishes,
Taco
Hi,
in cont-en.xml there are two places that are unusal
1) cd:inherit with optional=no:
cd:command name=setupbodyfontenvironment file=font-ini.tex category=font
s
cd:sequence
cd:string value=setupbodyfontenvironment/
/cd:sequence
cd:arguments
cd:keywords n=1
Hi,
could we add some unique key to the commands? That way we could have a
more reliable way to know which command is which. It is useful when you
use cd:inherit and refer to a command, such as color (which can be an
environment or a standalone command) or commands with variants. It even
removes
Patrick Gundlach wrote:
Hi,
could we add some unique key to the commands? That way we could have a
more reliable way to know which command is which. It is useful when you
use cd:inherit and refer to a command, such as color (which can be an
environment or a standalone command) or commands with
Patrick Gundlach wrote:
Hi,
could this:
symalign references symalign, which is not defined.
cd:parameter name=symalign
cd:resolve name=symalign/
/cd:parameter
in setupitemgroup, line 6072.
and
cd:keywords optional=yes
cd:constant name=lefttext/
Hi,
So you also use the advanced feature with the cd:define keys? I
recently came across a problem there, but I can't remember which it
was, I'll try and find out again.
symalign references symalign, which is not defined.
cd:parameter name=symalign
cd:resolve name=symalign/
Patrick Gundlach wrote:
Hi,
So you also use the advanced feature with the cd:define keys? I
recently came across a problem there, but I can't remember which it
was, I'll try and find out again.
symalign references symalign, which is not defined.
cd:parameter name=symalign
Patrick Gundlach wrote:
Hi,
how is cont-en.xml and the related files currently maintained? Is this
file created of some other file or is it updated manually?
manual (it would make sense to merge it in the sources but ..)
What are the current applications that use the xml-files?
reference
26 matches
Mail list logo
