Bike 1.7 Preview (90)

I just tested on Monterey and I got it working there too.

For you are any of the autocorrect, text replacement, text substitution features working? For example will smart dashes work?

I did notice that by default Bike’s settings didn’t match system settings. So you need to go into Bike’s check panel and check all the options that you want. Here’s what my system and Bike preferences look like to get it working on Monterey.

First glance feels great! I love the look and feel and functionality of the blue and red lines. I love that the blue lines disappear after moving on to the next sentence, and I love that if I select some text, a light blue lines reappear. Really well thought out.

1 Like

I just realized that “Dash Replacements” translate ... into a single character , that’s in addition to translating -- into . For efficiency I need to hardcode these values instead of running the checking mechanism everything … does anyone know of any other sequences that “Dash Replacements” replaces?

Same question for smart quotes. Now I am checking only for " and ', does smart quotes smarten up any other sequences?

It was my screwup. I did not have Spelling checked in the Bike’s checking panel. My bad.

It works fine.

macosxguru

Great to hear! I think I can clear things for future by disabling autocorrect checkbox in case when spelling isn’t selected.

I used it all day yesterday and it worked beautifully. I love the refinements of how the different elements work, especially the persistent autocorrect underlines for the whole sentence, the collection of all auto-correct related options in the Checking panel, and how Bike handles default settings. Really nice!

1 Like

Any good sources or links for finding out what those are,
and how we might test them ? :slight_smile:

Ha, not really! Or not exactly as implemented.

The background as I understand it is that before we had selection ranges in graphical text editors we had point and mark in console based text editors. So to do something with a range of text you needed to set the mark, position the point, and then perform the command.

And in same text editors people wanted to undo or move text, and they did that by putting deleted text into the kill ring, and if you wanted to get it back you would use yank commands.

From that history a very specific implementation of these ideas exists in the cocoa’s text system, not well documented. I think the primary reason why you might uses (and why I bothered adding to Bike) is because these are convenient (or at least common) features to use when building custom keybindings.

For example save the XML at the end of this post to this path:

~/Library/Keybindings/DefaultKeyBinding.plist:

Then restart TextEdit and Bike and then:

  1. Select some text
  2. Press and release Control-a
  3. Enter character (

And the selected text will be wrapped in ().

To make it all work it’s important that Bike’s commands have the exact same behavior as TextEdits. So most of the work was trying to understand and copy the not well documented default behavior.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>^a</key>
    <dict>
        <key>(</key>
        <array>
            <string>delete:</string>
            <string>insertText:</string>
            <string>( </string>
            <string>deleteBackward:</string>
            <string>yank:</string>
            <string>insertText:</string>
            <string> </string>
            <string>moveLeft:</string>
            <string>insertText:</string>
            <string>)</string>
            <string>deleteForward:</string>
        </array>
    </dict>
</dict>
</plist>
1 Like

Perhaps, looking at your plist code, ^a ?

(that seems to work here)

The extension I need here seems to be .plist

(rather than .dict)

Given that change of path, and using ^a, it works well …

(In both Bike and TextEdit)

Interesting and impressive …

Oops, yes, fixed now.

The extension I need here seems to be .plist

Odd, for me .dict does seem to be working. Though plist is probably more appropriate. I’ll change that above too.

1 Like

Yeah, I never knew Macs custom keybindings could do multiple commands in a single binding. Also didn’t know they could recognize sequences over time.

I wish I could plug into that system and enable different sets of bindings. For example different sets of bindings when in outline mode. So far I haven’t figured out how to do that, seems like they are read on app startup and not changeable after.

1 Like

This might be of interest to you. KeyBindings - BrettTerpstra.com

macosxguru

2 Likes

Great changes overall – with one major exception. :frowning: I find this behavior to be quite problematic:

Instead of avoiding autocorrects Bike makes them easy to undo. You can undo an autocorrect with a single Delete keystroke, instead of doing the two key Right Arrow, then Left Arrow dance to avoid like in TextEdit.

Since…

Bike autocorrect runs anytime you finish a word while typing text.

…it means that typing the space character after any word will trigger autocorrect. If I hit Delete then, it’s unclear what I actually mean – do I want to cancel autocorrection? Or do I want to remove the space character because I’ve forgotten to place a comma after the last word? Of course, instead of using Delete I could use the Left arrow key to move the cursor, insert the missing comma, then go back with Right arrow key – but that’s not what most people I know would do, myself included. I doubt I can retrain my brain just for one app.

This gets even worse if - as in my case - most of autocorrect results are expected which means that in most cases I really do want to delete the last character and not cancel autocorrecting.

I guess I’d prefer being able to use Cmd-Z – solved better than in TextEdit? only cancel autocorrect (i.e. once Bike autocorrects after I pressed space, I can hit Cmd-Z to cancel autocorrect, then hit Cmd-Z again to undo recent text operations)?

Thanks for taking a look!

This is true except it doesn’t come into play when typing space after any word, it’s only when typing space after a word that is incorrect and then gets autocorrected. This case is clearly indicated because the previous word will have a blue underline.

I agree it’s still an odd UI state, but for my own use it doesn’t come up that often and when it does I see it clearly indicated.

Few thoughts on a fix:

  1. I’m happy to make this delete shortcut an option in preferences.
  2. You can already use Command-Z to undo the last correction. The behavior is better than text edit since it only undoes the correction, it doesn’t undo the text that you entered to cause the correction. This doesn’t solve the problem with delete, I just mean undo is already implemented.
  3. Before I make any changes can you try out Google Docs and see if you run into the same problem there? That’s where I got the idea for Delete to undo a correction. I think Bike acts the same way, but maybe the do something to avoid this problem?

I agree it’s still an odd UI state, but for my own use it doesn’t come up that often and when it does I see it clearly indicated.

You’re right about the frequency in English, I haven’t noticed that state when writing down my outlines in EN. Once I switched to Polish (or even German) though, my frustration began to grow. There are way more commas in use there, I think.

  1. I’m happy to make this delete shortcut an option in preferences.

I’d love that. Thanks!

You can already use Command-Z to undo the last correction

This is excellent, works exactly like I would expect standard apps to work like! I should have tested it myself, sorry.

That’s where I got the idea for Delete to undo a correction. I think Bike acts the same way

I didn’t know that. Indeed, it seems to be the same behavior and I don’t like in Google Docs either :wink:

1 Like

Thanks for trying it there. I’ll make it a preference then.

1 Like

One more thought… maybe you already know, but autocorrect happens when you end a word in any manner, not just when you end with a space. So if you enter a comma to start with then autocorrect will run and you won’t need to go back and add the comma.

I’ll still make delete to revert the autocorrect an option, just wanted to be sure you knew that you didn’t need to add space if you really wanted to have a comma.

if you enter a comma to start with then autocorrect will run and you won’t need to go back and add the comma

Yup, thanks. My problem affects cases where I forgot to put comma (or quickly decided to begin a subordinate clause which has to be separated by a comma).

Actually I was wrong. For me the above only works if I use .dict. Maybe a Ventura difference? I have no idea, but only dict seems to work for me with the above text.

1 Like

An older macOS here – 11.7, so perhaps a .plist.dict change in one of the intervening versions ?