Bike 2.0 (Preview 219)

[jessegrosjean]

• Added fetch (fetch permission) API
• Added outlineEditor.observeSelection API
• Added window.observeCurrentOutlineEditor API
• Added more editor API for folding and focus testing
• Changed some fields in outlineEditor.selection
• Removed network access in DOMScripts (fetch should always fail)

I have added an example inspector item to the @Bike extension that puts these
changes together. To try it out fully select a word in your outline. You should
see a list of synonyms show in the inspector. Dig into the @Bike extension to
see how it works… but the basic idea is fetch happens in the app context and requires the fetch permission. It sends results to the DOMScript context.

Next step, when you click on a synonym it should replace the selected word in outline.

Questions welcome!

Download:

• Downloads
• Extensions API

[complexpoint]

Am I right in thinking that in Preview 219 Go > Open link ⇧⌘O (and clicking on link icons) are asleep for the moment ?

[jessegrosjean]

Yes, lots of UI still not connected. Also find panel. Context menus, etc.

[jessegrosjean]

Just had a thought… in recent release I also added API for URL.open. Should be possible to implement Open Link in extension code now.

[complexpoint]

Good exercise for experimentation – I’ll try : -)

---

UPDATE

I like the synonyms example in (Preview 219 > Show Inspector > select word)

---

Defined in:

Preview 219 > Bike > Extensions... > @Bike/src/main.ts >
bikeObserveWindows > fetchSynonymsAndPostToDOM

[complexpoint]

Looking at Creating Extensions | Bike, and just checking that I have understood which string values are valid for the source key in:

• .addCommands
• .addKeyBinding

these are essentially the name of the source extension, without the @ prefix ?

(I notice, in the example, that the CommandSource value in the example starts with a capital letter, while the KeybindingSource value is all lower case. Should we follow that pattern, or is the value matching case-insensitive ?)

---

A separate question: is there any way of listing the keybindings (and commands) that are currently defined by JS extensions in a given context (editor or dom) ?

I am finding, with the rough draft @Startup below:

Expand disclosure triangle to view TS source

import { AppExtensionContext } from "bike";


function toggleCollapseCommand(): boolean {
    const
        editor = bike.frontmostOutlineEditor,
        selnRows = editor?.selection!.rows;

    return selnRows
        ? (
            // Effect
            editor.isCollapsed(selnRows[0])
                ? editor.expand(selnRows, "completely")
                : editor.collapse(selnRows, "row"),
            // Value
            true
        )
        : false;
};

export function activate(context: AppExtensionContext) {
    bike.commands.addCommands({
        source: "startup",
        commands: {
            "startup:toggle-collapse": toggleCollapseCommand
        }
    });

    bike.keybindings.addKeybindings({
        keymap: "block-mode",
        source: "startup",
        keybindings: {
            "t c": "startup:toggle-collapse",
        }
    });

    // bike.keybindings.addKeybindings({
    //     keymap: "text-mode",
    //     source: "startup",
    //     keybindings: {
    //         "cmd+e": "startup:toggle-collapse",
    //     }
    // });

    console.log("Defined ?")
}

That I can trigger startup:toggle-collapse either:

1. in the Safari console with bike.commands.performCommand("startup:toggle-collapse"), or
2. in Bike 2 Preview (219) block mode with t c,

but I don’t seem to be succeeding in binding a key to it text mode (see .addKeyBindings snippet commented out in the draft above).

Not sure whether this is because toggling collapse is more a block mode operation than a text mode edit, or whether I am just getting something else wrong.

[Gorgonzola]

This added sidebar view had me thinking…is it possible to build a calendar view with this that would work in conjunction with the Today shortcut flow? Basically a calendar picker for the corresponding day row?

[jessegrosjean]

@complexpoint

source keys … these are essentially the name of the source extension, without the @ prefix ?

That’s a good default, and probably all you need for now.

Looking at these API after a week away I think I let some duplication slip in. In particularly I added the “source” params first, and then later added keymap to the keybinding API. Not sure they are both needed.

The general idea with this string ids is…

The default behavior when adding things via the extension API is to return a Disposable. That’s your handle to the item, only way to reference it.

