- Why does ⌥↵ quit the application?
- How does one add a new line to row?
macosxguru
‘add a new line to row’
I wonder if you are expecting some kind of ‘node with note’ model ?
A Bike document is a pure outline of nodes, in which you can create:
- a following sibling with
returnor ⌘↩ - and a child by indenting a following sibling.
To bisect an existing line into (prefix) parent and following (suffix) child, you can use ⇧↩ at a selected point in the line.
⌥↵
Looks like a keystroke that awaits implementation.
I am expecting a node with note. Similar to the TaskPaper New Note.
TaskPaper is a tab-indented text outline, and its ‘notes’ are, of course, just following lines at a higher level of indentation (and without a leading hyphen or trailling colon).
Bike is a pure outline too, with a native format (an HTML <ul> nest) which allows for an invisible layer (ids, attributes) as well as the visible text layer.
The text of each node is a single <p>, without any <br> line breaks – it can be long and folded, but not multi-line.
Are you essentially looking for a single keystroke which creates an indented child node after the current node ?
(new item followed by indent is the default pattern)
TaskPaper’s ^⌘↩ (New Note) doesn’t, of course, indent under the current line – it just makes a new line without any special hyphen or colon syntax – effectively a new sibling, rather than a child, of the preceding line (and not structurally attached to it, beyond good neighbourliness).
Perhaps New Item followed by Indent (or a shortcut which combines them), is what you are looking for, in the context of Bike ?
Thanks for the explanation.
If a node is incapable of being multi-line, it is a restriction on the structure of the writing that can take place in Bike.
Your suggestion of a New Item followed by Indent might be the way around the limitation of the design. It would be easier to use that if it is augmented with a keyboard shortcut.
Thanks for talking through this with me.
Do you think so ?
Are there any particular structures that feel intuitively excluded ?
If a node is incapable of being multi-line
Multi-line paragraphs are easily represented as a sequence of lines (just as in Taskpaper, and in Markdown too)
I find, in practice, that parent ⇄ child and sibling ⇄ sibling connection are the basis of all text structures.
FWIW I’ve sketched a fairly general draft script for Bike → Markdown (including continuous paragraphs, nested bullets, quotes and code snippets etc etc) here:
Draft demos: Copy As Markdown & Save As Markdown - Bike - Hog Bay Software Support
Thanks for reporting, that’s a bug, I’ve fixed for next release.
I agree that there’s a feature that outliners like OmniOutliner have that Bike does not have… the ability to attach an extra note directly to an existing item in a separate line. So one item, two lines.
This is a design choice (not just me being lazy… this time). I guess it can be limiting for some specific cases, but generally I don’t think it’s too limiting, and I think it’s a cleaner design overall to implement that sort of feature differently.
Instead of creating a special case “note” field for any item I would instead like to just use a new item type to represent notes. This is what TaskPaper does. The benefit here is uniformity, that note can now be edited/moved just like any other item. It’s a fully player in the editor, not hard coded special case.
To support this in Bike I need to support different item types. That’s definitely on the not too distant future list (much of the infrastructure is done), but it won’t be in 1.0 release. Eventually I expect a number of item types: headings, separators, notes, etc.
Once that’s in place (and stylesheets) then you’ll be able to have a note item and it can have it’s own formatting rules (font, color, etc). I think that’s the end goal you are looking for? If you still think the design needs work let me know.
1 Like
To support this in Bike I need to support different item types. That’s definitely on the not too distant future list (much of the infrastructure is done), but it won’t be in 1.0 release. Eventually I expect a number of item types: headings, separators, notes, etc.
Once that’s in place (and stylesheets) then you’ll be able to have a note item and it can have it’s own formatting rules (font, color, etc). I think that’s the end goal you are looking for?
That will be perfect. Looking forward to it.
1 Like
I think that works very well – perhaps memories of email apps (or paper-clipped bunches of sheets with yellow post-it notes on top ?) are responsible for that uncomfortably (and rather oddly ?) constraining approach of outlineable header lines with non-outlineable flat text notes ‘attached’ to them.
1 Like