Jrnl: Better md output formatter

[bjornasm]

Feature Request

Use Case/Motivation

I think the terminal output (using jrnl -n 1 ) especially when using markdown to have subheadings and lists, isn't up to the level of the rest of this tool. It would be great if a little bit of formatting, adhering to f.ex markdown could be a great addition, without taking away from this fantastic minimalistic tool.

jrnl "This is todays journal. Today I was on github after it crashed. ## Work. Work is going ok"
then

jrnl -n 1

will output something like this:

13.07.2020 This is todays journal.
| Today I was on github after it crashed. ##Work. Work is going ok

instead of f.ex:

13.07.2020 This is todays journal.
This is todays journal. Today I was on github after it crashed.
Work.
Work is going ok

Example Usage

jrnl -n 5 --md
or
jrnl -n 5 --prettify

Other information

Piping the output to other open source libraries such as mdv (pip install mdv) could be a simple way to achieve this.

[eshrh]

What is wrong with jrnl -n 5 --export md? Works fine for me.

[wren]

Hi, @bjornasm! Thank you for the praise about the rest of jrnl!

We're always open to enhancement suggestions. Can you give--export md a try and let us know which parts you'd like to see improved?

[bjornasm]

Thank you for your answers @eshrh @wren - I see in retrospect that I wasn't as clear as I should. I have updated my initial answer, what I meant was the output when looking at earlier entries using for example jrnl -n 5 to view them in terminal. The --export md works as intended, however that requires us to export and then open in a markdown viewer of some sort if I am not mistaken, however I was seeking a bit more styling straight from the CLI.

jrnl "This is todays journal. Today I was on github after it crashed. ##Work. Work is going ok"
then

jrnl -n 1

will output something like this:

13.07.2020 This is todays journal.
| Today I was on github after it crashed. ##Work. Work is going ok

instead of f.ex:

13.07.2020 This is todays journal.
"This is todays journal. Today I was on github after it crashed.
Work.
Work is going ok

[eshrh]

This makes sense. My problem is that this sort of thing prefers one specific formatting over another, when jrnl is supposed to be a simple format-agnostic text storage. I can also very easily imagine people typing hashes and other markdown syntax unintentionally.

I wonder if another exporter could be written, say MDpretty that does this. I think that would be more in line with existing code and methodology. I don't think that doing this is very difficult. It's as simple as writing a few regexps for hashes, wrapping them in a couple of newlines and \033[1m. Usage would look like jrnl -n 1 --export MDpretty

I'll wait to see what a maintainer has to say.

[wren]

Hi, again!

I agree that --export is confusingly named (as mentioned in #814 comments). It really should be --format (and will be in v2.5).

So, using --export, you can output to the cli by doing something like jrnl --export md -n 1 and you'll see your entry formatted as markdown without having to save or export any files anywhere. You can also take that same output and pipe it to the viewer of your choice. For example, I use mdcat to view markdown files in my terminal. So, to view a jrnl entry I would do something like jrnl --export md -n 1 | mdcat and it looks pretty great.

Anyway, I'm all for making optimizations to the markdown exporter, but I really want to avoid implementing our own markdown parser nested inside of jrnl, especially when projects like mdcat are already handling it so well. I think the size and scope of projects like mdcat should tell us that it's really not as easy as it may seem (this comment from bat maintainer gives us just a taste of the), and jrnl always strives to "do one thing well." So, changes to our markdown format should be aimed at making better output for other tools to format for us.

That being said, I do think that if this were to be done, that a new exporter would be the place to put it. The good news is that jrnl is actually already written to accept custom plugins just by placing a python file in the plugins folder. So, if anyone were to write a custom markdown exporter, jrnl is ready to make use of it. But for us to even think about including it in jrnl, though, a markdown parser would have to be available as a rock-solid, across-platform, and actively maintained Python library.

[wren]

After writing this up, I realized that always having to add --export md is pretty annoying. So, here's two things:

1. This is an alias I use to display jrnl entries as markdown (it pipes to mdcat for formatting, then less for paging):
   alias jm='func() { jrnl --export md "$@" | mdcat | less -r; }; func'
2. Maybe we should have a way to select a default format for a journal when displayed on the command line? Right now we always default to the jrnl format, but maybe we could make that customizable in the config file to save users some keystrokes.

[bjornasm]

Thank you, @wren and @eshrh for the insightful discussion! I think latest suggestion from @wren might be the best, to chose format. But until that might be implemented, I really appreciate the suggestions on "exporting" and piping to mdcat :) Will use that for now on!

[wren]

Ok, sounds like this issue is resolved. I'll make a new one for default format in the config. Let us know if you have any other questions!