Importing

MojoPad eats almost anything. Every import becomes a page, named after the file, ready to link.

Bringing your notes over from another app

Notes scattered across two or three apps, and you want them together? Nearly every notes app can export what you've written as a folder — the notes in one place, the pictures they use beside them. Choose that folder with File ▸ Import…, or drop it onto a page, and the whole thing comes in.

Pictures come with the notes. This is the part that usually goes missing. A note points at its pictures by a path that only means something in the folder it came from, so MojoPad reads them while that folder is still in front of it and puts them in the page. It handles the three ways apps write those links — a plain path, a path with its spaces escaped, and the bare-filename style where the picture could be anywhere in the export.
The folders you had are the folders you get. Notes arranged in folders arrive arranged the same way, however deep. Choose Unfiled instead if you'd rather sort them out yourself.
Links between notes keep working. A link written [[Like this]] becomes a real link to that page — MojoPad links by name, so once both notes are in, they find each other.
Tags become tags. A #tag written in a note is added to the page's own tags, and stays in the text where you wrote it.
Settings folders are left alone, so you get your notes and not an app's configuration.

You choose what comes in, and where each part of it goes. Most people's notes aren't one kind of writing — a journaling app often holds a diary in one journal, a notebook in another and a pile of half-thoughts in a third, and a folder of notes usually has folders inside it. So choosing an export doesn't import it: MojoPad opens on what it found, a line for each part with its own count, and you say where each one lands, rename it, or leave it behind entirely.

Each part goes where you send it — into a folder you already keep, chosen from a list of everything in your wiki, or into a new one you name on the spot. If you've been keeping notes here for a while, the folder you have in mind is already on that list.
Writing that carries dates can go to the Journal, as the days it belongs to — entries from the same day are put together on that day, in the order they were written, the way a diary has always worked. Anything else goes to a folder of its own, named after where it came from.
Two things arrive switched off unless you ask for them. Some apps record where you were for every single note — a quick-capture app keeps the map coordinates of everywhere you've ever typed, and a journal keeps the place and the weather. That's not usually what someone means by "import my notes", so it's yours to turn on rather than yours to discover later.

If your app offers a choice of export format, take the one that keeps attachments — some offer to put the pictures inside the notes themselves, which works here too. Export a handful of notes first and import those before committing to all of them; it takes a minute and tells you what you're getting.

What it won't do — worth knowing before you start

Better said plainly here than discovered halfway through a library.

Pictures live inside the pages that use them, which is how every picture in MojoPad works. That makes a page self-contained and portable, and it means a wiki holds its pictures in memory while it's open. Bringing over a few hundred photos is comfortable; bringing over thousands is not, and there's no warning when you cross the line — it simply gets heavy. If you're moving a photo-heavy journal of years, bring it over in parts rather than in one go. A single picture larger than about eight megabytes is skipped rather than embedded.
Video and sound aren't brought across. A journal export can contain both, and MojoPad can't play either yet — so an entry arrives with its words and its pictures, and its recordings stay in the export folder where you can still get at them. Better that than a page pretending to hold something it can't play.
A title written into the note appears twice. Some apps put the note's name at the top of the note as well as in the filename, so you'll see it as the page's name and again as its first heading. MojoPad leaves it: the only way to remove it automatically would be to delete any heading matching the page name, which would quietly eat headings people meant to keep. One keystroke removes it; nothing brings back a heading deleted without asking.
A Scrivener project isn't imported. MojoPad doesn't read Scrivener's own format, so a project you choose or drop — or any folder inside one — brings nothing in, and one inside a folder you import is left out while the rest of the folder comes in. MojoPad tells you which. In Scrivener, choose File ▸ Compile… to make a plain text or Markdown file, and import that instead — it arrives as a page you can write in. MojoPad won't link a project or any file in it either, or read one as a library, and your assistant's imports leave it alone the same way.
Pictures your notes point at but that aren't in the folder are left out. If an export references something outside the folder you chose, MojoPad won't reach outside for it — a note is a file anyone can write, and a link in one is a request, not permission. Help ▸ Save Diagnostic Report counts anything skipped this way, so you can tell "nothing was there" from "something went wrong".

Importing the same folder twice

You brought a folder over last month, wrote in some of those pages since, and the files have moved on too. Import it again. MojoPad remembers which file each page came from, so nothing doubles: the ones that are already pages are named back to you and left exactly as they are, and only files it has never seen become pages.

Pages an older MojoPad imported carry no record of their file, so importing such a folder again brings it in once more — and from then on it is recognized.

The same goes for clipping a page from the web that you have clipped before, and for dropping one file onto a window twice.

Nothing you have written is ever overwritten. This is the promise the rest of it rests on. A page you imported in March may since have been read, annotated, linked and rewritten, and a folder of files knows nothing about any of that — so a page that holds anything other than what the import put there is left alone, whatever the file now says.
One file, or one clip, asks you. A single import is a deliberate act, so instead of a quiet refusal you get a question: open the page you already have, or take it again anyway. Taking it again is always available — a second copy on purpose is a reasonable thing to want, and MojoPad does not stand in the way of it.
A folder tells you. Dropping in a folder where a dozen files are already pages names those pages and offers to show you one, rather than asking a dozen times.
A page you have thrown away does not count. Something in Recently Deleted is not something you have, so importing its file again simply makes the page again.
Files are matched by the file, not by the name. Two different notes both called notes.md, in two different folders, are two different pages — and renaming a page here does not make MojoPad forget which file it came from. A clipped web page is matched by the address it was taken from, ignoring the tracking bits a newsletter or a share button adds, so one article reached two ways is still one article.
A paper or a PDF is left as it is. Attachments are never replaced by a re-import, even when the file on disk has changed. Your highlights are anchored to positions inside the copy stored in the wiki, so swapping the file underneath them would move every highlight onto the wrong words without saying so. Replacing an attachment is something to do deliberately to one page, not something a folder should do to fifty.

If what you actually want is for pages to keep up with a folder as it changes, that is a different feature and it already exists: follow the folder, and MojoPad watches it and keeps the pages in step, renames included. Importing is a copy taken once; following is a living link. See Linked Files and Folders.

When an assistant does the importing, it works the same way with one difference: an assistant re-running an import does bring a page up to date from a newer file — that is what "import that folder again" means when you ask for it — but only while the page still holds exactly what the import left there. The moment you have written in it, the file loses. And it refreshes only pages it imported itself: a page MojoPad imported is left as it is, because the two read a file differently — MojoPad turns a saved web page into an article, for one — and an assistant cannot tell a newer file from its own way of reading the same one. What it did is reported back item by item, so it can tell you which pages it refreshed and which it left alone, and why.

