Joplin: Add option to disable auto-save and auto-sync

[alexdevero]

Joplin saves and syncs the notes every time there is some change, for example editing the note. This is not necessary. It could also cause issues. Please, add an option to disable this functionality. Also, an option to set the delay before edits are saved and synced could be added as well.

P.S.: I tried to add this option by myself. However, I couldn't find where the main trigger for saving and syncing is. I've been looking at Note.jsx. If you can tell me @laurent22 where should I look, I could solve this.

Operating system

• [X] Windows
• [ ] macOS
• [ ] Linux
• [ ] Android
• [X] iOS

Application

• [X] Desktop
• [X] Mobile
• [ ] Terminal

[laurent22]

One mobile, saving is actually already manual. On desktop, this could indeed be optional. You'd need to add the option and modify the scheduleSave() logic in NoteText.jsx.

For the sync interval, I'd rather leave it short like now so that devices are always in sync, which avoids conflicts. The sync operation after save is actually a light one (only the last changes are uploaded) so normally it should cause any issue.

[tessus]

What is the status on this?

All duplicates are closed, yet the app is still auto-saving and syncing when a note is changed.

[luriomer]

Hi. For me (on desktop) it causes problems since sync interval is so fast it sometimes deletes characters not matching the last sync (the read\write simply cannot follow the changes fast enough). I think 5 mins interval is enough to keep track of latest changes. How can I set it and disable the autosync every second?

[alwashe]

Had the same trouble, while typing the title of a note, there is a small lag, and Joplin did not recognize the key stroke.

[luriomer]

For me in the latest version it became rather annoying and frequent. Does anyone know what actually controls the sync interval?

[luriomer]

Please make this thread a bug report since this actually disturbs using the program.
Thanks

[laurent22]

For information there are two types of sync:

• Regular sync, which you can configure in the Option screen. It sends all the latest changes, delete notes as needed and download the latest changes.

• Sync after save. It's a light sync operation that only sends the latest changes and it cannot be configured at the moment.

Actually rather than making it configurable I'd prefer using heuristics to determine when to save and to sync after save. I think 5 min for instance would be too long a delay, in particular if you change a note, then close your laptop a minute later. Then when you open it in your mobile, you won't have the latest version and that will create conflicts that are not easy to make sense of.

Another issue at the moment is that there's a bug in the sync after save. It's doing it twice instead of one, so that will indeed need to be fixed.

And the third issue is that it's sometimes dropping key strokes.

[Peppernrino]

My two cents, maybe set the default Synchronisation interval as Disabled out of the box. It could save a lot of headaches for new users like me. Just had a few notebooks delete themselves, a la issue #255 lol. Anybody setting up sync has to go into the Tools>General Options tab anyway. :D

[LL2]

auto-save every word you write could be harmful for your hard disk. Please, add an option to disable it.

[Peppernrino]

Upon looking through the ~\Roaming\Joplin folder, I see there are some GPUCache files... Perhaps the disk writing only takes place at scheduled intervals, or after the program is closed. That's what I would surmise from this anyhow. :thinking:

[NothingCtrl]

When edit a lager file, every change make app lagging event I change layout to code mode...

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "backlog" and I will leave it open. Thank you for your contributions.

[luriomer]

I don't remember having this issue lately, but I'm not really sure. Maybe leave it open as you suggest, and I'll recomment if it happens again. Thanks!

[laurent22]

Yes that's fine, let's keep it open, as I'd like to add this some day.

[Babber]

Please, add this option! On Linux Mint, syncing is so ridiculously slow, that basically it is syncing all the time. Before I found this open issue, I was about to post a bug report for having my sync interval set to 24h and yet it is syncing non-stop, which is a very contra-intuitive feature to say the least! Please, fix this so that it observes the sync interval even if editing happens in the meantime. (And bwt, why does it take so much longer to sync on Linux than on Android?)

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[luriomer]

For me it still happens:

sync interval is so fast it sometimes deletes characters not matching the last sync (the read\write simply cannot follow the changes fast enough)

[lord-aerion]

The auto-save feature has become a major issue for me.

It's far too easy to make mistakes on touch screen devices, and I've already lost several notes as a result. In some cases I've been able to 'restore' a note by quickly disabling sync and switching on my desktop to retrieve the note there, but this has not always been the case.

At the very least there should be an undo function, but I'd much rather have the option to turn auto-save off. It used to work just fine when the save was manual, never had sync issues.

