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