If a re-import surprises you, Help ▸ Save Diagnostic Report is the place to look. Every import records how many files it was offered, how many pages it made and how many were already here — so you can tell "it found everything already there" from "it did not read the folder I meant", which look identical from the outside and are both quiet. The record is counts only: it never carries your file names, your folder layout or anything you have written, because that report is a thing you might email to us.

Files

Drag and drop files or a whole folder — onto a page to bring them in there, or onto the pages column on the left, which is usually where you mean. Drop straight onto a folder in that column and they're filed into it. Dropped on a page, or on the column away from any folder, they go to your import folder (see Where imported files land, and what they are called, below). Or use File ▸ Import… (multi-select works, and folders can be chosen too).
Pick where they land. After you choose files with File ▸ Import…, MojoPad asks which folder the new pages should go into. Pick a folder, choose Unfiled to sort them out later, or type a name that doesn't exist yet and MojoPad offers to create the folder on the spot — a thousand files can arrive already filed, no moving them one at a time afterwards. (The list filters as you type, so a deep tree is two keystrokes away.) Your answer is the only place they go: the import folder in Settings does not apply to a batch you have just placed, and Unfiled means in no folder at all.
Drag files onto a folder. In the sidebar's Folders view, drop files from Finder straight onto a folder row — they import and file into that folder in one motion, and into no other. Right-clicking a folder offers the same thing as Import Files Here…. Into a folder you follow from your Mac, either one first asks, once, whether to save the files of writing there as files too — see Folders in the sidebar.
Images land inline, ready to resize and annotate.
PDFs become readable pages, shown in MojoPad's own reader — clean pages on the page background, no plugin chrome, with real selectable text (select, copy, drag excerpts to a canvas or — from a pane beside your page — straight into your notes; see Transclusion and Panes). Their text is searchable, so a word inside the PDF turns up in search and ⌘F finds it in the reader (see Searching). Long documents open instantly: pages draw as you reach them. You can mark passages as you read — see Reading with a pen in your hand below. For ink-level markup, click Open in PDF editor… above the page: it opens in your default PDF app (Preview, Acrobat, …), and because the file lives inside your document, your edits save straight back into it — press Reload to see them. A file named .pdf that MojoPad can’t read — a damaged file, or one that is not really a PDF — says so on its page, with Open in default app… to try it in another app.
Text files become editable pages — plain text, Markdown, and other text formats like Org-mode (.org), reStructuredText (.rst), AsciiDoc (.adoc), LaTeX (.tex), and log files. If it's really text, it opens as text.
Anything else is stored in the document and linked.

A page is named after the file, so the file’s name is the page’s name. For a folder of papers that is not a detail: name each file after the work’s identifier — PMID12345678.pdf, PMC1234567.pdf, or a DOI in its encoded form — and every mention of that identifier anywhere in your wiki opens the copy you just brought in. The rule, in full, with the reason a DOI cannot be a filename as it stands and working code for both directions, is in Properties ▸ Naming a paper by its identifier.

Files MojoPad will not open for you

A colleague sends you their project wiki, and one of its pages is a "PDF" with an Open in PDF editor… button. The file underneath is really a Word document with macros. Or a page you imported links to report.pdf on a shared drive, and that turns out to be a program. A wiki can hold any file, and a page can link to any file on your Mac — so before MojoPad hands a file to another app, it looks at what the file really is: inside it, not just at its name or at what the wiki says it is.

That check runs for every way a file leaves MojoPad: Open in default app… and Open in PDF editor… on a file’s page, Open in default app… on a PDF MojoPad can’t read, Open in another app beside a recording that will not play, the open button in a peek, a paper in a shared library, and a link to a file in a page.

MojoPad will not open these, and says which it found:

programs and scripts, and folders (a program can look just like one);
Word, Excel and PowerPoint files with macros or other code in them, and the older Office formats, which can carry macros MojoPad cannot look inside to check for;
Office files that fetch part of themselves from the internet as they open, such as a template kept on a website — the usual way macros get in, and one nobody can check in advance;
rich text files, web pages, disk images, settings profiles, and the files your Mac acts on, such as a saved web link, a Terminal shortcut, or a saved location that connects to a server or to another computer’s screen;
aliases. Your Mac opens whatever an alias points to, so an alias called invoice.pdf can open a program sitting beside it. Open the file it points to instead.

A dot or a space after a file’s name does not change what MojoPad decides: on Windows those are dropped before the file is opened, so a script with a dot after its name is still a script.

Each time, it offers Show in Finder. If you know where the file came from and trust it, open it from the Finder yourself. The choice stays yours; MojoPad just won’t make it for you with one click.

MojoPad asks first about an Office file that fetches pictures from the internet as it opens, because each fetch tells whoever made the file that you opened it. It also asks about any file in a wiki with a password, or on a page with a password of its own (see Encryption and Privacy). Cancel is always the default, and there is no "always" to check.

Links that start with ms-word:, or another Office app’s name, hand a document from the internet straight to that app before MojoPad could look at it, so MojoPad does not open them; open the document from its own website instead. A link to a server on your network asks every time you click it.

Reading with a pen in your hand

Three kinds of reading, and MojoPad now handles all three without making you stop and take notes:

The paper you're reviewing for a colleague. Mark the three passages you want to raise, in three different colors — one for methods, one for claims you doubt, one for the sentences you'll quote back.
The chapter you're studying. Mark as you go, keep reading, and let the marks be the map you come back to. Nothing leaves the page and nothing interrupts the reading.
The contract, the manual, the long report. Mark the clause you'll need to find again in six weeks, when you will not remember which page it was on.

How. Open the PDF and select the words you want to mark. A small bar of colors floats just above the selection — amber, yellow, green, pink or blue, the same five the editor's text highlighter uses. Click one and the passage is marked; the color you chose is the one offered first next time, so marking a whole chapter in one color is one click per passage. A press anywhere on the bar — between the colors or at its ends — leaves your selection as it was.

Changing your mind. Right-click a mark for its own menu: pick another color, or remove it. To clear every mark in the document at once, use the reader's toolbar. Marks live in the document, so they are there on every view of that PDF, they survive quitting, and they travel with the document if you move it.

