Zettlr: Marker constantly jumps to beginning of note

[Nissentott]

Description

Since 1.7 Beta the marker jumps back up to the very first line of the note after some seconds of writing, thus it's impossible to write anything without constantly clicking back to where I were. This behaviour started with the 1.7 Beta and sadly makes writing impossible.

Reproducing

Expected behaviour

The marker staying at place so one doesn't constantly have to click back to where one were editing.

Screenshots

Platform

• OS and version: Win 10
• Zettlr Version: 1.7 Beta 2 (same with earlier 1.7 Betas)
• Screen Resolution:

Additional information

Love the implementations so far, fantastic app, but needs to downgrade to 1.6 until this is fixed cause I can't produce anything without constantly clicking back to where I were now after some seconds. Might be something with the new tabs?

[nathanlesage]

Yes, I noticed this myself. However, I am oblivious as to what is causing this behaviour. However, it is one of my highest priorities as I need to use the app professionally myself, so I will make sure it makes its way into the codebase this very week.

[nathanlesage]

I think that this is related to #746

[TheAlmightyDada]

This is happening to me also.

Does it have something to do with autosaving to a cloud directory?

I have my Zettlr directory in my OneDrive and was getting "file has been modified remotely" notifications whenever Zettlr autosaved.

After I clicked the checkbox on that error, the notifications have stopped but whenever Zettlr autosaves the cursor jumps to the top of the editor.

Current workaround is Ctrl + End to get me to the end of the document.

EDIT: Also, if it helps. When working in a file the file ID (normally shown in a little grey box on the tree panel) isn't shown. At the point the file autosaves, when the * disappears from the file name, the ID appears in the grey box for less than a second before the cursor jumps back to the top - when the cursor does jump to the top, the ID disappears again.

EDIT 2: I have no idea what I'm talking about but is it possible it has something to do with this, as it does seem as though the file is reloading on autosave?

88 "always_reload_files": "Always load remote changes to the current file",

(source/common/lang/en-US.json)

[nathanlesage]

I have no idea what I'm talking about but is it possible it has something to do with this, as it does seem as though the file is reloading on autosave?

Yeah, something like this is happening I think.

… wait a moment. I think the cloud service thingy might be the right pointer. I just remembered that I have added that one check in the previous implementation if the file has _really_ changed. I did not implement it in the new FSAL, because I didn't think of it (just remembered it now).

@Nissentott @TheAlmightyDada Would you both maybe try to work for a day on a note that is _not_ being cloud-saved? Just to test this theory? Because if working normally on a file that is not cloud-saved doesn't exhibit this bug this might be the … oh WAIT A MOMENT. *checks notes* Oh yes.

I think I may have found something that points to the right direction:

Previously, Zettlr would check the mTime-property of a file to check if it was really changed. If it wasn't, it wouldn't do anything. However, now it internally uses cTime as this captures more changes to the file, but, as you can see in the screenshot, also includes reads — and whenever a cloud service reads a file, this is considered a change. Now, chokidar (the library that watches the file system) uses mTime, so it should not trigger. However, if it does, currently Zettlr is simply unable to check if the file has really been modified.

Long story, short: I would greatly appreciate it of you two to help me fix one last thing:

1. Try to normally work with a file that is *not* being monitored by a cloud synchronisation tool such as Nextcloud, Dropbox, OneDrive or the likes. Does this work as intended?
2. Also, try to keep the logs open (at least, if they work, because @Zverik reported there's some issues with that as well) and try to look out for such "file-replace" events (or replace-file) occurring AFTER the file has already been saved. What should happen is: The file is being saved (a save command is issued). Then, a "file replace" event is emitted to the renderer ("IPC OUT") which holds the new data (that is: the new modification date and such). There should not be a second file-replace event.

If we can clarify this, I think we finally pinpointed that pesky bug and I can implement a fix!

[TheAlmightyDada]

@nathanlesage - Hi, I'm really sorry but I'm not sure how to view the log - I'm having a quick look through the documentation but I will be off to bed soon.

As for the rest of it. I created a new directory just in my D drive, which is not connected to the cloud and made a test file in there. The results were:

• No cursor jumping to the top.
• Saving works fine.
• ID (in grey box on tree) visible throughout, no flickering or disappearing.

So it seems like you are on the money! I try and look at/upload the log if I can.

[nathanlesage]

I will be off to bed soon.

Yeah, I mean there's no data loss so it's not _that_ urgent. It's just a big nuisance, take your time!

You can have a look at the log by activating debug mode (which basically only activates a previously hidden "Develop" menu item) -> there you can find the log viewer. But as I said, take your time, I'll be going to bed myself, so let's tackle this freshly tomorrow!

But I really like the outcome of your quick test, it looks promising! :)

[TheAlmightyDada]

@nathanlesage

I didn't expect you to get back so quickly. Thanks for the details - I've had a look through the log. Including the point of the first save it looks like this;

