Bike: Innovative Rich Text Editing(hogbaysoftware.com)
hogbaysoftware.com
Bike: Innovative Rich Text Editing
https://www.hogbaysoftware.com/posts/bike-rich-text/
139 comments
I really wish browsers would support this for `contenteditable` (even without the tail, just having some way to put the cursor in either position, maybe based on from what direction the cursor is coming from).
Slack's message editor is `contenteditable`-based, and it means there is absolutely no way to put the cursor inside at the beginning of e.g. an inline code snippet.
Despite the code snippet formatting having an outline border and some padding, meaning it should be possible to even click inside or outside the snippet unambiguously just with your mouse, Chrome will always place it in the same spot and you have to do the awkward trick of replacing the first character.
This single behavior makes `contenteditable` so terrible
It is possible via JS to place the cursor in that position. The issue is the a native browser cursor navigation skips over it. It would be quite possible to implement this on a contenteditable editor.
That particular bug with slack would be possible to fix with JS. The particular difference about that style is there is a little bit of padding at the start of the style. Bowsers have no understanding of clicking on that padding to select inside the the beginning of the inline style.
That particular bug with slack would be possible to fix with JS. The particular difference about that style is there is a little bit of padding at the start of the style. Bowsers have no understanding of clicking on that padding to select inside the the beginning of the inline style.
> It is possible via JS to place the cursor in that position...
How? No matter what I try, the insertion point is always before the bold element, and not inside it.
How? No matter what I try, the insertion point is always before the bold element, and not inside it.
The behavior for inserting text varies by browser and/or OS, unfortunately. I made [sandbox] to test this. Click the button to set the selection to the first position inside the first <strong> tag in the contenteditable div.
[sandbox]: https://codesandbox.io/s/gracious-dew-rx3xhz?file=/index.htm...
On my Mac, Firefox 104.0.2 inserts new characters inside the <strong>, so they're bold.
In Chrome, the browser API allows positioning the selection there, but during the input event, the selection ends up normalized to just before the strong tag, so the characters aren't inserted into the <strong> tag.
In Safari, the browser API accepts the arguments to set the selection to the first position inside the strong tag, but normalizes during the API call, and the selection always ends up right before the strong tag.
The variance of contentEditable is a huge impediment to using the API raw. If you want reliable, relatively low-level control of rich text input on the web, use ProseMirror.
(I learned a lot about this stuff while working on Notion's rich-text editor, which is all custom.)
[sandbox]: https://codesandbox.io/s/gracious-dew-rx3xhz?file=/index.htm...
On my Mac, Firefox 104.0.2 inserts new characters inside the <strong>, so they're bold.
In Chrome, the browser API allows positioning the selection there, but during the input event, the selection ends up normalized to just before the strong tag, so the characters aren't inserted into the <strong> tag.
In Safari, the browser API accepts the arguments to set the selection to the first position inside the strong tag, but normalizes during the API call, and the selection always ends up right before the strong tag.
The variance of contentEditable is a huge impediment to using the API raw. If you want reliable, relatively low-level control of rich text input on the web, use ProseMirror.
(I learned a lot about this stuff while working on Notion's rich-text editor, which is all custom.)
Thank you for the example. I do mostly the same thing and as a Safari user there is no way to place the caret in "the right spot". What I found working (but I still have to test on other browsers and make my mind if it is really worth the hack) is to place a dummy marker with [contenteditable="false"] at the beginning and the end of the inline elements (the one on the end has to be skipped to avoid getting stuck in a limbo inside the parent element). This way the result is similar to the one in Bike, with the caret that stops on both sides of the element. Let's see if this thing goes somewhere...
Of of the top of my head, you'll need to watch out for:
- The default behavior that triple-click to selects a whole paragraph/line will stop at the first contenteditable=false element.
- Android may dismiss the keyboard & selection if the selection ever touches one of your contenteditable=false marker elements.
- Firefox won't let you place the caret in between two contenteditable=false elements, or at the start or end of a contenteditable=true element if the first/last child is contenteditable=false.
Why not use ProseMirror?
- The default behavior that triple-click to selects a whole paragraph/line will stop at the first contenteditable=false element.
- Android may dismiss the keyboard & selection if the selection ever touches one of your contenteditable=false marker elements.
- Firefox won't let you place the caret in between two contenteditable=false elements, or at the start or end of a contenteditable=true element if the first/last child is contenteditable=false.
Why not use ProseMirror?
I am sure that there are plenty more! Working on top of customeditable is hell, but it is the price to pay if you want to implement a custom editing experience. Of the issues you listed, the triple-click is a good one, and easy to solve with a custom handler (even if there is no tripleclick event, the detail property of the event object holds the number of consecutive clicks). I am pretty sure that ProseMirror does something similar, because it uses [contenteditable="false"] decorations without interfering with the triple-click selection. For mobile devices and Firefox I would surrender, and gracefully degrade the editing experience.
Why not use ProseMirror? It doesn't fix this issue, does it? At least in the demos on their website you cannot insert text at the beginning of a styled element. You cannot do it even in a native application (at least on macOS) without a custom handling of the selection.
Why not use ProseMirror? It doesn't fix this issue, does it? At least in the demos on their website you cannot insert text at the beginning of a styled element. You cannot do it even in a native application (at least on macOS) without a custom handling of the selection.
Thanks for the sandbox. I'm working on a company-wide blog post on a good richtext editing strategy / library and wanted to demostrate how unpredictable it is with contenteditable. This sample is perfect and I'm thinking of hyperlinking the sandbox :)
Do you happen to have any more samples to demonstrate how difficult it is to work with contenteditable APIs?
Do you happen to have any more samples to demonstrate how difficult it is to work with contenteditable APIs?
Oh, I made that sandbox for my HN comment. I actually have a similar internal blog post & several more complex examples I built for that, but can't share any of it publicly.
I just started experimenting with contenteditable yesterday so there might be an easier way, but I think you do this by manipulating the Range object in window.getSelection().
I think natively if you don’t jump into a tag and you don’t jump out of a tag. So if your cursor is in the tag and you move to the boundary, you stay in it. Similarly if you are outside of it, and move to the boundary you stay outside of it.
So I basically would listen to the the relevant input events, see if I’m at the boundary and the orientation of the cursor (which I save in memory) and if I’m only moving across a boundary (i.e. not to the next character) I call event.preventDefault(), manipulate the range accordingly, and update the orientation state.
I’m not sure how to style the caret it self (other then the color) but I’m sure it can be achieved with some absolute position hacking.
I think natively if you don’t jump into a tag and you don’t jump out of a tag. So if your cursor is in the tag and you move to the boundary, you stay in it. Similarly if you are outside of it, and move to the boundary you stay outside of it.
So I basically would listen to the the relevant input events, see if I’m at the boundary and the orientation of the cursor (which I save in memory) and if I’m only moving across a boundary (i.e. not to the next character) I call event.preventDefault(), manipulate the range accordingly, and update the orientation state.
I’m not sure how to style the caret it self (other then the color) but I’m sure it can be achieved with some absolute position hacking.
You'll need to track your own selection state and take over actually inserting the characters by calling preventDefault() during beforeinput in Chrome and Safari. Both Chrome and Safari will fight you on this one. To say nothing of Android...
My Sciter [https://sciter.com] uses that since 2012 :
https://terrainformatica.com/2012/11/04/caret-positions-in-h...
The feature there is named "directional caret"...
The feature there is named "directional caret"...
Nice work on Sciter.
When I came up with this feature in Bike I was pretty proud of the idea and it seemed original. Then a few weeks later I came across your post on StackExchange UX... everything already been invented I guess :) I'm curious how you came with idea? Also have you come across other editors that implement it?
For me I new that something bothered me about rich text editing... always seemed more painful then required. I was also aware of the idea of split cursor from Humane Interface book. And also aware of affinity idea from text cursor position in wrapped text editor lines. Bike's typing affinity came from combining those ideas.
Anyway would love to hear any related thoughts or ideas.
When I came up with this feature in Bike I was pretty proud of the idea and it seemed original. Then a few weeks later I came across your post on StackExchange UX... everything already been invented I guess :) I'm curious how you came with idea? Also have you come across other editors that implement it?
For me I new that something bothered me about rich text editing... always seemed more painful then required. I was also aware of the idea of split cursor from Humane Interface book. And also aware of affinity idea from text cursor position in wrapped text editor lines. Bike's typing affinity came from combining those ideas.
Anyway would love to hear any related thoughts or ideas.
In https://tigyog.app I'm solving the same problem in a different way. Like Bike, the TigYog editor treats those two cursor locations as district. But TigYog shows which position you're at in a different way: when the cursor is inside a link, the link gets a "focus" outline.
Yeah, looks really nice.
The innovation is the visual indicator, the cursor tail. The rest is how WordPerfect worked 30 years ago.
It is horrifying to think how much the Microsoft Word approach has hobbled rich text editing for all those years, and continues to do so.
The innovation is the visual indicator, the cursor tail. The rest is how WordPerfect worked 30 years ago.
It is horrifying to think how much the Microsoft Word approach has hobbled rich text editing for all those years, and continues to do so.
Microsoft Word never had problems with inserting any formatting at any position in the text. It also has some visual style indicators via caret shape and size.
MSWord doesn't have formatting codes, at least not for simple text styles. Instead, each individual character has formatting attributes. So the word italics is not a single italicized region, it's 7 separately italicized characters, that just happen to be next to one another. It's a radically different model from HTML/markdown/WordPerfect markup.
Microsoft Word may never have problems inserting any formatting, but I have; when it comes to paragraph structure, indenting and such, I find it very hard to predict. For example, I'll look at sections of a document with basically the same structure, but in one place the spacing between a table and the paragraph that follows is much larger, and I have no idea why or how to make them the same.
Microsoft Word may never have problems inserting any formatting, but I have; when it comes to paragraph structure, indenting and such, I find it very hard to predict. For example, I'll look at sections of a document with basically the same structure, but in one place the spacing between a table and the paragraph that follows is much larger, and I have no idea why or how to make them the same.
I guess it won't work for rich editors that create tons of elements for every style applied, like `<b><span style=font:...><span style=...>...<i>...` it requires some sanity of the editor.
Older content editable editors would do that. But modern ones have moved to not nesting inline styles, and separating internal data structure from the exported html. Full html isn't really that great for the internal data structure of a rich text editor.
Think of them as having only a none nestable <span> tag with a style attribute.
Think of them as having only a none nestable <span> tag with a style attribute.
I'm hoping these modern editors you refer to at least replace those <span...> atrocities with the correct elements on save.
They do, they separate the internal representation of the editor state from the saved html.
I don't think it would matter, text affinity happens at texts "run" boundaries... so only where formatting changes. Doesn't matter how many attributes each run has. I think that is proper way to design the feature, but it does means it's maybe less flexible then you are thinking. You can pick left or right run... you can pick individual attributes within a run with text affinity.
What if there are more than three cursor locations? Like a bold link?
It works on text "runs", so there will only ever be two choices. In the case you describe there's no way to choose only bold, or only link... you would need to revert to standard rich text dancing for that.
I'm Bike's developer. Thanks everyone for the comments.
While I have the eyeballs I hope you don't mind me asking...
I'm in process of adding autocomplete to Bike. Problem is that I generally find macOS autocomplete painful and unpredictable. I both disable it and have many typos. I'm not talking so much about the suggestions, but about the surrounding UI.
I'm looking for ideas/links for how to make autocomplete better and more predictable. I know Mac apps, I do know much else. What are your favorite autocomplete implementations past or present? If you could have a "fixed" macOS autocompletion what would it look like?
While I have the eyeballs I hope you don't mind me asking...
I'm in process of adding autocomplete to Bike. Problem is that I generally find macOS autocomplete painful and unpredictable. I both disable it and have many typos. I'm not talking so much about the suggestions, but about the surrounding UI.
I'm looking for ideas/links for how to make autocomplete better and more predictable. I know Mac apps, I do know much else. What are your favorite autocomplete implementations past or present? If you could have a "fixed" macOS autocompletion what would it look like?
Couple weeks ago the guy who implemented autocomplete on iOS went on a bit of a rant.
Doesn't translate directly to macOS but useful reading: https://twitter.com/kocienda/status/1565341723860971520
And just in case you or somebody isn't familiar, read this classic: https://norvig.com/spell-correct.html
I suggest to try and keep it simple.
Doesn't translate directly to macOS but useful reading: https://twitter.com/kocienda/status/1565341723860971520
And just in case you or somebody isn't familiar, read this classic: https://norvig.com/spell-correct.html
I suggest to try and keep it simple.
Great product and new features! Will definitely try it out when I get a chance. While I am right in your target user base, over a decade ago I built https://zetabee.com/text for myself and even though there are now so many better solutions to the text outlining problem, it is just too difficult for me to switch. Not sure what your keyboard binding for collapse/expand is but I played with backtick (single key) and loved it because it just feels natural and I never type ` in my notes.
Long ago, I tried to make a better autocomplete feature so people with speech disabilities have fewer buttons to push. Here's what I did - https://ktype.net/wiki/research:articles:progress_20110209 - basically broke down tweets into n-grams (1-4) and then used the 5 most likely next words as suggestions. If I were to do this today, I would still try to get a large volume of text in my target use case (what do most of your users type? Tech project notes? home construction items? grocery lists) and break them down into large lists of 2-3 n-grams. Then ask GPT3 (or equivalent) for 3 possible suggestion for next 1-2 words and save them. Compress and hard-code this list into the app (or alternatively make it download/update from your site infrequently).
If you would like me to explain more, please feel free to reach out!
Long ago, I tried to make a better autocomplete feature so people with speech disabilities have fewer buttons to push. Here's what I did - https://ktype.net/wiki/research:articles:progress_20110209 - basically broke down tweets into n-grams (1-4) and then used the 5 most likely next words as suggestions. If I were to do this today, I would still try to get a large volume of text in my target use case (what do most of your users type? Tech project notes? home construction items? grocery lists) and break them down into large lists of 2-3 n-grams. Then ask GPT3 (or equivalent) for 3 possible suggestion for next 1-2 words and save them. Compress and hard-code this list into the app (or alternatively make it download/update from your site infrequently).
If you would like me to explain more, please feel free to reach out!
Your outline project looks great. Hard to beat an app that you make yourself and can change when you see fit.
Bike does have a keyboard shortcut for expand/collapse, but truth is I don't remember what it is without looking. Instead what I do is always exit to "outline mode" with escape key, and then use left/right arrow keys.
Outline mode is inspired by vim, it's a mode where there is no text input, so you can use typing keys for other purposes. Right now it does very little, mostly just expand/collapse and delete. I hope to expand on this in future, but right now I'm more focused on text editing fundamentals.
Thanks for the autocomplete links. I maybe didn't explain well in my question... but I think I'll leave the actual autocomplete logic to macOS. I want to integrate with their autocomplete system so users will have consistent experience that way.
I'm more interested in UI problems of indication that correction has happened and easy undo when corrections go wrong. In this regard I think macOS is pretty poor.
For example on macOS if you type "hello " then after the space it will be corrected to "Hello ". If that's not what you wanted then there aren't really easy options to undo. Of course you can undo... but that will remove the space and then select "hello". Then another few keystrokes to get back to what you wanted. On the other hand in Google docs all you need to do is backspace and it undoes the autocorrect. I like that and will probably copy, but am looking for more autocorrect systems to learn from.
Bike does have a keyboard shortcut for expand/collapse, but truth is I don't remember what it is without looking. Instead what I do is always exit to "outline mode" with escape key, and then use left/right arrow keys.
Outline mode is inspired by vim, it's a mode where there is no text input, so you can use typing keys for other purposes. Right now it does very little, mostly just expand/collapse and delete. I hope to expand on this in future, but right now I'm more focused on text editing fundamentals.
Thanks for the autocomplete links. I maybe didn't explain well in my question... but I think I'll leave the actual autocomplete logic to macOS. I want to integrate with their autocomplete system so users will have consistent experience that way.
I'm more interested in UI problems of indication that correction has happened and easy undo when corrections go wrong. In this regard I think macOS is pretty poor.
For example on macOS if you type "hello " then after the space it will be corrected to "Hello ". If that's not what you wanted then there aren't really easy options to undo. Of course you can undo... but that will remove the space and then select "hello". Then another few keystrokes to get back to what you wanted. On the other hand in Google docs all you need to do is backspace and it undoes the autocorrect. I like that and will probably copy, but am looking for more autocorrect systems to learn from.
One of the most important changes that I've noticed in autocomplete on iOS (I have it disabled on MacOS, so no idea how it works there), is this:
Old behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting and trying again would enter the same mistake.
Current behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting a few characters causes it to suggest (again) the word I actually wanted. It remembers the next most likely suggestion and I can quickly select it.
This change in behavior was the most significant improvement that I can recall. It went from maddening to somewhat annoying but useful.
Please keep up the good work. Mac nerds who care about high-quality native apps appreciate what you're doing.
Old behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting and trying again would enter the same mistake.
Current behavior: Autocomplete suggests the word I want partway, but by the time I tap it, I've typed additional keys and the suggestion changed. Deleting a few characters causes it to suggest (again) the word I actually wanted. It remembers the next most likely suggestion and I can quickly select it.
This change in behavior was the most significant improvement that I can recall. It went from maddening to somewhat annoying but useful.
Please keep up the good work. Mac nerds who care about high-quality native apps appreciate what you're doing.
> I have it disabled on MacOS, so no idea how it works there
Well that's really at the core of my question. Why do you have it disabled? What need to be improved so that you don't disable it.
I think almost everyone would agree that if you type "teh" or other common typos it would nice for computer to automatically correct them. But many people (myself included much of the time) disable autocorrect. I think this is because the UI isn't ideal.
I'm looking for ways to fix that. Maybe it's not fixable, but if you can enumerate specifics on why you disabled autocomplete on macOS I might come up with some solutions. Thanks!
Well that's really at the core of my question. Why do you have it disabled? What need to be improved so that you don't disable it.
I think almost everyone would agree that if you type "teh" or other common typos it would nice for computer to automatically correct them. But many people (myself included much of the time) disable autocorrect. I think this is because the UI isn't ideal.
I'm looking for ways to fix that. Maybe it's not fixable, but if you can enumerate specifics on why you disabled autocomplete on macOS I might come up with some solutions. Thanks!
Sorry that this isn't very likely to help you gain much actionable insight.
I just turned the feature on for the first time since originally disabling it whenever it was introduced.
After playing with it briefly, it isn't fast enough to offer me any real help. Perhaps if I was hesitating on spelling a challenging word (does it have two of that letter or just one?) it would help me out. But I don't run into those scenarios often enough that it'd be worth the other downsides.
Just now, when I wanted to manually enter typos in the bottom line, it was clunky to dismiss without changing the words. I could mouse over the X or use the arrow keys to change position. Maybe there's another way that isn't intuitive to me? Maybe Esc, but I've already disabled it. Point is, it broke my flow.
I prefer to have the computer point out to me when I spell something incorrectly. It's a method of reinforcing the correct spelling. Then I can hopefully learn not to make the same mistake in the future.
Finally, as I've had it on while typing this post, it autocorrected a typo to the wrong word (amke turned to take; wtf). Had I not noticed, it would make my sentence strange (though most would just assume I was typing on a phone). That's fine on a web forum, but that's not acceptable in professional emails and the like.
It's just not useful to a life-long computer user with a full-sized kbd. However, despite 15 years of thumb typing on phones, the targets are still small enough and my thumbs are still large enough that it's mostly useful.
PS: Because I'm a fan of text-substitution apps (I use aText, but TypeIt4Me is also well-regarded), I already have custom entries for things like hte or thakns).
Good luck conquering this obstacle!
I just turned the feature on for the first time since originally disabling it whenever it was introduced.
After playing with it briefly, it isn't fast enough to offer me any real help. Perhaps if I was hesitating on spelling a challenging word (does it have two of that letter or just one?) it would help me out. But I don't run into those scenarios often enough that it'd be worth the other downsides.
Just now, when I wanted to manually enter typos in the bottom line, it was clunky to dismiss without changing the words. I could mouse over the X or use the arrow keys to change position. Maybe there's another way that isn't intuitive to me? Maybe Esc, but I've already disabled it. Point is, it broke my flow.
I prefer to have the computer point out to me when I spell something incorrectly. It's a method of reinforcing the correct spelling. Then I can hopefully learn not to make the same mistake in the future.
Finally, as I've had it on while typing this post, it autocorrected a typo to the wrong word (amke turned to take; wtf). Had I not noticed, it would make my sentence strange (though most would just assume I was typing on a phone). That's fine on a web forum, but that's not acceptable in professional emails and the like.
It's just not useful to a life-long computer user with a full-sized kbd. However, despite 15 years of thumb typing on phones, the targets are still small enough and my thumbs are still large enough that it's mostly useful.
PS: Because I'm a fan of text-substitution apps (I use aText, but TypeIt4Me is also well-regarded), I already have custom entries for things like hte or thakns).
Good luck conquering this obstacle!
I use Typinator, which includes the TidBITS AutoCorrect Library. https://gist.github.com/a-gu/1218e4935d282a68795259e96c238fd... It's far less aggressive than macOS auto-correct, but corrects the most common typing mistakes and misspellings.
> I'm looking for ideas/links for how to make autocomplete better and more predictable.
Consider taking a hint from every code editor. As the user types they are presented with a drop-down list of completions and corrections for the current word. This list hovers below the cursor and moves with it. The top item of the list is automatically selected such that hitting the completion key combo (often just the Tab key) replaces the current word with the selected item from the drop-down. The elements of the drop-down are sorted by likelihood of them being what the user meant to type and are navigated with up/down arrow keys. Hitting escape hides the completion drop-down and allows the user to use the up/down keys to move the cursor. At any time the user can press a key-combo to bring up a completion/correction drop-down for the word under the cursor.
Consider taking a hint from every code editor. As the user types they are presented with a drop-down list of completions and corrections for the current word. This list hovers below the cursor and moves with it. The top item of the list is automatically selected such that hitting the completion key combo (often just the Tab key) replaces the current word with the selected item from the drop-down. The elements of the drop-down are sorted by likelihood of them being what the user meant to type and are navigated with up/down arrow keys. Hitting escape hides the completion drop-down and allows the user to use the up/down keys to move the cursor. At any time the user can press a key-combo to bring up a completion/correction drop-down for the word under the cursor.
I agree code editor autocomplete is a good design for searching through space of options efficiently. I'm not sure if that design works for "autocorrect" in general writing instead of code editing.
I guess you could popup a list of all possible matching "correct" words as you type, but that would likely get old fast for normal writing. You would always see the popup. Generally autocorrect (fixing typos and spellings) happens once you have finished typing a word. At that point the word is checked, and maybe autocorrected.
I think that basic design is good. Finish word, then autocorrect if there's a high quality match. The place where I think problems happen and maybe a better design can help include:
1. Clear indication of what has been autocorrected
2. Easy way to revert autocorrections
3. Don't pop up to much UI during this whole process
I guess you could popup a list of all possible matching "correct" words as you type, but that would likely get old fast for normal writing. You would always see the popup. Generally autocorrect (fixing typos and spellings) happens once you have finished typing a word. At that point the word is checked, and maybe autocorrected.
I think that basic design is good. Finish word, then autocorrect if there's a high quality match. The place where I think problems happen and maybe a better design can help include:
1. Clear indication of what has been autocorrected
2. Easy way to revert autocorrections
3. Don't pop up to much UI during this whole process
I love Bike so much on my Mac. It’s light and nimble in a way that OmniOutliner never was, and makes me want to use it. I’m a very happy customer! My only “complaint” is that now I desperately want it on my iPad. “Light and nimble” are especially important on mobile and I haven’t found an awesome alternative there.
> I know Mac apps, I do know much else.
Possible autocomplete-related grammar error? ^_^
I'm not a user of Apple products, but in the Linux world there are code editors that enable the user to define custom completions. I find this to be an excellent productivity feature, not just for coding.
The editor Geany calls them snippets.
Possible autocomplete-related grammar error? ^_^
I'm not a user of Apple products, but in the Linux world there are code editors that enable the user to define custom completions. I find this to be an excellent productivity feature, not just for coding.
The editor Geany calls them snippets.
Thanks. I agree the way that programmer text editor handles snippets is nice. I think this is a pretty good and clear UI already.
For autocorrect I'm talking about corrections that are less predictable such as spelling or grammar errors. They can be very useful because they mean fixes happen without any extra work, and mean you don't see lots of red spelling errors in your document... but it's also a case where computer is doing automatic work that sometimes might be wrong. So needs good way to indicate that correction has happened and easy way to revert.
For autocorrect I'm talking about corrections that are less predictable such as spelling or grammar errors. They can be very useful because they mean fixes happen without any extra work, and mean you don't see lots of red spelling errors in your document... but it's also a case where computer is doing automatic work that sometimes might be wrong. So needs good way to indicate that correction has happened and easy way to revert.
Since this is HN... :) would be nice if you share how is your business going on? Are you able to fully concentrate on your apps? Thanks!
Yes... kinda...
I've been doing indie Mac software since around 2003. Mostly full time with some consulting mixed in. I've had varying levels of success. Generally business grew into (enough to support me and three others for a few years) until around 2012. Then down down (with very little bumps of success in-between). Since 2012 it's been just me. I make less than I would in a "real" job. Sometimes quite a bit less. Even with Bike's recent success I'm mabye making less than average US programmer.
Some of this is likely due to indie being hard. Much is also due to me being mostly programmer driven, not business driven. I am doing many stupid things business wise. But I also get to work on exactly what I want to work on.
I've been doing indie Mac software since around 2003. Mostly full time with some consulting mixed in. I've had varying levels of success. Generally business grew into (enough to support me and three others for a few years) until around 2012. Then down down (with very little bumps of success in-between). Since 2012 it's been just me. I make less than I would in a "real" job. Sometimes quite a bit less. Even with Bike's recent success I'm mabye making less than average US programmer.
Some of this is likely due to indie being hard. Much is also due to me being mostly programmer driven, not business driven. I am doing many stupid things business wise. But I also get to work on exactly what I want to work on.
Very nice. I love these little innovations, it’s exactly the type of design ideas that makes me want to try an app.
I wonder if it’s an intentional easter egg that the keyboard shortcuts in the popover spell out “bischl”… which is more than a little reminiscent of “bicycle”. (Could improve it by replacing “h” for “highlight” with “y” for “yellow”: “bisycl”.)
I wonder if it’s an intentional easter egg that the keyboard shortcuts in the popover spell out “bischl”… which is more than a little reminiscent of “bicycle”. (Could improve it by replacing “h” for “highlight” with “y” for “yellow”: “bisycl”.)
No easter eggs in Bike yet... though I should add something someday. At the moment just trying to get features in to make it a good place to work and think.
Having it start with B I was pretty much a given, since that's how it's always been.
https://www.versionmuseum.com/history-of/microsoft-word
https://www.versionmuseum.com/history-of/microsoft-word
I was expecting them to say “..as easy as riding a bike.”
The video, demonstrating the features of the rich text editor, is well done. Now I want to try this Bike app (unfortunately I have no mac). I hope more developers will copy this whenever they are implementing a rich text editor.
For me, it was too long and verbose: instead of showing with no prior knowledge, it starts telling me how intuitive stuff will be. Also the sound started activated and by clicking, as instructed by the blinking text, I disabled it, which was confusing.
This is genius. Very clear explanation of what's wrong with rich text editing too. Especially frustrating in Slack. On desktop they support "Mrkdwn" (a bastardisation of Markdown) but there's no way to do custom link text with it at all! The only way is if you switch to their shitty WYSIWYG editor.
In their app I think you can only use WYSIWYG, but it's full of insane flaws, like if you open a code span (backticks) and then close it but don't immediately enter some more text then there is literally no way to escape it into normal text again. You have to delete the whole code span and start again.
If anyone from Slack is reading this, fix your shit!
In their app I think you can only use WYSIWYG, but it's full of insane flaws, like if you open a code span (backticks) and then close it but don't immediately enter some more text then there is literally no way to escape it into normal text again. You have to delete the whole code span and start again.
If anyone from Slack is reading this, fix your shit!
That sounds an awful lot like what emacs is doing in org mode (if you configure it too). I have to say, it's often nice, but sometime still gets in the way of editing in my experience. So I'm often conflicted if I want this or pure editing of the org without the rendering.
I was just going to comment about how bringing features like this to org would be great. Do you know if there's a way to have caret affinity displayed in org, or equivalents for the other features mentioned? Sorry if they're obvious features, I'm a bit rusty on the latest developments.
I'd like to see what emacs/org mode is doing ... is there a link to documentation, of demo video somewhere?
Text affinity and the command pallet is innovative. Could probably bundle this up as a Objective-C library that acts as a drop in replacement for UITextView/NSTextView. Perhaps a JS/WebComponent library for <textarea> as well. I’m sure you could extract some revenue with licensing those libraries or tech support.
For puzzle one, in Microsoft Word, control+space clears direct font formatting from the cursor (or if text is selected, the selected text). So exactly a consistent way to go back to unformatted text.
For puzzle two it uses some opaque heuristic to decide where to insert the text, I wouldn't really on it, I'd right click and edit the link.
For puzzle two it uses some opaque heuristic to decide where to insert the text, I wouldn't really on it, I'd right click and edit the link.
Thanks, I didn't know about Control-Space on MS Word. Looking in menu's I see "Clear Formatting" menu item, but the shortcut isn't listed. How did you know about this shortcut?
I don't remember. I spend quite a bit of time editing in Word and usually end up searching if there is something I think should be possible and don't know how to do, and I'll keep an eye out for other tidbits when reading.
> Those formatting characters are always visible
My solution, when I coded my own word processor, was to use a single, invisible control character, '¶' ¹.
So, for example, bold would be enclosed by '¶b' and '¶B', and a first-level heading would be a line starting with '¶1'.
So, there exist characters in the text that are invisible but you know are there: you can insert the couple and delete it just like any other character.
¹(part of the extended character set - '¶' is easily accessible on some systems as [AltGr]+[R])
My solution, when I coded my own word processor, was to use a single, invisible control character, '¶' ¹.
So, for example, bold would be enclosed by '¶b' and '¶B', and a first-level heading would be a line starting with '¶1'.
So, there exist characters in the text that are invisible but you know are there: you can insert the couple and delete it just like any other character.
¹(part of the extended character set - '¶' is easily accessible on some systems as [AltGr]+[R])
How is that different from HTML tags?
> How is that different
Two chars - fixed amount. One control, one command. Just cleaner, simple and functional. It's something you type, and it is hidden, you want it to be short and clear.
«How is that different», more literally: it is markup, like in htMl, but it is a special markup for that other special purpose of direct rich text tagging in word processors, not for hypertext (HTml). I called it differently, but if you so fancy, it is DRTTIWPML.
Two chars - fixed amount. One control, one command. Just cleaner, simple and functional. It's something you type, and it is hidden, you want it to be short and clear.
«How is that different», more literally: it is markup, like in htMl, but it is a special markup for that other special purpose of direct rich text tagging in word processors, not for hypertext (HTml). I called it differently, but if you so fancy, it is DRTTIWPML.
I love all of these features. The link part is a little rough. I think this is the best choice out of a space or bad options, but it sucks that it means that the thing a link does 99% of the time has to be flipped on its head. I don’t see a good alternative though; if you make it an “edit” button instead of a “visit” button, you make normal text editing super inconvenient, and that’s the effect users will usually want in an editor.
I agree it's not perfect. In particular it's a little weird to highlight the link text blue since it's not what you interact with. Mostly just makes it easy to see and then find the link button, also useful if you are planning to publish a document so that you can see where the links will be in published document.
One feature that I do like about this design is it's pretty generic. For example in the future I could imagine detecting dates and then insert a button after the detected date to interact with calendar. I think the general idea of inserting simple interaction button in text can be quite useful.
One feature that I do like about this design is it's pretty generic. For example in the future I could imagine detecting dates and then insert a button after the detected date to interact with calendar. I think the general idea of inserting simple interaction button in text can be quite useful.
Is there a Windows / Linux alternative to this. I was excited to be reading about this prior to realising it was Mac only.
Other than games on Windows, it seems like the Mac is the only desktop operating system with anything interesting happening on it.
Workflowy is what I use. It's cross platform, but a lot clunkier than this.
Workflowy is what I use. It's cross platform, but a lot clunkier than this.
Is that really true? I had a feeling that macOS desktop developers are on the decline.
There are certainly a lot of Windows-only apps that are quite nice.
Further, as a person trying to develop a cross-platform, desktop-only GUI framework and applications, macOS is absolutely the worst offender on nearly everything. From only supporting an outdated OpenGL version to requiring that windows are managed on the main thread. Neither Windows nor Linux have either of these limitations.
There are certainly a lot of Windows-only apps that are quite nice.
Further, as a person trying to develop a cross-platform, desktop-only GUI framework and applications, macOS is absolutely the worst offender on nearly everything. From only supporting an outdated OpenGL version to requiring that windows are managed on the main thread. Neither Windows nor Linux have either of these limitations.
How does the affinity cursor work when there are multiple formats applied?
For example, “<b><i>text” has three insertion points shown with the pipe character: “|<b>|<i>|text”
For example, “<b><i>text” has three insertion points shown with the pipe character: “|<b>|<i>|text”
Internally a lot of editors don't nest inline styles like that. The formatting is more like a style attribute on a <span> tag, listing all style properties. So you still only have two positions, previous formatting to the left, new formatting to the right.
I suspect that is how Bike is doing it.
I suspect that is how Bike is doing it.
This is correct.
If I were implementing this, I would ignore the middle one. There's virtually nothing visible to the user that there is a middle one OR that <b> is actually placed before <i>. I feel handling this edgecase causes more UX problems than not.
The approach I took with my own hacky editor component was to highlight the styles that currently apply at the caret position via toggle buttons for B, I, etc. This is something word processors have been doing for decades, although I recognise it's far from a perfect solution.
Respect. This must have been a pain to implement. (I still have PTSD from writing a text editor for macOS).
Writing the text editor has certainly been painful and taken me a long time. This particular feature (typing affinity) isn't actually to hard and I think could be bolted on to most existing edit editors. Really you just need to take one extra bit of state... and then can calculate cursor drawing + moment based on that state and all the other state the editor normally tracks.
Hello! I keep asking this, but do you have any good resources for doing that? For example, any repos you would recommend studying?
Thanks!
Thanks!
I've spent a lot of time reading through these codebases and found that reading very useful.
- https://codemirror.net - https://prosemirror.net - https://xi-editor.io
- https://codemirror.net - https://prosemirror.net - https://xi-editor.io
This looks awesome. I do all my writing (creative writing, outlining, todos) in Bear and really love it. But this app seems like it would make outlining more fun and intuitive. Def gonna try it!
Great to see fresh, innovate apps like this that prioritize fast native experience.
Great to see fresh, innovate apps like this that prioritize fast native experience.
I'm a very, very happy HogBay customer. Two comments: the product is high quality and the support is outstanding. Recommended.
The cursor affinity could be entirely subsumed by the visible typing attributes, which might be more intuitive. For both, I'd worry about the user's cursor configuration affecting things - it could be safer and more widely compatible to have it float nearby rather than have it attached to the cursor.
The link editing doesn't seem like an improvement on other rich text interfaces, with no visually obvious way to edit the link destination.
A keyboard shortcut that tells you other keyboard shortcuts isn't at all innovative, but it is handy and more software should have it.
The link editing doesn't seem like an improvement on other rich text interfaces, with no visually obvious way to edit the link destination.
A keyboard shortcut that tells you other keyboard shortcuts isn't at all innovative, but it is handy and more software should have it.
Brilliant idea. I am actually just researching how to build my own structured document editor for the web, based on my parsing engine for Pyramid grammars, and I'll certainly examine how to apply this idea in my context.
I'm surprised that no other text editor has these text caret features already.
It's not actually a straightforward idea. It's just good design. No project manager will ask for it (just as no one asked for multiple cursors until sublime came along and won lots of hearts with it). There's plenty of space for such ideas which will all feel stunning. But, surprising they were not made before, neah...
Good points.
I think this is a great example of where an individual can really innovate on their own, but they do need to have a good mix of experience with developing on a particular platform as well as a good sense for UX.
Working in a larger company, you tend to have each of those tasks (implementing vs designing) split out into multiple roles, making it very difficult to know what's possible to innovate, plus experience levels often differ, so newer designers may not know the limitations on a platform, so may over-design, and developers may not have experience to implement certain things, so they may limit the end result as well.
I think this is a great example of where an individual can really innovate on their own, but they do need to have a good mix of experience with developing on a particular platform as well as a good sense for UX.
Working in a larger company, you tend to have each of those tasks (implementing vs designing) split out into multiple roles, making it very difficult to know what's possible to innovate, plus experience levels often differ, so newer designers may not know the limitations on a platform, so may over-design, and developers may not have experience to implement certain things, so they may limit the end result as well.
Please see footnote in linked article. Like all ideas it's probably been invented many times before. But also like all ideas you need to invent, make good implementation, and then hopefully luck into people finding out a about it.
Of course, but it doesn't seem that any currently available text editor has this. Even the one mentioned in the Stack Overflow post is now gone, it seems.
Still, this looks amazing - thank you for implementing it. Would love to see this formatting UI used in more apps going forward.
Still, this looks amazing - thank you for implementing it. Would love to see this formatting UI used in more apps going forward.
There're some other editors that have similar behaviors. AFAIK, CKEditor [1], an online rich text editing framework, is optimized for cascaded formatting tags. A <pre> or <a> element will be highlighted if the cursor is "within" its context, and when your cursor is at the edge of such an element, you can press the arrow key again to move into/out from it.
[1] https://ckeditor.com/ckeditor-5/demo
[1] https://ckeditor.com/ckeditor-5/demo
It always makes me smile to see Hog Bay Software releases get such positive attention. Jesse Grosjean is one of the only indie developers of note that I am aware that are based in Maine. Makes myself, the aspiring iOS developer, not feel so alone in this state. :)
What Jesse is doing here for rich text editing is astounding, to me, and is exactly the type of advancement that the popular word processing apps should take note of.
What Jesse is doing here for rich text editing is astounding, to me, and is exactly the type of advancement that the popular word processing apps should take note of.
Go Maine! Where are you based? Got any app links? And excuse me if I should already know your handle, I have a terrible memory.
Rich text posts in HN constantly recalled this personal story that I am waiting to happen (e.g. be developed by someone else).
Since the use of an early Palm Pilot [1] I wanted to have a personal wiki. It was a little awkward in that moment comparing to something like a Squeak Wiki [2]. So when the iPhone 1 appeared [3] there was another call.
The first versions of iOS didn't include text selection and copy and paste to generate links to new pages. In this context I did a basic reverse engineer of the UITextView and could advance this towards the "wiki dream" but it would never be accepted in the Apple Store so I abandoned the idea that was basically without a business perspective.
As tptacek [4] said recently: "For several years I just use Apple's Notes.app. It's honestly pretty great; it's frustratingly good..." [5]. I would add: but it will be more great if they add native hyperlinks within the internal notes.
[1] https://en.wikipedia.org/wiki/Palm_(PDA)
[2] https://en.wikipedia.org/wiki/Swiki
[3] https://en.wikipedia.org/wiki/IPhone_(1st_generation)
[4] https://news.ycombinator.com/user?id=tptacek
[5] https://news.ycombinator.com/item?id=27535683
Since the use of an early Palm Pilot [1] I wanted to have a personal wiki. It was a little awkward in that moment comparing to something like a Squeak Wiki [2]. So when the iPhone 1 appeared [3] there was another call.
The first versions of iOS didn't include text selection and copy and paste to generate links to new pages. In this context I did a basic reverse engineer of the UITextView and could advance this towards the "wiki dream" but it would never be accepted in the Apple Store so I abandoned the idea that was basically without a business perspective.
As tptacek [4] said recently: "For several years I just use Apple's Notes.app. It's honestly pretty great; it's frustratingly good..." [5]. I would add: but it will be more great if they add native hyperlinks within the internal notes.
[1] https://en.wikipedia.org/wiki/Palm_(PDA)
[2] https://en.wikipedia.org/wiki/Swiki
[3] https://en.wikipedia.org/wiki/IPhone_(1st_generation)
[4] https://news.ycombinator.com/user?id=tptacek
[5] https://news.ycombinator.com/item?id=27535683
I want these features on every text caret everywhere. Love the typing affinity tail!
Brilliant work! Wish I was a Mac user.
For the hyperlinks, it seems editing the text and visiting the link is easy. But there isn’t a way to edit the hyperlink itself quickly?
Have you considered using affinity cursor along the up/down for that as well? Eg. Up updates the hyperlink content while default/down updates the link text.
Not sure how it would work out UX wise. Maybe opens up a popover with cursor for the hyperlink.
For the hyperlinks, it seems editing the text and visiting the link is easy. But there isn’t a way to edit the hyperlink itself quickly?
Have you considered using affinity cursor along the up/down for that as well? Eg. Up updates the hyperlink content while default/down updates the link text.
Not sure how it would work out UX wise. Maybe opens up a popover with cursor for the hyperlink.
> But there isn’t a way to edit the hyperlink itself quickly?
Correct. For that you need to use Formatting pallet (also in video). I did initially build it so clicking link would open a pallet with option to follow link or edit link (Pages.app) does that. But in the end felt better to make following link fast and add/edit links slower.
Up/Down could work, but I think it would break text editing movement/consistency more than I would want. For example if you were down arrowing to navigate you document and then randomly hit a link it would be frustrating to see link editor instead of keep moving down.
Correct. For that you need to use Formatting pallet (also in video). I did initially build it so clicking link would open a pallet with option to follow link or edit link (Pages.app) does that. But in the end felt better to make following link fast and add/edit links slower.
Up/Down could work, but I think it would break text editing movement/consistency more than I would want. For example if you were down arrowing to navigate you document and then randomly hit a link it would be frustrating to see link editor instead of keep moving down.
Is there any hope of turning this editor into a web-embeddable rich test editor like eg tiptap? Would love that and would gladly pay for it.
Sorry, I'm tried web tech in previous apps. This time I wanted build native, and I don't have resources to do it all.
What I would love...
Take a look at Bike's file format, it's just a subset of HTML. Would love to someone to write a web based editor for Bike's file format. Then you could edit Bike files anywhere you want... and also have cool native experience on Mac.
Also note that Bike does read/write .txt and .opml.
What I would love...
Take a look at Bike's file format, it's just a subset of HTML. Would love to someone to write a web based editor for Bike's file format. Then you could edit Bike files anywhere you want... and also have cool native experience on Mac.
Also note that Bike does read/write .txt and .opml.
Discovered this on HN a few months ago, and it has become indispensable for me. Beautiful software with subtle, nifty innovations in UX.
I love that Jesse is taking a first principles approach with this and not constraining himself with the standard text editor patterns. He's also pretty active on the support forum and very receptive to feedback.
I love that Jesse is taking a first principles approach with this and not constraining himself with the standard text editor patterns. He's also pretty active on the support forum and very receptive to feedback.
Bike is beautiful! I'm tempted.
But all my notes are in Notational Velocity (https://notational.net/) at the moment, because the largest source of friction for me is finding note files. In Notational Velocity I never have to open a file dialog; file dialogs on Mac OS are still shockingly slow, and even if they were fast it would take too long to find the file I want. My hands never leave the keyboard; I just type a few characters and Notational Velocity finds the correct note for me.
Do you have any interest in adding an instant search feature, like Notational Velocity? I'd replace it if I could keep the fast search while being able to outline and edit with Bike's fantastic rich text capability.
But all my notes are in Notational Velocity (https://notational.net/) at the moment, because the largest source of friction for me is finding note files. In Notational Velocity I never have to open a file dialog; file dialogs on Mac OS are still shockingly slow, and even if they were fast it would take too long to find the file I want. My hands never leave the keyboard; I just type a few characters and Notational Velocity finds the correct note for me.
Do you have any interest in adding an instant search feature, like Notational Velocity? I'd replace it if I could keep the fast search while being able to outline and edit with Bike's fantastic rich text capability.
Eventually yes, but not anytime soon.
Right now Bike is very much a text editor, while notational velocity is more database of text files. At some point I hope to add a "workspace" aspect to Bike where you can open a directory of Bike files, but this is a long way off. For now the focus will just be to improve the text editor aspect of Bike.
Right now Bike is very much a text editor, while notational velocity is more database of text files. At some point I hope to add a "workspace" aspect to Bike where you can open a directory of Bike files, but this is a long way off. For now the focus will just be to improve the text editor aspect of Bike.
The caret tail is rad
[deleted]
I really enjoy seeing how you demo the features of Bike. The design is really thought out and you do a great job of communicating how it works in simple terms. (I'm an indie Mac/iOS dev myself, so I'm going to take pointers on how you present your innovations!)
I find AppleScript very useful for this. I script the text input, menu items, and timings like this:
menuItem("Format:Bold", 0.2)
type("Efficient")
press("⏎")
menuItem("Format:Bold", 0.2)
type("Efficient")
press("⏎")
Good suggestion. I always forget AppleScript exists.
“Those formatting characters are always visible. They make my text look messy.”
This problem was solved in Vi with highlighting and concealing: the formatting characters are hidden and the target formatting is approximated until you move the cursor to edit the formatted bit. I’m sure Emacs has an equivalent.
This problem was solved in Vi with highlighting and concealing: the formatting characters are hidden and the target formatting is approximated until you move the cursor to edit the formatted bit. I’m sure Emacs has an equivalent.
Happy to see this here! I'm a long time fan of Jesse's work [1] and love seeing independent software developers ship their own products.
1. https://www.hogbaysoftware.com/about/
1. https://www.hogbaysoftware.com/about/
Thanks :)
Affinity cursor and formatting tooltips are cool.
Sadly, only for macOS.
I am a long time Apple user, but knowing Apple's direction, cannot invest in software made only for macOS.
Obsidian gives me everything I need, and mostly a multiplatform confidence.
I am a long time Apple user, but knowing Apple's direction, cannot invest in software made only for macOS.
Obsidian gives me everything I need, and mostly a multiplatform confidence.
Now that I've used this, I want it everywhere there is rich text.
I like it, specially the contextual format popup, it is sort like emacs made visual (for text format).
Being a meta-shortcut I guess the more complex/options it gets, the worst.
Being a meta-shortcut I guess the more complex/options it gets, the worst.
The affinity cursor is a really smart solution to such an old and common problem. Bravo! I hope more editors adopt it as a standard pattern.
Are there any examples out there what kind of documents people are writing with this?
What's the right way to write more than one line per row? Return always just adds a new row. For instance, with Workflowy, you can hit Return+shift to add a note to row which can be as long as you want, and only the first line of it will be shown if not focused.
What's the right way to write more than one line per row? Return always just adds a new row. For instance, with Workflowy, you can hit Return+shift to add a note to row which can be as long as you want, and only the first line of it will be shown if not focused.
I personally use it for a thinking tool... as opposed to document creating at this point. So I store notes and ideas. Process ideas. I don't author final documents.
Currently there is no way to add multiple lines to a row. I "think" I would rather solve this problem by adding multiple row types (maybe heading vrs notes) and then use some sort of filtering. That's still on todo list.
Currently there is no way to add multiple lines to a row. I "think" I would rather solve this problem by adding multiple row types (maybe heading vrs notes) and then use some sort of filtering. That's still on todo list.
We really need Rich Text Editing on the web.
Few years ago, I was writing a tiny note taking app, and the only viable alternative was Trix.
Few years ago, I was writing a tiny note taking app, and the only viable alternative was Trix.
There are many open source Rich Text editors.
The most popular is Quill, and then there are block style like EditorJS, and those meant to be very extensible like Lexical.
And many more- try searching for "Quill alternatives"
The most popular is Quill, and then there are block style like EditorJS, and those meant to be very extensible like Lexical.
And many more- try searching for "Quill alternatives"
This is the second time in 8 days that something I submitted first made it to the front page from someone else's repost less than 24 hours later. What am I doing wrong?
https://news.ycombinator.com/item?id=33480410
I think a lot of getting to the front page depends on your random luck of the first 10 people that see the post. If enough of those 10 like your thing, it gets seen by thousands more and may make it to the front page. If none of those 10 do, it's fades away. It's 10 people out of millions that visit HN, so there's a lot of variability. You could post the exact same thing 15 minutes later then the first time and get a totally different "first 10" and that post could perform completely differently.
Yeah, all good points. I guess I'm partially just confused about the dupe detector. E.g., when I post something that someone else has already submitted recently, it just redirects me to the existing post.
Re the luck factor, part of the appeal of Hacker News is there seems to be a lot of work done to minimize the role of luck. Which generally felt like it worked well for me historical, just not recently.
Not a big deal in any event, but if there's something I should be doing differently, I'd like to do it.
Re the luck factor, part of the appeal of Hacker News is there seems to be a lot of work done to minimize the role of luck. Which generally felt like it worked well for me historical, just not recently.
Not a big deal in any event, but if there's something I should be doing differently, I'd like to do it.
Yeah, unfortunately I think a huge amount still comes down to luck.
HN is better then any other platform (which is incredible considering how many engineers work on it) at detecting fraud (e.g. "upvote rings"). But I think a ton still comes down to the first few people that see the post.
HN is better then any other platform (which is incredible considering how many engineers work on it) at detecting fraud (e.g. "upvote rings"). But I think a ton still comes down to the first few people that see the post.
Are we sure that there aren't some users involved in a voting ring?
Pretty sure :) I submitted this story a month ago when Bike first released this feature and only got 3-4 upvotes. Very pleased and surprised to see it generating interest today.
These are pretty nice ideas fixing existing problems for desktop computers.
How would these work with mobile devices ? It doesn't seam compatible.
Also, these are user interaction suggestions. What about the encoding ? There are plenty limitations with Markdown (the pseudo standard) on this aspect.
How would these work with mobile devices ? It doesn't seam compatible.
Also, these are user interaction suggestions. What about the encoding ? There are plenty limitations with Markdown (the pseudo standard) on this aspect.
This is a neat solution! Though I wonder if this can carry over to terminal environments
Really nice features announced. I guess it can be adopted by other editors.
That's a bummer that it is Mac only, no Linux support, and even Windiws!! WTF?
And ideally it could be opensource)
I hope new tools would emerge, that implement this ideas.
That's a bummer that it is Mac only, no Linux support, and even Windiws!! WTF?
And ideally it could be opensource)
I hope new tools would emerge, that implement this ideas.
So many great ideas, loved the video, keep up the excellent work!
In Firefox, I enable the cursor mode to solve the link problem... I can click anywhere and the select the text using the keyboard.
I was a little sad when I figured out this was part of an app and not a rich text editor I could use in my projects.
How about we have an informal rule that if is Mac only, or Win10 only, etc that it says so in the title?
So nice. I use Notion daily at work and these ideas solve so many annoyances that repeat over and over
Simple and clean, I like it.
Any plans to support Math(Jax) or other latex-like math notation ?
Unlikely in the near term. I feel like there are many other features that I need to do first. Longer term maybe?
Definitely like what you have now in terms of a text editor! But thanks for letting me know about math.
This looks really nice. If only it weren't Mac-only. :(
Fantastic innovations. But where's the underline? :)
For links or for just general formatting?
For links I just decided to leave out. Seemed blue was enough, and especially since link interaction in Bike only happens through link button. For general formatting I left out because underline formatting seems to be falling out of favor as a standard and when I asked in my forum most users said they didn't need it. Eventually I would like to read/write Markdown from Bike and underline isn't a part of standard Markdown.
For links I just decided to leave out. Seemed blue was enough, and especially since link interaction in Bike only happens through link button. For general formatting I left out because underline formatting seems to be falling out of favor as a standard and when I asked in my forum most users said they didn't need it. Eventually I would like to read/write Markdown from Bike and underline isn't a part of standard Markdown.
Lots of browsers format links with just a thin underline and no color change. I actually prefer that approach since it avoids the visual color clutter. Would be nice to have an option to do that instead of color.
Lots of great ideas, especially the format affinity indication/control. Is that just arrow key or arrow with cmd key? If it is only the arrow key, how do you distinguish user intent to actually move the cursor vs change the affinity?
Lots of great ideas, especially the format affinity indication/control. Is that just arrow key or arrow with cmd key? If it is only the arrow key, how do you distinguish user intent to actually move the cursor vs change the affinity?
Eventually I hope to add theme support so that links can look how you want, but that's not a feature that I'll be working on super soon.
The affinity is just treated as a new character position. When caret moves through that position is doesn't "move", but instead draws tail differently. So it's just normal arrow key with one extra state to move through. That extra state only happens at formatting boundaries, so generally the cost isn't too much.
The affinity is just treated as a new character position. When caret moves through that position is doesn't "move", but instead draws tail differently. So it's just normal arrow key with one extra state to move through. That extra state only happens at formatting boundaries, so generally the cost isn't too much.
Let’s hope Microsoft doesn’t read HN. Else you’re going to see that bundled with Office in no time.
\s
\s
Heh, I'm actually finding MS Word a good source for autocorrect ideas.
Internally the inline formatting will be marked as tags in a rage, exactly like html. Essentially there is a possible cursor position both inside and outside a formatting tag, but both appear as the same visual location on the screen. This is such a lovely way to indicate the difference.
So with this code:
There are two cursor positions that are visually the same place:
Most editors "jump" over one of those positions to hide the implementation detail from users. This idea exposes it with a little tail on the cursor.