Everything else the right-click menu did, it still does. Away from a mark you get the usual macOS menu — Copy, Look Up, Read Aloud — and it now works on whatever word is under the pointer, so you can look a word up without selecting it first.

Marking versus quoting. Dragging an excerpt into a note also leaves a permanent mark on the PDF, and that's the move when you want the words in your writing. Use a highlight when you want the passage to stay where it is and simply be findable — the point of the pen, rather than the scissors.

Web pages

File ▸ Import URL… (or paste a link onto a canvas ▸ Add web page here…) renders the page first — so JavaScript-built articles arrive as real content, not an empty shell — then extracts a clean, editable page. It keeps what matters: the article's structure — real tables, blockquotes, figures and captions, nested lists; the sharpest images (the full-resolution originals, not thumbnails or lazy-load placeholders); a quiet byline line (author · date · site, read from the page's own metadata); and any embedded videos, which arrive as players you can actually play. Ads, share bars, cookie banners, newsletter sign-ups, and "related articles" rails are left behind. On-device AI then trims to just the article. Type the address as you have it: example.com/article works as well as the whole address, and a page on an older, unsecured address is fetched over a secure connection, the only kind MojoPad uses. Where it came from stays with it. An imported or clipped page wears a small ⇱ badge with the site’s name at the top, beside the title. Click it to open the original. It applies to saved snapshots and PDFs too — and to everything you clipped before today, because the address was always being kept; it simply had nowhere to show itself. (For pages behind a login, use the Clip to MojoPad extension below, which captures from your own browser session.)
Safari web archives (drag a .webarchive in) offer a choice: Clean & editable (the article, extracted) or Original snapshot (the page exactly as saved, pixel for pixel — like VoodooPad kept them). The pictures come with it. Anything the archive did not already contain is fetched once, as the page is saved, and kept inside your document — so the page still has its pictures when the site it came from has been reorganized or closed, and it reads the same on a train as it does at your desk. If some of those pictures live on other sites, MojoPad names them and asks once before fetching them; anything you decline stays as a link, and a page with links left in it does contact those sites when you open it.
Pictures kept on other sites. An article's photographs often live somewhere else — a picture service, the publisher's own image host. Those come with the page and you are not asked about them: their addresses were written by the page you chose to keep, and your own browser fetched every one of them while you were reading it, so there is nothing of yours that could travel out that way. MojoPad works out where the page keeps its pictures from the page itself, so this only ever covers the page in front of you. An address that came from somewhere else is still a question, asked once for the whole page rather than one each. Allow brings the pictures into your document, so the page reads the same offline. Don't Allow leaves them as links — pictures on a secure site are then loaded from it each time you open the page, and any that are not are not shown at all. Check Remember and you are not asked about those sites again for that wiki; the answer is listed under Settings ▸ Sharing and can be taken back there. It is an answer about pictures only: it does not let that wiki's plugins reach the same sites, which is a separate question with a separate answer.
Local HTML files (.html) import the same way — the same Clean & editable / Original snapshot choice, with images and stylesheets from the file's own folder pulled in so the snapshot still looks right. (Page scripts don't run — snapshot freezes the static page, clean keeps the article.) A snapshot is shown in a frame of its own, so the site's styling stays inside it and can't restyle MojoPad or cover any of it. A picture the snapshot couldn't keep when it was saved still loads from the web when it opens (see Saved web pages keep their own pictures in Migrating from VoodooPad).
ePub books offer a choice too: As wiki pages turns the book into a page per chapter with a linked contents page — readable in your theme, editable, in the graph — or As an attachment keeps it as one file page that reads like a book: one warm serif column with chapter dividers, in MojoPad's own reader — and the book's own images and diagrams appear in place, sized to the column. (Only images carried inside the book itself are shown; anything a page tries to fetch from the web is quietly left out, so reading never phones anywhere.) Select and copy from it, drag passages to a canvas, and excerpts leave permanent highlights that thread back from your notes — the same loop PDFs have. It's searchable and askable too, whole-book AI included. (DRM-protected books can't be opened — true everywhere.)

Where a clip lands. By default, in whichever wiki you were last using — quick, and fine when you keep one. Keep several and it means what you clip while reading depends on which window happened to be in front, which is a filing accident waiting to happen. Set Clip to in Settings ▶ Web Clipper to a particular wiki and every clip goes there instead, whatever you have open; if that wiki is closed, MojoPad opens it, because a clip you cannot see is a clip you cannot trust. Underneath it, File clips under folder names the folder they arrive in — and that folder is created for you if it is not there yet.

A clip is filed in that folder and nowhere else. That holds however you clip: the extension, the bookmarklet with or without a selection, and Explore's Clip selected and Save to wiki. The folder named under Settings ▶ Files & Backups ▶ Importing files is for files you hand to MojoPad from outside, and it never applies to a clip. Clear File clips under folder and clips stay at the top level; they do not go to the import folder instead. (Until this was fixed, a clip with an import folder set was listed under both folders, and that folder was made in your clipping wiki if it was not there. Clips listed twice then are still listed twice, because MojoPad does not take pages out of your folders on its own. To take one out, right-click its entry under the folder it does not belong in and choose Remove from folder; the page stays in the other.)

Or choose while you clip. If you keep several wikis, a setting made once in the app is often the wrong shape — you know where a page belongs at the moment you read it, not in advance. Right-click the extension's button and choose Options, then check Ask which wiki, every time I clip: from then on the popup waits instead of clipping on sight, offering your wikis with the last one you chose already selected. (It arrives with an extension update, so if you do not see it yet, your copy has not been updated — the Clip to setting in the app works either way.) So the usual case is still one click, and moving a page somewhere else is one more. Leave it unchecked and clipping is exactly as it always was — the popup clips the moment it opens.

A wiki you pick goes first. Pick a wiki in the chooser and that clip goes there, ahead of Clip to — from version 0.3.3 of the clipper extension; until your browser has that version, Clip to decides. The wiki the popup has ready from your last clip is only a reminder: when you were not asked, Clip to decides, and the remembered wiki is used only when MojoPad has no other place the clip can go.

The list only appears when you have more than one wiki, since otherwise there is nothing to choose. And the browser is told what your wikis are called and nothing else — never where they live on disk, because a folder name can say more about your work than the page you are filing.

