RE: bug in latest ConTeXt (confirmed)

RE: bug in latest ConTeXt (confirmed)

[ishamid]

Hi Hans,

>===== Original Message From Hans Hagen <pragma@wxs.nl> =====
>at the moment the best way of dealing with is is to use texexec's engine 
handler;
>
>locate texexec.ini (or rme) and set
>
>set UseEnginePath to true
>
>after that pdfetex, aleph, xetex, mpost etc will end up on their own path.

I have done that previously and, yes, I do get the subdirectories. But that's 
not the problem. The problem is that aleph is searching for its format in 
pdfetex's subdirectory:

This is Aleph, Version 3.141592-1.15-2.1-0.0-rc4 (Web2c 7.5.3)
 \write18 enabled.
Copyright (c) 2002--2004 the Aleph task force
---! c:\CONTEXT\tex\texmf-mswin/web2c/pdfetex/cont-en.fmt was written by 
pdfetex

How do we make aleph search its own subdirectory?

Just to be sure, texexec --verbose gives

setting : 'UseEnginePath' to 'true' for 'all'

Best
Idris

============================
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

RE: bug in latest ConTeXt (confirmed)

[ishamid]

>===== Original Message From Hans Hagen <pragma@wxs.nl> =====
>ishamid wrote:
>
>> lines all over the place in my work that compiled fine with the old ConTeX,
>> and I suspect that XeTeX may be responsible. Is there a way to completely
>> isolate the new stuff because I'm going to lose a lot of time trying to 
track
>> down every situation where my previously well-behaved stuff now gives 
errors
>> because of this.
>
>just put \endinput atthe topmost lin eof supp-dir.tex and remake the format

Those problems I told you about in a private email are still being caused by 
supp-dir, even after  \endinput. I played around with supp-dir and thise 
following works;-)

==========================================================
\unprotect

\chardef\inlinedirection\zerocount % 0==notset 1==LR 2==RL

\beginETEX \beginL

%  \def\pardir#1#2#3% messages end up in a higher level command
%    {\global\TeXXeTstate\plusone
%     \if#2L\chardef\inlinedirection\plusone\else
%     \if#2R\chardef\inlinedirection\plustwo\fi\fi
%     \checkinlinedirection} % needed / added

 %\appendtoks \checkinlinedirection \to \everypar % see core-ini.tex

  \def\checkinlinedirection
    {\ifcase\inlinedirection\or\beginL\or\beginR\fi}

\endETEX

\protect \endinput
==========================================================

It seems that the \checkinlinedirection is still needed or I get other errors.

I hope that you and Adam can up with something that won't kill me next time:-)

Best
Idris

============================
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

Re: bug in latest ConTeXt (confirmed)

[Hans Hagen]

ishamid wrote:

> Ok, the new supp-dir.tex helps. But there is another problem. Now my following 
> macros are messed up (used in our private ar-cont.tex)

one reason more for a layer of abstraction -)

> \let\beginRL=\leavevmode\startarabictext

\let\beginRL=\startarabictext

or:

\def\beginRL{\dontleavehmode\startarabictext}

it was a miracle that your code worked anyway since your \beginLR was equal to 
\leavevmode and you entered arabictext immediately

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

Re: bug in latest ConTeXt (confirmed)

[Hans Hagen]

ishamid wrote:

> This has been a really frustrating week...

sorry for that

i played a it with the $engine stuff in web2c and (as adam already found out for 
xetex) somehow that mechanism does not work well [one can set en engine in 
texmf.cnf, like

TEXFORMATS    = .;$TEXMF/web2c/{$engine,}
MFBASES       = .;$TEXFORMATS
MPMEMS        = .;$TEXFORMATS
TEXPOOL       = .;$TEXFORMATS
MFPOOL        = .;$TEXFORMATS
MPPOOL        = .;$TEXFORMATS

but when generating format files that way, pool files are not found and such.

at the moment the best way of dealing with is is to use texexec's engine handler;

locate texexec.ini (or rme) and set

set UseEnginePath to true

after that pdfetex, aleph, xetex, mpost etc will end up on their own path.

(in case of the minimal distribution, TEXFORMATS are set to an os specific texmf 
tree, say texmf-linux/web2c or texmf-mswin/web2c, so don't worry about the cnf 
file; currently texexec prepends the engine subpath so it should work this way 
but it's kind of a hack because in the future i'd like kpse to handle it - also, 
problems will be less when pool files move into the binary - there have been 
some discussions about that recently)

Hans


-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

Re: bug in latest ConTeXt (confirmed)

[Hans Hagen]

ishamid wrote:

> lines all over the place in my work that compiled fine with the old ConTeX, 
> and I suspect that XeTeX may be responsible. Is there a way to completely 
> isolate the new stuff because I'm going to lose a lot of time trying to track 
> down every situation where my previously well-behaved stuff now gives errors 
> because of this.

just put \endinput atthe topmost lin eof supp-dir.tex and remake the format

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

RE: bug in latest ConTeXt (confirmed)

[ishamid]

>===== Original Message From Hans Hagen <pragma@wxs.nl> =====
>> Sounds like supp-dir needs a no-Omega check, as well. Hans?
>
>attached for testing, i dunny what the pardir equivalents are for \beginL and
>\beginR -)

