I’m new to Scapple (on macOS 12.3.1); I love it! Extremely useful for what I want it to do. Thanks, L&L .
But I can’t get import to work.
Specifically: I can’t get Scapple to break a multi-line TextEdit file into multiple Notes - even setting the delimiter to ‘\n’, ‘\r’ or either one ‘¶’ or two '¶¶'s (the default).
Scapple just groups the contents of the entire file into one Note.
If I paste the file’s contents into BBEdit (so that there is no styling) and drag that BBEdit file onto an empty Scapple window, all I get is a ‘URL’ to the file on my Desktop.
I know it can be done… have watched the video and read the relevant page [66, para 9.1.1] in the manual.
If someone has a minute kindly to explain what I might be doing wrong, I’d so appreciate it: would mean I didn’t have to go into the resulting single imported note and split it manually.
I am unable to replicate the trouble you are having.
If you are only trying to make this work with the actual content you are trying to port over, you should try it with a test case – type a simple three line text directly into TextEdit or BBedit and save as plain text (.txt). Drop the resulting file onto the window of a fresh Scapple doc. Using simple carriage returns in the source doc, I get just what is expected in the resulting Scapple doc.
If that pans out differently than the result you are seeing with your content doc, then you know it has something to do with /it/. It’s line breaks may encoding line breaks in a different way than Scapple is expecting.
In BBedit you can snoop this out by showing inivisibles and look at the character code of the newline character on the Character Inspector palette.
That’s all I can think of that might be running interference.
In the interest of full disclosure, I am running an older macOS than you, so there is, I guess, that too.
DOS-style line ending should be supported, at least I don’t run into any issues with them.
One thing that definitely will fail though is if the text file has so-called “line breaks”, which can come from word processing software typically, and are another kind of character entirely from a text-compatible newline. You can test that theory by changing your separator to line breaks, with ⌃↩ (which if it works correctly, will insert a white space character that looks like the Return key symbol used here).
Could you upload your test file, the one with these three simple lines that you are trying to import, in a response? You might need to zip compress it in Finder if it doesn’t upload directly.
I wonder how your encoding prefs are set in TextEdit. Here is how mine look. The only user controllable parts here that might matter would be i) format: plain text, and ii) Saving files: Unicode (UTF-8).
This makes me think - as @AmberV (and you) kindly suggest - I must be getting the ‘Split into multiple…’ setting wrong. Which delimiter works for you, please?
I can’t see anything in this RTF file that would trip things up, and indeed it imports and splits just fine for me. The only thing I can think of is that is that your separators field has some hidden junk character in it somehow.
I’d try pressing ⌘A in the field to select the entire contents and delete to clear it. Try importing with an empty field—you should get a warning mess about the software being unable to split by nothing. If you get that, it means the field is truly empty. Cancel the warning to return, and import again. This time enable the split option again and type in a single Return into the field.
They were unaware you were trying to split an RTF file, so changing the extension to TXT caused that result. Basically the same type of result you would get if you took an HTML file and changed its extension to .txt: you’d see the raw markup just like you do here.
Do you have any idea why I get this when trying to drag a BBEdit file (which I believe has even less formatting) in to import, please:
The problem is related to the previous issue: file extensions. There isn’t one, so it doesn’t know what this kind of file is.
It’s been a very long time since the Mac was viable without file extensions. They used to be unheard of, back in the old Mac OS days, because files identified themselves with metadata rather than naming conventions. These days you really need extensions for most software to understand what kind of data the file represents.
.