The Web Clipper clips from your browser with one click, and the two ways of doing it differ in a way worth knowing. The Clip to MojoPad Chrome extension captures the page as you are seeing it — so a subscription article, or a site that refuses anything that is not a browser, comes through intact. The bookmarklet (which works in Safari too) sends your selection if you have made one, and otherwise sends only the address for MojoPad to fetch itself — which many news sites refuse, and which cannot reach anything behind a login, because that page exists only inside your signed-in session. So: on those sites, select the part you want, or use the extension. See Page Links Everywhere.

Getting the extension. It is free and part of MojoPad. Open Settings ▶ Web Clipper and click Get the Clip to MojoPad extension, which takes you straight to it; it runs in Chrome, Brave, Edge, Arc and Vivaldi. Safari cannot run it — on Safari the bookmarklet is the way, and it is on the same settings pane.

When a clip is not the page. A site can answer a fetch with a cookie dialog, a security check or a sign-in wall, and what lands looks exactly like a clip that worked — the title is right, the byline is right, and the article is nowhere in it. MojoPad measures how much of the page survived, and when very little did it writes a short note at the top of the page beginning “This may not be the article.”, saying what it measured and how to stop seeing these. Nothing is refused; the note only declines to let a clip pass for something it is not.

The note never says your choice was wrong. Clean & editable is meant to leave things out, and a note that read as a complaint about that on every clip would be a note about a decision you already made. It says the clip may not be the article, which is a different claim and the only one the measurement can make.

If your clipping is deliberately narrow — you have set things up to keep one part of a page and throw the rest away — that measurement is describing your own choice, and the note is worth turning off: Settings ▶ Web Clipper ▶ Warn on a page when the clip may not be the whole article. The note itself says where that switch is, so you can reach it from the thing you want to stop seeing.

Handing MojoPad a file from outside it. Right-click a file in the Finder and choose Services ▶ Add to MojoPad, print to Save PDF to MojoPad from any print dialog, or open a file with MojoPad: the file becomes a page, MojoPad comes to the front and opens it, and it lands where File imports under folder says — under Unfiled until you name a folder, so you can put it where it belongs. That folder is for files handed in, never for a clip or for files you place yourself: a clip goes to your clip folder, and files you place — dropped on a folder, Import Files Here…, or the folder you pick in File ▶ Import… — go where you put them. Each page is filed once, in one folder.

Which wiki it goes to is Settings ▶ Files & Backups ▶ Importing files ▶ Add to. Left alone the file lands in the wiki you were last using. If you keep a wiki per project, choose Ask each time: MojoPad asks before anything is added, and the question offers the wikis you have open, the ones you have used lately, and Choose another wiki… for any other on this Mac. A wiki that is closed is opened for it; one with a password holds the file at its unlock screen and files it the moment you type the password. The question carries the folder as well, so one batch can go somewhere else without changing the setting, and Don’t Add adds nothing and leaves your file exactly where it was. Or name a wiki and every file goes there, whether or not it is open. This is a separate setting from Clip to on purpose: a paper you hand over is not a clip, and sending it wherever your clips go would put it somewhere you never chose.

A clip waits for the wiki, rather than being lost by it. If the wiki you clip to is closed, MojoPad opens it and holds the clip until it is genuinely ready — and if that wiki has a password, the clip waits on the unlock screen and files itself the moment you type it. If the wiki you named cannot be opened at all — renamed, moved, or on a drive that is not connected — MojoPad says so and offers to put the clip in a wiki that is open, rather than quietly filing it somewhere you did not choose. Nothing arrives silently and nothing is thrown away without telling you.

One case where dismissing is an answer. Out of the box MojoPad asks how to keep a whole page — clean and editable, or the page exactly as it looked. If you dismiss that question rather than answering it, the clip is discarded, and the status line says so, naming the page. That is deliberate, and it is safe for this one thing only: a web clip has another copy, because the page is still on the web and its address is still in your browser. It is also the alternative to what used to happen, which was the same question greeting you at every launch for two weeks. Set a format in Settings ▶ Web Clipper and it stops asking altogether.

A clip that ends without a page is finished with. It is not handed back the next time the wiki opens — not when you dismissed that question, not when the page was already in your wiki and you chose Open the one I have, and not when MojoPad asked to fetch from that site and you said no.

When a site will not hand the page over. You clip a news story or a paper with the bookmarklet and nothing selected, and MojoPad has to fetch the page itself — and many news sites refuse anything that is not a browser, while a page behind a subscription exists only inside your own signed-in session. MojoPad says so once, naming the page and its address so nothing is lost with the clip, and does not try again: the site would say the same thing tomorrow. Two ways do work. Select the part you want first and clip that — the words come from your browser, so MojoPad fetches nothing. Or clip with the browser extension, which captures the page you are already looking at, signed in and all. The same goes for a page that came back with nothing in it to keep, such as a sign-in wall. A page on a site that still uses an older, unsecured address is fetched over a secure connection instead, which is the only kind MojoPad uses.

When the page could not be reached. You clipped on a train, or the site was having trouble, or a hotel's network was showing its own sign-in page in front of every site. That clip is kept and tried again the next time the wiki opens — three tries in all, each saying how many are left. After the third, MojoPad lets it go and says so, with the page's address, so you can clip it again once you are back online.

A clip that could not be saved is kept until you say otherwise. A page from the browser extension, or a selection, is the only copy of what you clipped — the page may have changed or gone behind a paywall since. So if MojoPad cannot save it (the disk is full, say), it tells you why and asks whether to Keep It or Discard This Clip. Kept, it is tried again each time the wiki opens, and asked about again only if it still cannot be saved. MojoPad never lets go of one of these by itself. If that wiki has since been moved or renamed, the next wiki you open asks whether to save the clip there, and names the wiki it was kept for.

A clip that is not the article says so, at the top of the page it made. Some pages hand a clipper a consent dialog, a sign-in wall, or a shell that needed a browser to draw the words at all — and each of those files itself as a perfectly ordinary-looking page. You find out months later, when you open the one source you were sure you had. So MojoPad reads what it captured before filing it: if what came through is a cookie notice, a "turn on JavaScript" holding page, or so little text that it cannot be the piece, a short note at the top of the page says which of those it looks like. The clip is still saved and the note is ordinary text you can delete — it is there to be seen at the moment you file it, not to argue with you.

And it tells you in the browser, where you are. You clip from Chrome; MojoPad may be on another desktop, behind a full-screen window, or on a second display. Anything it needs from you there would be invisible — which reads exactly like a clip that failed. So when MojoPad is not the app in front and it has something to say about a clip, it sends a notification, which crosses desktops when a window cannot. Click it and MojoPad comes to you with the question waiting.

