On 6 October 2015 at 22:48, Karl Berry <k...@freefriends.org> wrote: > unless there's an argument > for backwards compatibility. > > Obviously any change will break backwards compatibility and existing > manuals that made their hacks to deal with the existing behavior will, > most likely, fail. But it seems like you've already changed newline > behavior in other cases, namely macros, and if the end result is cleaner > (i.e., can be the same for all formats), it is at least arguably worth > it. Seems like your choice to me. I myself always avoided changing > such behavior, but that may have ultimately been the worse choice.
The change I made for macros was for macro arguments. It was to match 'texi2dvi -E', to make it less necessary - it's a bad experience to process a Texinfo file with "texi2dvi" and either get an error message or bad output because you didn't pass the -E flag. Some manuals do use hacks as you say. I was trying the gcc manual, and with the latest texinfo.tex, there were many extra blank lines, because of this: @macro gccoptlist{body} @smallexample \body\ @end smallexample @end macro @c Makeinfo handles the above macro OK, TeX needs manual line breaks; @c they get lost at some point in handling the macro. But if @macro is @c used here rather than @alias, it produces double line breaks. @iftex @macro gol @end macro @alias gol = * @end iftex @ifnottex @macro gol @end macro @end ifnottex In my download of the gcc manual sources, this was in gcc/doc/include/gcc-common.texi. It's used like this: @gccoptlist{-fconstant-string-class=@var{class-name} @gol -fgnu-runtime -fnext-runtime @gol -fno-nil-receivers @gol -fobjc-abi-version=@var{n} @gol -fobjc-call-cxx-cdtors @gol -fobjc-direct-dispatch @gol -fobjc-exceptions @gol -fobjc-gc @gol -fobjc-nilcheck @gol -fobjc-std=objc1 @gol -fno-local-ivars @gol -fivar-visibility=@r{[}public@r{|}protected@r{|}private@r{|}package@r{]} @gol -freplace-objc-classes @gol -fzero-link @gol -gen-decls @gol -Wassign-intercept @gol -Wno-protocol -Wselector @gol -Wstrict-selector-match @gol -Wundeclared-selector} So there's some pain here, but I think it's better to fix it and make it consistent, otherwise everyone in the future writing other documents will have exactly the same problem, and have to come up with a similar work-around. > As for existing manuals, as you know, lilypond and groff and calc are > ones that persistently come up as making extensive use of macros, > conditionals, and other "tricky" features. I've tested the groff manual, haven't tested the lilypond manual because I can't extract the documentation files from their build system in a form I can compile, and didn't know about the calc manual.