I would love to see support for Cocoa’s builtin key binding customization. In ~/Library/KeyBindings/DefaultKeyBinding.dict, I have the following:
{
“^w” = “selectWord:”;
“~f” = “moveWordForward:”;
“~b” = “moveWordBackward:”;
“~d” = “deleteWordForward:”;
“~\U001b” = “deleteWordBackward:”;
}
I use Opt-f, Opt-b, and Opt-delete constantly. Bike’s custom text system doesn’t appear to honor them.
As a partial step towards supporting more key bindings, I’d be thrilled to just have builtin support for these five:
“^w” = “selectWord:”;
“~f” = “moveWordForward:”;
“~b” = “moveWordBackward:”;
“~d” = “deleteWordForward:”;
“~\U001b” = “deleteWordBackward:”;
@Luke And actually I see your request wasn’t so much about outline mode. I think I should be able to get those shortcuts working sooner than outliner mode.
Edit This post was made by Jesse. I have no idea why it appears to be posted by Luke. Maybe a bug in forum software, or maybe I just am misreading the UI.
Outliners are near and dear to my heart (I’m one of the original co-authors of OmniOutliner).
Royalty! Welcome 
At time time, I used TextEdit.app as the gold standard for how the editing experience should work. It looks like you’re taking a similar approach and going even further with it. So fun!
That’s actually how I started TaskPaper. First just used TextEdit without any customizations to make up a syntax. Then use TextEdit source code and make little modifications to make the experience a little nicer… and then a huge amount of work to rewrite everything and give it an outline model.
Really looking forward to having all my favorite text editing shortcuts available in Bike.
I think this is fixed. The issue that I see was that I hadn’t implement the moveWordForward and moveWordBackward selectors, I was using the left/right ones.
I do think the select-word keybinding was already working though right?
@jessegrosjean Yep, it looks like it was just moveWordForward and moveWordBackward that were missing.
Thanks!
@jessegrosjean I’m not sure if this is a feature request or bug report. I’m leaning towards bug, but perhaps it’s debatable (and bugs are no fun), so let’s call it a feature request.
To me, Bike is doing something odd when I press Control-K. Apparently, this is something I do all the time without thinking about it to delete lines of text. In short, think it would be nice if Bike interpreted Control-K just like TextEdit does. Instead, it does something… curious.
If I have a Bike file with four lines:
|One <-- Using the pipe character to indicate cursor position
Two
Three
Four
…and I place the cursor at the beginning of the first line/row (“One”) and press Control-K, that deletes the text “One”, leaving the cursor on a blank line above “Two”:
| <-- cursor blinking here
Two
Three
Four
When I press Control-K a second time, I expect it to delete the blank line I’m on and pull up “Two”, resulting in this:
|Two
Three
Four
But instead, what happens is I get this:
| <-- cursor blinking on blank line
Three
Four
It deleted the newline at the end of the current line/row, and then it deleted all of the text up to the newline on the next row.
I’m doubtless a crusty crank, in that I still expect text editing to work more or less the same now as it did in NeXTSTEP long ago, but I’m not sure that Bike’s current behavior is necessarily “better” than how TextEdit (and the Cocoa text system in general) is handling this.
Maybe? Am I looking at this wrong?
And if you’ll forgive me double dipping and putting two things here, I noticed something else that was a tiny bit surprising about Control-O.
Given this outline:
One
|Two <-- Tabbed in one level, cursor blinking at the start of "Two"
Three
When I press Control-O, I “expect” (and here’s what might be silly) to get this:
One
| <-- Cursor blinking on blank line, tabbed in one level
Two
Three
But what I get is this:
One
| <-- Cursor blinking on blank line, tabbed in one level
Two <-- Note that "Two" is now on the same level as "One"
Three
I can see how this matches what TextEdit does, and it’s very literally correct if you think of the levels “just” as tabs, but it struck me as counterintuitive.
When I press Control-O to insert a new line, I’m not intending to change the level of the current line. Again, maybe I’m not thinking about this quite right, but somehow when I’m text editing in an outliner, I do want some subtle differences from “flat text editing”, and I think this might be one of them.
Or I can just learn to enjoy the new way. 
Ugh. The forum killed the “tabs” in my formatting. Hopefully the extra bits I wrote about the “level” of each line will provide enough context.
I agree on the behaviour of ctrl-k. In fact, it would be nice to have the Taskpaper “Item->Delete Items” function (cmd-k), as that’s quite useful
secondly, i tried to change the keyboard shortcut for Edit->Selection->Select Branch to cmd-b, but i couldn’t get the change to happen.
otherwise, really nice!
I’ll look into ctrl-k.
I don’t think I will add back TaskPaper’s Delete Items command. Instead I encourage you to escape to outline mode and then use delete key.
I understand isn’t quite as fast for each individual action, but I think the design is better overall. With an outliner there are lots of different actions where it makes sense to work at the item level. Instead of adding a specialized command for each my preference is to use outline mode for those things. It allows Bike to stay simpler overall I think.
Of course you can always implement TaskPaper’s Delete Items using scripting and assign a shortcut if that’s what is really needed.
outline mode is great. i had been ignoring it.
revisiting this, i am back to thinking that a ctrl-k command to delete a line would be useful in text mode.
in outline mode, deleting a line also deletes the children, which makes sense. but one also regularly moves children into other parents, and often this is most easily done by deleting a parent and letting the children slide up. i use ctrl-k all the time in taskpaper, more than i had realised until i didn’t have it in Bike.
Same goes for Duplicate. in text mode, it would be nice if duplicate only duplicated one line. As long as there are two modes, it would be good to have the text mode work more like a word processor.
I agree on duplicate and coming around to adding a delete row in text mode similar to TaskPaper. It’s on my list now, but still thinking. Yell at me in a month or two if you don’t see movement
Hey all, chiming in on this thread.
@jessegrosjean Love Bike and not surprised to see you coming up with another fantastic Mac app.
I also have some custom system keybindings that don’t work correctly in Bike. I can describe if helpful.
Good to see you, glad you are liking Bike.
Yes please do. I’m working on text system things this release and plan to investigate keybindings issues.
@jessegrosjean Tried to think of the best way to do this and I decided just to attach my keybindings file along with a list of a few hotkeys, most of which don’t work. A couple may clash with Bike’s own default hotkeys which obviously is not a problem. But some seem to fail because Bike actually interprets the keybinding intructions differently.
⌃a, a Wrap with <a href=""></a>
⌃o Select paragraph without line break
⌃u Delete paragraph
⌃w Select word
⌃k Copy paragraph
⌃d Duplicate paragraph
⌃‘ Delete character before paragraph
⌃, Delete character after paragraph
Thanks for taking a look!
I am always tinkering with keybindings and will probably create new ones in the future. Seems like many new creations would also break in Bike … 
DefaultKeyBinding.dict.zip (3.9 KB)
I think a part of the problem is that I haven’t implemented any of these mark commands:
- (void)setMark:(nullable id)sender;
- (void)deleteToMark:(nullable id)sender;
- (void)selectToMark:(nullable id)sender;
- (void)swapWithMark:(nullable id)sender;
I’m not sure exactly how they should behave and I can’t find any documentation. Can anyone point me in the right direction? I guess they are an extra selection point in addition to selections normal head/anchor points, but I don’t understand much more then that. Some questions:
setMarkedText and markedRange as used by the text input system, or are they separate.@jessegrosjean I don’t have much documentation, but I’ll share what I’ve got!
Archive.zip (536.7 KB)
@jackbrannen @luke @doug When you get a chance can you try the latest Bike Preview:
I’ve done a bunch of work on cocoa test system corner cases. Probably still some issues, but a lot of new things should now be working. Please let me know how it goes.
Way better. Thank you for your efforts!!