This is the one part of clipping that depends on something outside MojoPad: if you have turned MojoPad's notifications off in System Settings ▶ Notifications, there is nowhere for it to say anything, and a clip that needs an answer will sit waiting in a window you cannot see — the very thing this exists to prevent. Nothing is lost when that happens; bring MojoPad forward and the question is there. But if you clip a lot and never want the detour, setting a format (below) is the surer fix.

Most often that question is simply which format, because out of the box MojoPad asks each time. If you always want the same one, set it in Settings ▶ Web Clipper and it stops asking — clips then land without a detour, and the only notifications you get are the ones that matter.

Which setting reaches which. The pane says so beside each group, because the two tools do not take the same ones. Clip to and File clips under folder apply to both. Format for a whole page applies whenever a whole page is clipped, either way — clipping a selection never asks, because a selection is already just your text. Highlighting your pages as you browse needs the extension and does nothing without it.

Clipped articles arrive as ordinary rich-text pages: headings, images, and links intact, and any code or preformatted blocks render in tinted boxes that wrap long lines instead of running off the page.

Talk to your videos — transcripts

Under any YouTube, Vimeo or TED video sits a small 📄 Transcript button — always there, no hunting for it. Click it. MojoPad fetches the video's captions and lays them out beneath the player as timestamped paragraphs — real, searchable text that becomes part of the page. Search finds talks by what was said in them; the transcript travels into your exports; and it renders wherever the video does, including on a canvas card.

The button does its work once and then goes away: a video that already has its transcript doesn't need it again.

Every timestamp is a link. Click one and the player jumps to that moment — no scrubbing. It's the fastest way to re-find the ten seconds you actually wanted.

Pull a quote onto a board — and jump back to hear it. Open the talk beside a canvas (⌥-click it, or right-click its card ▸ Open beside the board), then drag a transcript line onto the canvas. It lands as a sticky stamped from 🎬 the talk · 12:34. Click that stamp later and the talk opens beside the board, the video seeks to the exact moment those words were spoken, and a thread draws itself from your note to the video. Your notes remember not just where an idea came from, but when.

Transcripts are best-effort: a video with no captions, or a platform that changes its internals, may come back empty — an occasional maintenance patch keeps them flowing. Auto-generated (machine) captions are labeled as such.

From anywhere on your Mac

The Bucket — press ⇧⌘7 in any application and a small capture window appears; type a thought and it's appended to your Bucket page, timestamped. When you capture from another app, MojoPad stays out of your way: the moment the panel closes it hands focus straight back to wherever you were — your browser, your editor, the call — so the capture never yanks you into MojoPad. Inside MojoPad you can also open it from the 🪣 Bucket button in the toolbar or File ▸ Quick Capture (Bucket). Click the 📌 pin in its title bar and the panel floats over everything for drip-capture: each ↩ saves the thought and clears the box for the next one, clicking elsewhere no longer dismisses it, and esc closes it when you're done — perfect alongside a call or a video.
Triage the Bucket into real pages. When the capture page fills up, run Explode Page… from the command palette: every block gets a checkbox and a page-name field — check the pieces that should become pages (give two pieces the same name and they join the same page), and a → link stays behind for each so the trail survives. ✦ Group with AI asks your local model to propose the grouping — related captures checked and named in one pass, yours to adjust before anything moves.
Create Page from Selection (command palette) works anywhere, not just the Bucket: select any passage and it moves to a new page — named from the words, adjustable before it lands — leaving a link where the text used to be.
Save PDF to MojoPad — in any app's print dialog, open the PDF menu and choose Save PDF to MojoPad. The PDF lands in your frontmost document.
New Page from Clipboard (⌥⌘V) — also on the page list's right-click menu.

Checking what your sources say

You have written a section that cites eleven papers, and you would like to know that it is true. Check What Your Sources Say… reads each cited sentence against the paper it cites and comes back with one of three answers.

Borne out — the source says this, and here are its words. Worth a look — the source's own words differ from what your sentence claims; they are quoted, and you decide. Not found — nothing supporting the sentence turned up.

That third answer is not the second one. Looking cannot prove a paper does not say something, only that this did not find it — perhaps in a section it did not read. Being told "your source disagrees" when the truth is "I could not find it" would be worse than being told nothing, so the two are kept apart. A source with no words to read — a scan that was never given a text layer — says that too, rather than being counted as a source that failed you.

Every quote is one the paper really contains. A model asked to copy a sentence will sometimes paraphrase instead, and a paraphrase inside quotation marks is a fabricated receipt on the one part of a claim a reader would never think to check. So a quote that is not literally in the source is discarded rather than shown with a caveat.

It will not rewrite your sentence. A button that softens a hedge on a machine's judgment would be the dangerous half of this idea — nobody re-examines a hedge they were told to add. It shows you the paper's words; the writing stays yours.

A check that could not run is not a finding. If the model fails on a source, stops short, or is handed more of it than it can read at once, nothing about that source was actually checked — so its line in the run says not checked, with the reason, and it is left out of the report altogether. What the report holds are checks that ran. Run it again on those sources; if the reason was size, a model that reads more at once is what helps.

A locked source is not read, like everywhere else in MojoPad, and nothing is sent anywhere until you ask for the check.

Writing from your sources

You are writing a paragraph and you want three of your papers in it, each saying what it actually found. Insert from Your Sources… does the whole of that without leaving the sentence. Type /sources where you are writing; it is also under Edit and in the command palette.

It opens with a search box that takes the whole query language: words, "a phrase", OR, NOT, and the terms tag: in: type: name: prop: and the date ones. prop: is new and is the one that matters for a library: prop:Year=2025 finds papers with that year, prop:Authors=Kelly finds an author, and prop:Title on its own finds every page that has a title — useful mostly for finding the ones that do not.

Then there are three ways out, because there are three things a writer does with a shelf of papers. Link them puts every checked one in at once — as a list, or as A, B and C in the line you are writing — and needs no model at all; it is the quicker move, and the one for a see-also line or the sources behind a claim. Write them in takes an instruction instead — one sentence on its method and its main finding, a two-line annotation, what it says about older adults — and each source is read separately and written in as its own paragraph with a link back to it. Reference list is the third, and it is below.

