Hello,

\AtBeginOfFile* {filehook.sty}{\expandafter \let
     \csname ver@filehook.sty\endcsname \@undefined }

Well... Think about it.

If filehook is loaded, the "hook" is executed at once, just
like if it was said: \AtEndOfPackageFile* {filehook}

I think there is no point to provide star forms for the
\AtBegin<...> hooks.

When will they be executed otherwise ?
\AtBeginOfFile means: before the file is loaded. If the file
is loaded already, it could be dangerous to set such a hook.
Otherwise, the user had said: \AtEndOfFile*

Am I wrong ?

Yours sincerely.

On Mar 23, 1:22=A0pm, GL <gouail...@gmail.com> wrote:
> Hello,
>
> \AtBeginOfFile* {filehook.sty}{\expandafter \let
> =A0 =A0 =A0\csname v...@filehook.sty\endcsname \@undefined }

This should be  \AtBeginOfPackageFile* {filehook.sty}.
There is no star form of \AtBeginOfFile.

> Well... Think about it.
>
> If filehook is loaded, the "hook" is executed at once, just
> like if it was said: \AtEndOfPackageFile* {filehook}
>
> I think there is no point to provide star forms for the
> \AtBegin<...> hooks.
>
> When will they be executed otherwise ?
> \AtBeginOfFile means: before the file is loaded. If the file
> is loaded already, it could be dangerous to set such a hook.
> Otherwise, the user had said: \AtEndOfFile*
>
> Am I wrong ?

I need  \AtBeginOfPackageFile* to change some internal code before
loading the to-be-patched related packages `scrfile` and `fink`
which is then done  \AtEndOfPackageFile*. In the case when this
packages where loaded beforehand the code in \AtEndOfPackageFile*
would break/produce errors
because of the missing initialization.  So I added the star versions
of the  \AtBeginOfPackageFile and  \AtBeginOfClassFile.

While they wont be used as often as \AtEndOfXXXXFile* it is IMHO no
harm to have them. If the user wants to break his document I can do so
without them as well.

Best Regards,
Martin Scharrer

Le 23/03/2011 15:32, Martin Scharrer a �crit :
> On Mar 23, 1:22 pm, GL<gouail...@gmail.com>  wrote:
>> Hello,
>>
>> \AtBeginOfFile* {filehook.sty}{\expandafter \let
>>       \csname v...@filehook.sty\endcsname \@undefined }
>
> This should be  \AtBeginOfPackageFile* {filehook.sty}.
> There is no star form of \AtBeginOfFile.
>
>> Well... Think about it.
>>
>> If filehook is loaded, the "hook" is executed at once, just
>> like if it was said: \AtEndOfPackageFile* {filehook}
>>
>> I think there is no point to provide star forms for the
>> \AtBegin<...>  hooks.
>>
>> When will they be executed otherwise ?
>> \AtBeginOfFile means: before the file is loaded. If the file
>> is loaded already, it could be dangerous to set such a hook.
>> Otherwise, the user had said: \AtEndOfFile*
>>
>> Am I wrong ?
>
> I need  \AtBeginOfPackageFile* to change some internal code before
> loading the to-be-patched related packages `scrfile` and `fink`
> which is then done  \AtEndOfPackageFile*. In the case when this
> packages where loaded beforehand the code in \AtEndOfPackageFile*
> would break/produce errors
> because of the missing initialization.  So I added the star versions
> of the  \AtBeginOfPackageFile and  \AtBeginOfClassFile.

Yeah I didn't notice that thanks !
Then it would be better to define internal commands for this purpose:
      filehook@AtBefore{srclfile}
Or simply:
     \ifdefined\scrlfileversion     ....
     \else \AtBeginOfPackageFile {scrlfile}{....}
     \fi

scrlfile does CheckCommand on \InputIfFileExists first.

More important, the following does not work:

% ---------------------------------------------
\documentclass [a4paper]{article}
\usepackage {filehook}
%\usepackage {scrlfile,interfaces}

\begin{document}\makeatletter

%\AfterFile{\jobname.toc}{End of the table of contents}
\AtEndOfFile{\jobname.toc}{End of the table of contents}

\tableofcontents

\section{One}


\end{document}\endinput
% ---------------------------------------

interfaces did the following to enable the hooks for
files that are loaded with \@input:

