Sure. Anytime I work on anything else than a first draft, I’m frequently shuffling things around, a lot of times it ends up being multiple paragraphs, or parts of them combined with others: Character dialogue, pacing etc, but mostly it has to do with cutting stuff out rather than rearranging. Other times it’s combining ideas split between paragraphs. It gets annoying when I’m constrained to whole blocks when selecting. One wrong move and your whole selection is gone 
1 Like
Fascinating. I’ve never even considered using Bike for long-form text like this! 
I didn’t use any outliners before Bike. But discovering it made me realise that when using Markdown editors, a very large portion of my time was spent making lists - as that’s just the way I like to structure my thoughts. And then obviously a dedicated outliner is way better at this!
Now, I’m not saying “you’re using it wrong!”, because I totally get the urge to use Bike for everything - as it’s just that good. 
And I absolutely think you should voice the concerns related to your workflows. But I guess it’s a bit like the podcasters who edit their shows in Logic: It does work, and perhaps even well - but as it’s not the main use case for the app, there might be changes that prioritise the main use case above niche ones.
(You didn’t ask - but lately I’ve been using what I’d call “The Bike of Markdown editors” 
: Paper. It’s too expensive, but the free version is very generous. And it’s a small developer also needing support, so buying it is a good thing as well. 
It’s more minimalistic than long-form mainstays like (the also great) Ulysses and iA Writer. So if your do end up being disrupted by Bike 2.0, I’d take a look in that direction! I use Bike alongside Markdown editors, so it’s not either-or. 
)
I do actually want to make Bike work for this use case, long form writing.
In my mind an outliner is a more powerful text editor. It should work for writing long documents. It will have a different feel than more standard writing tools, but it should work. And in some ways it should work better I think.
In current form it’s missing some somewhat major things. I think for example a sidebar index for navigation would really help for long documents. Also some publishing mechanism to process an outline into a sharable document. All those are down the road post 2.0.
Lots to explore here – I really like the power and flexibility of this stylesheet design.
A minor quirk for testers is that the version 2.0 demo, sharing a bundle ID with Bike 1.0, turns out – at least on this system, if you install the demo to /Applications – to become the default target of any script which writes:
Application("Bike")in JS, ortell application "Bike"in AppleScript
I think ways around it, while we’re exploring the demo, may include:
- testing the demo from some folder other than
/Applications/, or - specifying a full path to Bike 1, for example with:
Application("/Applications/Bike.app")
2 Likes
Huh, that’s interesting. I can absolutely can see the possibility, though!
For instance, one thing I like about Ulysses is how easy it is to move parts around - and Bike is obviously also good at that. And I always like my text editors to support folding (like NotePlan and, ofc., FoldingText), which outliners also does.
And while Bike only support one header level (at the moment), I suppose you could indent to simulate the other levels - and that this also could work on export.
I agree that it’s a good long-term goal to have it work well for long-form writing. But in a world with lots of competition and limited dev resources I think it’s smarter to focus on the stuff that makes Bike (and outliners) unique (which I feel like you’re doing, btw!), instead of making sure it also does all the stuff Ulysses (and so many others) already do, if you know what I mean.
Now I’m absolutely an “outliner novice”, and not an “Outliner purist” who’s saying “Outliners should only do this, and not that!”. But to give a concrete example, I know that handling of media (images etc.) is on your radar. And if it was to be a serious contender for long-form writing, this is obviously needed. But I don’t mind it not being at the top of the prioritiy list, because there’s already tons of apps I can use for academic writing or blog posts. And as you already have tons of great ideas for features that these apps don’t have, I’d rather see you focus on them (see, Bike 2.0! ).
An arbitrary number, already defined, as you say, by indentation.
See, for example: Blog post: Scientific refereeing using Bike Outliner - Bike Outliner - Hog Bay Software Support
and particularly:
Absolute vs. relative hierarchy in document markup languages
it is the context of a node that determines what its level in the hierarchy is, not the node itself.
i.e. to be a header of level N is not a quality of the row itself – it’s a (nesting) relationship to other rows, and to the scope of the subdocument which you are considering or using.
Once Bike has flagged a row as a header, its effective level depends on:
- where it is,
- what sub-outline / sub-document you are extracting,
- and what you are defining as the outermost starting level for the purposes of formatting that sub-document, for a specific use.
(and, in the Bike 2.0 stylesheet system, you will be able to define different visual styles for data-type="heading" rows at different levels of nesting).
1 Like
Here’s one way you could do that:
defineRowRule(".heading count(ancestor::*) = 2", (env, row) => {
row.color = Color.systemGreen()
})
I’m just heading off now for kids spring vacation road trip (9 days). Will be checking in, but intermittently.
2 Likes
Cool! Does that re-contextualise as you focus in/out?
That’s very interesting, @complexpoint ! And especially this, as you say 
I’m not trying to come off as a downer here! As mentioned, I want to use Bike for as much as possible. And I’m usually the guy who expects too much of software, and sometimes wants stuff to be more than the creator might want it to be, heh. And perhaps I’ve been a bit too narrow in my view of what an outliner can do, influenced by stuff like what Omni Group says about theirs.
But I’d love it if Bike was a great place for long-form writing, as well as structuring ideas, etc. - so I don’t want to come off as I’m trying to limit that!
But in that case, I’m not sure the change that takes away the possibility of marking text in different rows, without marking everything, is a good one… You know, the thing from @Gorgonzola that started it all. 
Because that makes it a better (traditional) outliner, but at the expense of more classical long-form writing.
Writing already works superbly in Bike. It’s what drew me to it in the first place: the fluid animation and snappy feel, typing affinity… Everything added afterward, e.g. the ability to hide basically the whole UI when writing was icing on top. But longform editing is a different beast and this is precisely why I think block editing is a step backward 
But I think we may disagree on a political level: I don’t share the opinion that using Bike is hard 
, and I loved having two distinct options of working the outline.
Thanks, I know about Paper, but I can’t find a use case for it. I already own iA Writer and Ulysses, and I really need a document library, I hate working with files. Bike is an exception here because it’s so good 
Hah, yeah - I feel exactly the same! So much so, that I made a large shortcut, to make it easier to use Bike as my document library (both creating files from it, and linking other files to it). 
My thought process was the following:
- I like Bike so much, that I want to use it even though I have to deal with files.
- But then I have to do some stuff to make dealing with files better for me.
- And then maybe I should have my main Markdown editor also be files based, so I’m all the way into files again? (Hence Paper.)
I’ve also adapted a ruby script that automatically tags my Markdown and Bike documents with native Finder tags if I write something on top of my documents.
1 Like
I am interested to see how this develops as well. I downloaded the 2.0 beta but almost immediately gave up on it, as it’s too unfinished for me personally to mess around with at this time, since I use Bike for work stuff. Maybe if I were on vacation!
I just wanted to vociferously echo the plea to keep the current (what I would think of as “normal”) behavior of selecting text. I would like to preserve the ability to select whatever random little old fragment of text I want, just as I do in any other editor. What the relationship between this and the ultimate decision about modes is, I am not savvy enough to predict or weigh in on. I love almost all of Bike’s current idiosyncrasies (with the major exception of those infernal squiggly marks every time I make curly quotes), but I’m afraid if we deviate too far from established text-editor behaviors, it might start getting too confusing and ultimately frustrating to be used full time without extra mental overhead.
I don’t think so
Possibly a slight misunderstanding ?
( not a beta - just a demo of a couple of things - particularly of a flexible approach to defining display styles )
Right, sorry for the imprecise vocab. In any case, I just wanted to voice concern about text selection’s behavior possibly changing.
I wonder if I am missing something here ?
When I select text, it tends either to be:
- within a row – part, but not all, of the row text. Moving a word or clause for example, OR
- One or more whole rows. (Moving some rows to a new position, for example)
What I don’t find myself doing is selecting across row boundaries …
I can’t immediately imagine, for example, selecting the lower half of one row, and the top half of the next row.
Can anyone explain a use case in which they feel that that might arise in their rough drafting or restructuring ?
Wouldn’t it just be a symptom of the document’s segmentation failing to match its meaning ? A case of needing a simple row split keystroke ( 
) , or perhaps row join ( ⌫ ), in other words, rather than an exotic selection ?
Have users of OmniOutliner, for example, complained that such half and half selections (across row boundaries) are frustrated ?
(I don’t think I’ve ever noticed any discussion of that kind …)
Yes. Shortening a point made across two paragraphs into a single paragraph for brevity and moving from abstraction to concreteness. Or taking one piece of narrative/dialogue and placing it somewhere else.
Those are certainly core elements of outlining:
- subsuming the expansive under the pruned or abstracted
- repositioning elements
but neither of those seem to have an obvious connection with selecting the latter half of one row and the first half of another …
Can you help me with an example or two ?
Are we talking about merging rows ? Splitting them ?
Are you thinking of an operation which is impossible, or incurs more friction, in something like OmniOutliner ?
- Splitting a row into two rows (at the cursor point)
- merging two adjacent rows into one
both of these are, I notice, easier in Bike 1 than in omniOutliner.
Splitting:
- In Bike 1 we hit a simple return ( )
- in omniOutliner it has to be control-return ( ^↩ )
Merging:
- With cursor at the start of the second line, in Bike 1 we hit backspace ( ⌫ )
- In omniOutliner, that needs to be control-backspace (^⌫)
(More burden on memory – less intuitive – frustrating if you have to look it up)
I’m not sure we’re talking about the same issue.
Bike v1:
vs. Craft (block editing)
This is only one sentence. Imagine how many of these come up in a 100k+ word draft.
how many of these
these refers to splits ?
Can you describe the friction you are aiming to represent with those videos ?
Without words it may not be quite as clear to an observer as it is clearly self-evident to you.
It looks as if your point may be about splitting, but I am not yet sure …
No, in this example it’s actually merging two adjacent rows, but performing that merge by cutting out a selection of text spanning both rows, to be pasted elsewhere (or removed altogether). In my example it only includes the dialogue quotation mark in the second row, but that can vary from a single character to a few full sentences. This may be specific to editing prose.
2 Likes