An answer points at your own copies. When an answer names a paper you hold — by its DOI, its PubMed number, or the name of the page it lives on — the link opens that page rather than the publisher's website. Where you do not have a copy, the same link goes to the registry, which is the rule everywhere else in MojoPad: write the identifier once, and it finds your copy if there is one.

Reading one before you check it. Right-click any result for Open Beside or Open in Small Window. The chooser steps out of the way while you read — a bar at the foot of the window says how many you have checked and what you are looking at, and Resume choosing brings the list back exactly as you left it. Nothing is lost by going to look.

What you type is what is asked. The instruction box passes your words to the model and adds nothing to them but the source itself. Ask for bullets and you get bullets; ask for a table, a heading, a numbered list, two sentences and no more — you get that. MojoPad adds only the link to each source afterwards, and the one rule it does keep is about honesty rather than shape: never invent a finding, a number or an author, and say so when the source does not answer.

One source at a time, on purpose — and all of them together when you ask for that. A model handed six papers at once blends them, and afterwards you cannot tell which sentence came from which — which is the opposite of what citing is for. So Write them in as starts at a paragraph about each source, in turn: each paper is asked about alone, and each paragraph belongs to one source and carries its link. Nothing lands on the page until the run ends — every source answered, or you stopped it — so you never see half a paragraph; a source that failed, or whose answer stopped short, is left out and the run's log says so.

Some asks are about the set rather than about each paper: what the six of them agree about, a table of their methods, a list in a style this app does not ship. Those are one answer about all of them together. Every source is labeled in what the model is shown, so the answer can say which is which, and all of them are linked under it. Each source's share of the reading shrinks as you check more; where that would leave too little of each paper to count as reading it, the ask is refused and tells you roughly how many will fit — write the rest in as a second pass.

You can see it, and you can stop it. The moment Write them in starts, a run appears in Research runs & scripts and as a small card at the bottom right of the window, both saying which source is being read — reading 2 of 4. The row names the model that is answering, and so does the first line of the run's own log, so a small model standing in for the one you chose can never again go unmentioned. The card has a Stop, and so does the run when you open it from the list. Stopping ends the source being read and keeps the ones that had already answered. The run keeps a line for every source afterward: what it was read from, what was written, and why nothing was — a scan with no text, a model that answered with nothing, a source you stopped before it was read. The list shows how far a run has come each time you open it, and picking a run opens it: how long it has been going, which model answered, and every line it has printed, opened at the newest line. The card on screen keeps counting. Start a second job and its card takes the front; the first one's comes back, still counting, when the second ends. Check What Your Sources Say… and filling a property across a kind appear in the same list and stop the same way.

The end of a paper is its reference list, and reading a paper from both ends was handing the model the citations instead of the conclusion. Each source is now read from its beginning and from just before its references — the model is told the list was left out on purpose — and the run's log says when that happened and how far into the paper the list began. A paper with no such section is read exactly as before.

Reference list is the third way out, and it uses no model at all. Check your papers, choose Vancouver or APA 7, and each one is written from its own details — Authors, Year, Published in, Title, and Volume, Issue, Pages and Journal abbreviation where the page has them — read from its properties. A page that says too little but is named or labeled by a DOI, a PubMed number or a PubMed Central number is looked up through the same catalogs and the same kind of asking as ⌕ Look up this source: one question first, naming the catalogs and counting the requests — up to two for each page, one to the catalog and one more when its record names a DOI — and only the identifier leaves your Mac. What a catalog answers is used for the list and is not kept on the page; the lookup button is how to keep it. A field the record does not state is left out rather than guessed at; a journal is abbreviated only when the catalog supplied the abbreviation; and a page with too little to cite — no author and no title, or no year and no identifier — is left out of the list and named in the run's log instead of being printed broken. A page you have locked is left out too, and named the same way: its words are sealed, and a line in a numbered list that is only a filename is a gap wearing the shape of a reference. Vancouver entries are numbered in the order you checked them; APA entries are alphabetical and unnumbered, as that style is, and they hang their second line the way that style does. Each title is a link to its page.

An entry that has an identifier ends somewhere you can go. A Vancouver entry closes with the paper's DOI, or with the PubMed or PubMed Central number where there is no DOI. An APA entry closes with the address that identifier stands for — doi.org for a DOI, and the paper's own page at PubMed or PubMed Central for the other two — because a numbered entry carrying a title, a year in brackets and nothing else is a gap wearing the shape of a reference, and a paper known only by its PubMed number used to print as exactly that.

Two styles, and there is a reason there is no third. A named style like Chicago prints authors' full first names, and the catalogs disagree about whether they have them: one shelf of papers would come back with full names for some entries and initials for others, inside one list. It also wants titles capitalized word by word, which is a judgment about which words are names — and a list that is nine tenths right in a style you cannot check looks finished. Vancouver and APA 7 are the two this can do without guessing.

Two things it will not do, on purpose. It will not re-case an article title: which words in a title are names is a judgment, and a program that made it would make it silently and be wrong in both directions, so what you get is what the record says. There are two exceptions, both in APA and both of the kind that cannot be wrong: the first letter after a colon in a title, and the journal name, which that style prints in title case and which the catalogs hand over in sentence case — so The Cochrane database of systematic reviews prints as The Cochrane Database of Systematic Reviews. Only a lowercase word is ever raised, and only up: a word already written with a capital in it is left exactly as it was, so PLOS ONE, eLife and mBio come through untouched. A journal name that says it is in another language is left alone altogether — what says so is an accent, or a word like de, und or tijdschrift, so a name in another language that carries neither is capitalized like an English one. And it does not shape a book, a chapter or a conference paper; those print from the pieces they have. It is not the self-keeping References block, which lists what a page cites in no style at all — see A reference list that keeps itself.

Ask Write them in for a reference list in Vancouver format and it will not write prose about each source right away: a line under the box says that this asks for a reference list, the style is set for you, and Reference list is the button to press. Press Write them in again without changing what you typed and it writes the prose — so a question that happens to mention a paper's bibliography is pointed at the list once and then answered.

What it will not do is invent. The model is told to be faithful and to say when a source does not answer the question, rather than filling the gap. A source with no readable words — a scan with no text layer — is skipped and counted, so the number written in tells you if one was missed. And the model that answers is the one you chose: your own agent or the model you set up, when that is what the chooser says, and the run's log names it.

A link to a folder