Not to belabor this, but I'm getting

### simple group (level 1) entered at line

lines all over the place in my work that compiled fine with the old ConTeX, 
and I suspect that XeTeX may be responsible. Is there a way to completely 
isolate the new stuff because I'm going to lose a lot of time trying to track 
down every situation where my previously well-behaved stuff now gives errors 
because of this.

This has been a really frustrating week...

Idris

============================
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

RE: bug in latest ConTeXt (confirmed)

[ishamid]

>===== Original Message From Hans Hagen <pragma@wxs.nl> =====
>> Sounds like supp-dir needs a no-Omega check, as well. Hans?
>
>attached for testing, i dunny what the pardir equivalents are for \beginL and
>\beginR -)

Ok, the new supp-dir.tex helps. But there is another problem. Now my following 
macros are messed up (used in our private ar-cont.tex)

\let\beginRL=\leavevmode\startarabictext
\let\endRL=\stoparabictext

\catcode`\<=\active
\catcode`\>=\active

\defineactivecharacter < {\enclosedarabic}
\def\enclosedarabic#1>{\struttedbox{\beginRL#1\endRL}}

Aleph complains that

(\end occurred inside a group at level 2)

### semi simple group (level 2) entered at line 102 (\begingroup)
### simple group (level 1) entered at line 102 ({)
### bottom level

Can you fix the XeTeX macros so that this is no longer affected? I also have 
some otp's that use the \beginRL\endRL syntax; I'm afraid that's all going to 
be negatively affected now...

Idris

============================
Professor Idris Samawi Hamid
Department of Philosophy
Colorado State University
Fort Collins, CO 80523

Re: bug in latest ConTeXt (confirmed)

[Hans Hagen]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Adam Lindsay wrote:
> ishamid said this at Tue, 22 Mar 2005 18:30:48 -0700:
> 
> 
>>! Undefined control sequence.
>>\pardir #1#2#3->\global \TeXXeTstate
>>                                    \plusone \if #2L\chardef 
>>\inlinedirecti...
>>l.1 \pardir TLT
> 
> 
> Oops, I think I recognize this.
> This came about when Hans and I were trying to introduce some very basic
> imitations of Omega's bidi support, prompted by XeTeX's Unicode
> capabilities. Unfortunately, it rests on an eTeX check--not a problem
> with Omega, but with Aleph, it means we clobber the \pardir primitives!
> Oops, indeed.
> 
> Sounds like supp-dir needs a no-Omega check, as well. Hans?

attached for testing, i dunny what the pardir equivalents are for \beginL and 
\beginR -)

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
      tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------

[-- Attachment #2: supp-dir.tex --]
[-- Type: application/x-tex, Size: 1563 bytes --]

[-- Attachment #3: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: bug in latest ConTeXt (confirmed)

[Adam Lindsay]

ishamid said this at Tue, 22 Mar 2005 18:30:48 -0700:

>! Undefined control sequence.
>\pardir #1#2#3->\global \TeXXeTstate
>                                     \plusone \if #2L\chardef 
>\inlinedirecti...
>l.1 \pardir TLT

Oops, I think I recognize this.
This came about when Hans and I were trying to introduce some very basic
imitations of Omega's bidi support, prompted by XeTeX's Unicode
capabilities. Unfortunately, it rests on an eTeX check--not a problem
with Omega, but with Aleph, it means we clobber the \pardir primitives!
Oops, indeed.

Sounds like supp-dir needs a no-Omega check, as well. Hans?

adam
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Adam T. Lindsay, Computing Dept.     atl@comp.lancs.ac.uk
 Lancaster University, InfoLab21        +44(0)1524/510.514
 Lancaster, LA1 4WA, UK             Fax:+44(0)1524/510.492
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-