View group of entries as single continuous text file, outline

Instead of just viewing how about allowing edits as well? This would be great when looking over a bunch of notes in a single view and spotting something that needs updating. Just edit the text right there and it updates in the appropriate note.

I'd like to highlight a range of folders and files, click an icon or logical keyboard sequence and see them as a full-screen outline with instream notes that you could then edit and otherwise mess with.

I've been thinking about something like this, too. I'd like to be able to take several notes and merge them together. Should be easily accomplished with an AppleScript; just haven't had time to write it yet.

G Gordon,

You should check out the Assemble Content script that's included with the scripts pack. It is probably very close to what you are looking for.

I created a merge entries script today and based it on assemble content script (I didn't realize it existed until I started checking around the script folder for a good starting point). It pretty much works, but it has a bug (shared by the assembled content script) that the attributes of the text are not copied into the new note, which is annoying since I usually subdivide my notes using headers and mark things using the highlight feature.

Any work arounds or is this just a bug?

Merge Entries script attached for anyone who wants to try it. Select several entries and you'll get a new one with the selected entries merged together. It will recurse down the entry tree, but the result is flat (multiple levels of subheadings in a future release).

I think the original request allows for the greatest flexibility in simply selecting multiple items and then viewing them as a series of headings as one note. Being able to edit this aggregated view would also be very helpful in editing large files.

Deselecting items in the "Entry View" could remove that one item temporarily or collapse it to allow for easier editing (see http://www.hogbaysoftware.com/node/476).

So Leo has pretty robust support for this sort of thing - its meant as "literate editor" and it allows you to both output flat textfiles and edit them and have the changes resynced into the outline. I think, but don't know, that if you could integrate Leo's python code into the Mori codebase, as a plugin or otherwise, you should be able to port it over withoug much trouble. However Leo is GPL. You are probably alright if you port it to a "open source" plugin, but not perhaps if you fold it into the Mori codebase itself.

Just changing the title back, for clarity. That's a pretty unintuitive update interface, where new comments can affect the original title. I don't know if there's a drupal setting or not for this, but I think most posters think that they are adding a title to their own comment and not changing the original request title.

Yeah, that was my fault sorry. What was even stranger is I could have sworn it didn't change it initially.

Agree with #6, the original request was not at all about document assembly, which is what Leo is good at. That feature is of interest to me too, but there is already a node open for that one. This is about being able to "assemble" in place, for the purpose of editing, and then dissolving that assembly back into the outline seamlessly. To date, I've only seen one application do anything like it, Scrivener Gold. It has a "Draft Mode" where you can view and edit your outline as a contiguous document. Headers become styled titles directly in the text itself. But this implementation was a static view of your entire outline, not as flexible as this approach could be.

Alas, the next version of Scrivener will not have this feature at all, but it was good while it lasted. In a way, Jer`s Novel Writer also acts like this, but there is no other way to view your text. Really, it could be thought of more along the lines of Mellel's Outline, where you have powerful outline control over the flow of a document that is presented in a linear fashion.

This request, though, is more interesting and flexible. It is something that I have expressed interest on to another software package, Tinderbox, nearly a year ago. I think the request fell along the wayside though. Personally, I think it would be a wonderful way to write, as it would allow you to keep your sections in small parcels, but easily see the "big view" when you need to. Combined with Mori's Smart Folder collection abilities you could create ad hoc documents with ad hoc content. :)

Leo has exactly this functionality. You can assemble, edit the assembled and then it integrates the changes into the outline.

It seems to me that the remaining difficulty is one of interface - i.e. "seamlessly". In leos language these operations are tangle and untangle.

Perhaps I am mistaken, then. I had thought that Leo requires you to export "tangle," the documents out to the disk, where you could then do whatever you wanted, and if you edited them on the disk, you could "untangle" and it would move everything back into the outline. This is half of what HBN did, right? I don't think it had an untangle, but it did have a tangle.

I think what is different here is that we are talking about "(un)tangling" right in the Mori interface, skipping the whole disk part. The advantages here are that it requires no syntax in the documents themselves -- these "pseudo-documents" can been made and un-made simply by selecting them and then pressing a button or closing the document. It is simply a way of viewing your existing notes in Mori. The resulting tangled document never fully exists, it is just a presentation of all the other notes. Thus any edits made to them are implicit.

Right now what Mori can do (but many other apps cannot) is take a single TextStorage object and display it in several different TextViews at the same time. This is what happens when you open a note in its own note window--if you leave your original outline open to the same note, you can see that any changes to either is immediately reflected in the other.

I think the heart of Amber's comment (and the thread in general) revolves around doing the reverse. Namely, having a single TextView (your assembled document window) and displaying several TextStorage objects in it contiguously, so that there is no visual distinction where one ends and the next begins (except perhaps for a paragraph marker.) Then all edits to this assembled text would actually be edits to the underlying TextStorage so that they would be automatically reflected in the orignial notes.

I agree wtih everything Amber said in her last comment. However, as she said, Leo does provide the ability to untangle a document - merge edits with the original outline.

Now as far as implementation goes whether one write a temporary file to a disk or to RAM (which the os might well write to disk) seems to me irrelevant, and probably transparent to the user. The difficult part is write a script which will - in an elegant way- tangle and untangle a selection of nodes.

How and when one activates this script is a seperate, and much simpler issue of the user interface.

Thus I repeat my suggestion that someone fluent in python port Leo's scripts to Mori. It is probably just a matter of replacing a few Leo calls with applescript calls to mori, at least in a first iteration.

What do you mean by no syntax in the documents themselves? If you want to be able to merge your edits in a robust way you are going to have to have some sort of markup. I suppose this markup doesn't have to be in a text file way, one could outline the nodes in various colors or something, but you will need something.

Joecoffey, see BMEguy's comments on what I am trying to say (without any knowledge of the underlying programming, he seems to at least know what would be involved technically).

There would be no (visible) markup because this would not be a pre-planned event. As opposed to tangling and HBN's assembly, where you have a very solid idea of how your outline is going to export itself. There is certainly a place for this, it is very valid feature, but what I am talking about -- and what the original request is asking for, is the merging of n number of documents -- on the fly, in memory -- right inside of Mori. The resulting "meta-document," "pseudo-document," whatever you want to call it, would be nothing more than a text editing window that contains multiple files within it. These files are dilineated by their headers, which are styled in a manner which makes it obvious for what they are. They cannot be deleted. In this way, there will be no confusion about what input is going into which document.

Pseudo-document Window ------\
 Document A
   This is document A. It exists somewhere arbitrary in Mori's outline, and the contents of that document are displayed in this window.

 Document B
   And this is document B. It exists somewhere else in the outline, and might have little do with Document A, ever, but for now we wanted to display it as if A and B were one document, so they will appear this way, as sections in a larger document, until this window is closed.
\----------- End of Pseudo-document Window

As to whether or not there is some hidden syntax and temporary files going on and what-not is, as you said, not relevant. We are talking about UI here and what the user sees. To the user, the pseudo-document window will look exactly like a large document with sections. The edits they make in this document will go straight into the sub-documents which are being used to construct it. Same technology as when you have a separate window open, like BMEguy said.

I know that this is possible, for I have used the application I mentioned, and it acted precisely in this fashion. Only, always displayed the entire outline tree (being designed to write novels and such, this was perfectly fine behaviour), and the sub-document order was defined by the outline order. So if I went back to Binder View and changed the position of some scenes around, then went back to Draft View, the "pseudo-document" would now look different.

It is just a multi–file viewing mode. I imagine that since Mori is not even working with "files" internally, but database entries, this should not pose too much of a difficulty, but like I said, I am completely ignorant of programming on the Mac. I just do a little scripting.

So in short, this isn't about a robust tangle, or document assembly that you'll be doing over and over. Proper assembly would be what you want, then. This is about, "I've never viewed these documents together before, and I probably never will again, but I would like to right now."

I do believe that if such a feature were extremely easy to use, it would change the way we write in Mori. Right now I am hesitant to use the sub-document feature, because it is difficult to view the entire group at once, as a finished article. Under this system, I could keep sections and even sub-sections in discrete entries, working on a detailed basis with them, and view the "big picture," whenever I wanted to.

Hope that makes more sense. This has nothing to do with exporting, or writing to the disk, or adding syntax to create a complex collection of entries. It has everything to do with rapidly editing multiple documents you might have no intention of ever displaying together otherwise. Say you decided to enact a style change to signify "comments" in your entries. Just load up all 30 entries in a Smart Folder, that contain comments, hit the "View as document" button (or whatever,) and rapidly copy/paste formatting rather than copy paste close open paste close open paste close, et cetera.

Eh, reading your other comment again, I see you probably got most of what I just said. Consider it illumination for the sake of future readers of this thread. Hopefully I clarified the lack of needing syntax, at least. :)

My only question about markup in the tangled -temporarily or otherwise- is that if you want to edit the tangled document, say move nodes around, edit different clones differently, etc... then the tangled document is going to have some markup or you will never be able to consistently recover your data in the outline. Now this mark up needn't be text based, or rather mori needn't it render that way, but you are going to have to have something along the lines of

asjdkfsdfjsdafasadsf

or even

@section heading
alskdfasdfasdjf
@@child headign
note asdfjasdd
@@child heading
noet jaskdlfasdf

something.

or whatever. Mori can, of course, render these tags in some other way non textual way, but presumably you don't want to be stuck in the Mori editor for the rest of your days. So the text file generated should look something like that.

I looked at Leo for a few minutes, and unfortunately he seems to use single letter variables for everything so its pretty fricking difficult to follow.

I tried to put some xml'ish tags in that last post and of course it got stripped out, but you get the idea. I feel like we are speaking at cross purposes though. I understand what you want, I am just saying that the hard part has been done in another open source program.

Joe
I'm not convinced that you need to markup the text in some way. It may well be the case that Leo did accomplish this with text markup to handle tangle and untangle, but I have a feeling that you can accomplish the same with much less difficulty using cocoa's text objects and views. Editing the assembled, psuedo-document and editing the individual notes of the entries would be doing the same thing under the surface--simply the interface presented to the user would differ.

On the other hand, if you're talking about marking up the textstream for use outside of Mori, then I think that that would be a separate issue that would be handled by an export plugin. Even right now, one could use the OPML export plugin as an example and fairly quickly generate a decent "assemble document" export plugin with attributes you describe. If you're hoping to assemble the document into a single text string (not several underlying NSTextStorage objects), edit it in a separate tool, and then have those edits come back to Mori, with everything going back to where it should be (i.e. entry hierarchy with their attached notes, which have perhaps been split or combined); then, I agree that it's worth it to draw upon the experience of Leo in that realm. However, for assembled viewing and editing of entries that stays completely within Mori (until a one-way export of a 'finished' product) it's likely that direct markup of the textstream is not necessary.
Course, I could be wrong. :)

Best,
Jeff

Interesting!

I propose following methods:

By selecting multiple items Mori consolidates the selection in the notes view showing all selected items seperate by headers containing the names of each. Each note is still editable but is logically seperated however you wish. This acts a temporary grouping, very convienient

Also, this would work well if it achiveed same result, not by selecting but by simply selecting a folder or grouping, instead of having notes on folders/groups it would show a consolidated view of the notes in the root of that group.

Scrivener has this implemented, I like the header idea, especially as an export feature to MS Word or Pages so we can take our info out of Mori to be published.

I'd recommend rethinking the current "extract" and "inline" text menu choices with respect to this functionality, so there's a consistent approach to splitting apart and rolling up entries in Mori. I think there are three issues: 1) an entry needs its own distinct notes text even if it has subentries, 2) the ability to link to an entry and replace the link with that entry's text is useful, and 3) incorporating unlinked subentries text into a note needs to be done in a consistent way.

What if there was a "view inline" option for an entry's note text where 1) links to any other entries would be replaced by that entry's text, and 2) non-linked subentries were incorporated in order at the end of the note? You could also have full consolidation, where this was applied recursively to sub-subentries, etc. This would be a view that could be toggled on and off. Each entry could have its title as a subhead in a style specified in preferences (with the size relative to its own content), separated from the preceding text by a blank line, with a blank line after the subhead. The resulting consolidated note would be printable, meeting the need to print folder contents.

Extract would work as now, and the current inline could be renamed "move inline", or something like that. The advantage of this approach is that it would handle replacement of links with text correctly, while also allowing unlinked subentries to be rolled up into their parent's text in a consistent way. I also think setting this up as a view rather than moving the originial subentries into the parent would have benefit.

I don't know if you know Basket Note Pads (or have access to a linux machine to try it out) but this has a very nice functionality for full text display of different notes or folders. They're separated like paragraphs and one can collapse them individually or even shuffle them around by dragging them....