Over the years, the few issues I've submitted have all been related to
improving/adding functionality to use Rednotebook from the console. I
always had the option to use the main GUI, so the basic lack of
console usefulness was something that could be overlooked. However,
I'm now in a situation where 90% of the time I don't have access to a
windowing system, so for my workflow I am now having to look for a
mostly console-based solution. Jendrik has done such a great job with
rednotebook over the years of development that it is next to
impossible to find a replacement. In the end, I am going with a
kludged-together solution of zim patched for markdown support with the
Journal plugin. This isn't exactly an elegant solution, but it does
meet my current needs.
I only mention this here because there are a couple of changes that
can be made to Rednotebook that would also work. These changes are
foundational, would require a lot of work implementing, require
changes that could be very visible on the user's side and would
require letting go of backward compatibility (think of the Microsoft's
changes from .doc to .docx - new versions of Word can read documents
from past versions, but past versions of Word cannot open the new file
format). There would be no immediate benefits to these changes except
for the handful of users who share the same type of user stories as I
do. But there could be major benefits in the future, addressing things
that aren't even issues today... In other words, this is more of a
thought experiment than anything, but perhaps some value could come
from it for future rednotebook development.
Divorce rednotebook from yaml
This would be the biggest change, it would immediately break
backwards-compatibility and break the storage model for rednotebook.
But yaml is not a good fit for a journal concept. I am pretty sure I
understand the initial concept, and it maybe could've eventually led
to different features being added, but with this implementation yaml
just adds an extra layer of complexity that doesn't need to be.
Current rednotebook journal files are plain text files containing yaml
documents consisting of two key/value pairs: day number and text in
txt2tags format. There are two major issues with this set up:
1. Embedding txt2tags within yaml creates complicated text parsing
issues, requiring escaping the contents of the "text" value to not
break the yaml document. We've all seen these issues unexpectedly
occur when rednotebook won't open because of an invalid character
in one of the month files.
2. The current format can lead to a loss of an entire month's worth
of journal entries because of a corruption in one file, e.g. a
corrupt file for July 2021 destroys entries for July 1 - July 31,
3. There is no inherent benefit of a single month file containing
multiple day records over having one extra directory level
underneath month with a text file for each day. I would propose a
directory structure as:
Journal root
- Year in YYYY format
-- Month in MM format
--- Day in DD format
e.g. Rednotebook/2021/12/01.txt or Rednotebook/2021/12/01.md
Switch to markdown or enable multiple markup language modules
This is either a controversial suggestion or one that makes perfect
sense. As with every great software package, Jendrik made
rednotebook to use what he was most comfortable with, and at the time
his preferred markup language was txt2tags. That makes perfect sense
and justifies txt2tags being rednotebook's markup language. However,
over the years since, markdown has become the biggest (and
unfortunately least-strict) markup language. I will use two
different technologies to defend my statement: R-markdown and GitHub
markdown. Markdown is used almost everywhere.
However, Rednotebook doesn't need to abandon txt2tags formatting if a
modular approach is used. The parser used to build what is displayed
could theoretically be made modular, so any markup language could be
used as long as a definition file is provided, much like vim/neovim do
with their syntax files.
Anyway, that's my two cents. :) As mentioned, I've loved Rednotebook
for a long, long time and I will be keeping an eye on future
development. I wish I had the coding skills and the time to help out
with development, but I hope that something in this email will help out.
