The match is fuzzy, for for example to match “Hello World” you can type “hw”
Keyboard shortcut is Command-P to match with what many code editors use
Go Home can now be replaced by Command-P followed by Enter.
After a few days of flailing around implementing my own slow version I decided to use the incredibly fast nucleo rust crate for the matching and scoring. It’s fast!
I did notice a possible regression from before, with links in the document – I can’t seem to make the “directional caret” appear for plain links pasted directly into an outline:
They do appear if I linkify some text, or eg. make something bold. But at the end of a line like the one above, if I press the right arrow the cursor moves directly to the next line.
I think this is correct behavior, because that is a “syntax highlighted” link. So there’s no associated attribute run to insert into. Instead the link is just being computed from the text content. Hope that makes sense.
Ah, thanks for explaining – I think it does. I had a mental model that if I pressed space and continued to type it would “extend the link”, but I see it just jumps the cursor out of the link and after the little arrow icon. Thanks!
I ran into this when trying to “move past the arrow icon” by pressing my right arrow key, but that would always jump me down to the next line, which is different from the other kind of links, and is why I thought something was up.
Edit: btw, just wanted to say that I really like the directional caret idea; it is always fun to see a new solution to an old problem like that, and it works very well in practice.
If some of your blank lines are habitually ending up flagged as having a header type, you could assign a keystroke to a clean-up script. (Setting all blank header lines to the default body type).
Something, for example, like:
tell application "Bike"
set doc to front document
if doc exists then
tell (rows of doc where its type is heading and its name is "")
set n to count
if 0 < n then
set its type to body
(n as string) & " blank rows set to body type."
else
"No blank header rows found."
end if
end tell
else
"No document open in Bike."
end if
end tell
(() => {
"use strict";
// Set the type of any empty heading rows in a Bike
// document to "body".
// ('empty' is interpreted as either no characters, or
// only space characters).
// Heading lines containing only spaces are trimmed,
// as well as reset to `body`)
// @RobTrew 2023
// Ver 0.01
const doc = Application("Bike").documents.at(0);
return doc.exists()
? (() => {
const
nBlankHeads = doc.rows.where({
_match: [
ObjectSpecifier().type,
"heading"
]
})()
.reduce(
(n, row) => "" === row.name().trim()
? (
row.type = "body",
row.name = "",
1 + n
)
: n,
0
);
return 0 < nBlankHeads
? `${nBlankHeads} blank headings set to body type.`
: `No empty headings found in "${doc.name()}".`;
})()
: "No documents open in Bike";
})();
You’re correct. Your proposed solution seems reasonable.
I also belatedly learned that I can just put the cursor at the start of the row and hit backspace to reset the row type to body—which is exactly what I was looking for when I posted the question (a keyboard shortcut to clear row type formatting). Sorry I missed it.
This took a while, but Bike 148 adds settings for choice views such as “Focus Heading”. Each different choice view can have different settings. So you can customize “Focus Heading” one way and customize a future (not yet implemented) “Link Row” choice view differently.
The settings consist of a display mode and an outline path to select the initial rows.
The display mode is either list or outline.
List is flat and matches are sorted by how closely they match the search. I think this flattened list is best when you have many rows that you are filtering and when you are not quite sure where you are going (because all the best matches show together). Another advantage of list is that you match against the entire path to root for each row, not just the row text.
Outline display mode shows results in outline order with indentation. This means it easier to understand the outline context of the results. I think this view is better for smaller lists that you might also want to browse via arrow keys without even filtering. For example this is the default view for “Focus Heading”. When you search the tree is filtered, but not reordered. Then the highest quality match is selected. Sometimes this works well, at other times it’s maybe a bit to jumpy when it scrolls to the highest quality match. Maybe I should take that part out … and just always select first match. Any thoughts?
The second goal is to allow you to configure what rows are show for each choice view. I’m doing that with an outline path… which I didn’t intend to work on this release, and which isn’t really done. But it seems good enough for this rather corner case. I’ll expand on it in Bike 1.15. I’m hoping that it’s easy enough to hack at to handle some of the cases that have come up.
The default “Focus Heading” settings path is:
//@type = "heading" or @level <= 1/ancestor-or-self::*
This has the effect of including any heading row, any level one row, and all ancestors of those matching rows in the set of initial rows. If you instead would like to also include level 2 rows in your “Focus Heading” list you can change @level <= 1 to @level <= 2 in the above query.
I thought I had done this… and in some cases you can see more rows (for example outline view), but maybe still need bigger?
Just had an unrelated suggestion: Could the auto-strikethrough on task row types be turn-off-able? For my eyes, it’s a bit tough to read the items I’ve crossed off my list.
Yes, I agree, the strikethough is too much. As you note: not possible to read what the item was that was completed. I’d love it if “complete” offered an option to just turn the text gray instead of standard black. Then we’d know the item was done and wha the item was.
Currently I highligh all undone items. Then when an item is done I unhighlight it. Works decently well for me, but a better way to conver a finished task would be better.
thank you !