In the case of keybindings I don’t think that’s enough. For example you might want to build a “mode” style behavior where a particular set of commands or keybindings is active. You might also want multiple extensions to contribute commands/keybindings to this mode. That’s not possible if the only handle to a set of keybindings/commands is a Disposable instance. So instead use source/keymap as a way to group those items.

I think that makes sense in big picture. But to this point I haven’t really had the need to use the details of these API, so it’s a bit difficult to know what parts are needed or not needed.

Noted that I need to explore this a bit further.

[jessegrosjean]

@complexpoint

A separate question: is there any way of listing the keybindings (and commands) that are currently defined by JS extensions in a given context (editor or dom) ?

Unfortunately not yet, but needed I agree.

For now I recommend always opening the entire Extensions folder when creating an extension. And then at least you can search for API calls to see where things are added. At this point I am not adding any native keybindings or commands… all the calls should be made by code in that extensions folder.

@complexpoint

but I don’t seem to be succeeding in binding a key to it text mode (see .addKeyBindings snippet commented out in the draft above).

Sorry, two issues that I see. A bug in (bike) code and a bug in documentation. For now I think it should work if you change cmd+e to command-e.

[jessegrosjean]

@Gorgonzola

This added sidebar view had me thinking…is it possible to build a calendar view with this that would work in conjunction with the Today shortcut flow? Basically a calendar picker for the corresponding day row?

Yes, I think that fits well into what I want extensions to be able to do and I think it could be done with current API’s though I haven’t actually built yet.

I think there are two main calendar view types that could be useful.

1. A calendar like you propose, where a calendar presents a different view of “Today/Calendar” outline structure.
2. A calendar that displays the results of a query. For example show me all “due” rows in my outline … adding calendar event for each due date.

I think there are many possible views like this, that will present a different view of your outline such as Kanban, MindMap, Timeline, plus visualizations such as graph layout, treemap, table.

I think the UI for many of these views can be quit cleanly done by adding a new sidebar item and when you click that item present the new view as a sheet.

Edit

Adding a bit more on different view types I can imagine. For the inspector bar I imagine views that update based on “current” whatever that current might be. For example they might show information about the current word, row, or outline. As example synonyms or definition for current word, backlinks of current row, count summaries of current outline.

Another view category is process views. For example I’ve long wanted to add a way to “publish” an outline into a flatter HTML structure. But adding something like that to the core of my apps never felt quite right… there are many ways/cusotmizations you might want to have.

On the other hand in Bike 2 I think it should be possible to create a nice “Publish” command that will open a sheet that transforms your outline into a flatter HTML document and provides a live preview that you could copy elsewhere or post to come blog service.

---

I hope that over time as I/we explore these views we can build up a library of extension reusable code that I will include with Bike. Simple things like a date picker or more complex things like a web based text editor that can edit Bike row text while preserving attributes. Maybe higher level messages so that it’s easier to post and sync data between the app context and the DOM context. Anyway those are all long term goals, for now goal is just to think of ideas an see if they will work or not with current API.

[Gorgonzola]

@jessegrosjean

I hope that over time as I/we explore these views we can build up a library of extension reusable code that I will include with Bike.

Sounds a bit like different EMacs distributions

@jessegrosjean

I think there are many possible views like this, that will present a different view of your outline such as Kanban, MindMap, Timeline, plus visualizations such as graph layout, treemap, table.

I think the UI for many of these views can be quit cleanly done by adding a new sidebar item and when you click that item present the new view as a sheet.

Hmm…some thoughts re: our conversation about row versioning. Maybe a version of the row (i.e. its content) could be the value of a @version-1/2/3 attribute itself, and then a sidebar view could pull out those versions and show them? I’m only thinking about this because Bike doesn’t seem to have a problem with keeping OPML notes from OmniOoutliner as a _note attribute, and those are only visible in the Outline path explorer. Another interesting thing would be to see diffs between versions in that sidebar view.

I’ve also been thinking about the way for example Scrivener takes snapshots of documents, which is kind of like versioning. Maybe rows could be exported into a different file, and the sidebar view would be able to pull up those rows in the sidebar based on the original row’s unique ID. What would also really be cool is if this way, there would be an option for a .bikeproject package file that contains everything inside it to make portability/git easier.

Anyway, just throwing some stuff out there, it’s probably not feasible. I do like this idea of being able to expand Bike into a production workspace you can do a whole writing project in.