You want the address of a folder — to paste into a task manager, an email, or a page in another wiki. Right-click the folder in the sidebar and choose Copy Link to This Folder. What lands on the clipboard opens that folder in this wiki from anywhere on this Mac, with every folder above it opened too so it is genuinely on screen rather than merely expanded somewhere out of view.

That is a different thing from Link Selection to Folder…, which is in the editor's right-click menu and makes words in a page point at a folder. One puts a folder's address on the clipboard; the other writes a link into what you are writing.

Opening the registry's page for a number

Once a paper carries its numbers, they are listed under Aliases in the Info panel — and each one is a link. Click a DOI and doi.org opens it in your browser; a PubMed number opens PubMed, a PubMed Central number opens the article there. Right-click for Open in Browser, Copy Link or Copy Identifier, which is the quickest way to paste a paper's DOI into a message.

Nothing is fetched by MojoPad when you do this — the address goes to your browser, which is the same thing that happens when you click an identifier written in your own prose.

A paper that prints no identifier

You have a shelf of offprints and scans, and half of them carry no DOI anywhere in the document. That is normal — a manuscript accepted for press, a chapter, anything published before identifiers were universal — and it used to mean the paper could never be looked up at all.

Now the title is the key. ⌕ Look up this source appears on those pages as well, and selecting a batch offers to search by title for the ones with no identifier — telling you how many before it asks, because a title is words out of your library and an identifier is not. The title goes out, and the first author's surname where the page keeps one — which is there to tell two works of the same name apart rather than to make the match. Nothing else does.

It matches exactly or not at all. A catalog will rank five plausible near-misses above nothing, and a wrong identifier here does not stay cosmetic: it becomes an alias, and starts linking your writing to somebody else's paper. So a work is taken only when its title matches yours word for word — capitals, punctuation and typesetting aside — and where two works answer to the same title with nothing to tell them apart, neither is taken. At the end of a batch the ones identified this way are counted on their own line, because they are the ones worth a glance.

And the paper it finds brings its other numbers with it. A title match ends in a DOI, and a DOI is then asked of PubMed for that paper's PubMed and PubMed Central numbers. All three land as properties — DOI, PMID, PMCID — and each one also becomes an alias, so writing any of them in a note links to the page and a citation written any of those ways opens your copy.

A paper whose file name is a DOI with underscores where the slashes should be — 10.1093_ptj_pzaa150.pdf, which is how a fetching program writes one when it cannot put a slash in a filename — cannot be read as an identifier. Real DOIs contain underscores of their own, so nothing afterwards could tell which was which, and a rule that swapped them back would file some papers under the wrong work in silence. So MojoPad asks instead: pressing ⌕ Look up this source checks up to four spellings of that name with the registry — an identifier-shaped guess, never your words — and takes one only if it is the only spelling the registry knows — a record without a title still counts as a spelling it knows, because the name is ambiguous either way. Where the page already carries a Title, or a name that reads as one, the record's title has to match that as well — which for a paper freshly imported under a name like this one is usually not yet the case, so on those pages the registry knowing exactly one spelling is the whole of the check. The button says so before you press it, and the page's name is left exactly as it is. Next time, name the file with the one your assistant's read_identifier gives you and none of this is needed.

A link to a sentence in a paper

Copy Link to Selected Words works in a stored PDF as well as on a page. Select the sentence, right-click, and take the link — the same command, by the same name, in both places.

A page can keep the mark by wrapping the words in the text itself. A PDF cannot be written into, so the words are highlighted where they sit and the link points at that highlight — which is also how citations into a paper have always worked here, so the mark is a thing you can see and remove afterwards. Following the link opens the paper beside what you are reading, scrolled to the sentence with the highlight showing.

Pasted into a page, it works like a quote's ↵. Click it and the paper opens beside your page — or, if a pane already shows the paper, that pane goes to the sentence — and a line draws from the link to the highlight for a moment. While the paper is open in another pane, the link also has that pane's thread and is underlined in its color, like any other link to the paper. If the highlight has since been removed, the paper still opens beside your page and the status line says the marked passage isn’t there. Followed from another app — a task, a mail message — the link opens the paper at the sentence without the line, since nothing in MojoPad was clicked. A link copied before the wiki was moved or renamed still names where the wiki was: it opens the paper the same way, with no line and no thread. Copy it again to have both.

The link works anywhere on this Mac. Unlike the page version it does not offer a web address: a highlight is MojoPad's own idea of a place, and a shared copy of the wiki has no way to jump to one — so rather than hand out an address that quietly lands at the top of the paper, it does not offer the choice.

Linking to a folder

A project note wants to point at the folder its papers live in, not only at one of them. Select the words, then Link Selection to Folder… — in the right-click menu and under Edit ▸ Link, beside the same command for a page. Pick any folder in Collections and the words point at it.

Clicking such a link opens that folder in the page list — and every folder above it, so it is actually on screen rather than expanded inside something still closed — and shows what is in it as a gallery, the same view the folder's own ▦ button gives. The link is stored by the folder's identity rather than its name, so renaming the folder does not break it, and two folders sharing a name are never confused for one another.

Where imported files land, and what they are called

You have downloaded four hundred papers and every one is named after a fragment of its address. A paper fetched by its identifier arrives as pnw107.pdf — the last piece of 10.1093/pm/pnw107, because a web address had nothing else to give. Nothing truncated it; the title was never in the filename. So the one thing you would search for — what the paper is about — is written nowhere MojoPad can see, and the folder of them reads as a list of serial numbers.

Settings ▸ Files & Backups ▸ Importing files answers the first half. Add to names the wiki a file goes to when you hand one to MojoPad from outside — the Services menu, Save PDF to MojoPad, or Open With — so a bulk import does not depend on which window happened to be in front. File imports under folder names the folder they go into, made for you if it is not there. Name a path and it nests — PDF Library/Endoscopy files two deep and creates whichever part is missing, so a library can grow subfolders without any of them being made by hand first. Leave it blank and they stay at the top level, which is what MojoPad has always done. On whichever wiki is in front, or with a wiki named, nothing is asked at the time: the point of a setting here is that a hundred files can go in at once without a hundred dialogs — change the setting between batches and each batch lands where you last set it. On Ask each time you are asked once for the whole batch, and the answer names the wiki and the folder both. The folder box in that question starts on this setting until you have answered it once; after that it starts on the folder you chose last time, so twenty papers into one project is one answer and nineteen agreements. Clearing the box is an answer too — it means the top level, and the next question starts blank rather than back on the setting.

