Bike 2.0 Split/Join Demo

[jessegrosjean]

I encourage you to read about the original Bike 2.0 Selection Demo for context:

Bike 2.0 Selection Demo

I encourage you to read about the original Bike 2.0 Demo for context: The biggest question raised there concerned Bike 2’s selection model. The change is (like in 1.0) you can select individual text characters within a row, but (unlike 2.0) when you extend the selection beyond a single row you start selecting at the row level. How to try the change The previous 2 demo was mostly concerned with getting something out the door and demonstrating stylesheets. The actual implementation of selecti…

This demo shows two things:

1. Fixes a lot of inconsistencies in selection model (let me know if you find more)
2. Adds first iteration on split/join commands

To try it:

1. Download Bike 2.0 Split/Join Demo
2. Launch App
3. Open existing document
4. Make some selections (Inconsistencies brought up in selection demo should be fixed)
5. Then try join/split

Join (Control-Command-Delete)

If you have multiple rows selected the trailing rows will be removed and their text is appended to first selected row.

If you have a single row selected then the next visible row will be removed and joined with the single row. Once nice thing about the single row case is your selection is preserved. You can do repeated joins, undo, all without really loosing your place.

Split (Control-Command-Return)

I think join is quite useful as is. Split is interesting, hopefully useful, but I’m not sure. Let me know if you have suggestions for improvement.

It comes in three flavors:

1. If you have a text caret then it works just the same as pressing Return
2. If you have a text selection then it splits the row into three rows: prefix, selection, suffix.
3. If you have a block selection then each selected row is split at sentence boundaries

Let me know what you think.

I think next demo will be to add outline filtering.

Then it will be time to get serious and start adding back Bike 1.0 UI and generally making Bike 2.0 a real app. I expect this will take some time.

[complexpoint]

I find this split very useful – not least the 3rd flavour:

(from block selection → sentence-delimited rows)

[Gorgonzola]

I notice with this version, Shift+CMD+Left/Right doesn’t extend to new lines anymore after the initial press.

Also, if I do Shift+CMD+Up/Down, it jumps straight into outline mode (doesn’t let me select text until end of row, which is the same as in Selection demo (207)), but now I don’t have a good way to select text from caret until end of row. I think this is then inconsistent with reversing the process: If I Shift+CMD+Down, and then Shift+CMD+Up, I now have a selection from initial caret position until end of row. From here I can Shift+CMD+Left, and it will incrementally reduce selection line-by-line until it jumps around the caret; after that, I can’t make line selections anymore.

I think it should work like this:

• Shift+CMD+Up/Down selects from caret until end/beginning of row; doesn’t jump straight into block selection
• Shift+CMD+Left/Right should extend/reduce selection by line as it was in 207. It should allow to select until end/beginning of row, the next iteration brings it into block mode. Reverse should be the same.

Also, CMD+A now selects entire row text, then jumps straight into select all blocks. I wonder if there should be a middle step in here, which initially selects just the row, so like this:

1. Select all text in row
2. Select row as block
3. Select entire outline as blocks

I think this is consistent with other selection behaviour when you reach end of row: 1. select text, 2. select row, 3. extend selection of rows.

This is how Craft functions. Zavala doesn’t even allow for that kind of text/block level jump without manually going into block mode first via ESC. Not sure about other apps.

As for Split/Join, they are useful tools for sure. It’s an added layer of flexibility that’s welcome. But I would struggle to find a use case for it in my work at this stage. It’s different from other editors and I think it’s something that takes a bit of practice and consistency to incorporate into a workflow.

[jessegrosjean]

@Gorgonzola

I notice with this version, Shift+CMD+Left/Right doesn’t extend to new lines anymore after the initial press.

I think that was a bug and current behavior is correct? Generally Command+Left/Right is supposed to move to visual line ends, but not beyond them. I think with Shift held down it should have same behavior.

@Gorgonzola

Also, if I do Shift+CMD+Up/Down, it jumps straight into outline mode (doesn’t let me select text until end of row, which is the same as in Selection demo (207)), but now I don’t have a good way to select text from caret until end of row.

I think the standard way to select to the start/end of paragraph is Shift+Option+Up/Down and Bike supports that. I think I also agree with you that in Bike’s new text extends to outline selection model Shift+Command+Up/Down should do the same thing.

@Gorgonzola

I think it should work like this:

1. Shift+CMD+Up/Down selects from caret until end/beginning of row; doesn’t jump straight into block selection
2. Shift+CMD+Left/Right should extend/reduce selection by line as it was in 207. It should allow to select until end/beginning of row, the next iteration brings it into block mode. Reverse should be the same.
3. Also, CMD+A now selects entire row text, then jumps straight into select all blocks…

This is tricky, but I think worth getting consistent and right. Thanks for your continued experimentation.

I think I agree with your #1 and will change that.

I also think I agree with #3

I’m not sure about #2, anyone else have thoughts?

I think the “standard” macOS behavior is what is currently implemented. In TextEdit the Command+Left/Right movement sticks to visual line boundaries… it doesn’t advance to next visual line even when repeatedly invoked.

Standard macOS apps that are built on Cocoa text view all behave as (well close too, Bike doesn’t to the select full visual line thing described below) Bike does now.

But every “ground up” editor seems to implement this differently:

• Xcode: Command-Right goes to visual line end… then next line start, then next line end, until gets to paragraph end… then sticks. On the other hand Command-Left goes to visual line start and sticks. So inconsistent in reverse.

• VSCode+Zed: Command-Right goes to visual line end… then goes to paragraph end… and then sticks at that end. Consistent in reverse.

I can maybe be convinced by any argument. I think one key thing to remember is that visual lines are kinda meaningless except for the geometry. That’s why I don’t like the current macOS behavior of selecting the full visual line when you do Shift+Command-L followed by Shift+Command-R … what’s the point?

I find myself using Shift+Command+L/R often to move around, but never to extend selection.

[Gorgonzola]

@jessegrosjean

I’m not sure about #2

I’ve tested a bunch of other apps and advancing line by line indeed seems to be the exception. I’m inclined to withdraw my suggestion, because I agree that advancing line by line isn’t all that…purposeful; OTOH I just dislike the idea of the selection becoming stuck at end of line

@jessegrosjean

I think the standard way to select to the start/end of paragraph is Shift+Option+Up/Down

Forgot about this one, sorry.