\renewcommand*\@input[1]{\IfFileExists{#1}
    {\scr@load@hook{before}{#1}%
     \@@input\@filef@und
     \scr@load@hook{after}{#1}}%
    {\typeout{No file #1.}}%
}% \@input


I say 'did' because it would be nice if filehook hooks
worked with \@input and hence for \tableofcontents.

interfaces needs such hooks: this allows to implement
very simply a multicolumn table of contents.

I would like interfaces to rely on filehook rather than
scrlfile if possible. Next version promises to be much more
clean than previous ones...







Is this on purpose that you use ^^J instead of \MessageBreak which
preserve alignment in your \PackageError(s) ?


\ifcase
     \ifx\InputIfFileExists\latex@InputIfFileExists 0\else
     \ifx\InputIfFileExists\memoir@InputIfFileExists 0\else
      1%
     \fi\fi
\relax

is often more readable as:

\ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
        \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
        1\relax


> While they wont be used as often as \AtEndOfXXXXFile* it is IMHO no
> harm to have them. If the user wants to break his document I can do so
> without them as well.

Yes but conversely the documentation for filehook presents the star
form \AtBeginOfPackageFile*  and this is confusing at least !

Regards.

>
> Best Regards,
> Martin Scharrer
>

Le 23/03/2011 15:32, Martin Scharrer a �crit :
> On Mar 23, 1:22 pm, GL<gouail...@gmail.com>  wrote:
>> Hello,
>>

Sometimes you take care about silent assignments to \relax in
  \csname ... \endcsname and the hooks are always:

\@nameuse{\filehook@include@after@#1}

which makes the assignment.

It would be an improvement to replace \@nameuse by
something like \csuse provided by etoolbox to avoid this.

Best regards.

On Mar 23, 2:59=A0pm, GL <gouail...@gmail.com> wrote:
> Le 23/03/2011 15:32, Martin Scharrer a crit :
>
>
>
> > On Mar 23, 1:22 pm, GL<gouail...@gmail.com> =A0wrote:
> >> Hello,
>
> >> \AtBeginOfFile* {filehook.sty}{\expandafter \let
> >> =A0 =A0 =A0 \csname v...@filehook.sty\endcsname \@undefined }
>
> > This should be =A0\AtBeginOfPackageFile* {filehook.sty}.
> > There is no star form of \AtBeginOfFile.
>
> >> Well... Think about it.
>
> >> If filehook is loaded, the "hook" is executed at once, just
> >> like if it was said: \AtEndOfPackageFile* {filehook}
>
> >> I think there is no point to provide star forms for the
> >> \AtBegin<...> =A0hooks.
>
> >> When will they be executed otherwise ?
> >> \AtBeginOfFile means: before the file is loaded. If the file
> >> is loaded already, it could be dangerous to set such a hook.
> >> Otherwise, the user had said: \AtEndOfFile*
>
> >> Am I wrong ?
>
> > I need =A0\AtBeginOfPackageFile* to change some internal code before
> > loading the to-be-patched related packages `scrfile` and `fink`
> > which is then done =A0\AtEndOfPackageFile*. In the case when this
> > packages where loaded beforehand the code in \AtEndOfPackageFile*
> > would break/produce errors
> > because of the missing initialization. =A0So I added the star versions
> > of the =A0\AtBeginOfPackageFile and =A0\AtBeginOfClassFile.
>
> Yeah I didn't notice that thanks !
> Then it would be better to define internal commands for this purpose:
> =A0 =A0 =A0 filehook@AtBefore{srclfile}
> Or simply:
> =A0 =A0 =A0\ifdefined\scrlfileversion =A0 =A0 ....
> =A0 =A0 =A0\else \AtBeginOfPackageFile {scrlfile}{....}
> =A0 =A0 =A0\fi
>
> scrlfile does CheckCommand on \InputIfFileExists first.
Yes, that's the reason I change it back to the default value at begin
of scrlfile.

At first I had a \@ifloaded to check for srclfile and then thought
that a starred version of AtBegin... would be better :-)



>
> More important, the following does not work:
>
> % ---------------------------------------------
> \documentclass [a4paper]{article}
> \usepackage {filehook}
> %\usepackage {scrlfile,interfaces}
>
> \begin{document}\makeatletter
>
> %\AfterFile{\jobname.toc}{End of the table of contents}
> \AtEndOfFile{\jobname.toc}{End of the table of contents}
>
> \tableofcontents
>
> \section{One}
>
> \end{document}\endinput
> % ---------------------------------------
>
> interfaces did the following to enable the hooks for
> files that are loaded with \@input:
>
> \renewcommand*\@input[1]{\IfFileExists{#1}
> =A0 =A0 {\scr@load@hook{before}{#1}%
> =A0 =A0 =A0\@@input\@filef@und
> =A0 =A0 =A0\scr@load@hook{after}{#1}}%
> =A0 =A0 {\typeout{No file #1.}}%
>
> }% \@input
>
> I say 'did' because it would be nice if filehook hooks
> worked with \@input and hence for \tableofcontents.
Originally I tried to avoid processing aux files.
I needed `filehook` first for `svn-multi`s to collect a file list for `
\tableofrevisions` where
you don't like to have .toc and .aux etc. in it.
Also in some cases (like \lstinputlistings) you want to read external
files without
executing hooks. In the past I suggested doing this using \@input.
But I see your point and might add it. Maybe as an option.


>
> interfaces needs such hooks: this allows to implement
> very simply a multicolumn table of contents.
>
> I would like interfaces to rely on filehook rather than
> scrlfile if possible. Next version promises to be much more
> clean than previous ones...
>
> Is this on purpose that you use ^^J instead of \MessageBreak which
> preserve alignment in your \PackageError(s) ?
No, actually just a bad habit.

> \ifcase
> =A0 =A0 =A0\ifx\InputIfFileExists\latex@InputIfFileExists 0\else
> =A0 =A0 =A0\ifx\InputIfFileExists\memoir@InputIfFileExists 0\else
> =A0 =A0 =A0 1%
> =A0 =A0 =A0\fi\fi
> \relax
>
> is often more readable as:
>
> \ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
> =A0 =A0 =A0 =A0 \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
> =A0 =A0 =A0 =A0 1\relax
Thanks, I will have a look on that.

>
> > While they wont be used as often as \AtEndOfXXXXFile* it is IMHO no
> > harm to have them. If the user wants to break his document I can do so
> > without them as well.
>
> Yes but conversely the documentation for filehook presents the star
> form \AtBeginOfPackageFile* =A0and this is confusing at least !
I see. The star in the documentation is gray which means it is
optional. The optional [ ] arguments are also gray for this purpose.
But you are right, it isn't very clear and I should display both the
normal and the starred version instead.

On Mar 23, 3:15=A0pm, GL <gouail...@gmail.com> wrote:
> Le 23/03/2011 15:32, Martin Scharrer a =E9crit :
>
> > On Mar 23, 1:22 pm, GL<gouail...@gmail.com> =A0wrote:
> >> Hello,
>
> Sometimes you take care about silent assignments to \relax in
> =A0 \csname ... \endcsname and the hooks are always:
>
> \@nameuse{\filehook@include@after@#1}
>
> which makes the assignment.
>
> It would be an improvement to replace \@nameuse by
> something like \csuse provided by etoolbox to avoid this.
Yes, I'm actually thinking about to change my packages to use
etoolbox.

Le 23/03/2011 22:14, Martin Scharrer a �crit :
> On Mar 23, 3:15 pm, GL<gouail...@gmail.com>  wrote:
>> Le 23/03/2011 15:32, Martin Scharrer a �crit :
>>
>>
>> It would be an improvement to replace \@nameuse by
>> something like \csuse provided by etoolbox to avoid this.
> Yes, I'm actually thinking about to change my packages to use
> etoolbox.

Good idea in general ! But for filehook if you permit, this is very
- very much - low level package and I think it should not load etoolbox.
Besides, it's always better when reading the .log for "debugging
purpose" -- or development purpose - to keep into your own code rather
than switching to another package code, even if it's only for a few
lines.

Better to just define:

\filehook@exec : #1 -> \csname \ifcsname #1\endcsname #1\else
                                                       relax\fi
                        \endcsname

short, efficient, meaningful with @exec, and no etoolbox for such
a little thing ;-)

Best regards.

Le 23/03/2011 22:13, Martin Scharrer a �crit :
> On Mar 23, 2:59 pm, GL<gouail...@gmail.com>  wrote:

>> Then it would be better to define internal commands for this purpose:
>>        filehook@AtBefore{srclfile}
>> Or simply:
>>       \ifdefined\scrlfileversion     ....
>>       \else \AtBeginOfPackageFile {scrlfile}{....}
>>       \fi
>>
>> scrlfile does CheckCommand on \InputIfFileExists first.
> Yes, that's the reason I change it back to the default value at begin
> of scrlfile.
>
> At first I had a \@ifloaded to check for srclfile and then thought
> that a starred version of AtBegin... would be better :-)
>>
>> More important, the following does not work:
>>
>> % ---------------------------------------------
>> \documentclass [a4paper]{article}
>> \usepackage {filehook}
>> %\usepackage {scrlfile,interfaces}
>>
>> \begin{document}\makeatletter
>>
>> %\AfterFile{\jobname.toc}{End of the table of contents}
>> \AtEndOfFile{\jobname.toc}{End of the table of contents}
>>
>> \tableofcontents
>>
>> \section{One}
>>
>> \end{document}\endinput
>> % ---------------------------------------
>>
>> interfaces did the following to enable the hooks for
>> files that are loaded with \@input:
>>
>> \renewcommand*\@input[1]{\IfFileExists{#1}
>>      {\scr@load@hook{before}{#1}%
>>       \@@input\@filef@und
>>       \scr@load@hook{after}{#1}}%
>>      {\typeout{No file #1.}}%
>>
>> }% \@input
>>
>> I say 'did' because it would be nice if filehook hooks
>> worked with \@input and hence for \tableofcontents.
> Originally I tried to avoid processing aux files.
> I needed `filehook` first for `svn-multi`s to collect a file list for `
> \tableofrevisions` where
> you don't like to have .toc and .aux etc. in it.
> Also in some cases (like \lstinputlistings) you want to read external
> files without
> executing hooks. In the past I suggested doing this using \@input.
> But I see your point and might add it. Maybe as an option.

..toc file is not .aux file in my opinion. .aux file should not be
processed, but the user (or package writer) has to care. Easy !

\lstinputlistings is exactly a .toc file (actually named .lol)
and I noticed today that list of listings can be formatted very
simply with tocloft package:

          \newlistof {listing}{lol}{List of Listings}

And then one can use \listofsetup from interface to configure the
typesetting in exactly the same way as for \tocsetup:

\listofsetup{  title =
                label =
             bookmark =
            pagestyle =
         listing/skip =
         listing/font =
       listing/dotsep =
      listing/leaders =
           twocolumns,
   columns/rule/color =
               before =
                after =
   listing/pagenumber = on | off
listing/number/width =
    listing/page/font =
}
etc.  and finally:      \listoflisting instead of \lstlistoflistings

Nothing to do so far than to say \newlistof{listing}{lol}{<title>}
(the <title> is overwritten by \listofsetup is specified here)

This is very convenient for it is exactly the same syntax as for the
..toc, and probably more flexible than the formatting provided by
listings.sty internals.

Just thank to listings to use \contentsline in its list of listings!

An excellent package. I wonder how I'll manage to make possible to
put a listing environment inside tabu ! Not done yet... too bad

>> Is this on purpose that you use ^^J instead of \MessageBreak which
>> preserve alignment in your \PackageError(s) ?
> No, actually just a bad habit.

Why not. An error is an error ;-) Who cares of the alignment inside
the .log ? Even TabU makes it poorly...

>> \ifcase
>>       \ifx\InputIfFileExists\latex@InputIfFileExists 0\else
>>       \ifx\InputIfFileExists\memoir@InputIfFileExists 0\else
>>        1%
>>       \fi\fi
>> \relax
>>
>> is often more readable as:
>>
>> \ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>          \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>          1\relax
> Thanks, I will have a look on that.

Mind the spaces !

Something impossible with LaTeX 3 (spaces are ignored)


>>> While they wont be used as often as \AtEndOfXXXXFile* it is IMHO no
>>> harm to have them. If the user wants to break his document I can do so
>>> without them as well.
>>
>> Yes but conversely the documentation for filehook presents the star
>> form \AtBeginOfPackageFile*  and this is confusing at least !
> I see. The star in the documentation is gray which means it is
> optional. The optional [ ] arguments are also gray for this purpose.
> But you are right, it isn't very clear and I should display both the
> normal and the starred version instead.

Cheer up !

FC

GL <gouailles@gmail.com> writes:

> Le 23/03/2011 22:13, Martin Scharrer a écrit :
>> On Mar 23, 2:59 pm, GL<gouail...@gmail.com>  wrote:
>>> \ifcase
>>>       \ifx\InputIfFileExists\latex@InputIfFileExists 0\else
>>>       \ifx\InputIfFileExists\memoir@InputIfFileExists 0\else
>>>        1%
>>>       \fi\fi
>>> \relax
>>>
>>> is often more readable as:
>>>
>>> \ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>>          \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>>          1\relax
>> Thanks, I will have a look on that.
>
> Mind the spaces !
>
> Something impossible with LaTeX 3 (spaces are ignored)

But LaTeX 3 syntax defines ~ to be a space token.  And if you use
LaTeX 3 you should use \c_zero and \c_one instead of 0 and 1 because the
former is faster and less error-prone.  Or use something like that:

\bool_if:nTF { \cs_if_eq_p:NN \InputIfFileExists
\latex@InputIfFileExists || \cs_if_eq_p:NN \InputIfFileExists
\memoir@InputIfFileExists } { ... } { ... }

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

Le 23/03/2011 23:20, Philipp Stephani a écrit :
> GL<gouailles@gmail.com>  writes:
>
>> Le 23/03/2011 22:13, Martin Scharrer a écrit :
>>> On Mar 23, 2:59 pm, GL<gouail...@gmail.com>   wrote:
>>>>           1\relax
>>> Thanks, I will have a look on that.
>>
>> Mind the spaces !
>>
>> Something impossible with LaTeX 3 (spaces are ignored)
>
> But LaTeX 3 syntax defines ~ to be a space token.  And if you use
> LaTeX 3 you should use \c_zero and \c_one instead of 0 and 1 because the
> former is faster and less error-prone.  Or use something like that:
>
> \bool_if:nTF { \cs_if_eq_p:NN \InputIfFileExists
> \latex@InputIfFileExists || \cs_if_eq_p:NN \InputIfFileExists
> \memoir@InputIfFileExists } { ... } { ... }

Yeah ! too much fun !
I definitely hate LaTeX 3 syntax.
No one of the TeX, eTeX pdfTeX primitives contains any character other
than [a-z] !
  \ifodd \ifx \x\y 0 \fi \ifx \x\z 0 \fi 1\relax .... \else ... \fi
no braces hence no runaway argument ! And the .log comes with the
solution in a couple of lines.

It's a nightmare to know how TeX works with spaces but once you
cope with it you can't do without.

Good night.

On Mar 24, 9:16=A0am, GL <gouail...@gmail.com> wrote:

> I definitely hate LaTeX 3 syntax.

That's a shame, really.

> No one of the TeX, eTeX pdfTeX primitives contains any character other
> than [a-z] !

Yeah. And no packages have ever had naming conflicts before, have
they? Do you also hate using @ in command names?

* * *

The point of expl3 is that often the primitives need arcane knowledge
to use, such as the fact that numbers are terminated by a space that
is gobbled.

If you are a TeX guru you'll have no problem with code like

\ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
         \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
         1\relax
....
\else
....
\fi

(which I personally find horrible) and I'm sure you'll never run in to
nesting or skipping problems with your primitive \if's because you
know what you're doing -- but I have a hard time trying to argue in
favour of these primitive constructs when the *logic* behind code like

\bool_if:nTF {
    \cs_if_eq_p:NN \InputIfFileExists \latex@InputIfFileExists
    ||
    \cs_if_eq_p:NN \InputIfFileExists \memoir@InputIfFileExists
} { ... } { ... }

is much clearer. (Sure, there's cognitive overhead with knowing that
_p is a predicate that is evaluated inside \bool_if and that "||"
means "or", but these rules are pretty straightforward.) And you'll
never have to worry about skipping over \fi's or nesting your
conditionals incorrectly.

I don't mind that people find expl3 strange at first, and I certainly
don't mind if they choose not to use it, but you seem not to have
considered the explicit design decisions that went into it, nor the
advantages it has for programmers who aren't as expert as yourself
(like me). So I find your saying "I hate expl3" to be particularly non-
constructive.

Consider the ease of writing and maintaining the following two
relatively simple pieces of code:

\begingroup\expandafter\expandafter\expandafter\endgroup
\ifx\csname baz\endcsname\relax\else
  \expandafter\let\csname foo\expandafter\endcsname\csname baz
\endcsname
\fi

vs.

\cs_if_exist:cT {baz} {
  \cs_set_eq:cc {foo} {baz}
}

Now that computers are fast, we can spend a little bit of computer
time making our code easier to understand and saving us time writing
it.

In my mind, it just doesn't make sense to want to hold onto TeX's
primitive programming model. And in the short term while we're still
programming in a TeX-based language, something like expl3 or etoolbox
is the best way to make this abstraction.

Best regards,
Will

Le 24/03/2011 02:09, Will Robertson a �crit :
> On Mar 24, 9:16 am, GL<gouail...@gmail.com>  wrote:
>
> \bool_if:nTF {
>      \cs_if_eq_p:NN \InputIfFileExists \latex@InputIfFileExists
>      ||
>      \cs_if_eq_p:NN \InputIfFileExists \memoir@InputIfFileExists
> } { ... } { ... }
>
> is much clearer. (Sure, there's cognitive overhead with knowing that
> _p is a predicate that is evaluated inside \bool_if and that "||"
> means "or", but these rules are pretty straightforward.) And you'll

I didn't saw the matters from this point. It's probably interesting
in terms of logic and language definition.
But I prefer e-TeX though.

> Consider the ease of writing and maintaining the following two
> relatively simple pieces of code:
>
> \begingroup\expandafter\expandafter\expandafter\endgroup
> \ifx\csname baz\endcsname\relax\else
>    \expandafter\let\csname foo\expandafter\endcsname\csname baz
> \endcsname
> \fi

You're cheating: I use e-TeX not TeX. I couldn't make a program without
\scantokens and \detokenize, and there is only \unexpanded that I hardly
ever use. I don't like \unexpanded. I like tokens! Now see how I write 
that:  		This is software for TypoGraphy !
                 Mind the lines ! Mind the alignments !
                 Mind how the primitives are "grouped"

\ifcsname baz\endcsname \expandafter\let % Carriage Return=>you see 
*\let* at once
      \csname foo\expandafter\endcsname =\csname baz\endcsname  \fi

2 lines ! clear.

> vs.
>
> \cs_if_exist:cT {baz} {
>    \cs_set_eq:cc {foo} {baz}
> }
>
> Now that computers are fast, we can spend a little bit of computer
> time making our code easier to understand and saving us time writing
> it.
I just can't read a log produced by siunitx. (Nor by \xkeyval either...)

  > In my mind, it just doesn't make sense to want to hold onto TeX's
> primitive programming model. And in the short term while we're still
> programming in a TeX-based language, something like expl3 or etoolbox
> is the best way to make this abstraction.
expl3 is abstraction. Interesting but not playful, not "ludic".
etoolbox this is e-TeX not TeX: even simpler but not much clearer read:
   \ifcsundef{baz}{}{\csletcs{foo}{baz}}

No definitely not simpler to understand. I probably read too much lines
of TeX .log and for me \ifcsname baz\endcsname \expandafter\let
                            \csname foo\expandafter\endcsname =\csname 
baz\endcsname

is definitely clearer, no risk of error, more ludic to type than pairs
of braces and finally read quicker because this is a "language" in the
sense that it has a "meaning": it's not only "code"...

But it's true that writting 50 lines of pure excellent TeX code takes 
more time than typing 500 lines of argument parsing.
     Economy + Exact grouping = excellent code in general.

> Best regards,

Best regards as well, I'm looking to LaTeX3 with pleasure but I don't
want to use it personally. And with the experience of hours while
developping tabu, I can say that pure (e-)TeX code is really faster
at compilation time. Not a liar !

> Will

Florent.

By the way you maintain tocloft (among other certainly): excellent
package ! I didn't notice how good it was while writing the first
versions of interfaces...

Good night ;-)

Le 24/03/2011 02:09, Will Robertson a �crit :
> On Mar 24, 9:16 am, GL<gouail...@gmail.com>  wrote:

> (which I personally find horrible) and I'm sure you'll never run in to
> nesting or skipping problems with your primitive \if's because you
> know what you're doing -- but I have a hard time trying to argue in
> favour of these primitive constructs when the *logic* behind code like
>
> \bool_if:nTF {

> is much clearer.

What I find funny in \bool_if:nTF is that bool means true or false,
if means true or false and TF means true or false !!!

Compare to \ifodd 1 or 0 : this is the same, but only once... ;-)

Hi Florent,

Thanks for the interesting discussion. We'll have to agree to disagree
on how we like to write our TeX code, but I'm glad we can talk about
it!

On Mar 24, 1:50=A0pm, GL <gouail...@gmail.com> wrote:

> You're cheating: I use e-TeX not TeX. I couldn't make a program without
> \scantokens and \detokenize, and there is only \unexpanded that I hardly
> ever use. I don't like \unexpanded.

Really? I couldn't do without things like

\edef\1{...\unexpanded{...}...}

You're right, the code above is written in TeX, but I could easily
come up with an example in which the \expandafter chains were just as
long (or longer).


> > Now that computers are fast, we can spend a little bit of computer
> > time making our code easier to understand and saving us time writing
> > it.
>
> I just can't read a log produced by siunitx. (Nor by \xkeyval either...)

I'm not sure if I can read a log produced by pretty much any complex
package... but I haven't tried much. You were saying you had scripts
to help you parse the output, which would make things much easier.


> expl3 is abstraction. Interesting but not playful, not "ludic".
> etoolbox this is e-TeX not TeX: even simpler but not much clearer read:
> =A0 =A0\ifcsundef{baz}{}{\csletcs{foo}{baz}}

One nice thing about expl3 is that its argument specifiers "scale" for
any macro, so we write

    \cs_set_eq:cc {foo}{baz}

and

    \blah_blah:cc {foo}{baz}

and in both cases the arguments are first turned into csnames before
being passed to the function.


> By the way you maintain tocloft (among other certainly): excellent
> package ! I didn't notice how good it was while writing the first
> versions of interfaces...

I only maintain it -- I didn't write the code :)
Unfortunately I'm not as good at responding to bug reports as I hoped
I would be...


> What I find funny in \bool_if:nTF is that bool means true or false,
> if means true or false and TF means true or false !!!

You're right, this could probably be written `\bool:nTF` (in fact in
historical versions of expl3 it was called `\predicate:nTF`).

Have fun!

Will

Will Robertson <wspr81@gmail.com> writes:

> On Mar 24, 9:16�am, GL <gouail...@gmail.com> wrote:
> 
> > I definitely hate LaTeX 3 syntax.
> 
> That's a shame, really.

It is.

> The point of expl3 is that often the primitives need arcane knowledge
> to use, such as the fact that numbers are terminated by a space that
> is gobbled.

I found expl3 does not reduce the arcane nature of the knowledge 
needed, but heaps on too much of it to be memorized.

> 
> If you are a TeX guru you'll have no problem with code like
> 
> \ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>          \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>          1\relax

Sure I'd have a problem with buggy code like that (always odd,
and the two tests are the same).  More to the point, the
\ifodd hack to do "or" isn't necessary.  Cleaner programming
style is more functional, by putting the actions into macros
and using two separate \ifx conditions

\ifx \InputIfFileExists\XXX@InputIfFileExists
  \performaction 
\else \ifx \InputIfFileExists\YYY@InputIfFileExists
  \performaction
\else
  \elseaction
\fi\fi

> (which I personally find horrible) and I'm sure you'll never run in to
> nesting or skipping problems with your primitive \if's because you
> know what you're doing -- but I have a hard time trying to argue in
> favour of these primitive constructs when the *logic* behind code like
> 
> \bool_if:nTF {
>     \cs_if_eq_p:NN \InputIfFileExists \latex@InputIfFileExists
>     ||
>     \cs_if_eq_p:NN \InputIfFileExists \memoir@InputIfFileExists
> } { ... } { ... }

And that is not arcane?  The big killer is that the predicates and
suffixes are not universal -- you can't take just any base and attach 
just any extensions, you have to *remember* what can go with what.

> \begingroup\expandafter\expandafter\expandafter\endgroup
 [\expandafter]
> \ifx\csname baz\endcsname\relax\else
>   \expandafter\let\csname foo\expandafter\endcsname\csname baz
> \endcsname
> \fi

That is deliberately obfuscating 

\@ifundefined{baz}{}{\let\foo=\baz}

And you left out an \expandafter.

The only reason to do the csname inside a evanescent group is because 
of a bad decision in TeX design (permanent assignment as a result of 
\csname), and it only intrudes when people program "close to the metal" 
for highest performance and efficiency.  More reasonable alternatives
already exist in LaTeX and more could be easily added (think \@namelet)
without a complete refactoring.



-- 
Donald Arseneau                          asnd@triumf.ca

Le 24/03/2011 04:50, GL a �crit :
> Le 24/03/2011 02:09, Will Robertson a �crit :
>
> > In my mind, it just doesn't make sense to want to hold onto TeX's
>> primitive programming model. And in the short term while we're still
>> programming in a TeX-based language, something like expl3 or etoolbox
>> is the best way to make this abstraction.
> expl3 is abstraction. Interesting but not playful, not "ludic".
> etoolbox this is e-TeX not TeX: even simpler but not much clearer read:
>   \ifcsundef{baz}{}{\csletcs{foo}{baz}}

I really can't see why \ifcsname is clearer than LaTeX3's 
\cs_if_exist:cT or etoolbox's \ifcsundef or any other similar construct. 
Those are conventions: you know the meaning of this or that command, you 
master it or not, but nothing is more natural or simpler than something 
else.

>
> No definitely not simpler to understand. I probably read too much lines
> of TeX .log and for me \ifcsname baz\endcsname \expandafter\let
>                            \csname foo\expandafter\endcsname =\csname 
> baz\endcsname
>
> is definitely clearer, no risk of error,

No risk? Why so? There are many more characters to type than in other 
solutions, so risk is definitely greater.
And the proof is: your code is buggy. Let's say you forgot the final \fi 
when pasting from the lines above; but there you \let \foo to \csname 
and have an extra \endcsname (a major error, you'll agree), all that 
because of the equal sign. So no risk of error, eh?

> more ludic to type than pairs
> of braces and finally read quicker because this is a "language" in the
> sense that it has a "meaning": it's not only "code"...

Again, I can't see anything supporting such assertions. Playfulness is 
in the eye of the beholder, obviously; I don't find "\ifcsname..." or 
"\expandafter\def\csname..." particularly fun; I prefer spending time 
trying to have good ideas for a code, and if \ifcsundef or anything else 
saves me a few micro-seconds I'll take them. Yet I definitely don't like 
braces; but you can also use macros like \ifcsundef which don't use braces.

As for language and meaning, that is absurd. How is \ifcsname more 
meaningful than \ifcsundef? Both are conventions, with the meanings they 
were given by their creators. Both are definitely "codes", I'm sorry to 
say, and have nothing to do with anything even remotely ressembling a 
language, except in the name: "programming language", which nobody is 
naive enough to consider it has anything to do with real language.

> But it's true that writting 50 lines of pure excellent TeX code takes 
> more time than typing 500 lines of argument parsing.
>     Economy + Exact grouping = excellent code in general.

Beware not to confuse pure TeX code and excellent TeX code.
Anyway macro definition is at the heart of TeX; "pure TeX" doesn't mean 
anything: try using TeX without a macro (which is in essence what you're 
proposing). If "pure TeX" is so good, why writing packages? Would you 
say to those who use your packages: don't use them, they aren't pure 
TeX! And why using LaTeX? Plain TeX is "purer" than LaTeX... For that 
matter, why using TeX at all? Go for machine code!

Best,
Paul

Le 25/03/2011 07:36, Will Robertson a �crit :
> Hi Florent,
>
>> You're cheating: I use e-TeX not TeX. I couldn't make a program without
>> \scantokens and \detokenize, and there is only \unexpanded that I hardly
>> ever use. I don't like \unexpanded.
>
> Really? I couldn't do without things like
>
> \edef\1{...\unexpanded{...}...}

Really ? Think about it... :

   \edef\1 ##1{\def\noexpand\1{ ... ##1 ...}}\expandafter\1\expandafter
                                               {< unexpanded material>}

> You're right, the code above is written in TeX, but I could easily
> come up with an example in which the \expandafter chains were just as
> long (or longer). >
>
>>> Now that computers are fast, we can spend a little bit of computer
>>> time making our code easier to understand and saving us time writing
>>> it.
>>
>> I just can't read a log produced by siunitx. (Nor by \xkeyval either...)
>
> I'm not sure if I can read a log produced by pretty much any complex
> package... but I haven't tried much. You were saying you had scripts
> to help you parse the output, which would make things much easier.
>
>
>> expl3 is abstraction. Interesting but not playful, not "ludic".
>> etoolbox this is e-TeX not TeX: even simpler but not much clearer read:
>>     \ifcsundef{baz}{}{\csletcs{foo}{baz}}
>
> One nice thing about expl3 is that its argument specifiers "scale" for
> any macro, so we write
>
>      \cs_set_eq:cc {foo}{baz}
>
> and
>
>      \blah_blah:cc {foo}{baz}
>
> and in both cases the arguments are first turned into csnames before
> being passed to the function.
>
>
>> By the way you maintain tocloft (among other certainly): excellent
>> package ! I didn't notice how good it was while writing the first
>> versions of interfaces...
>
> I only maintain it -- I didn't write the code :)
> Unfortunately I'm not as good at responding to bug reports as I hoped
> I would be...
>
>
>> What I find funny in \bool_if:nTF is that bool means true or false,
>> if means true or false and TF means true or false !!!
>
> You're right, this could probably be written `\bool:nTF` (in fact in
> historical versions of expl3 it was called `\predicate:nTF`).
>
> Have fun!
>
> Will

Le 25/03/2011 11:20, zappathustra a �crit :
> Le 24/03/2011 04:50, GL a �crit :
>> Le 24/03/2011 02:09, Will Robertson a �crit :

"pure TeX" doesn't mean anything:

pure TeX means no format, no plain TeX, no newcount, no newdimen etc:

\begingroup
	\countdef\mycount=1
         \toks\mycount{something}
\endgroup

is pure TeX

Le 25/03/2011 08:06, Donald Arseneau a �crit :
> Will Robertson<wspr81@gmail.com>  writes:
>
>> On Mar 24, 9:16 am, GL<gouail...@gmail.com>  wrote:
>>
>>> I definitely hate LaTeX 3 syntax.
>>
>> That's a shame, really.
>
> It is.
>
>> The point of expl3 is that often the primitives need arcane knowledge
>> to use, such as the fact that numbers are terminated by a space that
>> is gobbled.
>
> I found expl3 does not reduce the arcane nature of the knowledge
> needed, but heaps on too much of it to be memorized.
>
>>
>> If you are a TeX guru you'll have no problem with code like
>>
>> \ifodd \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>           \ifx \InputIfFileExists\latex@InputIfFileExists 0 \fi
>>           1\relax
>
> Sure I'd have a problem with buggy code like that (always odd,

Not always odd: \ifodd  \iftrue 0 <space>\fi evaluates to \iffalse
at once. Check any case:

\ifodd \iftrue 0 \fi
        \iffalse 0 \fi
        1\relax
        true
\else  false			%<= false
\fi

\ifodd \iffalse 0 \fi
        \iffalse 0 \fi
        1\relax
        true			%<= true
\else  false			
\fi

\ifodd \iffalse 0 \fi
        \iftrue 0 \fi
        1\relax
        true
\else  false			%<= false
\fi

> and the two tests are the same).
Yes. copy-paste too quickly done. it doesn't change the syntax...

More to the point, the \ifodd hack to do "or" isn't necessary.  Cleaner 
programming
> style is more functional, by putting the actions into macros
> and using two separate \ifx conditions

more functional but less readable and more difficult to maintain.
Getting the condition and the code at the same place is clearer and
thus minimises the risk of error.
Besides, it's optimal: \performaction twice is bad imha.
Finally you don't have to find a name to an unnecessary macro
          \performaction. Good naming of commands makes good code too...

> \ifx \InputIfFileExists\XXX@InputIfFileExists
>    \performaction
> \else \ifx \InputIfFileExists\YYY@InputIfFileExists
>    \performaction
> \else
>    \elseaction
> \fi\fi
>
>> (which I personally find horrible) and I'm sure you'll never run in to
>> nesting or skipping problems with your primitive \if's because you
>> know what you're doing -- but I have a hard time trying to argue in
>> favour of these primitive constructs when the *logic* behind code like
>>
>> \bool_if:nTF {
>>      \cs_if_eq_p:NN \InputIfFileExists \latex@InputIfFileExists
>>      ||
>>      \cs_if_eq_p:NN \InputIfFileExists \memoir@InputIfFileExists
>> } { ... } { ... }
>
> And that is not arcane?  The big killer is that the predicates and
> suffixes are not universal -- you can't take just any base and attach
> just any extensions, you have to *remember* what can go with what.
>
>> \begingroup\expandafter\expandafter\expandafter\endgroup
>   [\expandafter]
>> \ifx\csname baz\endcsname\relax\else
>>    \expandafter\let\csname foo\expandafter\endcsname\csname baz
>> \endcsname
>> \fi
>
> That is deliberately obfuscating
>
> \@ifundefined{baz}{}{\let\foo=\baz}
>
> And you left out an \expandafter.
>
> The only reason to do the csname inside a evanescent group is because
> of a bad decision in TeX design (permanent assignment as a result of
> \csname), and it only intrudes when people program "close to the metal"
> for highest performance and efficiency.

No. performance and efficiency of "silent assignment to \relax" is
neglictible... One more time, this is e-TeX programming requirement.
One wants to be able to test \ifcsname baz\endcsname later on...

More reasonable alternatives
> already exist in LaTeX and more could be easily added (think \@namelet)
> without a complete refactoring.

Le 25/03/2011 11:59, GL a �crit :
> Le 25/03/2011 11:20, zappathustra a �crit :
>> Le 24/03/2011 04:50, GL a �crit :
>>> Le 24/03/2011 02:09, Will Robertson a �crit :
>
> "pure TeX" doesn't mean anything:
>
> pure TeX means no format, no plain TeX, no newcount, no newdimen etc:
>
> \begingroup
>     \countdef\mycount=1
>         \toks\mycount{something}
> \endgroup
>
> is pure TeX

False. Braces set to catcodes 1 and 2 aren't pure TeX.
Anyway that wasn't exactly the main point of my message, which you 
erased almost entirely.

Paul

Le 25/03/2011 12:10, zappathustra a �crit :
> Le 25/03/2011 11:59, GL a �crit :
>> Le 25/03/2011 11:20, zappathustra a �crit :
>>> Le 24/03/2011 04:50, GL a �crit :
>>>> Le 24/03/2011 02:09, Will Robertson a �crit :
>>
>> "pure TeX" doesn't mean anything:
>>
>> pure TeX means no format, no plain TeX, no newcount, no newdimen etc:
>>
>> \begingroup
>> \countdef\mycount=1
>> \toks\mycount{something}
>> \endgroup
>>
>> is pure TeX
>
> False. Braces set to catcodes 1 and 2 aren't pure TeX.

Try:    etex \showthe\catcode`\{

I said TeX, not virTeX ...


> Anyway that wasn't exactly the main point of my message, which you
> erased almost entirely.
>
> Paul

Le 25/03/2011 12:13, GL a �crit :
> Le 25/03/2011 12:10, zappathustra a �crit :
>> Le 25/03/2011 11:59, GL a �crit :
>>> Le 25/03/2011 11:20, zappathustra a �crit :
>>>> Le 24/03/2011 04:50, GL a �crit :
>>>>> Le 24/03/2011 02:09, Will Robertson a �crit :
>>>
>>> "pure TeX" doesn't mean anything:
>>>
>>> pure TeX means no format, no plain TeX, no newcount, no newdimen etc:
>>>
>>> \begingroup
>>> \countdef\mycount=1
>>> \toks\mycount{something}
>>> \endgroup
>>>
>>> is pure TeX
>>
>> False. Braces set to catcodes 1 and 2 aren't pure TeX.
>
> Try:    etex \showthe\catcode`\{
>
> I said TeX, not virTeX ...

Are you sure you know what you're talking about? Calling eTeX, like 
other engines, calls the engine + plain TeX, which is why braces are set 
to those values. Just check that \fmtname is defined to plain.
But, I repeat, that wasn't the most important thing in my message.

Paul

Le 25/03/2011 12:23, zappathustra a �crit :
> Le 25/03/2011 12:13, GL a �crit :
>> Le 25/03/2011 12:10, zappathustra a �crit :
>>>
>>> False. Braces set to catcodes 1 and 2 aren't pure TeX.
>>
>> Try: etex \showthe\catcode`\{
>>
>> I said TeX, not virTeX ...
>
> Are you sure you know what you're talking about? Calling eTeX, like
> other engines, calls the engine + plain TeX, which is why braces are set
> to those values.

yes I noticed that. I didn't know.

Then "pure TeX" must be initex. \  is catcode of 0 but { } are not set.

True ;-)

Le 25/03/2011 11:20, zappathustra a �crit :
> Le 24/03/2011 04:50, GL a �crit :
>> Le 24/03/2011 02:09, Will Robertson a �crit :
>>
>> > In my mind, it just doesn't make sense to want to hold onto TeX's
>>> primitive programming model. And in the short term while we're still
>>> programming in a TeX-based language, something like expl3 or etoolbox
>>> is the best way to make this abstraction.
>> expl3 is abstraction. Interesting but not playful, not "ludic".
>> etoolbox this is e-TeX not TeX: even simpler but not much clearer read:
>> \ifcsundef{baz}{}{\csletcs{foo}{baz}}
>
> I really can't see why \ifcsname is clearer than LaTeX3's
> \cs_if_exist:cT or etoolbox's \ifcsundef or any other similar construct.
> Those are conventions: you know the meaning of this or that command, you
> master it or not, but nothing is more natural or simpler than something
> else.
>
>>
>> No definitely not simpler to understand. I probably read too much lines
>> of TeX .log and for me \ifcsname baz\endcsname \expandafter\let
>> \csname foo\expandafter\endcsname =\csname baz\endcsname
>>
>> is definitely clearer, no risk of error,
>
> No risk? Why so? There are many more characters to type than in other
> solutions, so risk is definitely greater.
> And the proof is: your code is buggy. Let's say you forgot the final \fi
> when pasting from the lines above; but there you \let \foo to \csname
> and have an extra \endcsname (a major error, you'll agree), all that
> because of the equal sign. So no risk of error, eh?
>
>> more ludic to type than pairs
>> of braces and finally read quicker because this is a "language" in the
>> sense that it has a "meaning": it's not only "code"...
>
> Again, I can't see anything supporting such assertions. Playfulness is
> in the eye of the beholder,

Right. In my eyes then...

obviously; I don't find "\ifcsname..." or
> "\expandafter\def\csname..." particularly fun; I prefer spending time
> trying to have good ideas for a code,

Good ideas for a feature, then good skill for the code...

and if \ifcsundef or anything else
> saves me a few micro-seconds I'll take them. Yet I definitely don't like
> braces;

You too then.

but you can also use macros like \ifcsundef which don't use braces.

Yes and will I rewrite etoolbox to remove braces ? Besides, delimited
arguments are not always the same as undelimited ones...

> As for language and meaning, that is absurd. How is \ifcsname more
> meaningful than \ifcsundef?  Both are conventions,

No. \ifcsname is a primitive, \ifcsundef a macro. \ifcsname is therefore
more meaningfull for it executes as \ifcsundef in the .log file. Thus
your code fits to the log and it's easier to follow.
This is my own practice...

Besides \ifcsundef is not equivalent to \ifcsname and I use it when I
load etoolbox (or \ltx@IfUndefined with ltxcmds). But I don't load
etoolbox for \ifcsundef... there are more interesting commands in this 
package.

with the meanings they
> were given by their creators. Both are definitely "codes", I'm sorry to
> say, and have nothing to do with anything even remotely ressembling a
> language, except in the name: "programming language", which nobody is
> naive enough to consider it has anything to do with real language.

imha a language is a langague. Mathematics is. TeX is etc.

>> But it's true that writting 50 lines of pure excellent TeX code takes
>> more time than typing 500 lines of argument parsing.
>> Economy + Exact grouping = excellent code in general.
>
> Beware not to confuse pure TeX code and excellent TeX code.

The word TeX did not appear in the equation.

> Anyway macro definition is at the heart of TeX; "pure TeX" doesn't mean
> anything: try using TeX without a macro
(which is in essence what you're proposing).

??? TeX without a macro ??? is initex not able to define a macro ???

If "pure TeX" is so good, why writing packages? Would you
> say to those who use your packages: don't use them, they aren't pure
> TeX! And why using LaTeX? Plain TeX is "purer" than LaTeX... For that
> matter, why using TeX at all? Go for machine code!

??? machine code is not a "langage". A language can be shared...

> Best,
> Paul

On Mar 23, 9:59=A0pm, GL <gouail...@gmail.com> wrote:
> Le 23/03/2011 22:13, Martin Scharrer a =E9crit :
>
>
>
> > On Mar 23, 2:59 pm, GL<gouail...@gmail.com> =A0wrote:
> >> Then it would be better to define internal commands for this purpose:
> >> =A0 =A0 =A0 =A0filehook@AtBefore{srclfile}
> >> Or simply:
> >> =A0 =A0 =A0 \ifdefined\scrlfileversion =A0 =A0 ....
> >> =A0 =A0 =A0 \else \AtBeginOfPackageFile {scrlfile}{....}
> >> =A0 =A0 =A0 \fi
>
> >> scrlfile does CheckCommand on \InputIfFileExists first.
> > Yes, that's the reason I change it back to the default value at begin
> > of scrlfile.
>
> > At first I had a \@ifloaded to check for srclfile and then thought
> > that a starred version of AtBegin... would be better :-)
>
> >> More important, the following does not work:
>
> >> % ---------------------------------------------
> >> \documentclass [a4paper]{article}
> >> \usepackage {filehook}
> >> %\usepackage {scrlfile,interfaces}
>
> >> \begin{document}\makeatletter
>
> >> %\AfterFile{\jobname.toc}{End of the table of contents}
> >> \AtEndOfFile{\jobname.toc}{End of the table of contents}
>
> >> \tableofcontents
>
> >> \section{One}
>
> >> \end{document}\endinput
> >> % ---------------------------------------
>
> >> interfaces did the following to enable the hooks for
> >> files that are loaded with \@input:
>
> >> \renewcommand*\@input[1]{\IfFileExists{#1}
> >> =A0 =A0 =A0{\scr@load@hook{before}{#1}%
> >> =A0 =A0 =A0 \@@input\@filef@und
> >> =A0 =A0 =A0 \scr@load@hook{after}{#1}}%
> >> =A0 =A0 =A0{\typeout{No file #1.}}%
>
> >> }% \@input
>
> >> I say 'did' because it would be nice if filehook hooks
> >> worked with \@input and hence for \tableofcontents.
> > Originally I tried to avoid processing aux files.
> > I needed `filehook` first for `svn-multi`s to collect a file list for `
> > \tableofrevisions` where
> > you don't like to have .toc and .aux etc. in it.
> > Also in some cases (like \lstinputlistings) you want to read external
> > files without
> > executing hooks. In the past I suggested doing this using \@input.
> > But I see your point and might add it. Maybe as an option.
>
> .toc file is not .aux file in my opinion. .aux file should not be
> processed, but the user (or package writer) has to care. Easy !
>
> \lstinputlistings is exactly a .toc file (actually named .lol)
I'm wasn't talking about the List of Listings, but about verbatim
files
read using `\lstinputlistings`. It uses \input internally and if the
file hooks
read external files, like svn-multi might do, this files are also
processed verbatim!
This is the reason 'filehook' patches '\lstinputlistings' to replace `
\input` with `\@input`.

Martin

Le 25/03/2011 12:46, Martin Scharrer a �crit :
> On Mar 23, 9:59 pm, GL<gouail...@gmail.com>  wrote:
>> Le 23/03/2011 22:13, Martin Scharrer a �crit :
>>
>> \lstinputlistings is exactly a .toc file (actually named .lol)
> I'm wasn't talking about the List of Listings, but about verbatim
> files

Right. Confusion with \lstlistoflistings (which is better with tocloft
     \newlistof{listings}{lol}{List of listings} \listoflistings)

> read using `\lstinputlistings`. It uses \input internally and if the

Yes... and no ! It uses \input{#1} which is \InputIfFileExists because
of the left brace -> \@iinput -> \InputIfFileExists for clarity (latex):

\def\input{\@ifnextchar\bgroup\@iinput\@@input}
\def\@iinput#1{%
   \InputIfFileExists{#1}{}%
   {\filename@parse{#1}%
    \edef\reserved@a{\noexpand\@missingfileerror
      {\filename@area\filename@base}%
      {\ifx\filename@ext\relax tex\else\filename@ext\fi}}%
    \reserved@a}}


Two points then:
	. First the implementation of \lstinputlisting is *unfair* :
Correct implementation would use the second argument of
\InputIfFileExists for the settings before input:

Correct implementation:

\def\lst@InputListing#1{%
     \lst@ifprint
         \begingroup
             \InputIfFileExists{#1}{%
                 \lsthk@PreSet \gdef\lst@intname{#1}%
                 \expandafter\lstset\expandafter{\lst@set}%
                 \lsthk@DisplayStyle
                 \catcode\active=\active
                 \lst@Init\relax \let\lst@gobble\z@
                 \lst@SkipToFirst}
                 {\typeout{No file: #1}}%
                 \lst@DeInit
         \endgroup
     \fi}%

filehook.sty can safely redefine \lstinputlisting, and the maintainer
should change the definition in listings.sty.

	. Second: filehook might be buggy and the doc is missing
           something important.

\InputIfFileExists{TheFile.tex}{\catcode`\A = 12 }
                                {\typeout{file not found}}

Before InputIfFileExists the catcode of A is 11
After InputIfFileExists the catcode of A is 12

Then a choice must be done: are the \AtBegin hooks to be executed
before or after the execution of the second argument of
\InputIfFileExists ?

My opinion is : before. Why ?
Because this second argument is given by the user when he writes
\InputIfFileExists, and is therefore not necessarily related to the
file in question: i mean a same file "TheFile.tex" can be loaded
twice with different settings for the second argument of
\InputIfFileExists.
Therefore, the filehook hook \BeforeFile should not take those settings
into account.


More difficult: what about \AtEndOfFile ?

The fact is that \InputIfFileExists{test.tex}{\catcode`\A =12}
                                              {\errmessage{not found}}
leaves the catcode of A in category 12 after execution.

This can be avoided (like lstinputlisting does for example) by grouping
the stuff:

\begingroup \InputIfFileExists{test.tex}{\catcode`\A =12}{...}\endgroup

But then... but then ? but then \InputIfFileExists leaves A in category
12 after execution. So the filehook hooks are executed in a context
where A is in category 12... no point to do that otherwise !

And the doc should claim: "Warning: \AtEndOfFile hooks are executed in
the context set by \InputIfFileExists in particular, loading of special
(non LaTeX) file by the mean of a \AtEnd hook might be `dangerous' / 
break. This especially applies to files read
"Verbatim" like VerbatimInput (pkg fancyvrb) or \lstinputlistings
(pkg listings.sty)"  or something similar.

\long\gdef\filehook@default@InputIfFileExists#1#2{%
   \IfFileExists{#1}%
     {\expandafter\filehook@swap
      \expandafter{\@filef@und}%
      {\filehook@every@atbegin{#1}% <= before #2
      \filehook@atbegin{#1}%	% <= before #2
      #2\@addtofilelist{#1}%
      \@@input}%
      \filehook@atend{#1}%
      \filehook@every@atend{#1}%
     }%

> file hooks
> read external files, like svn-multi might do, this files are also
> processed verbatim!
> This is the reason 'filehook' patches '\lstinputlistings' to replace `
> \input` with `\@input`.

If filehook patches \input only for the case of \lstinputlistings,
one have to look closer at it: is it possible to avoid this patch,
since \lstinputlistings finally loads the file with \InputIfFileExists?

> Martin

TEST :
% --------------------------------------------------------
\documentclass{article}
\usepackage [T1]{fontenc}
\usepackage {etex,filehook,listings}

\newenvironment{FILECONTENTS}{\def\ifeof ##1{\iftrue }\filecontents }
                               \endfilecontents

\begin{FILECONTENTS}{testVerbatim.tex}
             \VeRbAtIm ?
\end{FILECONTENTS}
\begin{FILECONTENTS}{testNormal.tex}
    Inside testNormal.tex:         catcode A = \the\catcode`\A \par 
\endinput
\end{FILECONTENTS}

\begin{document}\makeatletter

\def\lst@InputListing#1{%
     \lst@ifprint
         \begingroup
             \InputIfFileExists{#1}{%
                 \lsthk@PreSet \gdef\lst@intname{#1}%
                 \expandafter\lstset\expandafter{\lst@set}%
                 \lsthk@DisplayStyle
                 \catcode\active=\active
                 \lst@Init\relax \let\lst@gobble\z@
                 \lst@SkipToFirst}
                 {\typeout{No file: #1}}%
                 \lst@DeInit
         \endgroup
     \fi}%

lstinputlisting:\par
{\loggingall
\lstinputlisting{testVerbatim.tex}
}

\hrule

\AtBeginOfFile{testNormal.tex}{At Begin Of File testNormal: filehook 
says: catcode A = \the\catcode`\A \par}
\AtEndOfFile{testNormal.tex}{At End Of File testNormal: filehook says: 
catcode A = \the\catcode`\A \par}

\begingroup
\InputIfFileExists{testNormal.tex}{\catcode`\A=12}{}
\endgroup

\bigskip\hrule\bigskip

\long\gdef\filehook@default@InputIfFileExists#1#2{%
   \IfFileExists{#1}%
     {\expandafter\filehook@swap
      \expandafter{\@filef@und}%
      {\filehook@every@atbegin{#1}%
      \filehook@atbegin{#1}%
      #2\@addtofilelist{#1}%
      \@@input}%
      \filehook@atend{#1}%
      \filehook@every@atend{#1}%
     }%
}
\let\filehook@InputIfFileExists\filehook@default@InputIfFileExists
\let\InputIfFileExists\filehook@InputIfFileExists

\begingroup
\InputIfFileExists{testNormal.tex}{\catcode`\A=12}{}
\endgroup

\bigskip\hrule\bigskip

At End Document: catcode A = \the\catcode`\A

\end{document}\endinput
% -------------------------------------------------

Yours sincerely.

Le 25/03/2011 08:06, Donald Arseneau a �crit :
> Will Robertson<wspr81@gmail.com>  writes:
>
>
> Sure I'd have a problem with buggy code like that (always odd,
> and the two tests are the same).  More to the point, the
> \ifodd hack to do "or" isn't necessary.  Cleaner programming
> style is more functional, by putting the actions into macros
> and using two separate \ifx conditions
>
> \ifx \InputIfFileExists\XXX@InputIfFileExists
>    \performaction
> \else \ifx \InputIfFileExists\YYY@InputIfFileExists
>    \performaction
> \else
>    \elseaction
> \fi\fi

In fact your "Cleaner programming" manner is absolutely HoRrIbLe !!!

\let\next =.... \let\next =...  \let\next =....

And following TeX in the .log you see \next, \next, \next ...
Never you know which \next it is ! What the purpose of the command...

Awful, Ugly, Time Consuming, unsufferable !

Yours sincerely.

GL <gouailles@gmail.com> writes:

> Le 25/03/2011 08:06, Donald Arseneau a écrit :
>> Will Robertson<wspr81@gmail.com>  writes:
>>
>>
>> Sure I'd have a problem with buggy code like that (always odd,
>> and the two tests are the same).  More to the point, the
>> \ifodd hack to do "or" isn't necessary.  Cleaner programming
>> style is more functional, by putting the actions into macros
>> and using two separate \ifx conditions
>>
>> \ifx \InputIfFileExists\XXX@InputIfFileExists
>>    \performaction
>> \else \ifx \InputIfFileExists\YYY@InputIfFileExists
>>    \performaction
>> \else
>>    \elseaction
>> \fi\fi
>
> In fact your "Cleaner programming" manner is absolutely HoRrIbLe !!!
>
> \let\next =.... \let\next =...  \let\next =....
>
> And following TeX in the .log you see \next, \next, \next ...
> Never you know which \next it is ! What the purpose of the command...
>
> Awful, Ugly, Time Consuming, unsufferable !

Without \next, you have to use \expandafter chains to get rid of
\else/\fi:

\ifx \InputIfFileExists \XXX@InputIfFileExists
  \expandafter \dosomething
\else
  \ifx \InputIfFileExists \YYY@InputIfFileExists
    \expandafter \expandafter \expandafter
    \dosomething
  \else
    \expandafter \expandafter \expandafter
    \dosomethingelse
  \fi
\fi

That is equally bad.  Tricks like \ifodd are bad because the syntax
doesn't match the semantics: you actually don't want to test whether a
number is odd, but your code says otherwise.  The cleanest TeX-based
approach so far is in fact the expl3/etoolbox approach of hiding
expansion cruft in macros.

-- 
Change “LookInSig” to “tcalveu” to answer by mail.

Le 26/03/2011 12:43, Philipp Stephani a écrit :
> GL<gouailles@gmail.com>  writes:
>
>
> Without \next, you have to use \expandafter chains to get rid of
> \else/\fi:
>
> \ifx \InputIfFileExists \XXX@InputIfFileExists
>    \expandafter \dosomething
> \else
>    \ifx \InputIfFileExists \YYY@InputIfFileExists
>      \expandafter \expandafter \expandafter
>      \dosomething
>    \else
>      \expandafter \expandafter \expandafter
>      \dosomethingelse
>    \fi
> \fi
>
> That is equally bad.  Tricks like \ifodd are bad because the syntax
> doesn't match the semantics: you actually don't want to test whether a
> number is odd, but your code says otherwise.  The cleanest TeX-based
> approach so far is in fact the expl3/etoolbox approach of hiding
> expansion cruft in macros.

LaTeX3 uses \ifodd to switch to \iftrue or \iffalse.

If \ifodd was only there to test if a page number is odd, then
one could use it almost never...

Your series of \expandafter colapse into only one \expandafter
when using \ifodd or \ifcase.

Finally, no one of your argument is founded imha

Le 25/03/2011 13:56, GL a �crit :
 > Le 25/03/2011 12:46, Martin Scharrer a �crit :
 >> On Mar 23, 9:59 pm, GL<gouail...@gmail.com> wrote:
 >>> Le 23/03/2011 22:13, Martin Scharrer a �crit :


If you look at scrlfile.sty, the hook \BeforeFile is executed before
the second argument of \InputIfFileExists:

\IfFileExists{#1}{%
       \scr@load@hook{before}{#1}%
       #2\@addtofilelist{#1}%
       \@@input \@filef@und
       \scr@load@hook{after}{#1}%

while in filehook it is executed after:

   \IfFileExists{#1}%
     {\expandafter\filehook@swap
      \expandafter{\@filef@und}%
      {#2\@addtofilelist{#1}%
      \filehook@every@atbegin{#1}%
      \filehook@atbegin{#1}%
      \@@input}%
      \filehook@atend{#1}%
      \filehook@every@atend{#1}%


And this is an error ;-)