Add a "generated file, do not edit" field to every file generated by plaintextgen
eugenschindler opened this issue · comments
Obviously, we will need some kind of mechanism to specify how to generate this to a "comment", where comments are domain-specific things that can be different, depending to what type of file you generate to. So for a python script it would be:
# generated on <date>, do not edit!
and for java/C++/C/... it would be:
// generated on <date>, do not edit!
etc. for any other type of file
Maybe we shouldn't make a construct for it, but rather a reminder in plaintextgen templates (some text in the editor) that said "don't forget a 'generated on , do not edit!'"?
@klemensschindler: it could be useful to add something like a line "generated file, do not edit" in the template and then add a checkbox for outputting that text or not, a placeholder for a possible single-line comment character or two placeholders for a start-comment and end-comment character and also a checkbox to output the date or not?
I think that would work. It does assume that the comment will always be put at the same place in the file (e.g. top of the file, before the content). It also assumes that handling of all inline comments is the same and handling of all single-line comments is the same.
Cases for which this would not be sufficient if you have strange output formats such as ones that have a hard character limit per line. You may need to split your comment in a specific way (e.g. backslash at the end of a line to extend it) again.
However, all of these do not sound like unreasonable assumptions for most languages and you can still opt to not use this mechanism and do something custom entirely in your plaintextgen template if you need to generate a strange format.
We may be able to simplify handling with things such as dates a little bit though since we already separate the header from the content and can select whether we render the header or not with a checkbox.
The header can simply be a plaintextgen piece of template with a property macro that includes the date. This could also help people to customize things such as date formats in any way they like (code).
One other thing we need to think about is whether we want the header to be defined in every file (changes need to be executed in every template) or define one header per file exension format in your project and reuse it.
Sounds like all good additions. We may even have a checkbox for "hard line-endings, so a an escape character is needed" and then specify an escape character. Moreover, we can also have a special tag that indicates where such a notice of "do not edit" is placed in the file.
Making plaintextgen aware of "file extension types" is an interesting idea, but rather one for a different issue, not this one. Maybe it's good if you make a description for this in a new issue?
Kamino closed and cloned this issue to JetBrains/MPS-extensions