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
This greatly simplifies the entire data flow. Though, it comes at the
risk of introducing bugs, but I think it's worth it.
Plus, it makes everything far far more testable.
Certain Editors only support certain file formats. We can create an
editor either by -
* Giving it a Note, and letting it choose an editor based on the default
/ note metadata
* New Note with a file type
* New Note with a editor type + possible file type
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.
Now that we support multiple file types, sorting by title gets confusing
since a lot of notes don't have a title. Also, this simplifies a lot of
the code base.
Stop it being a singleton. This means it needs to be passed around a
lot. This sucks, but it's how it should be. I shouldn't be using a
global variable to get around this.
This is needed as Settings will soon become repo specific when we
support multiple repos.
This breaks saving the settings in a file, that feature was toggled off
anyway. It needs to be thought over again.
This reverts commit 303192d9d575b26a77a00f7a62212f310ec1e329.
This reverts commit cd9d128b47ed523036f7ae1232ec7adcf04ed8a9.
GitJournal is used by non-English speakers (a lot in China and Russia)
and while we don't support those languages completely, we do support
them a little bit. I don't want to loose this functionality. It would be
better for us to fix the bug in intl.
