Changes between Initial Version and Version 1 of Ticket #6877, comment 6


Ignore:
Timestamp:
09/12/2018 10:18:29 AM (2 years ago)
Author:
kvas
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #6877, comment 6

    initial v1  
    77What else can we do to solve the issue you pointed out? 
    88 
    9 One idea that came to my mind is that we could see the output of the parser as consisting of two separate things: metadata (maybe it should be a dict) and other lines (comments, filters and processing instructions). The parser would swallow the header and we would output it ourselves when writing out a filter list. This approach also solves the problems with merging metadata and not duplicating the headers but there's a bit of a catch. It changes the semantics of includes: now they just do simple line-based substitution and in this approach they would be at a higher level of abstraction. It seems like this could be good in some cases (e.g. automatically taking care of duplicate metadata keys) but it could also cause confusion, because it's different from what we do now. 
     9One idea that came to my mind is that we could see the output of the parser as consisting of two separate things: metadata (maybe it should be a dict) and content lines (comments, filters and processing instructions). The parser would swallow the header and we would output it ourselves when writing out a filter list. This approach also solves the problems with merging metadata and not duplicating the headers but there's a bit of a catch. It changes the semantics of includes: now they just do simple line-based substitution and in this approach they would be at a higher level of abstraction. It seems like this could be good in some cases (e.g. automatically taking care of duplicate metadata keys) but it could also cause confusion, because it's different from what we do now. 
    1010 
    1111What do you think about this second option?