On 07/17/2012 10:43 AM, Patrice Dumas wrote: > >>> In my opinion it is much better to have something consistent, and >>> leaving the end of line out is also better in my opinion, otherwise it >>> is not possible to have a macro expansion within a line. >> >> If this causes existing uses to break in subtle ways, then I disagree, >> but I've been unable to convince you in the past. > > Once again the difference is not on keeping or not the end of line, as I > showed with the examples done with makeinfo in C which do remove the end > of line. The difference is the order of comment removal with respect to > macro expansion. This change will break existing uses in subtle ways. > I could try to provide with a backward compatibility mode in which > comments are removed when expanding macros bodies, but I doubt it is > worth it. It could be interesting to document that change, though.
What does this mean to the end user? Autoconf needs to have a macro whose expansion does not end with the current line, and where the manual can be compiled with both old and new tools (that is, I do not want to force autoconf development to upgrade to the latest texinfo just to compile the manual). If you subtly change semantics of the approach autoconf is currently using, then you also need to document a construct that will work for both old and new tools (even if that means defining the macro twice inside some sort of conditional that determines which tool and therefore which semantics will be encountered). My preference would be for preserving the existing semantics, so that the autoconf manual does not have to change what it already has in place. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
