Allow for opening an attachment without first needing to save it.

Is this the same issue as having an alias in MORI that doesn't open the attachment?

by that I mean that it doesn't automatically open the attachment within the note - it opens the attachment in the source application when I click the alias

There are two issues here.

One is actual attachments that are stored in Mori; the other is links to documents on your hard disk.

Currently atttachments will not open until saved to disk. Hoepfully Jesse will fix this in the next version.

But what would be simpler, and as good as attachments for many or most purposes, would be just to make it easier to create links (which currently do open) by drag and drop and by an open/save dialog box.

Voodoopad3 has a new file attachments feature that we might learn something from. But it still seems to suffer the biggest problem that Mori has, if you embed a file you can't open it without first doing a "Save
As...". But it does handle opening of aliases files better.

I like the link idea. What is the best way to express it as a request?

This discussion reminds me of LinkBack. I thought about implementing it a while back, but I haven't been doing much development lately because I've got a lot of math to study over the summer, and I had been waiting for Mori 1.2 to stabilize. Anyway, I'd love to see this implemented, and I think this would resolve the issue here.

Unless I'm missing something, shouldn't things dragged in as aliased items (my dragging, then holding down the cntl key before dropping) already be able to be opened without having to resave the item as a separate file? I mean, I know that isn't how it's working now, but it really shouldn't be necessary to resave the file or write it to a temp directory and watch for changes because it's just a pointer to the file and not the file itself.
I mean, already I can drag any file into the note view (let's say a keynote file) and release it with the cntl key down to make a file alias and icon. Then select the icon and choose "Make link..." put in the file path (e.g. file://localhost/Users/jeff/Desktop/Polymer%20systems%20review.key/) and then everything is perfect. On click on the icon and it opens up in Keynote.

All the infrastructure is there, it's just a matter of connecting a few dots to make drag-and-drop file linking easy and intuitive. I think this would meet many users' needs until any type of linkback or "open and reimport edits" functionality was ready.

Normally I hate me too posts, but I'm going to post a really big ME TOO following BME guy's post. I think I said it before but not so clearly. Easier links to external files and folders would not be hard to implement, and would make a HUGE difference to MORI's usability, while we wait for easier to use true attachments. This is a big priority!!

In my earlier post, I didn't mean to make light of the difficulty of attachments because there are very few programs that handle them gracefully.

Also, in my description of an alternative solution, I didn't acknowledge that Mori's current behavior of importing an actual Finder alias of the file is in some ways superior to simply copying the file's current path as a link. This latter option will be broken if one moves the file to a new location, but the former is able to "track" the file despite moves. In this case, it might be best to just automatically save an alias file to the tmp directory and open the alias' target. There would really be no need to montior the file any further. Any changes would be updated when the file is saved. Mori can do this now. (you just have to switch to another not and back to the orginial for the change to be loaded.)

I think either of these options (Finder alias to tmp or automated linking) would cover 90% of the attachments for users. Of course, I may be oversimplifying the amount of coding involved.

In my earlier post, I didn't mean to make light of the difficulty of attachments because there are very few programs that handle them gracefully.

:), but I do agree with the general thread that referenced files should be the default, and it's true that they aren't nearly as hard to open properly (without forcing a save as) as embedded files. Right now the big problem is just lack of time. I have tomorrow off from baby-sitting and expect to release Mori 1.2 then. After that works starts on 1.3 which i expect to include some attachments improvements in.

This discussion seems to have arrived at some conclusions already, but I thought I should bring up an alternative - one that might make a nice option for some uses of Mori.

Bookends is a citation management program that lets you attach files to entries - PDF files of the cited article, or a Mellel document with notes on the cited article, etc. Bookends stores its citations in a database file, so these attachments are stored in an attachments folder. (Actually, when you drag a PDF onto an entry, it says: "Move to attachments folder, or don't move file?" But I use the attachments folder - it's user-defined in the app's Preferences.)

The advantages are: (1) If you don't mind having Bookends handle the attachments, it's great not to worry about where the attachments are stored. (2) Backup of all attached files along with the database is simplified. (3) Attachments remain searchable by Spotlight, so there's no need for the Bookends database file to contain Metadata on the attachments' contents.

For Mori, this would be a good system for users who want advantages (1) and (2) above. Advantage (3) looks like it might simplify things for Jesse in terms of Spotlight support in Mori. It wouldn't be great for users who want to keep their attachments in their original locations - but the discussion above in this thread seems to deal with that pretty well.

Yojimbo handels attacments very well as does Journaler 2