Which pages the import folder takes. A page that arrives is filed once, by the way it came in. Files handed in go to the import folder, or to the folder you answered for that batch: the Services menu, Save PDF to MojoPad, Open With, a file dropped on a page or on the pages column away from any folder, a file or web page added to a board, File ▸ Import URL…, and Import This Page on a link. Clips never go there — the extension, the bookmarklet and Explore all file under your clip folder, set in Settings ▸ Web Clipper. Files you place yourself go exactly where you put them and nowhere else: dropped on a folder, Import Files Here…, the folder you pick in File ▸ Import… (including Unfiled), and each part of an import you plan, including the parts you send to the Journal. However a page arrives, it is listed in one folder, never in two.

Where a batch went, and a second chance to move it. Files handed in from outside announce themselves once when the batch is done — Filed 12 files into “PDF Library” — with a Move… beside it. Choose it and you can send that whole batch somewhere else; typing a path that does not exist yet makes it, so the batch that belongs in a new subfolder gets one without you creating it first. The move can be undone. The notice goes on its own after twenty seconds; the ✕ closes it at once, and so does esc — you no longer have to start a move you did not want in order to be rid of it.

A batch is one question, never one per file. The Finder service hands MojoPad one file at a time, so a question at each arrival would be a question per paper. Files are collected as they arrive and asked about once, naming how many — and on the other two settings nothing is asked at all, so a bulk import runs from start to finish uninterrupted.

The second half is the name. A PDF usually knows its own title — publishers write it into the file — and MojoPad now reads it as the words are read, and puts it in two places: a Title property, which is where you read it and what a citation and a database view use; and an alias, which is what makes it findable. From then on the page lists under its title rather than its filename, typing [[ finds it by title, and [[The Paper's Full Title]] links to it. The filename still works too — nothing you could type before stops working.

The title is kept as words. Publishers and catalogs often write a title the way it was typeset, with hidden codes for italics, subscripts and special spaces. MojoPad keeps only the words: a subscript stays part of its word, so a title reads CO2 laser rather than CO 2 laser; an italic word keeps the spaces around it; and a code for a space or an ampersand becomes the space or the ampersand. That holds for the title a PDF carries and for the details ⌕ Look up this source brings back from a catalog or your Zotero library. A title saved by an earlier version is shown as words in the Pages panel, tabs, search results, reference lists and exports, while its Title field keeps what it holds until you change it or tidy it (below) — and so does anything that shows that field as it is, such as a Title column in a database view, or {{Title}} in a template, which puts it into the page as the characters it holds.

Paper titles that show markup. You imported a shelf of papers with an earlier version, and the Title field of some of them — or a Title column in a database view — still shows the hidden codes the journal typeset the title with, around an italic word, a subscript or a special space, where the Pages panel shows the words. Or you write a paper's title in a note and it never links, because the alias beside the title still holds those codes. Tidy Paper Titles… fixes all of them at once:

When you open a wiki with such titles, a notice at the bottom of the window says how many there are. Press Review…. Close the notice instead and it does not come back for that wiki; the command is always in the command palette (⇧⌘P), and on the menu you get by right-clicking the empty space in the Pages panel.
The sheet says how many pages it would change, and shows a few of the real titles as they are now and as they would be. Press Fix Them, or Not Now to leave them as they are. Either way the notice is not shown for that wiki again — unless MojoPad could not tidy them just then, when it says why, and the notice comes back the next time you open the wiki.
Each title becomes its words, by the same rule a new title follows, and so does the alias it was added as. Nothing in the pages themselves changes: each keeps its words, its name and its place in a list sorted by date, and the ⌕ beside a title that says which catalog answered it stays.

Every original is kept, on its own page. Press Undo on the notice that follows, or choose Put the Original Titles Back… from the same two places at any time later, and each tidied page gets back exactly the title and the alias it had. A title you have changed since it was tidied is yours: it is left as you wrote it, and MojoPad says how many it left. Choosing Tidy Paper Titles… again changes nothing it has already tidied.

What it leaves alone. A page with a password of its own that is locked is not looked at — unlock it and choose the command again, and the sheet says how many it skipped. An alias that would read the same as another page's name stays as it is, so one phrase never comes to mean two pages, and a formatted Title property keeps its formatting, since that is what it is for. A title you typed yourself with a word in angle brackets, such as a note on the parts of a web page, is left exactly as you wrote it, so no word is taken out of it. A less-than or greater-than sign that a journal wrote as a code stays written that way, so a title such as one about children under five can still show that code after a tidy. A title that a template has already put into a page is part of that page's words, and stays as it is there. Tidying is done in the window you opened the wiki in, while no other window has the wiki open, and not while the bar about changes on another device, or a bar asking about words waiting to be saved, is up; MojoPad says which. Help ▸ Save Diagnostic Report… counts the pages tidied, the titles still to tidy and the ones that keep such a sign, and never prints a title.

And the identifier a paper prints inside itself. A journal article states its own DOI on its first page. That is picked up as an alias as well, so [[10.1093/pm/pnw107]] links to the paper, and ⌕ Look up this source can find the work — which it could not do before, because it reads a page's name, aliases and properties, and all three said pnw107.pdf.

What it will not do is guess. Plenty of PDFs carry junk where the title should be: a word-processor filename, untitled, or a typesetting job number. A wrong title here would not be a cosmetic slip — it becomes an alias, so it starts matching your prose and linking your writing to the wrong paper, and it becomes what the page is called. So anything that does not read like a title is refused and the page keeps its filename. No title is a better answer than a confident wrong one, and for a paper with a DOI you can ask for the details to be looked up and get the real one from the registry.

Nothing already there is overwritten. A title you set is yours, a page you renamed keeps your name, and an alias that already names another page is left alone rather than made to mean two things.

Combining documents

File ▸ Merge Document… imports every page of another MojoPad document into this one — names are de-duplicated, links are rewired, and each page keeps its kind and the fields that go with it, the definitions they are read through included. File ▸ Split Document… goes the other way: pick pages, save them as a new document, optionally remove them from this one. A page with a password of its own goes into the new document still sealed with that password, open or not, and the same password opens it there. Split a wiki that has a password of its own, and the new document has that password too. Two pages wait for you first: one whose password was changed on another device (answer the bar at the top of the window), and one locked by an earlier version of MojoPad that you have not opened since (unlock it once, so its notes and properties go under its password with it).