[TxMt] Latex Bundle grammar

[Alain Matthes]

Le 11 sept. 07 à 23:18, Brad Miller a écrit :
>

>
> I think this is where we differ.  I don't think we want each user  
> to be modifying the latex grammar to decide which packages to include.

I don't say that. I want a "pure" latex grammar and perhaps it' not  
good to have some "TeX" grammar include because the syntax are  
different.
I don't want to modify only to add; it'not exactly the same thing.  
Perhaps I'm wrong and it's possible to put all together ! (pstricks,  
metapost and pgf etc...)

> For one thing it will be different for each different project.  So,  
> I"m either going to end up including everything all the time, or  
> I'm going to drive myself crazy modifying the latex grammar every  
> time I work on a different writing project.  Plus most users don't  
> want to go anywhere near editing the grammar file!

Yes, a good argument


>
> About listings, why make a grammar to this package ?
>
> Because lstlistings is the best package I've found for including  
> source code, and since I'm writing CS textbooks, I do that a lot.   
> If you can recommend a better one I would be happy to look at it!   
> But really, most of the grammar for the package is only concerned  
> with then command and then including the grammar for the particular  
> source code that is inside the lstlistings environment.

Yes it's the best package for including source code
>
>
>
> There is a way to turn around the difficulties.
>
> \lstinputlisting[key=value list]{hfile name}
>
> example :
>
> \usepackage{listings}
> \lstset{language=C}
> ...
> \begin{document}
> \lstinputlisting{main.c}
> \end{document}
>
> or you can make that
>
> \lstinputlisting[first=10,last=50]{main.c}
> I know  about this feature of lstlisting but I like to have the  
> code right there to look at as I'm writing.

Again a good argument . It's the same for me  with the pgf package.

> I guess its a writing style issue but I tried your method for a  
> while and I did not like it at all.
>
> I don't understand about the problem with utf8.  My latex source  
> files are all encoded as utf8 documents and I don't have any  
> problem with lstlistings.
>


Have you try for example a string "été"  ?

from listings.pdf

National characters If you type in such characters directly as  
characters of
codes 128–255 and use them also in listings, let the package know it— 
or you’ll
get really funny results. extendedchars=true allows and  
extendedchars=false
prohibits listings from handling extended characters in listings. If  
you use them,
you should load fontenc, inputenc and/or any other package which  
defines the
characters.
! I have problems using inputenc together with listings. This could  
be a compatibility
problem. Make a bug report as described in section 6 Troubleshooting.

The extended characters don’t cover Arabic, Chinese, Hebrew,  
Japanese, and so
on—specifically, any encoding which uses multiple bytes per character.
Thus, if you use the a package that supports multibyte characters,  
such as
the CJK or ucs packages for Chinese and UTF-8 characters, you must  
avoid letting
listings process the extended characters. It is generally best to  
also specify
extendedchars=false to avoid having listings get entangled in the  
other package’s
extended-character treatment.

% it's not easy with french texts

If you do have a listing contained within a CJK environment, and want to
have CJK characters inside the listing, you can place them within a  
comment
that escapes to LATEX– see section 4.14 for how to do that. (If the  
listing is not
inside a CJK environment, you can simply put a small CJK environment  
within
the escaped-to-LATEXportion of the comment.)
Similarly, if you are using UTF-8 extended characters in a listing,  
they must
be placed within an escape to LATEX.
Also, section 7 has a few details on how to work with extended  
characters in
the context of  A

Regards Alain