Add linewrap option 'auto'

[jonakeys]

This resolves the feature request #1246 It adds the possibility to set 'auto' as linewrap option so jrnl automatically determines the width of the terminal/columns.

I chose to do the check while outputting information. The downside is that when using the debug flag it outputs a line for every entry. But it could also be done earlier when the config file is being read. Would that be better? If so, I'll modify the code to do so.

Fixes #1246

Checklist

• I have read the contributing doc.
• I have included a link to the relevant issue number.
• I have checked to ensure there aren't other open pull requests
  for the same issue.
• I have written new tests for these changes, as needed.

[micahellison]

I have a small nitpick on the except clause, and I think this also needs some tests, either a unit test or a BDD test. Let us know if you'd like any help with that.

[micahellison]

Could you use except OSError here? The docs for get_terminal_size say that's the exception that fires when it can't get the terminal size for standard out, I'd like to avoid generic exceptions.

[jonakeys]

Thanks for your remarks! I can easily specify the except clause.
But for the tests I need some help. I can create a test for the 'auto' linewrap option. But how do I create a test that checks if the get_terminal_size fires the exception?

[micahellison]

We're working on the finishing touches of the 3.0 beta and are going to prioritize that now, but I'll get back to this PR to review in a week or so. Thanks for your work so far on it!

[jonakeys]

That's no problem, I'm happy to contribute where I can.
And ofcourse the v3.0 has full focus now for you as maintainers. Good luck!

[micahellison]

One minor issue - this is broken with the "fancy" format. Could you take a look? It has its own code in jrnl/plugins/fancy_exporter.py. Thanks!

[micahellison]

Thanks for making this change. It's working well for me. I don't like seeing the same code in multiple places at once, but this is a more of a problem with jrnl's architecture than with your PR. We eventually want to refactor the Journal/Entry classes as mentioned in #1184 to separate presentation from data travel, and that's way outside of the scope of this PR.

[jonakeys]

You're welcome, glad I can contribute! I'm also not a fan of duplicate code myself. But to fix it would need to create a function in a shared file with another import as consequence. That wouldn't be beautiful too. When the refactoring takes place, it will resolve issues like this indeed.