This is more a question of understanding / suggestion for better flexibility - not really an error.
We do have numerous Cobolsources with heavy use of TABULATORs.
Due to indention reasons there are even up to 11 TABS before various Cobol-statements, for example - and all that still stuck into that rigid 1-7,8-72,73-80 column corsett ... gosh !!!
As long as the parsed and returned Cobol-String is treated by a compiler capable of a wide or free source format, we are facing no problem at all, but if the modified Cobol-Statement/Cobol-Files is returned to the host, we have to conform to that infamous rigid Area-Format.
The current algorithm seems to replace each Tab by 4 blanks - but we would rather need more flexibility in that replacement algorithm like being able to define for example:
For further, better clarification: the parser has NO problems with such lines and parses them correctly. "JUST" the returned parsing String is "too long" and breaks the strict column format. So if the Parser is being used for various Cobol-enhancement-tasks (like reformatting, goto-elimination, dead-code-removal etc) and the modified sources are brought back to the host => then we face the problem (or have to handle it in a postprocessor => as we are doing right now)!
CobolPreprocessor.CobolSourceFormatEnum format = CobolPreprocessor.CobolSourceFormatEnum.FIXED;
CobolParserParamsImpl params = new CobolParserParamsImpl();
params.setCopyBookFiles(copyBookFiles);
String preProcessedInput = new CobolPreprocessorImpl().process(inputFile, format, params); // <<<<<======= THIS String is not Fixed format any more and not AREA-conform
This is more a question of understanding / suggestion for better flexibility - not really an error. We do have numerous Cobolsources with heavy use of TABULATORs. Due to indention reasons there are even up to 11 TABS before various Cobol-statements, for example - and all that still stuck into that rigid 1-7,8-72,73-80 column corsett ... gosh !!!
As long as the parsed and returned Cobol-String is treated by a compiler capable of a wide or free source format, we are facing no problem at all, but if the modified Cobol-Statement/Cobol-Files is returned to the host, we have to conform to that infamous rigid Area-Format. The current algorithm seems to replace each Tab by 4 blanks - but we would rather need more flexibility in that replacement algorithm like being able to define for example:
Somehow that issue relates to https://github.com/uwol/cobol85parser/issues/37 and https://github.com/uwol/cobol85parser/issues/24 as well => an option to retain the input format when getting a parsed String from the Cobol85Parser.
For further, better clarification: the parser has NO problems with such lines and parses them correctly. "JUST" the returned parsing String is "too long" and breaks the strict column format. So if the Parser is being used for various Cobol-enhancement-tasks (like reformatting, goto-elimination, dead-code-removal etc) and the modified sources are brought back to the host => then we face the problem (or have to handle it in a postprocessor => as we are doing right now)!