Editor slows down & Interesting editing

[ghost]

Right now, a note has only 210 lines of text, but there is a slow down in the editor, i.e., my inputs are showing up with a delay (and sometimes a long delay).

As for the "interesting editing" half of the title, I would like to give an example. In the following piece of text, when I want to write something after the last dot, I basically cannot. The editor neither lets me click there, nor lets me go there with my arrow keys.

**Premodifier** is a word that comes before the word which it modifies, e.g., *invited* in *an invited audience*.

[toolstack]

I can't reproduce a slowdown, but I can reproduce the second issue.

The second issue may be outside of my control, however a workaround is to go to the start of the next line and then go left once more, which takes you to after the period.

[toolstack]

Also hitting the end button takes you to after the period apparently.

[ghost]

I can't reproduce a slowdown, but I can reproduce the second issue.

Is it possible that it is because I have installed the application using Flatpak (which is the default way to do so anyways), and Flatpak is limiting how much of the memory it can use in the sandbox? I have no idea honestly. It does not happen in other editors (from Apostrophe to GNU Emacs) with the same file but in Folio.

The second issue may be outside of my control, however a workaround is to go to the start of the next line and then go left once more, which takes you to after the period.

Yes, that is what I do.

Also hitting the end button takes you to after the period apparently.

It does.

[toolstack]

I use the flatpak and can't reproduce the issue so it seems unlikely. As far as I know the sandbox doesn't restrict memory or cpu usage.

[ghost]

I actually realized something that might be related to this. Whenever I run Flatpak (e.g., flatpak update) it gives me the following output:

Looking for updates…

(flatpak update:5000): dconf-WARNING **: 11:26:47.715: unable to open file '/etc/dconf/db/local': Failed to open file “/etc/dconf/db/local”: open() failed: No such file or directory; expect degraded performance

Nothing to do.

And when I made that file with the touch command (which I did not think that it would solve the issue and it did not), the same Flatpak example gave me the following output:

Looking for updates…

(flatpak update:6000): dconf-WARNING **: 11:31:36.380: unable to open file '/etc/dconf/db/local': /etc/dconf/db/local: invalid gvdb header; expect degraded performance

Nothing to do.

I really do not know much GTK programming, do you know a way to fix this?

---

An update; I did dconf update after surfing about the issue online. Although it removed the warning message from the flatpak update output (which now looks like the following output), it still did not fix the lag of Folio. I still have no clue why.

Looking for updates…

Nothing to do.

[machitgarha]

I also experience noticeable (and sometimes drastic) input lag when working with a large file.

IDK exactly how Folio works, but this might be because Folio renders the whole document instead of just the viewable section.

[toolstack]

Yeah, I don't particularly like the rerender on every keypress design from Paper, but it would be a major rewrite to change that, and just the way markdown works it would be a nightmare to try and do partial updates.

I'm not convinced (though I could be wrong) that the rerender of the doc would be the issue though on this, unless the system was severely resource constrained already. I've created some large markdown docs and tested without issue so I haven't been able to reproduce this yet.

[machitgarha]

@toolstack, maybe your system is powerful?

I just profiled the app, and it seems a huge amount of the application time is spent on GtkMarkdown.View::restyle_text_{format,cursor}() functions. Here is the flame graph.

And yes, while the formatting is highly inefficient, it would require a major rewrite of the module for a significant speedup. Or we can try an external markdown engine.

[toolstack]

Yep, and looking at the graph a good bit of that time in those functions is actually on the strlen functions 🤷

50 is my placeholder for rewriting the markdown parser, but I haven't really started to think too much about it yet. If we could find a parser that returned a list of locations in the textfile that need markup that would be ideal, but I suspect most markdown parsers will instead just return an HTML formatted result, which does us no good.

[machitgarha]

Before we get into a rewrite, there can be temporary fixes.

One is to do restyles only when the inserted or deleted text contains one of the characters that is important in markdown formatting, such as *, _, #, parentheses, etc; or when the inserted text is inside a tag. By this, we eliminate most of the restyling process, and writing non-styled text will become more responsive. However, it might have its own difficulties and edge cases.

[toolstack]

Closing as #162 is merged.