Re: a tentative plan for the after release

[Karl Berry]

Getting back to your mail from last September (appended for convenience)
now that the release is, finally, out.

    1.a settle on the fate of Info versus HTML/Docbook/sexp-based output

Info is not going away in the foreseeable future, as far as I can see.

If Emacs wants to move to something else, that's something they will
have to push/propose, and in any case will surely take years.

Given the difficulties of coordinating anything with Emacs in the past,
I'm not inclined to do anything here without serious interest
originating on their side.

        and, if Info is retained as is, decide how things should be
        escaped in node and cross-ref names

Granted that we should do this, I don't know that it is a top priority.
People have been living with the restrictions on names, silly as they
are, since day one.

Nevertheless, here's my idea for handling arbitrary sequences is another
address@hidden escape.  Something like [literal text="..."].  The Info
readers would have to recognize this, or any solution, at an early
stage, like right after reading a file.  Won't be trivial, since it's a
fundamental break with the idea of Info output being essentially just
the plain text that can be searched, etc.

Most of the real work here is in the readers, I think.  Sergey, do you
have any opinions?

    1.b remove the need for an @iftex at the beginning of document.
        Cf my mail on this list

Similarly as with previous item, granted it would be nice, it doesn't
seem so critical to me.

    1.c determine how marksource material should appear in the tree (macro
        begin and end expansion location, include files, @ at end of @def*
        lines, etc.)

That one is for you, right?  I agree it's not urgent.

    1.d add the possibility to add @-commands to be processed by the Parser
        in customization files

That sounds awfully scary to me.  And those customization files aren't
going to be read by TeX ...

    1.e work with Guido on the customization of translations

Whatever is needed.  Translations in general are also not a top priority
in my eyes.

The things that do seem like the most important to me, i.e., will have
the greatest user impact, are:

1) as you say, stabilize and document the API -- ideally not just about
HTML output, either, but to the point where someone could feasibly write
another backend.  Arnold Robbins keeps asking me about an nroff
backend.  He knows nroff, but can't just look at the big mass of
texi2any code and know where to dive in.

2) the LaTeX backend; in practice, this is the only way we're going to
get real UTF-8 etc. support in the TeX output.

So, hmm, this is a bit different from your priorities ... ?

karl

Date: Sat, 15 Sep 2012 23:00:08 +0200
From: Patrice Dumas <address@hidden>
To: address@hidden
Subject: a tentative plan for the after release

Hello,

Here is what I think could be a possible plan for the work on texi2any
after the release.  Numbers are consecutives, letters are parallel.  
Dependencies of an item are listed in a parenthesis following the 
item number.letter.

1.a settle on the fate of Info versus HTML/Docbook/sexp-based output
    and, if Info is retained as is, decide how things should be escaped
    in node and cross-ref names
1.b remove the need for an @iftex at the beginning of document.  Cf my mail
    on this list
1.c determine how marksource material should appear in the tree (macro
    begin and end expansion location, include files, @ at end of @def*
    lines, etc.)
1.d add the possibility to add @-commands to be processed by the Parser
    in customization files
1.e work with Guido on the customization of translations

2.a (1.d, 1.e, certainly 1.c, maybe 1.b) stabilize the HTML API, document it
2.b (1.a) handle protection of escaped stuff in Info depending on 1.a

3.a (1.b) LaTeX backend
3.b (1.a) do the stuff agreed on 1.a that concerns other formats
3.c (1.c) actually implement marksource
3.d (2.a, 1.e) work on lilypond, to have lilypond use texi2any 
    http://code.google.com/p/lilypond/issues/detail?id=1000

The items that may be postponed to a later release are, in my opinion,
3.a and 3.c.  If 1.a is postponed, the dependent tasks should be
postponed too.