I'd argue that losing note contents is a bigger problem than sync issues, for example for users who use Joplin solely on their mobile phone.

It's such a big problem for me that I'm contemplating looking for another note app, which I'd really rather not do as it took me ages to look for an alternative to Catch Notes (still miss that app), and subsequently to Evernote. I was so pleased when I found Joplin!

This is not meant as some pointless threat like "I'll leave if you don't fix this!!", but to highlight that this is a genuine usability issue. A note taking app where I risk losing content every time I use it is simply not suitable for the task.

As an example, I often watch YouTube videos where someone recommends specific video games, for example an overview of the best games for a given console. While watching the video I add games I'm interested in to a specific wish list notebook in Joplin. To make it easier to read back this list later I sort them alphabetically, which means a lot of copy and paste work. If you accidentally hit the wrong part of the screen while trying to highlight the text you can very easily delete your selection by mistake, and it's goodbye to the list that I've been curating over many months.

It should not be _this_ trivial to lose one's work.

[xuhcc]

The option to disable auto-save is essential and it's really easy to add it. I even tried to submit a PR (#1781) but it was rejected, and since then I'm maintaining a Joplin fork: https://github.com/xuhcc/joplin/ (but you will need to build it from source if you want to use it @lord-aerion).

[tessus]

Yes, the mobile version is IMO unusable for editing notes. It's sad, because it's technically a few lines to just turn off that autlo-save feature.
Even the history feature isn't able to save your data every single time.

I use the mobile version only to read notes and create new notes. I'm too afraid to lose data.

I hope the people who complained they had to click the save button are happy now.

[b3taman]

Applicable config on Linux Desktop

• Synchronisation interval: Disabled
• Attachment download behaviour: Manual

Expected vs. actual behaviour
Expected: Given the above, no synchronisation unless I push that button.
Actual: It synchronises automatically 30 seconds after my last change.

Impact: Show-stopper
This is a huge issue for me: until I get my set-up safe for access from the Internet, I only want to sync to my personal Nextcloud instance when at home, never at work. I have invested a few weeks getting everything across from Simplenote into Joplin and last night felt I could start syncing across devices. Now I have no idea what to do: I can't block the IP as I need access to my server for other things, but I can't not use Joplin because I simply don't have the time to revert to Simplenote (which I _really_ don't want to do).

In a previous job this behaviour could have gotten me fired (trying to go outside the corporate network at a client site), so this is a real issue for people in such environments.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[xuhcc]

Not fixed.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[lord-aerion]

Still not implemented.

[lord-aerion]

Things have improved somewhat with the addition of both an undo and redo button (thank you @laurent22 ). Unfortunately auto save is still a thing, it's just mutated into save on exit. This is fine for most situations, but for more extensive edits this can be a problem if you decide you want to scrap your changes. The auto save on exit means multiple undo actions need to be performed to get the note back to its starting state.

I'm specifically talking about the Android client here as I hardly use the desktop client and don't know if the same issues exists there.

Can we please have a setting to enable/disable auto save? I can appreciate there are people who really like the auto save feature, so it shouldn't be a one-size-fits-all solution.

[lord-aerion]

The option to disable auto-save is essential and it's really easy to add it. I even tried to submit a PR (#1781) but it was rejected, and since then I'm maintaining a Joplin fork: https://github.com/xuhcc/joplin/ (but you will need to build it from source if you want to use it @lord-aerion).

Hey @xuhcc, thanks for the reply, only just seen it today. I pretty much stopped using Joplin because of this issue and was evaluating replacing it with Markor + Syncthing.

I assume your fork is for the desktop client only? I primarily uses notes on my Android devices, where the auto save issue is felt even more. It's slightly mitigated by the recent introduction of undo and redo buttons, but ultimately auto save (now save on exit) still poses a problem.

[xuhcc]

@lord-aerion Yes, currently the manual save feature only works on desktop. It previously worked on Android too, but there were a lot of changes in Joplin code in recent releases and the feature has been broken. Maybe I'll try to re-implement it but not sure when I'll have time for that.

Also looking for alternative :)

[lord-aerion]

It's a real shame. From being very excited about finding this impressive Evernote clone I've become really disappointed. The introduction of auto save killed it for me.

I was excited to see that undo/redo buttons have been introduced, as well as the much desired Solarized Light and Dark themes on both the desktop and Android clients, but auto save plus severe UI issues on landscape Android devices are still a showstopper for me.

