Closed PaulMansour closed 2 years ago
If I were to create file /here/this.md or rename an existing /here/this.whatever to /here/this.md then the next OpenProject would read it in as charlist here.this.
If there were a charlist there.that in the ws then ]setchanged there.that would write file /there/that.charlist unless there already existed a file /there/that.md when that would be overwritten instead.
Would that be useful?
I think the special casing around .dyalog files that writes back a fn, op or script as a .dyalog file if one of the relevant name exists - or at least a clone thereof - might be co-opted to enable this.
Apologies for the ambiguity of the last sentence. The parenthesis "- or at least a clone thereof -" refers to the special case, not the file. read:
I think the special casing around .dyalog files - or at least a clone thereof - that writes back a fn, op or script as a .dyalog file if one of the relevant name exists, might be co-opted to enable this.
@PaulMansour Your original post was a question. No-one else has answered it. Do you want me to implement the above solution?
Yes, if there are no objections. Let me just rephrase how it will work.
If I create a .md file on disk, Acre will read it in as a .charlist file. If I edit a charlist in the workspace, and there exists a correspondingly named .md file, Acre will write back to that file.
I assume if there is both a .charlist and a .md with the same name, then Acre should prioritize the .charlist file.
Will do.
then Acre should prioritize the .charlist file.
That's OK at the time of writing it out but if at the time of _OpenProject- or Refresh two files exist both of which would create the same named object then acre objects, reports the problem and brings neither into the ws.
Ok, sounds good.
Commit: Acre 8.3.0+340 2021-03-17 09:35
Import content of .md file in APLSource as .charlist without renaming. Changing and saving a charlist overwrites a correctly named .md file.
Resolved with commit a48563a74e246ffc37a04fcf76ebfec893470fe2 and 713d353a7ebbc9279b30b4057ca0b080f572f5cc
This might be nice as markdown files are handled nicely by github.