James K. Lowden

@dilodilo, sure, happy to help. Let me try to persuade you that you're making assumptions that are making your life difficult. I don't know the whole answer, but I do know it lies in another direction. You cannot in general "counteract" what TeX will do with your input. Anything you do will be easily overwhelmed by small changes in the TeX environment. You're furthermore complicating your life — and, if you ask me, doing a disservice to the reader — by using a stack of little brackets to represent...

Looking at SYN-Complete-Program-Info.texi, IMO the problem starts there. In general, typesetting tools don't want extra whitespace. If you want to line things up, you have to issue commands in terms of the output. If you're "getting away with it" by using verbatiminclude: @verbatiminclude SYN-\filetex\.texi then I would observe the input is already ragged, e.g. [ OBJECT-COMPUTER. Execution-Computer-Specification. ] [ ~~~~~~~~~~~~~~~ ] [ REPOSITORY. Prototype-Specification... . ] I don't know what's...

We may observe the problem is evident in the HTML, too. (It would be better if the TOC could link to "7. PROCEDURE DIVISION", but I never figured out how to do that.) To figure out what the solution to the issue might be, we need to know what causes it. That is, we need to examine the constructed TeX input, understand what's wrong with it, and then decide whether to change the .gen files that produce it, or the --help output that supplies the original input. Taking PROCEDURE DIVISION as an example,...

../../gcc/cobol/symbols.h:158:1: error: The one definition rule is violated, different classes/structs have the same name 'cbl_domain_elem_t' [ctuOneDefinitionRuleViolation] class cbl_domain_elem_t { ^ /home/jklowden/projects/3rd/gcc/parser/gcc/cobol/symbols.h:158:1: note: The one definition rule is violated, different classes/structs have the same name 'cbl_domain_elem_t' class cbl_domain_elem_t { ^ ../../gcc/cobol/symbols.h:158:1: note: The one definition rule is violated, different classes/structs...

const cdfval_base_t& cdfval_base_t::operator()( const YDFLTYPE& loc ) { static cdfval_t zero(0); return verify_integer(loc, *this) ? *this : zero; } report: ../../gcc/cobol/cdf.y:897:37: error: Reference to temporary returned. [returnTempReference] return verify_integer(loc, *this) ? *this : zero; Neither zero nor *this are temporary. cdfval_base_t is the public base class for cdfval_t.

trunk build failure

Let's abaondon this idea and close this issue. The notion as I recall was to help teams/projects to collect compiler options together by providing an explicit mechanism, namely a configuration file. It would control the default behavior of cobc. The way I remember the discussion, I agreed to provide the mechanism as a generalization of a much more specific idea: a way to configure which preprocessors are invoked, and in which order. On the evidence, both ideas died on the vine. I wrote a configuration-processing...

temporary: use std::set to debug SQL_IPTR free error