Textual Healing: iOS Text Editing Minutiae | Hacker News Reader

Textual Healing: iOS Text Editing Minutiae

sim.coffee

56 pointsinterpol_p9 comments

> When you hold option and hit the arrow keys, you jump across by word. This is how the text system understands what a “word” is and where the next one lives.

I only occasionally have to use Eclipse for my work, but whenever I do it drives me crazy that they override this behaviour from how it works in every other text input in the OS.

If I have the string of text, applicationNumber, anywhere in macOS I could have my cursor to the immediate left of the word, hold option+shift+right and it'll select the whole word. But in Eclipse, the same combination selections just "application" and leaves "Number" unselected.

Terminals always tend to have their own wacky version of text input as well that works nothing like anything else in the OS, to an even worse degree. But it made me happy to find Warp[1] which immediately sold me on the fact that the text input works like a normal text input field, with all the text navigation keyboard combos I'm used to.

[1] https://www.warp.dev

They didn’t choose to do non-Mac things, eclipse is a Java app so everything is Java’s own ui toolkit and does its own keyboard event handling and so anything built on it fails basic OS behavior that differs from their primary dev platform.

Electron apps are the same - intentionally so, chrome literally disabled basic os interaction in a variety of ways to make chrome behave more similarly across all platforms even if it meant crappy behaviour on macOS. At least they didn’t disable all the code in webkit that handles actual editing behavior, just enough that every electron app is noticeably janky.

You get the same again every time people think that they can make their own editor that isn’t just a content-editable element. There’s a huge amount of work in browser engines to do text entry correctly, and if you want to do that yourself you need essentially just as much code. The only editors that get close are things like Gmail or Google docs that have pretty much two decades of engineering at this point and often times are using variations of content-editable and textures behind the scenes anyway.

This is not just a Mac-ism, writing your own editor logic means you have to handle chord based key entry, input methods, etc on every platform and that is a lot of work on any of them (not sure what it’s like on Linux, but the old windows ime model is particularly terrible and essentially requires every editor to make guesses as to what IME is being used and then essentially handling the different rendering of each of them yourself by looking at what MS products did - though they often conflicted)

Close, but Eclipse actually has its own toolkit: SWT.

And SWT is built on calling system native components. Of course the “text editor” ends up being one large custom component that has nothing to gain from being in a “native” View.

All of that said, SWT and Eclipse do know that they are running on MacOS. It would be possible to mimic the same behavior, but that’s hard to do because there are so many minute details per platform.

I really like this feature on Jetbrains IDEs, called "camel humps". If I wanna select the entire identifier I click somewhere within then hit Control + G or Option + Up (which expands the selection based on AST)

Marrying it to mac text APIs may be an effort, but after using tree-sitter, I just don't see myself parsing code for displaying or editing any other way.

I'm going to have the Ben Harper song stuck in my head now.

I just came here to say that this name rocks

Text work is real work!

Reply on news.ycombinator.com