Patrick Gundlach wrote:

Hello Peter,

...

I suggested to the author of the very feature rich LaTeX-Listings package, Carsten Heinz, to port this package to ConTeXt, and it seems, that he is interested. But before doing it, there are some questions:

* What do Hans and other people thing about that?

what is listings.sty providing?

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 -----------------------------------------------------------------

Hello,

...

...

I suggested to the author of the very feature rich LaTeX-Listings package, Carsten Heinz, to port this package to ConTeXt, and it seems, that he is interested. But before doing it, there are some questions:

* What do Hans and other people thing about that?

what is listings.sty providing?

listings.sty is one of the very few packages from LaTeX, which I am still missing in ConTeXt. I yet never extensively used the listings functionality provided by ConTeXt, but from what I remember from reading the documentation, the liststings.sty is much more flexible. It has an easy interface to define new languages (like Opal, a functional programming language used in courses at my university), allows flexible line numbering (all, every n lines), it allows customization of all fonts (line numbers, keywords, comments, ...), indenting, ... Most importantly for me: It allows easy escaping to TeX. One option is to interpret all comments as (La)TeX code. This was very useful for typesetting correctness proofs of programs using the Hoare Calculus, because it makes such listings much more readable. Then there are other niceties already provided by ConTeXt, like frames, floats, etc. Oh, one other nice thing is, that it allows to use proportional fonts (is that the right translation? I mean non-fixed width fonts), and still can keep indentations correctly, e.g. with assignments like alongvariable = 1; short = 2; I think the algorithm is described a little in the documentation. As far as I remember, it assumes a (configurable) average character width of proportional fonts and typesets every word in a box of the width corresponding to the number of characters included in the word. These were at least the features most important to me ... -- Holger F. Schoener TU Berlin; Dept. IV: EE and Computer Science hfsch@cs.tu-berlin.de http://www.cs.tu-berlin.de/~hfsch/ Rooms FR2525 Tel: +49-30-314-73115, Fax: -73121 Office FR 2-1 Franklinstr. 28/29, D-10587 Berlin, Germany

Peter Münster wrote:

On Mon, 28 Jun 2004, Hans Hagen wrote:

...

what is listings.sty providing?

Hello Hans, here some features of listings.sty: - support for a lot of languages (for example C) - easy to add further languages - line breaking (see my email from 19. June mentioning \lstinline) - line numbering - different options for column alignment - escaping to TeX - layout elements (frames, spacing, background, captions, etc) - indexing - floating listings - special treatment of comments - a lot more...

I don't know about all the \definetyping features (only those, that are documented), perhaps the capabilities of ConTeXt are already sufficient. On the other side, listings.sty is a very great package and mostly written in Plain TeX. So perhaps it's worth the effort. I don't know...

A verbatim environment is tricky because one has to play with catcodes and the endcondition. There are also some spacing issues when used in combination with other macro package features. Another complication is that active characters are used for other features as well. I had put it on my todo list to reimplement some of the context verbatim features using etex (more robust and faster). When cooking up a new environment, it's best to separate functionality and use built in support when possible. For instance, line numbering, layout elements, floating listings are kind of independent of such a mechanisms. If some features are missing in the current verbatim environment (one of the older parts of context) i can add them if needed. On the other hand, it does not hurt to have multiple alternatives. One potential problem with third party modules is that they set tex variables without context knowing about it. Also, redefining low level context macros is asking for problems, so if some special kind of support is needed for a user module, better ask me so that i can provide that low level feature in the kernel. Third party modules start with t-* 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 -----------------------------------------------------------------

* Peter Münster [Jun 28, 2004 20:00]:

Personally for me, today I'm just looking for two features: - line breaking as suggested in my email from 19. June (-> \hyphenatedfile) - support for C and C++

What I think would work best is if someone could document the verbatim environment thoroughly---and how to add new types---so that it would be easy to add support for C and C++ oneself. I'm probably going to need to define one for Ruby at some point, nikolai -- ::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka ::: ::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden ::: ::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 ::: main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

On Thu, 10 Jul 2008 02:27:45 +0200, Mohamed Bana wrote:

Peter Münster writes:

...

Hello, I suggested to the author of the very feature rich LaTeX-Listings package, Carsten Heinz, to port this package to ConTeXt, and it seems, that he is interested. But before doing it, there are some questions:

* What do Hans and other people thing about that? * listings.sty uses keyval.sty, how is the proper ConTeXt-way to do the same things as keyval, or should listings stay with keyval?

I don't see the point. The native ConTeXt verbatim support seems to cover all what listings can do. The wiki page gives some examples: http://wiki.contextgarden.net/Verbatim_text Regards, BG

Quoting Mohamed Bana :

nico writes:

...

I don't see the point. The native ConTeXt verbatim support seems to cover all what listings can do.

The wiki page gives some examples: http://wiki.contextgarden.net/Verbatim_text

Regards, BG

Hi,

take a look at http://vega.soi.city.ac.uk/~abbg770/listing-sample.pdf, note you can customize the style of the font numbering, you can place a caption and my favourite is the colouring; if you use Eclipse you'll notice that it's the same colour the editor uses.

This can be done easily with current ConTeXt, for example: \setupcolors[state=start] \starttext \setuplinenumbering[location=intext] \setuptyping[option=color] \startJV /** * The HelloWorldApp class implements an application that * simply prints "Hello World!" to standard output. */ class HelloWorldApp { public static void main(String[] args) { System.out.println("Hello World!"); // Display the string. } } \stopJV See the wiki page for adding line numbering and frames (or ask here if the wiki page is confusing). It is possible to change the color scheme and the wiki page gives an example. To make sure that the frames break around pages, you will need to use backgroundtext rather than framedtext. The only advantage of listings is that it provides support for a *lot* of languages out of the box. Writing a syntax highlighter is not easy. I mean, you need to define all kinds of keywords, write regex or parser for identifying comments, strings, escape sequences etc. No matter what language is used to write a syntax highlighter, writing a good syntax highlighter takes time. And hence the advantage of listing. In terms of features, I think it is not difficult to add the required display features in ConTeXt. Line numbering every n lines[1], using proportional fonts, fancy frames, etc are pretty straight-forward things. One option for the long term could be to write a module for mkiv, that can parse the syntax highlighting files of some editor and use them directly. Since most decent editors have syntax highlighting files for lot of languages, we will not have to do the hard work. (well, in case you don't like any available syntax highlighting, and want to roll your own, then it is a different matter). There is a module that uses vim to generate syntax highlighting. Mojca started the module, and I extended it when I needed syntax highlighting for a project. After that, I have not really updated it. It works by using vim to generate a tex file which is then read by context. The only drawback is the starting and stopping times of vim are fairly large (few secs for each file to be transformed). Aditya [1] Actually, line numbering every n lines is already supported.

Hans Hagen writes:

there will be a new pretty print mechanism which provided more control in mkiv

Hans

Hi Hans, Will it support more or less the same features?

On Fri, 11 Jul 2008, Mohamed Bana wrote:

Hans Hagen writes:

...

there will be a new pretty print mechanism which provided more control in mkiv

Hans

Hi Hans,

Will it support more or less the same features?

Which features of listings do you find are missing from ConTeXt? Since I rarely use listings, it is very hard for me evaluate what ConTeXt is lacking. If you can explicitly point out the features that you want, it will be much easier to ensure that are implemented. Aditya