I've now decided to replace Joplin with Markor + Syncthing (which works great for Joplin syncing too). Tests I've done work great, and on the desktop I can use any editor I want instead of a _gargantuan_ Electron client. A whopping 485 MiB for a note-taking app, really?! LibreOffice, a full-blown office suite, only takes up 406 MiB.

I'll keep the Joplin Android client installed so I can keep an eye on any developments. Thanks to the markdown format notes created with Markor can easily be moved back to Joplin when the time is right.

[stale[bot]]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[xuhcc]

.

[laurent22]

As often adding two issues into one means we can never close the issue or sort it out. In this case, there won't be an option to disable auto-save, while there might be one for disabling auto-sync. So I'm closing the issue and feel free to re-open one for auto-sync.

[lord-aerion]

It's really disappointing to see that auto save, which causes genuine usability issues, will not get implemented. I never lost note contents when I could save manually, but after the introduction of the auto save 'feature' I repeatedly ended up with unwanted changes, whether accidental or because I changed my mind, with no way to get out.

The recent addition of an undo/redo function mitigates the problem somewhat, but as I've pointed out elsewhere, when you make a lot of changes, and change your mind, having to perform a series of undo actions is simply not practical. I should be able to back out of the note, without saving my changes.

As much as I want to love this project, and I really do (I even donated money to the project), I'm afraid this spells the end of my Joplin journey.

It's also very disappointing to see that comments that mention alternatives that do _not_ suffer from the risk of losing one's edits get deleted. There would not have been a need to recommend or even look for alternatives, had the issue of auto save been recognized as genuine and valid.

[laurent22]

This issue was opened when undo was lacking on mobile, so it's not relevant anymore, and auto-sync, which is a different issue. A new issue needs to be opened with up-to-date information.

But also, the scenario you describe is not very realistic. So you want to edit your note, make many changes and not save, but for how long? 10 minutes, 30 minutes? more? a day? How much editing do you have to do that it becomes cumbersome to undo? You also have the revision system and possibly your own backup to restore previous versions. If you are so unsure about the changes you make to a note, you can even duplicate it first.

There's so many way to handle this, so it doesn't make much sense to me. Just make changes to your notes and undo/delete/restore previous versions if you need to.

Another issue is that if auto-save is disabled and the app crashes, first feature request will be "Can the app keep a copy of my last edits in case the app crashes?". And we're back to auto-save except in a more complicated way.

[lord-aerion]

I'm glad you've opened the conversation again, instead of stifling the debate.

I suggest you read the comments again. I'm not the only one complaining about the mobile app being unusable as a result of auto save. @xuhcc even went as far as forking Joplin back in April, after having his pull request rejected, in order to be able to build a version without auto save. He called it essential.

You've clearly missed the parts where I mention that I've _lost_ notes, in full or partially. Or the part where I mention that I _never_ had issue _until_ auto save got introduced. The introduction of undo has not made this issue any less relevant.

The scenario may be unrealistic to you, but I assure you it is not to me. Manual saving has been with us for as long as we've had computers. I deal with it every day, working in GIMP or Inkscape or LibreOffice. None of them use auto save, none of them have caused me data loss. In fact, just the like couple weeks I've been very grateful for Inkscape's Revert option, on multiple occasions, as I had been experimenting so much with a logo I was working on that reverting to the version saved on disk was infinitely quicker and easier than working back through my undo history.

It's very easy to rack up a number of undos. Just doing a brain dump, then reformat it, change your wording, move words around, is enough to create a lengthy undo history. Just 10 minutes is enough.

Perform multiple undos to get back to the original state when the changes are unwanted, or having to rely on a revision history is much more cumbersome then simply being able to just abandon one's changes.

Yes, of course, manual save also carries the risk of data loss, but that's a risk _I_ choose to take. Personally, I am perfectly capable of hitting save periodically. Other people might forget, so for them auto save might be a completely desirable option. I've therefore not argued for disabling auto save altogether, but to be given an option to do so. This would allow each user to work the way that fits them best.

The fact is that I _rarely_ loose data due to crashes, in any app, yet I have repeatedly lost data in Joplin due to a forced auto save.

An app where it's _that_ trivial to lose data is not fit for purpose, imho, no matter how great the app is overall.

[laurent22]

Joplin in general optimises for the common use case and provides alternatives for the non-common use cases. The common use case is that you write a note and you want that to be saved, thus auto-save. Another common use case is that you make changes to a note, switch to a different app, then back to Joplin. Meanwhile the system might have terminated the Joplin app to free up resources, so you'd lose your changes. Again auto-save is there to prevent that.

