1. 79
  1.  

  2. 17

    This kind of thing is why I judge GUI frameworks entirely on the quality of their text editing widget. I’d estimate that the complexity of a good text editing widget is around double the complexity of the rest of the GUI framework combined. I think this is one of the big reasons that the user experience on OS X is often better than Windows. NSTextView is sufficient for building a rich DTP application so everyone uses it, including having a spell checking dictionary shared across every single text editing component in the system. The Windows RichText control is barely suitable for writing an email and so there’s a proliferation of custom ones and all of them behave subtly differently. For example, the multi-click selection behaviour in Notepad is different to most other text widgets in Windows, the paste behaviour in Teams (Electron using Chrome’s text view) is different from Word (its own text view).

    1. 9

      Apple made a deliberate choice to be as consistent as possible, and it sure paid off.

      The near-universal proliferation of native text widgets is one of the biggest things keeping me on MacOS, because they all have emacs bindings.

      1. 7

        Most of the functionality of the text view dates back to OpenStep, some even to NeXTSTEP. There’s a reason that there’s a 1:1 mapping between the things that NSAttributedString Additions can represent and the set of things that HTML 1.0 can represent: HTML was just a serialisation of the things NSTextView can render. There were a bunch of DTP things for *STEP for this reason.

        I recall reading back in the ’90s that the Office team prevented the Windows team from adding better functionality to the rich text control on Windows because they were worried about making it too easy for someone to write a competing word processor. No idea how true this is (I joined the company 20 year after any of that would have happened) but it would explain a lot.

        1. 4

          I worked for a company that makes a web-based document editor. At one point, I “snuck” some of the Emacs bindings into the text editing code, conditioned on the user being on a Mac, because I hated having to use the product without them. Most of our paying customers were on Windows, so they probably never noticed, but I did!

        2. 3

          I’m guessing the Chromium edit control is the most full-featured fully accessible one that’s available on Windows to anyone outside the Office team. I wonder if anyone disagrees.

          1. 4

            Not agreeing or disagreeing with your question. But WebKit/Chromium content-editable mode has tended to be really flaky. Even very recently I’ve been able to reliably mess up editable rich text in nearly any web page by dragging bullet-list items up and down: it generally fucks us the nesting and often the styles of nearby text.

            It turns out that a DOM tree is not the right data model for a text editor — it’s far, far better to use a mutable string/rope with attributes attached to character ranges. Which is exactly what Cocoa uses (NSMutableAttributedString.) With a DOM, many very simple editing operations often turn into super-complex tree manipulations. Unfortunately a web browser is inextricably tied to a DOM.

            1. 1

              Interesting; I wasn’t aware of those problems with DOM editing.

              For native applications, it’s too bad that as far as I know, no clone of the OpenStep APIs (e.g. GNUstep) has accessibility support. I suppose that leaves us with Microsoft’s RichEdit on Windows.

              1. 1

                I got that information from the horse’s mouth, i.e. Ken Kocienda, who did the first iteration of content-editable in WebKit. I was really excited by it but disappointed by how buggy it was, and he explained what made it so hard compared to an ordinary text editor.

                I also had a related experience in an experimental listserv I was writing a few years later. I was trying to prettify emails by cutting out the quoted stuff and the “On such-and-such day foo@bar.com said:” headings and boilerplate signatures. This became super difficult with HTML messages due to messing about with DOM nodes.

          2. 1

            I’d readily agree that Apple got a lot of UX things right. However, as a daily Linux user, something that always rubs me the wrong way is: in OSX, pressing Home and End in a multi-line text widget cannonballs the cursor all the way to the extreme beginning and end of the widget contents. On Linux, it only moves to the beginning and end of the current soft-wrapped line, which is so much better to work with. Going to the extrema is made possible with Ctrl-Home and -End. I realize I can use the trackpad on OSX to get to a specific spot in a text widget; but I don’t want to have to.

            1. 3

              Have you tried cmd-left/right?

              1. 1

                Oh, thank you! I did not know those were available. Now the hard part: Remembering these exist the next time I need them.

                1. 1

                  Option-arrow moves between words.

              2. 1

                in OSX, pressing Home and End in a multi-line text widget cannonballs the cursor all the way to the extreme beginning and end of the widget contents

                I’m not on a Mac right now, but as I recall, it moves the view not the cursor. You can get back by pressing any arrow key (which moves the view back to the cursor location). As with everything else in macOS, command and option are modifiers. As I recall, option moves one word, command one line. On an Apple keyboard, command, option, and function are all in a row and home / end and page up / down are function + arrow key, so all movement in a text box is left-hand modifier + right-hand arrow key.

              3. 1

                Isn’t Notepad just a thin wrapper around a native Windows TextBox control?

                1. 1

                  It doesn’t seem to be (though I’ve not looked at the code). TextEdit on macOS is a tech demo for NSTextView (it’s actually open source, so developers can see how to use NSTextView most effectively).

                  1. 1

                    I have no way of checking myself, but I’ve a vague recollection that it is based off of a combination of some sample code I think was bundled with Visual Studio 6, and that I also recall that Notepad had severe file size limitations for a long time on account of it just being a built-in control.

                    It’s over a decade since I did any Windows development in anger or even really used it, but I guess it’s something that could be checked by inspecting the window class of the control to see if it corresponds to that of a regular textbox control.

                    1. 1

                      Notepad isn’t, but WordPad was shipped as an example application for both MFC and RichEd.

              4. 14

                TFA links to a video that complains that we’re adding too many features to software and it’s affecting robustness.

                That is true in the general sense, but some features are necessary. TFA hints at this as well: it is not reasonable to say that an a11y feature is “unnecessary” or “bloat”; software that the user can’t use is pointless.

                Handling the user’s written language isn’t “bloat”, it’s literally the point of a text editor. That the user writes right-to-left or in a script with a massive number of distinct characters isn’t the user’s fault.

                1. 11

                  …and far better for those complex problems to be solved and features implemented once in a framework, library, toolkit, or OS API than to be re-implemented in each individual application.

                  1. 4

                    I remember a few years ago I saw someone say that emoji input on Android keyboards was unnecessary bloat. Which points to a mental model of software that’s along the lines of “anything that I personally don’t use is bloat”.

                    (Not that I’m accusing TFA of this; as you say, it points out that things like bidi and a11y are necessary.)

                  2. 6

                    I fear no man. But the third Text Edit selection, it scares me.

                    1. 2

                      The feeling’s mutual, I assure you.

                      [ suspicious glare intensifies ]

                      1. 1

                        Yeah, text editing is a complicated two dimensional business. I wonder if any text editing widget actually handles something top-to-bottom like traditional Mongolian script correctly.

                        1. 1

                          Indeed this is one of the problems here.

                          Simple editors are designed for linear text. Which makes sense because the text content is linear. Except that we want to have text in different languages intermixed. Is this still editing text then? One could argue.

                          In the opposite direction, one could argue that text editing should include things like bold/italic/underline, after all newlines are a formatting choice as well not part of the text content. And for most modern “text editing scenarios” those would be useful.

                          The task is not exactly well defined from an architectural point of view which is also why the solutions are a more complicated than many people might expect.

                        2. 1

                          I get the point but I also managed to do absolutely everything I needed to do with text on a computer without that much frustration.

                          Yes, it should/could be better but isn’t that true for literally everything in the world? I believe that as long as I manage to get my task done in a non-frustrating way then it means it’s good enough.

                          That’s why I never bothered really learning vim: it’s too frustrating when you get stuck that I simply find it silly having to waste time with an editor that actually seems to hate me, if I mix-match arabic, chinese, emojis, skintone modifiers, and some software doesn’t get it perfectly right, I’m OK with that.