The newline error in the Joplin code

Operating system

macOS

Joplin version

3.2.13

Desktop version info

Joplin 3.2.13 (prod, darwin)

Client ID: 6210ca0aae5c4a6fbda51d65707152b5
Sync Version: 3
Profile Version: 47
Keychain Supported: Yes

Revision: a898e17

Backup: 1.4.2
Freehand Drawing: 2.14.0

Editor

Rich Text Editor

What issue do you have?

I dont want double spaces in my notes. I can avoid double spaces, without enabling soft breaks, by inserting newlines, either directly using Shift-Enter, or the Markdown way, using two spaces and Enter. So why does using Enter once result in two line breaks?

It's a misunderstanding of the Markdown syntax. According to How to Add New Line in Markdown, you hit the Enter key twice to create one newline. Joplin is coded to have that backwards: when you hit the Enter key once, you create two newlines.

Please fix that.

I think we are a lot to ask ourselves this question about the Rich Text Editor and to try to find a way to avoid that with no success ( except with [SHIFT] [ENTER] ).

Among many things I tried this :


but I never see a modification of behaviour in the RTE.

I would be very cool to have [ENTER] = one line only.
(of course it will create a new paragraph in the same time except if we use [SHIFT] [ENTER] ).

Any pluggin able to do that ?

Thanks for help

Development note: I'm linking to a TinyMCE configuration option that might be relevant here (Joplin's Rich Text Editor uses TinyMCE):

Thanks a lot !!!

At this point I can just live with it. If I hit Enter and see an extra blank line, I back up and hit Shift-Enter. Ordinarily that would be a deal-breaker, but the other note systems I've tried don't synchronize reliably. Joplin lets me choose which cloud to synchronize in, it has a Synchronise button, and it shows sync progress. That's what I need.

Of course it would be better not to have to use Shift-Enter, but.... It's a good thing Shift and Enter are so close together. :neutral_face:

2 Likes

LOL

This thread reminds me of work (part of it anyway).

One of the things I end up doing involves Microsoft Word; automating production of documents that are at times 50+ pages tennes of thousands of times a day. Microsoft Word is probably one of the furthest things away from Markdown possible, but there's one problem I run into daily.

