2003Dec16 from RustyM
tkoutline Needs Distinction for Headlines, Whitespace in Text, and Metadata
From the sidelines (not being a programmer) I ask for Brian and other developers to consider the value of metadata in an outline. Metadata can be a distinction just for purposes of display ...regardless of a chosen "level" of expansion/collapse in the outline.
1. By this I mean the option (in some outliners) to collapse one or more levels ....but still display the "headline" as a clue to what is inside the node. If this is ever added as a tkoutline feature, I think it should be an "option" ...eg expand/collapse to "n" level __ with/without display of headline.
2. Now one can ask why not always display the entire text of a node when its given level is expanded/viewable. To this I must respond that the text of a node should be emancipated from the forced assumption that a new sentence= a new node. A node should be allowed to contain any amount of text with any amount of whitespace formatting to best communicate the node content. When a node is exported into the <outline> tag for OPML, that tag should be allowed to contain text that is at least as free as the tag in html for preformatted text (<pre> I think). My main point is that the metadata headline and its much larger text should RESIDE in the same node, being distinguished only by sequential status (first sentence vs. all others). Entry of the large body of text should NOT be afflicted with the automatic correlation of one sentence=one node.It should NOT be necessary to move the block of text to the next lower level of the outline in order to hide it behind its "headline". However, if whitespace can be rehabilitated into the text of a node, I can live with tkoutline by placing body text in the next lower level. To do this all defacto metadata headlines will have to be single sentence followed by a child of body text. I think it is more logical to have the headline and body text composed/contained in a single node and exported as such into any other text document or markup language.
3. Going one step further, the day may come when additional metadata about a node will be helpful. The concept of metatdata can be extended to include field:data pairs that are not derived from part of the text of a given node. Of course metadata needs additional application tools to be useful with special sorting,indexing, and forms of display and access. Since this is posted in a wiki, I cite Diamond Wiki as an example of attempt to add metadata to a wiki process (wiki is often lacking in any polling process for gathering and displaying metadata). I cite this to support my view that metadata can be useful in an outline also.
My view is that even though the heirarchy of an outline is its first asset, there should be a special status for AT LEAST the first line of a node which is the typical "heading" in general writing (which also has heirarchical topics/ subtopics). Part 1 and 2 in this post are synergistic and sort of like a sword with two cutting edges. Even with its value as a singlepane outliner, tkoutline has not embraced the functional gains of distinguishing the headline status and emancipating the node text from relentless "newline=new node". Part1/2 are immediately important and Part3 metadata tools are worthy of future consideration.
Thanks for reviewing this and adding your thoughts _ RustyM
16Dec03 - Brian Theado - Having headlines as a separate entity from body text is a reasonable feature request. When writing outlines I have always found it difficult to decide when to put text in a headline vs. when to put text in a body section and therefore have never implemented it. I have added this to the todo list (Future plans). I'm not sure how easy or difficult this will be to implement.
RE: Metadata - The tree data structure that is used to represent an outline's hierarchy is already very flexible and will support any sort of key/value pair metadata. In fact, tkoutline uses the key named title to store headline text and the key named expand to indicate whether a node is expanded or collapsed. To give you an idea how this works, try the following from tkoutline's console (type in the lines preceded by the % prompt):
% getnode insert node1 % tree keys node1 expand title % tree set node1 title node1 % tree set node1 expand 0 % tree set node1 mykey "My very own metadata key" My very own metadata key % tree keys node1 expand title mykey
2003Dec16 RustyM
Thanks Brian,for considering feature(s) to distinguish headline and allow whitespace within a node. When there is no interest in providing a headline for a node, the convention could be to begin the node with oneline of whitespace (the structured text convention in wiki) Besides having whitespace within nodes,it would be great to have a display mode that could render the entire outline by the rules of structured text. This could bring an outliner closer to being a presentation tool. I would like tools to render structured text even ahead of tools to define fonts (or color) for headlines at specific levels.
Re item 3: I am not at all sure that embedded metadata will be useful, but it has been the principle of freeform text databases such as Asksam since DOS days. I am not aware of a structured text convention for *hiding* text in a rendered display. To hide a fieldname:data pair something unheard of in usual punctuation would do to enclose the pair--something like backward square brackets--**]address=12 Main St.[bad-link: **</p><hr size=1><p>03 Dec 5 RustyM Value of Whitespace in outline node text</p><p>Unless I am missing some configuration fix, it seems that tkoutline is committed to the use of return key to define a new sibling node. I mourn the loss of a strategic formatting tool to make text more readable ...the blank line.</p><p>Rhetorical interlude: If one must give up the blank line which provides a human pause in thought (paragraph) when will we give up its kin the single space which is use to define words. What if I do not wish to automatically consign every pause and emphatic separation of thought to become a new outline node.</p><pre> Whitespace is a simple,valuable formatting item to make this wiki more readable:</pre><p># Lines of text are normally joined, with empty lines used to delineate paragraphs # Lines starting with three spaces, a "*", and another space are shown as bulleted items. The entire item must be entered as one line possibly wrapping).</p><p>In tkoutline,is there any way to emancipate the return key from its duty as the key for defining a new sibling node?</p><p>If the creation of a new node is a assignable function which leaves its legacy in immutable text features, what are those features in plain English? A node seems to be dictated by any newline, node position seems to be dictated by a tab count variable, which is inherited from the most recent value of the previous line/node.</p><p>Could we let a new node be defined by "any newline + some obscure key (configurable by the user)? If return key can be emancipated, are the parsing schemes for identifying nodes in export and import neutral about existing whitespace?</p><p>Much as I like tkoutline as a single pane composition of an outline, I am in mourning; but maybe I am only unaware of some configuration steps? RustyM</p><p>5Dec03 - [Brian Theado]**03 Dec 5 RustyM Value of Whitespace in outline node textUnless I am missing some configuration fix, it seems that tkoutline is committed to the use of return key to define a new sibling node. I mourn the loss of a strategic formatting tool to make text more readable ...the blank line.Rhetorical interlude: If one must give up the blank line which provides a human pause in thought (paragraph) when will we give up its kin the single space which is use to define words. What if I do not wish to automatically consign every pause and emphatic separation of thought to become a new outline node. Whitespace is a simple,valuable formatting item to make this wiki more readable:# Lines of text are normally joined, with empty lines used to delineate paragraphs # Lines starting with three spaces, a "*", and another space are shown as bulleted items. The entire item must be entered as one line possibly wrapping).In tkoutline,is there any way to emancipate the return key from its duty as the key for defining a new sibling node?If the creation of a new node is a assignable function which leaves its legacy in immutable text features, what are those features in plain English? A node seems to be dictated by any newline, node position seems to be dictated by a tab count variable, which is inherited from the most recent value of the previous line/node.Could we let a new node be defined by "any newline + some obscure key (configurable by the user)? If return key can be emancipated, are the parsing schemes for identifying nodes in export and import neutral about existing whitespace?Much as I like tkoutline as a single pane composition of an outline, I am in mourning; but maybe I am only unaware of some configuration steps? RustyM5Dec03 - [Brian Theado - There are two ways you can get vertical whitspace. Hopefully one of them will alleviate your mourning.
The first way is to use the undocumented <Control-b> keystroke. This will toggle the display of the bullet for the current node. If such a node has no text, then it will appear as a blank line. If you are already on a node for which the display of bullets is suppressed, then if you hit the return key the inserted sibling node will also have bullet display suppressed.
The second way is to redefine a key in the configuration file. Just change
*splitNodeKey: <Return>
to
*splitNodeKey: <Control-m>
This has the effect of getting the current <Return> key functionality of creating a new node only when you hit <Control-m>. Now when you hit <Return> it will actually insert a newline.
There are two problems with this second way. First, I just discovered when trying this out for myself that it doesn't work--a just discovered bug in version 0.92 is causing user defined keys in the configuration file to be ignored :(. The second problem is that when you do hit <Return> the new line doesn't have any indentation and you have to insert any horizontal whitespace yourself. If all you are after is vertical whitespace, then this is probably OK because you would leave it blank. There is a way to work around the first problem if you want to try it out to see how you like it. Hit <F2> to bring up the console window and type the following two commands:
event delete <<SplitNode>> event add <<SplitNode>> <Control-m>
FYI, the tree structure in tkoutline is not tied to any delimiters found in the text. There is a true tree data structure backing the outline.
5Dec03 RustyM
Thanks Brian for the rescue with F2 console. Way1 - gives relief just by removing the prominent bullet marks. I suppose if/when automatic numbering is invoked, the count will reflect all blank lines composing paragraphs along with all nodes in each level
That should be if/when automatic numbering is implemented as its not currently implemented - Brian
Way2 - the console accepted the redefinition commands OK - I noticed the lack of automatic indentation (as you mentioned)- but there was an additional bug behavior when hitting either delete key or backspace key to edit any line created under the new "regime". Either key would jump the cursor from the intended line to the corresponding column in the uppermost line/node above in the document .
I would guess there are also other problems too as I've never tried that before. - Brian
Re tkoutline data structure:I suppose that the data structure you are referring to is composed of the curly braces surrounding text phrases. I tried to follow those for a small outline and still could not understand the pattern clearly. For my brain I would be helped by seeing the file building on screen in real time according to the navigation/composition along with the stream of entered text keys. Or maybe the saved file is not the same as the processed file held in memory. RustyM
Depending on what you are trying to accomplish, I don't think understanding the file format will get you much. In memory the outline is stored as a tree object whose api can be read about at outline widget. The text found in each of these nodes are then displayed in a text widget. Are you trying to figure out ways to fix the vertical whitespace problem or understand tkoutline in general? - Brian
RustyM: above, I was only musing about general design and not that I have any skill to program any fix. About all I can do is describe my own problems with software tools and generalize to others (I believe that is called either projection or recruitment in psychologic terms) (I am posting another of my problems right now, but over on the maillist)