The less common use case is that you modified a note, but changed your mind and don't want to save any of your changes - for this, there's undo and the revision system. For even more specific use cases, like you want to make a quick draft, you can duplicate notes before making changes.

So that's why disabling auto-save is not on the table because there are several ways to achieve very similar goals as it is, or by changing your own usage patterns.

But also it's not entirely clear to me how you can lose data now that the undo feature is available. If you frequently write for a long time, then find that you want to go back to an earlier version, then why not duplicate the note first? Or why not change your usage pattern and, for example, use smaller notes, grouped under a notebook? If it's really just about auto-save, then indeed the best is to fork the app as will allow you to tweak the app any way you want (and indeed I'd suggest you'd look into it as it doesn't take long to learn how to build the app, and then disable the parts you don't like).

[xuhcc]

why not duplicate the note first
why not change your usage pattern

Why not disable auto-save? For some reason you think that one usage pattern is better than the other, but it's not true. People have different preferences. In case of manual/auto saving, the app could easily support both usage patterns, that's what this issue is about -- giving users an option.

[laurent22]

the app could easily support both usage patterns

And you could easily fork the app and tweak it whichever way you want. I get this suggestion "why don't you just add an option" once or twice a month, that's potentially 20-30 new options per year. How many developers to maintain all this extra complexity?

Which is why my answer to "it's easy to add an option" is now "it's easy to fork the app". And it is! Just take a few hours of your day, learn how to build the app, and you're done. Much easier and faster than discussing this on GitHub.

That being said, my questions aren't rhetorical, I'd be interested to see if there's a way to make that particular use case possible, and in a way that's manageable for me (in terms of development).

[Perkolator]

revision system

Which can't be trusted that much to keep all the changes made to the note. See: https://github.com/laurent22/joplin/issues/2197

E.g. "Subsequent modifications within the "revision worker" idle period (15min?) are lost."

[xuhcc]

Which is why my answer to "it's easy to add an option" is now "it's easy to fork the app". And it is! Just take a few hours of your day, learn how to build the app, and you're done. Much easier and faster than discussing this on GitHub.

I already maintain a fork of Joplin :) And I could say that discussing it on Github still makes sense because the difference between codebases is small but maintaining a fork requires significant effort.

[lord-aerion]

Joplin in general optimises for the common use case and provides alternatives for the non-common use cases. The common use case is that you write a note and you want that to be saved, thus auto-save. Another common use case is that you make changes to a note, switch to a different app, then back to Joplin. Meanwhile the system might have terminated the Joplin app to free up resources, so you'd lose your changes. Again auto-save is there to prevent that.

Sometimes a one-size-fits-all approach is not appropriate. I have repeatedly indicated that auto save does _not_ work for me. What you describe may well be a valid use case for _other_ people. The way I use notes means I do not swap back and forth between Joplin and other apps. I don't need the 'protection' of auto save. I'm perfectly capable of hitting Save periodically, when I feel the need to save my changes.

You're making the mistake of thinking that you know what your users want. You've got a number of people here telling you that what _they_ want is not what _you_ think is the common use case. Just because the most likely outcome of starting a note is that you want to save it doesn't mean that the saving therefore must be done for them. _Making_ an assumption is one thing, _forcing_ that assumption upon people is another. The clue is is the word force, no one likes being forced to do anything.

Your (assumed) use case isn't wrong. Mine isn't wrong either. We clearly need _choice_.

The less common use case is that you modified a note, but changed your mind and don't want to save any of your changes - for this, there's undo and the revision system.

This is a bad UX:

1. Backing out of a note without saving changes is just 1 action, maybe 2 if you prompt the user to confirm he wants to abandon all changes (this would also be a good option to have, instead of auto save). This is a logical and natural workflow.
2. Performing a series of undo actions before you can safely back out of a note without storing the changes is neither a logical nor a natural workflow, and depending on the number of edits made this could lead to having to perform many actions to get back to the original state.
3. While it's great to have a revision system, it's not logical or natural to make changes, decide against them (why is irrelevant, could be accidents, could be change of mind), have those changes saved anyway, then have to rely on the cumbersome revision process which restores the old revision to a separate notebook, so you then have to delete the note with the unwanted changes, and move the restored note to its original location. Oh, and you can only do this in the desktop version; not great when you're working on a mobile device away from home.
4. I should not have to rely on traditional backups just to get rid of unwanted or unintentional changes. Again not a logical or natural workflow.

