On Wed, Jan 18, 2023 at 08:54:21PM +0000, Gavin Smith wrote: > On Wed, Jan 18, 2023 at 11:52:33AM +0100, Patrice Dumas wrote: > > Even the recent one? I started having more categories in command_data.txt > > both for the inner commands classes (in_heading_spec) and outer commands > > classes > > (contain_simple_text, contain_plain_text), maybe simply adding more > > classes/flags would be enough to have a clear code. The issue is that > > the number of flags is constrained for the XS parser. > > If it would help simplify matters we could add space for more flags in > the XS parser. We would just have to add another field to the COMMAND > structure: "unsigned long flags2" for another 32 flags. We'd also > need a new macro to access the flags, likely command_flags2, and > a naming scheme for the flag symbols, e.g. with a CF2_ prefix. It > may also be possible to use a 64-bit integer type. > > It's nice to limit the number of flags for the sake of simplicity alone, > but this is not an absolute requirement.
Ok. > However, there are already unused flags in commands.h: currently, > CF_item_container, CF_item_line, and CF_inline. Would there be any > reason not to delete these now from commands.h? I feel this would be > a good idea to make it clear that they are no longer relevant. I agree. > There are also some flags that are not used in the XS code, like > CF_letter_no_arg, and there might be the scope not to generate these > in command_data.c. command_data.awk already omits a list of flags > not used in the XS code. Some of those flags could become useful, and most probably would allow to have a code more similar to the pure perl parser, if the pure perl parser code is found to be clearer for that case. So I would suggest keeping the flags that can become useful, as is the case for CF_letter_no_arg even if they are not used. -- Pat
