[Feature Request] Referential Cells

[matchavez]

The feature I'm looking for here is that any particular cell should be a file elsewhere instead of a .json string. For example, if I want to work with a markdown file, I should be able to reference a markdown.md file within my machine, and have that be the cell. It is a de-facto editor, and when you exit focus of that cell, it saves and closes the file.

Why do this? At least within .txt, .rtf, and .md, you can have an external file that you might need to have as an .md for example. Once it goes into Quiver, it's a separate existence. I can't use Quiver on Windows, and I can't edit on my iPhone. However, I can edit .md files with my phone or win box. This creates interoperability, while still allowing me to work within Quiver.

Thanks, @ylian .

[ylian]

The right solution to this problem is supporting multiple note types. Eventually .qvnote will become just one note type (in cases where you need multiple cells). Simple .md, .txt should be supported as their respective types (in cases such as writing Markdown documents, web scraping saved as text). And by that time the notion of notebooks will be equivalent to folders in Finder.

[matchavez]

So if you're suggesting you'll support .md as a note type, that's very encouraging. However, having an include of a .md I still believe would be useful. Generally, when you construct a note, the reason that Quiver is so cool is that you can mix and match. But with markdown, a code fence is usable within the .md itself. So if .md was the underlying format, but cells were still "enforced", you'd have a more usable product.

Your product is considerably more polished than Mweb, but I think they have it right using .md as the underlying files. If you can take that polish and presentation layer that makes Quiver so handy, but use a standard file/folder structure using .md as a "markup" language, you would have the best of all worlds. If you do that, the "reference" feature here becomes unnecessary. But if a .qvnote is a GFM base, you then end up with "code" that can be manipulated, but the great presentation Quiver does so well.

[ylian]

Yes I think external folders should be supported.

.md will be a supported file type, so you won't need to import .md into Quiver but can open it directly. This is for users who use Markdown exclusively.

Another file type that should be supported is a rich text format (.rtf or .html). That's essentially what Evernote does.

But the multi-cell file type (.qvnote) will still be the crucial feature of Quiver. That's what Quiver does differently from others, and many people including me use the multi-cell note type exclusively.

Also, the main reason for using a code cell instead of a fenced code block is the editing experience. Editing in a code cell feels like in a code editor. But it's possible to improve the Markdown editor to make editing in a fenced code block exactly the same as in a code cell (admittedly not an easy task, but possible).

[matchavez]

I guess I'm not explaining it well. Look at it this way:

Quiver has a multi-cell note consisting of:

• text cell
• text cell
• text cell
• reference cell (external file.txt)
• text cell

So my suggestion is simply that in this 5-cell example, you have a "Reference Cell" that simply reads from an external source. The power of Quiver is to have all of these co-exist in cells. All 5 here are whatever they are, but one new type of cell is linked to a local "file.txt", drawing its content into just that one cell, making a local copy, on any change amending file.txt to be equal.

Separate from that was my thought about using markdown as a storage format, but in rethinking it after your comments, it is an inadequate method to store rich text. With that said, if we can have a way to open a path similar to an Atom "Project Folder" that will open .qvnote and .md, that would be super-amazing. Thanks for the consideration; hopefully it provides some thoughts. I really appreciate the fact you're responsive, from one IT manager to another. 💯

[ylian]

I see. You were not insisting on mapping every cell to a file, but suggesting a new cell type. That's an approach I haven't thought about.

I think the several things we discussed (external folder support, using Markdown as a storage format, reference cell) all try to solve the same problem --- Quiver forces a user to move content into it, and import/export is a hassle. I will consider all these approaches and find the simplest solution.

[matchavez]

Also consider some of us have to use Windows at times. :(