Half the embedded stylesheets that get used have 0 line spacing between paragraphs. The other half do. Basically none of them are consistent between 20+ years of legacy templates, and the end users disagree on preferences on how much spaces should even be between paragraphs. (Part of my current stuff is saying from a business efficient POV, disagree all you want, I'm going to make things consistent regardless because there's a ridiculous amount of problems caused by not being able to even know what something is going to look like until it's already rendered, at which point, it'll look broken most likely if there's not consistency in approach).

That is, your average desktop user is completely willing to just spam the enter key repeatedly to create space, ignoring the fact it's the equivalent in HTML to having <p></p><p></p><p>Actual text</p> and all the problems associated with algorithms that try to keep pseudo <h1>Title</h1><p>Text</p> logically connected on the same page which fall apart.

Word also has shift enter, which is a "line-break", and is treated differently by the layout systems. I see people realise this exists in Excel (where enter works completely differently) but even those users do not know the semantic difference in Word.

And ultimately, I'd imagine TinyMCE builds its defaults around users expectations, where the significant majority of users base their defaults on Microsoft Word due to that lovely proprietary stack in the education system, where one enter key is absolutely one logical paragraph regardless of whether it's visually lacking in space or isn't.

The analogy from Word to Markdown is clear in the specification, the Word equivalent of a line break in Markdown is simply a single carriage return to go down to the next line. The equivalent of a paragraph mark is two carriage returns in a row with nothing in-between them, a simple \r\n\r\n

IMO, it makes more sense for Joplin to have an option to override the renderer/CSS to remove line spacing between paragraphs than it does to flip the behaviour of the enter key to act as if it's a line break bind and not a paragraph bind, especially if you were to e.g., ever consider exporting your notes in alternate formats like HTML.

So in my opinion, the defaults make sense from a user experience point of view because it emulates the behaviour most people are familiar with. In the context of Joplin specifically with the markdown editor and the actual preview being separate, I can see it being annoying in the markdown preview; but from a technical correctness POV where the content and presentation of content are separate, in my opinion it makes sense to treat that as a styling/theme problem and not a content problem.

(Appreciate this isn't really an answer, but thought people might find it interesting anyway).

Devils Advocate mode: I personally feel markdown encourages this when I use it outside of Joplin (e.g., Nano):

Every sentence should be on it's own line.
This is still a paragraph.
If I see this. It's wrong. Git diff works better when these are broken up.

So even I'm a hypocrite, because swapping the enter key would make sense in a lot of contexts too, I write more sentences than paragraphs.

4 Likes

Very interesting analyse. So you mean there are two ways for the devs to avoid the double lines between paragraphs : modifiying the "content" (HTML code ?) or modifiy the styling (CSS code ?) and you think the second solution is better ?

1 Like

I think if you boil the problem to the simplest form, the frustration isn't "There's 2 lines", it's "I can see two lines", the users preference is less line spacing.

That's at the visualisation layer, not at the content layer IMO. Because from e.g., the perspective of a plugin who's job is to count paragraphs

this
is
not
identical

to

this

So swapping the button is equivalent to changing the content layer to fix a visualisation problem, which is what CSS tried to save HTML from, and, being literally WebTech, is pretty comparable with Joplins Markdown IMO.

1 Like

That's clear. Thank you.

1 Like

It doesn't look that simple from where I am. Generally I enter data into Joplin on my Mac, and read and delete it on an Android phone or tablet. I just used my tablet. In places where I saw blank lines, I was able to place the cursor in the blank lines and backspace to delete the blank line.

If the blank lines were visualization, I wouldn't even be able to put the cursor in them. That's what I expected, but it's not what I got. That tells me the blank lines are content.

And no, I did not "inadvertently" insert the blank lines myself.

Quoted from somewhere: For every problem there is a solution that is clear, simple and wrong.

P.S. Here's a howdy-doo! Sitting at the Mac, with the Android phone next to the keyboard, I entered a line with Enter. A blank line was created, and I could not put the cursor in it. Sync occurred automatically. I opened the same note in the phone, entered edit mode, and put the cursor in the blank line. So is the blank line content or visualization? Is there really such a distinction?

1 Like

It's not really wrong, the exact issue is treating the markdown as self descriptive, when in reality everything from its fonts to its positioning is determined by the renderer, which in Joplins case means taking the markdown from disk and converting into a webpage, where suddenly you have options to manipulate the CSS/HTML itself in such a way it looks how you want.

That is, just remove the <p></p> if you can identify it as empty, which doesn't sound too hard for a plugin to do, surely, or then set visibility on it to be removed from the view. Then having pruned dud lines, the rest is "add a variable toggle for line spacing that swaps the CSS dynamically on user preference". A basic feature of Word too.

It's not something I'd have the experience to do myself, but thankfully unlike my job, Joplin isn't Microsoft word and actually has good extensibility and is open for editing, the app already does this on the regular for XSS exploits to remove attack vectors. Why can't that same mechanic edit some CSS?

Don't change the enter button, just enable a setting to change how the app looks so you can spam the enter button forever if you please, it'll look the same and gives some nice options. Make the app just ignore spam enters if you've already done one. It's not unsolvable, though admittedly with all the different editors actually available, it sounds like a PITA.

The alternative of changing the mechanics of the enter button pushes changes on everyone who's in preference of how it is, so a toggle and configurability being optional sounds like something I think people could appreciate since it sounds realistically doable.

2 Likes

There is no consistent content. The same note, edited on the Mac in the wysiwyg editor to add a paragraph ended by Enter, appears
(a) in macOS with a paragraph margin of one space (can't put the cursor in it), and
(b) in Android with a blank paragraph after it (can put the cursor in it).

You can't talk about rendering the content until you know what the content is.

Another point, which may be relevant only to the way I use notes. I don't need paragraphs. I write and edit lists with comments and headers. It's more like writing code than writing text. Code editors don't have paragraphs; they just have lines. That means I'm perfectly happy just putting lines where I want them—and not happy if I see lines where I didn't put them.

2 Likes