This commit was already in PR #625 but this new one is based on a more
recent version of the master branch.
As discussed in https://github.com/GitJournal/GitJournal/pull/625 the
problem was that if there is no yaml header, the title does not get
stored anywhere and hence gets lost. The fix is to write the title back
to the file as a first heading. This is used for loading the title
anyway, afaict.
The side effect is of course that any *other* application using the note
in the meantime will see the heading containing the note title. This is
way less disruptive than losing the title fully, though.
Instead we're going to move back to standard exceptions.
Using a custom Result class has created far far more problems
- The Stacktraces aren't always right
- Sometimes one forgets to check the Result error
- All other exception throwing code needing to be converted to Results
- Non idiomatic Dart code
I think it's better to just go back to exceptions. They have their
problems, but overall, I think it's a better approach.
I'm trying to get ride of this huge 'Note' class, and have it be quite
dumb. The idea is that we'll have separate Note subclasses - TxtNote,
MdNote, etc
It's not ideal as the hash is now calculated twice, but it simplifies
such a large porition of the code as I can put proper asserts to make
sure all Files in the NotesFolderFS always have a valid GitHash.
Earlier one could never change a note type, and therefore its extension.
Now you can rename a note's filename to whatever and accordingly the
editor will change.
A warning message is shown when changing the file type.
Fixes#474
Fixes#78
This is probably the largest commit that I have ever made. From now on -
every File always has an mtime and ctime which is fetched from git.
Notes can optionally override that time by providing yaml metadata.
Additionally the 'filePath' and 'folderPath' is now relative to the
repoPath instead of being the full path.
This will slow down GitJournal like crazy as all the mtimes and ctime
still need to be cached. For my test repo it takes about 23 seconds for
GitJournal to become responsive.
Instead there is a new type called 'UnopenedFile'. This was part of my
effort to not have everything inside the 'Note' class and to make it a
bit more immutable.
But, wow, this took a very long time. The 'Note' class seems to be very
deeply integrated everywhere.
This makes us one step closer to making the Note class immutable which
will help GitJournal's overall architecture a lot. Plus it makes me one
step closer to having proper web support.
Now that dart-code-metrics has been updated, this lint can finally be
used. So far all of these are false positives, in the sense that I don't
care about their return values.
I wish there was an easy way of marking functions whose return value
shouldn't ever be ignored.
I'm trying to move all FS related operations out of the Note class, and
ideally make it super small. This class will need to be serialized over
the wire for the web version, and that needs it to be small.