Carriage returns in entries about jrnl HOT 5 CLOSED

Hi,

thanks for enjoying jrnl and your feedback! Interpreting \n as a carriage return makes sense, I'll implement that right away. Are you writing mostly inline one the command line, using the built-in editor (excuse the exaggeration) or an external editor? I'm thinking that maybe using the built-in editor Shift + Return could be interpreted as a line similar to most IM apps.

from jrnl.

I write the entries mostly inline on the command line. I'm not sure what you mean by the built-in editor...is that the "compose entry" mode that comes up when you just type "jrnl"? Doing something like a Shift-Return would also work for me.

Thanks for your reply.

from jrnl.

Okay, with fb3d7ab, \n will be converted to new lines. If using from the command line however you must wrap your entry in quotes OR escape the backslash, ie.

jrnl My new \n entry

will not work, but

jrnl "My new \n entry"

will, as will

jrnl My new \\n entry

In all of these cases, everything before the first line break will be interpreted as the entry's title (just as stuff before the first [.?!] already does)

from jrnl.

Hmmm, running on Windows 7 x64 bit with python 2.7 I don't have to escape the newlines as \\n. When I did, I got an extra slash on my entries. When I did:

jrnl Title.Line 1 \\nLine 2\\nLine 3

I got an entry like:

2012-07-05 12:18 Title.
Line 1\
Line 2\
Line 3

But if I just do the \n (with or without quotes), it was interpreting it correctly:

jrnl Title.Line 1 \nLine 2\nLine 3

I ended up with the proper entry:

2012-07-05 12:18 Title.
Line 1
Line 2
Line 3

Entries encapsulated in quotes worked as you described.

Either way, this works great for me and solves my issue perfectly. Thanks for the update!

from jrnl.

Aah, okay, only tested the patch on unix with bash - I suppose different shells treat \n in the arguments differently. Glad it works for you!

from jrnl.