Re: m4 lines handled everywhere?

[Patrice Dumas]

On Thu, Oct 27, 2011 at 11:06:52PM +0000, Karl Berry wrote:
> 
> Anyway, yes, @w should usually suffice.  But I think we should also
> make a simple command @numbersign{} to generate the # character, to
> avoid any chance of misprocessing.  Imagining multiple front-end passes
> and the @w{} getting eliminated at some point ...

As you like.

> (Aside: Not related to #line, but I've been thinking we may as well make
> @backslashchar{} too, since \ is foolishly part of @macro syntax.  Ok?)

Looks good to me.

>     I think it depends on what TeX would do with the lines directives.  
> 
> I have no feasible way to implement that kind of finicky parsing in
> texinfo.tex.  So a #line is going to be processed as normal Texinfo
> input.  (Outputting #, l, i, ...).
> 
> Besides that, introducing an @ command for this seems like it has great
> potential for complication: the directive itself could be embedded in
> complicated macros or whatever and it would highly unclear as to what
> was intended.  So I think in this one case, a cmdline option/init
> setting/whatever is the better way.

Well, if it had been useful, which is not the case, there could have
been something in the doc stating that TeX can only process it if within the 
main text or something like that.

> The only reliable way I see to embed a directive in the source file
> would be to do it on the \input texinfo line, but when I was speculating
> about enabling m4 or not that way on the list, nobody seemed to like the
> idea.  But maybe for this more limited on/off, it would be ok.

I can't see the fundamental difference between an @-command that sets this 
on or off and something on the \input line that do the same.  Using an 
@-command would be much more consistent with the remaining of the language
in my opinion.  I think that the \input line should remain something 'magical' 
that turns TeX on and should never be used for enything else.

> That is, the implementation I am imagining is a new "zeroth" pass which
> purely and simply scans the text as text, looking for (and removing)
> these #lines and not recognizing anything else.  Then the regular
> parsing takes over on the result.  Somehow actually taking account of
> the #line information for diagnostic msgs, of course.

If it is not possible to process those line in TeX, I guess that the best
is to remove them with a sed one liner before processing the file.

I have another idea, though.  If texi2any transforms the # lines directives into
something TeX friendly (which would certainly be rather trivial), like

  @synchronizeline 1, filename

or 

  @synchronizeline{1, filename}

maybe it would become possible for TeX not to output the command and synchronize
the line number and file name?  This new command could even be an official new 
command of texinfo such that other external tools can use that feature too.
For example, this could be used in tools that generate texinfo code, like I know
lilypond or singular do.

It may also be possible to have the user-defined @-macro information there such
that TeX can use this information in error messages while processing a file 
that was preprocessed by texi2any -E, with something along, for texinfo
coming from user-defined macros

  @synchronizeline 1, @mymacro, filename

and for included files

  @synchronizeline 1, , filename

On the texi2any side this wouldn't be that complicated to do as all the 
information is already there.

-- 
Pat