Irrelevant to the question of whether it is sensible to allow a flat text editor to be editing a file concurrently with an outline editor ?
You think so ?
Irrelevant to the mechanics of reading/writing files from the file system.
But not irrelevant to the user’s work and data.
Right – which is why I said that it’s acceptable for TaskPaper to pop an alert, “The underlying file changed. Do you want to stick with what is currently displayed or to update from the file?” (or whatever.)
But I don’t think locking up the app is a good choice. It’s a choice, sure, but not a good one.
We’re getting off track though – as a user, I certainly have my preferences about how TaskPaper responds when the file is modified (I think it should incorporate the changes made, just like most other apps in the modern document syncing/collaborative/iCloud/Dropbox era), but that is entirely up to Jesse/other devs. That is not what I am writing about.
My concern/bug report is that when the file is changed, TaskPaper (seemingly) causes both apps to lock up. I’m assuming you’re not suggesting that beachballing the app is the desired TaskPaper behavior under these circumstances. And if you agree with that, then the more productive line of reasoning here is to figure out what is going wrong and how to fix it.
I have tested my app as far as I can in this – this issue does not occur when I substitute TextEdit for TaskPaper, so it’s not simply a NSFileCoordinator issue, and doesn’t seem to be a mistake on my part. The reason I am writing is that further diagnosis will require some knowledge of TaskPaper’s code base and possibly running it in a debugging environment which means help from its dev(s).
I notice, FWIW, that Sublime doesn’t seem to struggle with opening an outline that is being edited in TaskPaper.
Sublime does, of course:
- display the outline as a flat unfolded file,
- and destroys the outline folding in the user’s TaskPaper session (on any save).
Users may vary in their enthusiasm for the proposition that TaskPaper should be rewritten so that their outline folding data can be more conveniently destroyed, mid-session, from another flat text editor …
I didn’t say that nvUltra had trouble when a file was being edited in TaskPaper, I said that TaskPaper had trouble when the file was edited in nvUltra. To the best of my knowledge, nvUltra properly handles coordinated file reading, so it is able to manage updating the document window when the file changes. I have not experienced any issues in this direction. The problems occur when nvUltra saves a file, and TP causes a deadlock when reading the changed file.
In addition, Sublime Text is a cross-platform app – I would suspect it does not use standard macOS NSFileCoordinators to handle file reading, so these deadlocks would not occur. But I do not know this for a fact. Possible additional evidence for this is the fact that ST does not update documents whose underlying files change while it is in the background – it only updates the document once the app is brought to the foreground. I believe the NSDocument object does not check foreground status when handling file changes (TextEdit does not, and MultiMarkdown Composer does not, which I built on an NSDocument model, which includes NSFileCoordinator functionality for read/write), but I suppose it would be possible to add this behavior if one desired.
Again – not relevant to the discussion at hand which is about deadlocking, not how TaskPaper chooses to handle whether to merge changes to the file or reject them. I am not asking that TaskPaper be “rewritten”, but rather that a bug be fixed – TP should not lock up when the underlying file changes, regardless of whether the choice is made that it accepts the changes or rejects them.
Same pattern with TextEdit, BBEdit, and Textastic:
- Neither blocked nor blocking,
- but a bad idea anyway – they destroy TaskPaper fold state on save.
I think the issue is related to frequency of saves. If the file is saved several times relatively quickly, it can trigger deadlocks within read code (this happened to me early on when I had some multithreading that was not quite handled correctly – it lead to deadlocks within my file read code that were not triggered otherwise. After I fixed them, it could handle updates as quickly as they happen. – Or, more precisely, it can catch up without deadlocking if it takes longer to read and update the file than the updates are taking.)
If your testing framework starts rapid-fire flat-file saves on a file that TaskPaper is editing as a foldable outline, with nodepath filtering and tagging, you risk:
- not only repeatedly destroying TaskPaper’s outline folding and nodepath filtering data, but also
- repeatedly depriving TaskPaper of the time it needs to rebuild a much more sophisticated parse and data model than a flat-file requires.
If a user of your flat-file editor attempts to open an outline with a .taskpaper extension, or with TaskPaper extended attributes, due diligence and protection of their data might (at the very least) suggest something analogous to:
- Using runningApplicationWithProcessIdentifier to check whether the TaskPaper outliner is running
- if it is running, check whether the AXDocument attribute of (at the very least) its front window shows the same file path as that selected by your user,
- warn the user that outline’s folding and filtering data would be destroyed if it were opened in your flat-file editor,
- and offer to switch focus to the outliner.
A flat-file editor may simply not be a useful instrument for editing outlines with folding state (and filter state) extended attributes.
A prudent default might be that your flat-file editor should offer to open TaskPaper outlines in the TaskPaper outliner.
What would you do with a docx file ?
PS the Cambridge dictionary is helpful here:
ultra definition: 1. a person who has extreme political or religious opinions
I wonder if this is the right decade in which to tie marketing to the image of ultras – whether to left or to right ? (‘Alt’ was already getting contaminated, alas)
Perhaps nvSolid, nvUseful, or nvModest ?
I give up.
I came here simply to report a bug in TaskPaper, which is that it craps out if the underlying file is modified under certain circumstances.
Fix it. Don’t fix it. Up to you. If any of my users have trouble, I’ll point them to this thread.
One of the things I used to love about Hog Bay products was the responsiveness and professionalism I saw when dealing with Jesse. I guess all things change.
My response is that of a user – nothing to do with Hog Bay.
Not clear to me from testing with other applications that there actually is a bug, but it is clear that editing a TaskPaper outline in a flat-file editor inevitably entails some data loss and is unlikely to be a sensible thing to encourage.
Better for the flat editor to open the file in TaskPaper.
1 Like
Quite possible! I know there has been such a bug before, though I did also rewrite all that code following the docs as closely as I could.
My test case for this is TextEdit… I open same file in TaskPaper and TextEdit and switch between the two as fast as I can… that still seems to be working for me on 10.15.2 without issue.
Are you able to reproduce this problem with TaskPaper and TextEdit?
2 Likes
complexpoint – When I click on your forum username, it shows that you are a member of the group “moderators”, of which you and Jesse are listed as the only members. This implies more of a relationship (in the forums at least) than simply just a user.
If I have misunderstood and you have no special standing with Hog Bay and are simply trolling, then my apologies to Jesse for allowing my frustrations with you to bleed over into Hog Bay.
Either way, at this point I have made my concerns about TaskPaper clear in this thread, and see no benefit in discussing further here. If Jesse has any questions, technical or otherwise, or wants a beta copy of nvUltra in order to test this to better and see what is going on, I’m happy to help.
Jesse – I have not been able to reproduce with TextEdit, but I think it is related to the speed of the updates (depending on the settings, nvUltra can attempt to update the file as quickly as every keystroke).
It was the speed which served as a stress test in my own development that revealed the issue in my own code. Less frequent saves passed through unscathed, so I did not initially detect the flaws in my own file writing/reading threading early on.
Email me and I can get you a link for nvUltra beta that should make it trivial to reproduce this so you can see whether there is a threading issue in TaskPaper. That is probably the easiest way to demonstrate this.
Seriously?
Having been significantly helped numerous times by @complexpoint throughout the years, I find the trolling comment to be inaccurate and insulting.
Plus, the comment “I guess all things change.” is out of place. For more than forty years, I have countless experiences with software and technical support. I have to say that the quality and speed of Hog Bay Software has been at the top of the heap in almost all regards. Jessie is nothing short of amazing.
I’ll cut you some slack—maybe you are having a bad day. But don’t take it out on @complexpoint and Jessie. They deserve better.
2 Likes
Please do send to jesse@hogbaysoftware.com, can’t promise that I’ll take too deep a dive, but will check out.
To be clear, I’ve never had anything but the best in support from Jesse.
2 Likes
I think this should be fixed in:
As per my email, this makes the problem better, but not entirely resolved. (TaskPaper locks but does not prevent nvUltra from editing, until I try to switch to a new document. So part of that may now be a bug in a different section of my code that I need to dig into further.)