meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revisionBoth sides next revision
new_settings_in_javacc_21 [2021/12/20 15:01] – revuskynew_settings_in_javacc_21 [2021/12/20 15:04] – revusky
Line 6: Line 6:
   * **EXTRA_TOKENS** This setting allows you to indicate some additional token types that are not defined with regular expressions in the lexical grammar. This can be useful particularly in token hook routines.   * **EXTRA_TOKENS** This setting allows you to indicate some additional token types that are not defined with regular expressions in the lexical grammar. This can be useful particularly in token hook routines.
   * **FAULT_TOLERANT** This turns on the experimental support for building a [[fault tolerant]] parser. It is off by default.   * **FAULT_TOLERANT** This turns on the experimental support for building a [[fault tolerant]] parser. It is off by default.
-  * **PRESERVE_LINE_ENDINGS** This is true by default (though this could change in the future based on user feedback. If you turn this setting off, all Windows/DOS style line endings (\r\n) are converted to UNIX/MacOS style (\n) internally when the file is read in. Note, by the way, that one advantage of this and the TABS_TO_SPACES option is that if you convert tabs to spaces and line endings to \n then your grammar's lexical specification can be a bit simpler. And your own code that runs over Tokens and Nodes. Your code can just assume that any line endings are a simple \n and and your horizontal whitespace is just spaces, not a mix of tabs and spaces, independently of what platform the generated code is running on.+  * **PRESERVE_LINE_ENDINGS** This is now off by default. That means that all Windows/DOS style line endings (\r\n) are converted to UNIX/MacOS style (\n) internally when the file is read in. Note, by the way, that one advantage of this and the TABS_TO_SPACES option is that if you convert tabs to spaces and line endings to \n then your grammar's lexical specification can be a bit simpler. And your own code that runs over Tokens and Nodes. Your code can just assume that any line endings are a simple \n and and your horizontal whitespace is just spaces, not a mix of tabs and spaces, independently of what platform the generated code is running on.
   * **SMART_NODE_CREATION** This is the default behavior, so you would have to explicitly turn it off. It means that if no JJTree-style tree-building annotation is used, then a new Node will be created if there are more than one Nodes on the stack. So, a production like '' A (B)* '' will create a new Node if there are one or more B's after the A. If there is only an ''A'' then the production will just leave it on the stack. It is our belief that this is the behavior that most people would want most of the time.   * **SMART_NODE_CREATION** This is the default behavior, so you would have to explicitly turn it off. It means that if no JJTree-style tree-building annotation is used, then a new Node will be created if there are more than one Nodes on the stack. So, a production like '' A (B)* '' will create a new Node if there are one or more B's after the A. If there is only an ''A'' then the production will just leave it on the stack. It is our belief that this is the behavior that most people would want most of the time.
   * **SPECIAL_TOKENS_ARE_NODES** This sets whether to add so-called "special tokens" to the AST. By default, it is set to false. (Note that this option and TOKENS_ARE_NODES are meaningless if TREE_BUILDING_ENABLED is set to false.)   * **SPECIAL_TOKENS_ARE_NODES** This sets whether to add so-called "special tokens" to the AST. By default, it is set to false. (Note that this option and TOKENS_ARE_NODES are meaningless if TREE_BUILDING_ENABLED is set to false.)