I would like to have the option that a page moved into linked folder (inside MojoPad) is moved to the folder in the filesystem. Which allows it to be opened by an external app.
I really hope this is possible, as it would allow to work on new pages created inside MojoPad in DEVONthink and working on pages created in DEVONthink to work in MojoPad.
Thanks.
Good news — you can do this today, and the drag you are describing is the right thing to ask for, so I am going to add that too.
Today: File ▸ Files on This Mac ▸ Move This Page to a File…
Pick that with the page open, and choose a location inside your linked folder. The page stops living inside the wiki and becomes a real file on disk. From then on it is the same arrangement as a page that arrived from that folder in the first place:
Edit it in either place and both stay in step. Change it in MojoPad and the file is written; change the file in another app and the page follows.
If both sides change before either has caught up, MojoPad will not pick a winner for you — it says so and lets you decide. That is the one thing an arrangement like this must never get wrong.
Its name, tags, properties and backlinks stay in the wiki. Only the words move out; everything the wiki knows about the page stays here.
One thing to know before you do it: the file is Markdown. A rich-text page is converted, so anything Markdown cannot express is simplified. MojoPad tells you this before it does anything, and pages that were already Markdown are unchanged.
That should give you the round trip you are after: files you put in the folder become pages, and now pages can become files in the folder.
What you actually asked for
You are right that it should be the drag. The folder in the sidebar mirrors a folder on disk, so dropping a page into it and having nothing appear on disk is a reasonable thing to be surprised by. I will make that gesture do it.
Two things I want to get right rather than quickly, and I would value your view on both since you will be living with it:
It will ask, once, rather than doing it silently. Dragging a row is a light gesture and writing a file into a folder you own is not — and there is the Markdown conversion to warn about. I would rather one confirmation than a surprise in your folder.
Dragging the page back out will not delete the file. It will mean “stop following”, and the file stays where it is. Deleting something from your disk because a row moved in a sidebar is not a thing I am willing to build — but it does mean “out” works differently here than for any other folder, so it needs saying plainly in the app rather than just in the manual.
If either of those is the wrong call for how you work, say so now while it is still a decision rather than a behavior.
Mark
Hi Mark, thanks for the explanation and I understand what you are saying.
I see that you are reluctant to build in the functionality that a move out of a linked folder should also mean that it will be removed (deleted) on the Finder level. This is a serious matter.
But for me, that is exactly what I would like. This is how I work in the Finder, DEVONthink and other apps. Moving a file/note/item from a structure to a different structure means exactly that.
Maybe it is what the Document/wiki is about. For example my journal is an “add only” structure. I put things in, never move them and never delete them.
For literature studies it is “everything goes”. Moving, deleting and adding. For this I have to decide which app is the master and other apps have to “blindly” follow.
So I would like, if possible, a setting which is asking the user to make sure she/he understands what dragging and dropping means on the Finder level.
It follows, for me, that a deletion in Finder of an item in a linked folder or the linked folder itself should be replicated in MojoPad. Currently the item stays in MojoPad.
I understand this would be a departure/change of your design. But I also think it should the the users responsibility what to do with the data.
Thanks for reading and all best.
You have changed my mind, and the sentence that did it is this one:
For this I have to decide which app is the master and other apps have to “blindly” follow.
That is the right model and I did not have it. I was treating “does MojoPad delete files” as one question with one answer, when it is a property of the arrangement — and you are describing two arrangements that genuinely differ. A journal you only ever add to is not the same as a literature folder where things move and go. Deciding that once, per folder, is a better design than me deciding it once for everybody.
You are also right that the way it behaves today is not defensible. Delete a file in Finder and the page stays here — so MojoPad already diverges from the folder it claims to mirror, and quietly. That is worse than either honest answer, because the structure looks like it matches when it does not. Whatever else is decided, that needed fixing.
So: “this folder is the master.” Set on a followed folder, off unless you turn it on, with one confirmation that spells out what dragging then means in Finder terms rather than in ours. With it on, moving a page out of that folder takes the file with it, and a file you delete in Finder takes the page.
One change to what you asked for, and I think you will want it. Neither side destroys anything: the file goes to the Trash, and the page goes to Recently Deleted. That is the same gesture Finder makes, and DEVONthink, and it is why your workflow feels safe there — not because the deletion is instant, but because it is recoverable in the place you would already look. It costs you nothing in how it works and it means a misdrag is an inconvenience rather than a loss.
And one thing it will not do, which is worth stating because it is the part that could actually hurt you. MojoPad will never read “I cannot see this file” as “you deleted this file”. A folder on an external disk, a network share, or a cloud folder that has not finished syncing is routinely unreachable for reasons that have nothing to do with intent — and a rule that replicated absence as deletion would empty a chunk of your wiki because a drive was unplugged. So it will act only when it can read the folder and the file is genuinely no longer in it. One misdrag costs one file; getting that distinction wrong costs a library.
You said it should be the user’s responsibility what happens to the data, and I agree — with the caveat that it should be your decision acting on it, and never an unmounted disk making the decision for you.
Does that shape match how you work? If the Trash step is wrong for you — if you would rather it were final — say so, because that is a decision I would rather take from somebody who lives this way than reason about from the outside.
Mark
I totally agree with your points.
Yes, a deleted file should go into the Trash.
Yes, network files and the like will have to be treated differently.
Thanks for your understanding and tremendous help.