Last line of invalid note still flagged as note?

[ftolsson]

Just checking in to see if this is on purpose:

As far as I understand it, if creating a multi-line note with an entirely BLANK line in the middle (without double spaces) that note should be invalid and not a note at all:

[[first line of note

line three]]

However, it seems as though in that scenario, the last line will still be .note == true

[[first line of note            --> .note == false
                                --> .note == false
line three]]                    --> .note == TRUE

The note is not given the note element color in the editor window, but the way I'm parsing stuff in my outliner that line three will be considered part of any previous note in the document (with some weird side effects, not least that selecting/deleting the previous note from my outliner, the selection range in the script will be too long and risk deleting text outside the note)

I can fix this with a workaround if the result is on purpose, but I'm guessing it is not?

[lmparppei]

 ⛄️🔜💀

This is not on purpose. I'm starting to regret supporting multi-line notes, but I'll look into this.

.note property is generated on the fly, and it checks if every index in the line is a note index (+ possible whitespace). Either that method isn't working or the parser doesn't do its job.

[lmparppei]

Is the last line rendered as a note in the editor, though?

[lmparppei]

Fixed in 1.927, caused by a badly thought out conditional in - (NSMutableIndexSet*)noteRanges:

[ftolsson]

Sorry for late reply, I think you already found out the answer -- but still:

Is the last line rendered as a note in the editor, though?

No it's not:

But in this situation, that "not-at-all" line appears as .note() == true.

[ftolsson]

Also probably should share this -- even though surely this will add to your hesitation about multi-line notes... Playing around to create the situation above I managed to get this:

I don't think you'll be able to recreate all of it at will, and perhaps you fixed it with that "badly thought out conditional". But anyways wanted you to see it -- sometimes I find the parser a bit reluctant visavi (what I perceive to be) interpreting changes "upwards", i.e. when making changes to the beginning of a formatted element. Most often it's when separating a dialog from its character name and then backspacing them back together, which takes some persuasion before the editor actually formats them as dialog.

This may be part of that issue, or it's a side effect of the multi-line notes thing. Either way, just thought I'd share.

[ftolsson]

Oh no, was it something I said?

:)

[lmparppei]

I can't reproduce your last example, but there are still some minor issues which mostly affect rendering. I have not commented my multi-line block code either, and it doesn't make things easier.

I think the latest fix eliminated some of these note bleeding issues, but can't be sure. Let's close this when it's confirmed. I'll post a beta on Discord today.

[ftolsson]

Let me share this one too -- interestingly, from what I gather, the editor and .note() disagrees somewhat as to what is a note and what not.

What you're seeing is this:

• It is my fault that all the lines are appended to the first note, I need to make some check that a note line cannot be added to a previous note if there's been a non-note line inbetween
• But interestingly, if you compare the lines served to my plugin with the ones marked red (note) in the editor, you will find that while the editor stops on the first line of that single-bracket no-longer-a-note (incidentally named marker)...
• ...the plugin is told by .note() that that entire none-note is a note -- AND the orphan closing line at the absolute end -- but NOT the action lines in between...

About reproducing it, you're right -- it is quite intermittent. But with this text, I've managed to add and delete beginnings of lines (and merging separating lines between the notes) and have it disappear and reappear a couple of times.

(I also know you're not meant to add multi-lines to markers, so I'm probably pushing the envelope somewhat. But since markers are served as notes, I'm guessing the parser really shouldn't care -- they only become markers when we red the content and interpret them as such right?)

[lmparppei]

Yeah, the problem was that because of my silly coding, some lines had note ranges which began from -1 and ran the length of the whole string. The editor figured out that this range is not valid at all, and ignored that while rendering, but lines themselves only saw that their note range index count covered the length of their string, so .note returned true.

[ftolsson]

Let's not make this a contest about whose coding is the silliest because you have nooothing on me.

Seriously though, that sounds like you figured it all out so sorry for piling up examples!

[ftolsson]

Downloaded 1.927 -- initial parsing works fine, and most of the stuff from above seems to be corrected!

One small thing remaining though -- if I enter this...:

[[a long note
••
line three]]

(with •• being spaces, of course)

...and then:

• put the caret after the two starting brackets,
• hit backspace, deleting one bracket (and making the note not a note anymore)
• then enter [
• then delete on or both of the two ]] that appear automatically...

...for me, that results in line one being rendered as a note, but the following two lines not.

Edited because: All three lines seem to be set to TRUE in .note(), so it's probably a rendering thing only.

[lmparppei]

I'm pretty sure I fixed this now, - (NSIndexSet*)terminateNoteBlockAt:(Line*)line index:(NSInteger)idx didn't automatically add the line on which note was terminated.

[lmparppei]

Fixed in 18864ed196021079bfef71e601a7dffea9ccdcff

Build available here: https://www.dropbox.com/s/h3uyiyglav8t8v4/Beat%201.927b.dmg?dl=1

[ftolsson]

One issue remaining, I'm afraid... To reproduce, enter a couple of multi line notes, like this:

[[Line one
••
Line three]]

Then some action before next note. Repeat a few times.

Then backspace out the two space-dots in any note (but the last).

Result: The note in question turns into action in the editor (expected). It also disappears from .note() and thus my plugin (also expected). But at the same time, so does the next note below, both in the editor and my outline/.note() (quite unexpected).

Let me know if you can't reproduce and I'll make a video.

[lmparppei]

Wow. The notes will reappear on next edit nearby any of the other note ranges. No idea what's causing this.

[lmparppei]

Well, this is now fixed with one caveat: when pressing shift-enter to add a single line break on a note like this:

[[multi-line
note]]

Resulting:

[[multi-line

note]]

This will correctly cancel note from the first two lines, but the last line will still remain rendered as a note. Not sure if the parser still sees it as a note, I'll have to investigate that.

[ftolsson]

Good morning! Tried your example above in the 1.927(beta2) I have, but in that build the last line would correctly revert to a none-note.

However, what I found instead was that any scene heading below will turn into lowercase when the note is rendered into action. Animated gif below.

(It is just a rendering issue as you can see; walking into it with the caret will put it back into uppercase). Also, extremely minor but perhaps related, there is a slight rendering delay for the very last couple of lines, causing them (and only them) to disappear and/or double for a split second.

[lmparppei]

I think I have fixed the parsing issues this morning, and it might affect the visual glitches too.

Two things I now regret the most: multi-line blocks and Hide Fountain markup.

[ftolsson]

No regrets!

(Okay so I may have been part of encouraging you about at least one of them, but they are both super super useful so...)

[lmparppei]

I guess this one has been fixed at some point.