Named Styles

You can use named styles, just as you can in most Mac applications. Invoke the ruler and use the styles pop-up. In fact it is OmniOutliner and the likes of Word which are the oddballs because they've each implemented their own styles regime. I agree that OmniOutliner makes particularly good use of their system, but styles are present in Mori just as they are in TextEdit, although not in a manner which would address your request regarding metadata.

Gordon and I had a mini-discussion about named styles a couple of months back. You can find it here:
http://www.hogbaysoftware.com/node/759

Well, I wrote a column or two about this in ATPO.

What Mori has is the ability to apply preset display attributes using the system facilities. These presets can be named, and accessed through that ruler popup. (I missed both the popup and the actual ruler. In 1.2, you have to find it as a toolbar button and add it.)

That speaks to the easy control and assignment of the appearance of text. That’s quite a bit different than what I request here.

Word and Omni have some persistence in the assignment, which means that you can take all the text that is styled “temp emphasis” and was displayed as red bold and change the assignment to normal italic. The old Nisuswriter went further with find and replace that could select all instances of text marked this way, using the style as real, character-level metadata.

Some products have a “highlighting” capability which is essentially the ability mark text like we mark containers of text.

How would I use this? Maybe I’d mark some text in a note as “This sentence needs fact checking” and as time goes on have it display redder and bigger. And at the same time have a smart folder that collects all note elements with such text in it.

Also, when I go to publish in some way — and I assume many Mori users will want to produce something — then I can use these style marks as “tags” to help me arrange things for print or web or whatever.

Make sense? Its all about structure. Nesting, columns, links and yes, NAMED styles where the name stays associated with the mark.

Sorry, "tedg" wasn't enough for me to guess ATPM's Ted Goranson. Like I mentioned in the discussion reference above, your ATPO article was what got me started thinking about named styles and their uses.
If I find time to do another plugin after mGTD, I'd like to tackle a fuller implementation of styles for Mori. What I'm thinking is a greater decoupling between semantic and display styles than is even allowed in OO3 or NWE. In both of those programs the name will stay associated with the tagged text, but all changes to the display of the style are made piece-wise. (e.g. adding red text to the "comments" style.)
I'm hoping for an implementation in which there are semantic styles that are applied to the content and then display styles that can be changed, dynamically depending on the target output.

For Example:

I define semantic/metadata styles:

• comment
• check facts
• revise
• action
• related URL

and display styles: (these examples are nec. simple but the style could be a complex mix of font, size, bold, underline, etc)

• red-bold
• invisible
• bracketed (adds parentheses at string ends)
• green-text
• italics
• embedded-link
• red-underline
• lighter (display styles could either be absolute or relative to the default or already applied styles. e.g. use the applied red but make it a little lighter--as you described in ATPO.)

The strength then would come from the ability to map the two style types dynamically and with saved mappings.

"working" map-view
META-------------DISPLAY
none-------------none
comment-------------red-underline
check facts-------------green-text
revise-------------italics, lighter
action-------------green-text
related URL-------------embedded link

"send-out draft" map-view
META-------------DISPLAY
none-------------none
comment-------------red-underline
check facts-------------invisible
revise-------------none
action-------------invisible
related URL-------------embedded link

"action items" map-view
META-------------DISPLAY
none-------------invisible (! rather than extract certain special info from a writing, we can simply not show all non-special text)
comment-------------invisible
check facts-------------none (i.e. display in default font, size)
revise-------------none
action-------------none
related URL-------------invisible

"text export" map-view
META-------------DISPLAY
none-------------none
comment-------------bracketed with "(* *)"
check facts-------------bracketed with "(? ?)"
revise-------------bracketed with "(- -)"
action-------------bracketed with "(! !)"
related URL-------------bracketed with "(http )"

Then I could keep one master representation of the underlying data and change views depending on the work I was doing or to whom I was sending a copy. Is this going to be possible within the context of Mori and with my limited time and programming skills? We'll have to see, but it's certainly interesting to think about. Another possibility would be to use tools like stx2any or reStructured text.

Well, let me know if I can help in this noble endeavor.

Of course, something like this could be accomplished in any document authoring program but the ability to tie in with associative semantics of outline "containment" and links can only be accomplished in an outliner. It would be something, that. Naturally, you'll have style semantics at the paragraph, note and header levels too?

I mentioned in a note to Jesse how I would like to see semantic outline association merged with the style assignment. At the moment, Mori has what I might call "passive" smart folders which are essentially saved searches. What if you had a smart folder that collected all the notes labelled red. I want to be able to take a note and drag it to a "hot" or active smart folder and have its label changed to red. Now extend that to hierarchical styles, suppose I selected a block of text or note and instead of pulling down a style list, I dragged it to a smart folder and the appropriate assignment rules were applied.