It's not about the amount of time it takes, that's just seconds, it's about the poor user experience of having to perform more actions than strictly necessary for a given task, something that must be avoided at all cost as it leads to frustration and a disrupted workflow.

I just performed a test. I edited a note and added the following lines:

Some changes.

I don't want them.

It took 9 (!!) undo taps to get rid of these two lines of text and two blank lines, versus just 1 if I could have backed out of the note without it getting saved.

Furthermore, while performing this test I accidentally hit the back button instead of the undo button, causing my unwanted changes to get saved. So now I have to either 1) edit the note again and manually get rid of the remaining unwanted changes, 2) restore my note from a backup, or 3) restore an older revision (which I may not even have, depending on the age of the note).

For even more specific use cases, like you want to make a quick draft, you can duplicate notes before making changes.

Again a lot more cumbersome than just being able to cancel changes by backing out without saving.

So that's why disabling auto-save is not on the table because there are several ways to achieve very similar goals as it is, or by changing your own usage patterns.

Similar, but not the same, and none of them as easy as just being able to _cancel_ your changes. Starting to see a pattern here?

Also, why should I have to change the way I've worked for the past 40 odd years? The way Joplin worked when I started using it was fine, now it's _not_.

To suggest that people change the habits to work around what they have identified as a shortcoming, and are reporting you, the developer, is not acceptable. It indicates a complete lack of understanding of the user's needs.

But also it's not entirely clear to me how you can lose data now that the undo feature is available.

Simple, as described above: accidentally hitting the back button while trying to perform an undo action. Combine that with a lack of revision history and presto: lost data.

If you frequently write for a long time, then find that you want to go back to an earlier version, then why not duplicate the note first? Or why not change your usage pattern and, for example, use smaller notes, grouped under a notebook?

Again, why do _I_ have to change the way I work, when that way has been fine for me until forced auto save got introduced?

If it's really just about auto-save, then indeed the best is to fork the app as will allow you to tweak the app any way you want (and indeed I'd suggest you'd look into it as it doesn't take long to learn how to build the app, and then disable the parts you don't like).

This is one of the most frustrating and dismissive responses a developer can give to feedback. Not everyone is a developer. And those who are may not have the time to create a fork. Again it shows a complete lack of understanding of the user's needs.

EDIT: In case this got missed along the way: I almost exclusively use Joplin on my two mobile devices, one of which has a full keyboard, making the need for the desktop app practically _zero_. Having to rely on a desktop app, just to work around automatically saved but unwanted changes is an awful alternative to just being able to cancel one's changes. Never mind those who don't own a traditional computer and exclusively work on tablets or mobile phones.

[lord-aerion]

And you could easily fork the app and tweak it whichever way you want.

Will you teach me how to code?

I get this suggestion "why don't you just add an option" once or twice a month, that's potentially 20-30 new options per year. How many developers to maintain all this extra complexity?

That in and off itself is a totally fair point. I can well imagine that many of such suggestions are not feasible, don't bring much benefit, are ill-conceived, or generate a disproportionate amount of work for a niche use case.

To use this argument, however, for not implementing a change to a newly introduced feature that several users are telling you is causing them problems, that they don't want, and that it worked better before this introduction, shows a lack of understanding. Either that, or a complete unwillingness to take on negative feedback.

Which is why my answer to "it's easy to add an option" is now "it's easy to fork the app". And it is! Just take a few hours of your day, learn how to build the app, and you're done.

I'm sorry, but this is just arrogant. It is easy for _you_ a trained and experienced developer. It will take me _years_ to get to the point where I could take on a project like Joplin. Don't assume that everyone with a GitHub account is by definition also a dev. I'm an admin, not a dev. I have an account on GitHub to be able to report issues on open source projects, and, where possible, contribute in a non-coding fashion.

Much easier and faster than discussing this on GitHub.

If you don't like discussing feedback about your app, then why list it as an open source project on GitHub?

That being said, my questions aren't rhetorical, I'd be interested to see if there's a way to make that particular use case possible, and in a way that's manageable for me (in terms of development).

@xuhcc submitted a PR that got rejected (#1781). Maybe that's a good starting point?

[laurent22]

It might be worth taking this discussion to the forum. You know my point of view, I know yours, so I don't have much to add, but other users might.