Thanks for your feedback.
I will default to standard behavior if I can’t make improvements, but I feel like standard behavior is lacking, and Bike codebase is in unique state to fairly easily try other approaches at this point in time.
For example say you want to edit the first line here to match the second line:
I don’t think there’s any easy way to do it. At least nothing as easy as it would be if you were working in Markdown. This is a difficult case, but in general any rich text editing that happens at attribute run endpoints can quickly become painful in rich text.
I “think” a solution for this is to add a text caret affinity (upstream/downstream) at these text attribute run end points. At those positions the text cursor might start in upstream affinity and draw with arrow pointing upstream. Pressing right arrow would transition it to downstream affinity … text caret would stay at same location, but affinity arrow would draw on other side. Pressing right arrow again would move caret forward.
If you type when there is upstream affinity then attributes are taking from upstream run. If you type when downstream affinity then attributes are taken from downstream run.
This interaction would have a cost, in particular when moving through characters with arrow keys it would “stick” for one press at text run boundaries. But the benefit is you always have full control over which attributes are applied to inserted text. Also there would be no need to special case some attribute run behaviors… for example in current editors the way that formatting attributes are applied is different than the way that link attributes are applied.
I haven’t actually implemented this idea yet, but I came to it after thinking through lots of alternatives over the past weeks, and I think it’s a new and useful solution that addresses the source of many rich text editing problems. I’m at least going to try implementing and see how it feels.
This is a useful shortcut, but one that I didn’t know about. I think maybe a more common way (at least how I would have done it) to “Edit Link” is place cursor in link text + ⌘K. Which of course is also a headache since placing cursor in link text is difficult without activating the link if you are using mouse.
In generally I think there can be an easier more discoverable way to gain access to attribute values that are hidden behind text. The idea I’m working on now is to automatically insert a button after attributes that you might want to interact with. Links for example:
The idea is to automatically insert a button after the attribute run. The button is a separate element outside the outline’s text content. This means there’s no longer a need to disambiguate between clicking on a link and editing link text. Clicking anywhere in “Hello World” will just place the cursor normally. Click the link button to show a popup for opening or editing link. Maybe double-click to activate link immediately… haven’t got that far.
I think this idea is pretty promising so far, but still a ways to go on the implementation.