[22:17:59]  >>> IPC IN: file-save
[22:17:59]  Trying to run command through Application: file-save
[22:17:59]  <<< IPC OUT: tags-database
[22:17:59]  <<< IPC OUT: tags-database
[22:17:59]  <<< IPC OUT: mark-clean
[22:17:59]  <<< IPC OUT: file-replace
[22:18:04]  >>> IPC IN: file-modified
[22:18:04]  Trying to run command through Application: file-modified
[22:18:04]  No command registered with the application for command file-modified
[22:18:04]  >>> IPC IN: file-modified

Those last 3 lines then repeat over until the next save at 22:18:53:

[22:18:47]  Trying to run command through Application: file-modified
[22:18:47]  No command registered with the application for command file-modified
[22:18:48]  >>> IPC IN: file-modified
[22:18:48]  Trying to run command through Application: file-modified
[22:18:48]  No command registered with the application for command file-modified
[22:18:53]  >>> IPC IN: file-save

I hope this helps - I'm happy to do anything else if you need me to. :)

Thanks for your hard work - This software is exactly what I have been looking for!

[nathanlesage]

Those last 3 lines then repeat over until the next save at 22:18:53:

Damn, there's an error in file-modified! There we go, thank you so much! :)

[nathanlesage]

False alarm, I misread my own logs, this just tells that there's no command for that, this is not an indication for an error …

[nathanlesage]

Alright, have to work now, but quick update: I tested a whole lot of stuff, and the jumping around started once I began adding images. Maybe this, and maybe more additional elements such as headings etc. seem to trigger that behaviour (maybe as well instead of only?) — so if any of you has the ability to check that later the day, just fyi!

[TheAlmightyDada]

No images, but I do have headers. This is one example...

[nathanlesage]

so maybe the headers are the problem … mh. Please continue testing so that we can pinpoint this issue. I'll be doing the same here and testing out the different plugins as well.

N.B.: You can also pinpoint if it's a plugin by turning off selectively the "Display" preferences ("Render x", "Render y" etc) — as soon as one plugin causes this, we know what's going on

[TheAlmightyDada]

I made some notes with no headers. The cursor is still jumping to the top.

I made some notes with nothing but text (i.e. without the ID at the top of the file - the file was getting the ID from it's name) and the cursor still jumped to the top.

[Zverik]

Seems like it's related to #746: when I click "yes" and just continue to type, the cursor jumps to the beginning of the note. I believe @TheAlmightyDada has auto-reloading turned on.

[nathanlesage]

@Zverik That was my initial assumption, but I couldn't verify it this morning with a cloud-synchronised note – so either I was just pretty lucky, or we have missed the real cause yet again :/ This bug proves really difficult …

[nathanlesage]

So, I just added a small check that will NOT in fact update the file if the mtimeMs-property of the file descriptor and the file's real value are the same. Instead, it will log the following as info (blue colored):

The file

I'll include this in the next beta. If you spot a jumping to the beginning, check the logs if they include this log entry. And if it doesn't, also check, just to be sure chokidar is (or is not) the culprit here!

[TheAlmightyDada]

Hey @nathanlesage - so just for clarity, to help, I should download the next beta and after an autosave on a cloud-synced note occurs, I should check the logs for;

The file has not changed, but a change event was fired by chokidar.

Then report back?

Thanks

[nathanlesage]

Basically that, yes! I hope for the following:

1. No more jumping to the top
2. Have above mentioned log entry

What might also happen:

1. Still jumping to the top but with the log entry
2. No jumping to the top without the log entry (albeit logically very improbable)

In any case, try to see if you can spot any patterns WHEN this strange jumping occurs, and how these (potential) log entries relate to this, because this helps me pinpoint where the issue originates!

[nathanlesage]

Just got a VERY verbose description of the bug over on the forum, please try this out so that we can further pinpoint it:

---

Description :
When i'm writing my cursor just jumps back, for no reason, to the begin of the document. Example, let's say i'm going to type the sentence "my cat is hungry" in a document where the first line is "#thisismytitle". Now, i am in the middle of the document typing "my cat i"... I keep typing. I realize that what i'm typing is not showing in my screen anymore. I stop typing. Nothing happens for 1 sec maybe. Then i'm in the beginning of my doc. I see "hungr#thisismytitle".

Frequency :
This didn't happen to me with 1.6. It started happening with 1.7.1. It doesn't happen in other apps (tried typora and atom). It happens in any note : notes with 10 lines of content or full articles. Also in new notes : created with the 1.7 version and old ones. In the root file, in subfiles... One note open, many tabs open... The jumping back also happens when i'm not actively typing. It happens very frequently, at least 1 time every 25 minutes [1 time/pomodoro session]

[nathanlesage]

Short update: I think I FINALLY found the error!

I was always wondering why the error always happened with documents where there was something rendered. Now I know: Until now I could rely that a marker that could not be found in the editor really was gone. But the markers are persisted as long as the document is open, which means currently it's messed up due to multiple documents being open …

But alas, we're (probably) finally there!

[enricllagostera]

Cool! I was just about to report that I'm having issues with the cursor jumping around different parts of the document whenever a citation is rendered. Sounds like it might be fixed by these same changes, so I'll check in next versions to see if it is gone. If not I'll submit an issue.

[nathanlesage]

Going to test it throughout the day, and I'll be releasing a new beta this afternoon, and hopefully the horror is gone then!