[HN Gopher] Text editing hates you too (2019)
___________________________________________________________________
Text editing hates you too (2019)
Author : tate
Score : 196 points
Date : 2021-05-21 17:12 UTC (5 hours ago)
(HTM) web link (lord.io)
(TXT) w3m dump (lord.io)
| wdb wrote:
| These days I make sure I am away making a cup of tea when these
| kind of topics are discussed at work. After writing a syntax
| highlighting editor in Delphi and a rich text editor in Flash/AS3
| I try to avoid it.
| bombcar wrote:
| For people involved with technology I think this is a perfect
| response to "how hard can it be" - no matter if they're
| discussing how to keep toilet paper stocked or why cURL can be
| replaced with five lines of shell script - it emphatically shows
| how complicated something apparently simple can be once you start
| diving into it.
| tonyedgecombe wrote:
| Strings, dates, floating point, even true and false are messy
| in some languages.
| slver wrote:
| Things are as hard as we allow them to be. You know, fixed
| width ascii terminals in text mode sure were much easier in the
| 80s
| tonyedgecombe wrote:
| Only if you didn't leave the US. Over in Europe (and I assume
| Asia) it was a constant source of problems.
| oblio wrote:
| And then we discovered that not only English speakers want to
| use PCs.
| geenew wrote:
| Didn't extended ASCII cover that and make text terminals
| usable with non-English character sets? Genuinely curious.
| skrebbel wrote:
| How would you use extended-ascii to write Arabic?
| superjan wrote:
| The following was actually used:
|
| https://www.charset.org/charsets/iso-8859-6
|
| There's no single byte encoding for Chinese, Japanese, or
| Korean though.
| enqk wrote:
| In practice, young folks write arabic with roman script
| when they chat. (with numbers to supplement the missing
| letters)
| qsort wrote:
| Extended ASCII was actually several different and
| incompatible encoding, "codepages". It was kind of a
| solution, but there were major issues that made it much
| worse than Unicode/utf8:
|
| - Asian languages needed special encodings, 256
| characters weren't sufficient.
|
| - It was impossible to work with different languages in
| the same document, each codepage only covered some
| character/alphabet.
|
| - There was no 'safe subset': Unicode codepoints 0-127
| are exactly ASCII, which means that ASCII is compliant
| utf8. The same wasn't true at the time.
| pjc50 wrote:
| Not even just non English speakers, we in en-gb land had
| enough trouble getting PS to work 100% of the time, which
| was kind of a basic requirement for business use.
| crazygringo wrote:
| No, things are as hard as they _need_ to be.
|
| Fixed-width ASCII terminals didn't work for virtually anyone
| except English-speaking users.
|
| Turns out the entire world needs to use computers.
|
| That's a "need". Not "allowing".
| slver wrote:
| It depends how big you think. Dealing with status quo,
| things like text direction are necessary complication.
|
| But at a higher scale it's purely incidental complexity:
| you only need one direction for all languages. All
| languages are linear. No language uses direction to encode
| meaning. Direction in language is just "stuff starts one
| place and ends in another".
|
| Balkanization of the encodings is not a good thing. Imagine
| if every city had a different color for a traffic stop
| light. Why not? Maybe it's a matter of cultural pride. What
| if every country had its own network protocols? Imagine
| what a nightmare internet would be.
|
| But thankfully we had common sense in few cases. In many
| others we don't.
|
| And Unicode is full of incidental complexity itself. Did we
| really need skin color emoji. Who is yellow here? Anyone
| being brightly yellow perchance? No. We had the perfect
| abstract color for emojis.
|
| But now we have to deal with this shit.
| zaptheimpaler wrote:
| ?srekaeps hsilgne-non lla rof sdrawkcab txet lla ekam ot
| si noitulos ruoy oS
| slver wrote:
| > ?srekaeps hsilgne-non lla rof sdrawkcab txet lla ekam
| ot si noitulos ruoy oS
|
| So you just said all non-English speakers use right-to-
| left? No, the direction isn't what's confusing me, rather
| the fact you're trying to score a cheap outrage comment,
| but actually wrote non-sense no matter which direction
| you read it.
|
| How about maybe educate yourself a little, and rephrase
| your question to reflect reality, and we can have an
| intelligent conversation about it.
|
| Most of the world uses left-to-right and top-down (yes
| look around when you go out and notice all the vertical
| logotypes in English around the city). Right-to-left is
| relative minority. If you have democratic thinking and we
| gotta vote for it, the winner is obvious. Yet, I'd rather
| learn to read fluently English in right-to-left than the
| current mish-mash of "whatever".
|
| Also read about Korean. It was a top-down right-left
| language, today it's written left-right. People are
| surprisingly adaptive, you know, it's supposedly our top
| advantage as a species. No one is born with "right-to-
| left" grafted in their DNA. We honestly gotta tone down
| the ignorance in these discussions.
|
| My native language isn't English, by the way. And I don't
| mind adapting.
| zaptheimpaler wrote:
| Okay, well sorry I was being snarky, so let me try to be
| a bit more serious.
|
| You are proposing that we teach millions-billions of
| people a new way to write, rather than teach a few
| hundred thousand at most how to write computer programs
| that accommodate existing ways of writing.
|
| Like maybe you underestimate how genuinely ridiculously
| hard of a problem it is to get billions of people to do
| anything! It would take literal decades of work by
| multiple governments and unimaginable amounts of money!
| Getting 10 people to agree on a favorite programming
| language is hard enough. Teaching a city full of kids a
| new way to multiply numbers takes 1000s of hours of prep,
| planning, syllabus development etc. by teachers. Just
| imagine how much harder this is.
|
| Certainly I can see how nice it would be if the whole
| world used the same date format, same language, same
| metric system etc.
|
| But from a practical point of view, making systems to
| accommodate the way people do things is 1000s of times
| cheaper and easier than getting them all to change.
| crazygringo wrote:
| I'm not who you're responding to, and obviously the
| commenter should have said "some" non-English speakers
| rather than "all".
|
| But the main point is still obvious and true: how would
| you like it if another country was a dominant
| technological power and we all had to re-learn to read
| and write English backwards precisely like that to use
| computers?
|
| No need to get snarky about it. Comments like "maybe
| educate yourself a little" are against HN guidelines. [1]
|
| Also, Korean is different because the characters
| represent entire syllables, so legibility isn't impaired
| as much by direction. CJK scripts have historically been
| flexible in direction in a way that Latin scripts never
| have been.
|
| [1] https://news.ycombinator.com/newsguidelines.html
| slver wrote:
| > how would you like it if another country was a dominant
| technological power and we all had to re-learn to read
| and write English backwards precisely like that to use
| computers?
|
| I'd actually like it.
|
| You know, thanks to this we have Murican Internet that's
| the same stack everywhere. How would YOU like it if
| "Internet" was just your country?
|
| We gotta disentangle this obsession with encodings as
| some kind of national cause for pride. Encodings are
| INCIDENTAL. Encodings are LEARNED. You weren't born
| reading right-to-left or left-to-right and you can switch
| both in surprisingly short amount of time, if you
| bothered.
| crazygringo wrote:
| Pride doesn't even matter here. It's simple economics.
|
| It's far less effort and cost for developers to
| accomodate the world's existing scripts, than it is for
| the vast majority of the world's population to re-learn
| how to read and write a new script.
|
| By orders of magnitude.
|
| And obviously, it's not _just_ direction that differs
| from English but a whole host of other aspects as well.
| brulard wrote:
| I see it the other way. It would be actually orders of
| magnitude less effort for the rest of the world to learn
| one standard system/language than to have every
| app/product/document adapted to every single
| language/script/whatever in existence
| crazygringo wrote:
| That's just factually untrue.
|
| The percentage of the world population involved in script
| adaptation and language translation is really quite tiny.
| Consumers vastly, vastly, vastly outnumber producers.
|
| Not to mention that we have things like automated
| translation that are "good enough" for many cases as
| well.
|
| Whereas learning a new language to fluency, for most
| adults, takes about ten years.
| antris wrote:
| >the rest of the world to learn one standard
| system/language than to have every app/product/document
| adapted to every single language/script/whatever in
| existence
|
| But they don't. That's precisely why the text input
| handling is so difficult, because it has to solve it for
| all apps. How many apps have you worked on that has had
| to create their own text input system from scratch? I
| think for most developers that's zero.
|
| Like the article said in the end:
|
| _> The necessary complexity here is immense, and this
| post only scratches the very surface of it. If anything,
| it's a miracle of the simplicity of modern programming
| that we're able to just slap down a <textarea> on a web
| page and instantly provide a text input for every
| internet user around the globe._
| slver wrote:
| > It's far less effort and cost for developers to
| accomodate the world's existing scripts, than it is for
| the vast majority of the world's population to re-learn
| how to read and write a new script.
|
| That's the short-term analysis. But this is not a short-
| term impact change. And in the long-term, things turn
| around.
|
| If as a species, we can't think long-term, we're
| basically doomed.
| bombcar wrote:
| It's not the last time major portions of the world
| fundamentally changed how they did things to align with
| the major powers at the time.
|
| Even WITH all the Unicode support that currently exists
| in the computing world I don't know of a single computer
| language that isn't based on English in ASCII. I guess
| you could count APL there (or perl!).
| KineticLensman wrote:
| > I don't know of a single computer language that isn't
| based on English in ASCII
|
| https://en.wikipedia.org/wiki/Non-English-
| based_programming_...
| dijit wrote:
| I think if you're reaching for _brainfuck_ as one of the
| solutions for the prevalence of English in programming;
| then you've probably failed.
|
| A few of the languages on the list are designed precisely
| to be unreadable.
| KineticLensman wrote:
| my link contains programming languages based on Arabic,
| Chinese, etc, not just unreadable esolangs
| slver wrote:
| Imagine if Europe was pre-metric system today. Merely
| proposing unification I'd be instantly downvoted, and
| called a bigotted racist who doesn't respect the cultural
| heritage of every nation.
|
| Unfortunately those are the times right now. We, the most
| adaptable and intelligent species on the planet, have
| become used to bragging about not having to adapt or know
| a lot. We sure do have really strong opinions about
| everything, though.
| bombcar wrote:
| I think that's the dividing line - each person decides if
| it's worth it to learn something new. For example, some
| people love foreign media so much that they trade fansubs
| of said media or even learn the language so they can
| watch.
|
| Someone who wants to program computers will most likely
| learn functional English, just because of how much
| content on that subject is in English (the "lingua
| franca" of computers).
|
| But someone in Mongolia who wants to text his mom has no
| inclination to learn a whole new language just to handle
| the limitations of ASCII. _And if you want to sell him a
| phone_ you 'll meet him where he is.
|
| (This doesn't even begin to touch the "it's not fair"
| aspect that people like to point at.)
| slver wrote:
| You PoV is understandable, but still do you believe the
| ongoing long-term pain of this fragmentation is LESS than
| the short-term pain of unifying?
|
| This is why I mentioned the metric system, and what not.
| Every time throughout history when we decided to unify,
| the advantages VASTLY, and I mean VASTLY have outweighed
| the short-term drawbacks.
|
| In fact I'd say, one of the biggest test for us as
| species is that we can fully understand, internalize and
| implement this concept. Because we always reach for the
| short term. Short term profits over long-term strategy in
| the enterprise. Short term economy benefits over long-
| term climate impact. And so on and so on.
|
| Someone in Mongolia won't have to switch overnight.
| Someone in Mongolia may gain the option to have it both
| ways until they're used to it, and eventually there will
| be unification. That's basic change management.
|
| Change management is a necessary art to survive and to
| thrive.
| colllectorof wrote:
| More often than not a problem that looks simple and has insane
| complexity once you dig a bit deeper is based on some faulty
| assumptions. Assumptions that either changed over time or never
| made sense to begin with. The wast majority of software systems
| out there are _significantly_ simplifiable. However, not all
| developers are willing to analyze and question fundamental
| assumptions about systems they deal with. Most, in fact, are
| far more comfortable learning to jump through arbitrary hoops.
| They then brag about their "expertise" in the "domain" (which
| often doesn't even exist outside of software).
| leoc wrote:
| Alan Perlis' old motivational-poster slogan "Fools ignore
| complexity. Pragmatists suffer it. Some can avoid it.
| Geniuses remove it." has a fair bit going for it.
| oneeyedpigeon wrote:
| I love that apart from the "Some can avoid it" bit -- feels
| out of place with the rest. Who's "some"? Pithy slogans
| often come in three parts rather than four; I love the
| overall message, I think I'd just prefer it with that 25%
| removed.
| alex_smart wrote:
| Does that mean that Geniuses would be terrible software
| engineers, since removing complexity is seldom the right
| thing to do business-decision wise?
| bsder wrote:
| > The vast majority of software systems out there are
| significantly simplifiable.
|
| I think exactly the opposite, actually.
|
| Most programmers don't just write lines of code for no
| reason. They generally stop when the problem is solved.
|
| So, you might be able to simplify new programs, but I
| wouldn't put a lot of money on it. The programmer would have
| had to miss something architecturally up front for that to be
| the case. It happens, but it's not that common.
|
| So, you might be able to simplify production programs. Maybe,
| but those have a lot of bug fixes already implemented. And
| they encode the political state of the entity that built it
| (see: microservices). So, a program that has existed a while
| may not encode the _current_ political system, but I don 't
| think fixing that is making things simpler.
|
| So, you might be able to simplify legacy programs. Perhaps,
| but those have a _LOT_ of business state encoded in them--
| much of which is still used occasionally but you won 't know
| that until you do a deep dig on the code. That rule for
| disbursements to Civil War descendants is there because the
| system still needed it up until a couple years ago.
|
| Oddly, the best way I have found to simplify _computer_
| systems is to give the _humans_ more power. Humans are good
| at exceptions; computers not so much. This is, sadly,
| anathema to modern programming and modern political
| /corporate structures.
| notriddle wrote:
| > More often than not a problem that looks simple and has
| insane complexity once you dig a bit deeper is based on some
| faulty assumptions.
|
| Okay, I'll bite.
|
| What are the faulty assumptions that cause text editing
| widgets to be so complicated?
| cgriswald wrote:
| I think there's some context that matters. I often don't need
| the full functionality of _ubertool_ and can implement the
| functionality easily because I don 't have to worry about 90%
| of use cases with their associated edge cases. It's dead simple
| to keep toilet paper stocked in my house. But I would not use
| the method I use for my house to run inventory for a grocery
| store chain.
| shard wrote:
| That's exactly the point. The "how hard can this be" comments
| are often applying an individual use case, where corner cases
| can be ignored or worked around, to an enterprise situation,
| where corner cases may hit some legal constraints (e.g.
| accessibility) or may no longer be corner cases once in
| enterprise-scale (e.g. multiple languages / currencies / time
| zones).
| 7373737373 wrote:
| This seems to be the ideal occasion to show off my latest pet
| project: https://icebergcharts.com
| cocoa19 wrote:
| Pretty cool. It would be nice to have one entry for computer
| science.
| 7373737373 wrote:
| Yeah, the Ultimate Minecraft Iceberg was already pretty
| surprising to me, I hope more subject matter experts will
| contribute
| benboughton1 wrote:
| For someone not overly ear to the ground culturally this is a
| rabbit hole. The Youtube one fascinates me. I've not heard of
| most but imagine there are hundreds of interesting stories
| behind every item. Interesting work and concept. Well done.
| shard wrote:
| Wasn't there a post or (most probably) a comment recently
| (within a month or so) with an iceberg chart? It looked very
| much like this site, but I can't find the right subject.
| Someone even commented that one of the best links in the
| chart was to a fictional story on the site itself. For the
| life of me I can't recall what the subject of the iceberg
| was, except that I think it was technology related, but I did
| spend several hours digging through all the links.
| shard wrote:
| Ah, found it in search. It was this one:
|
| The Cursed Computer Iceberg Meme
|
| https://suricrasia.online/iceberg/
| 7373737373 wrote:
| Yep, that's where I got my inspiration (and some CSS) from,
| and I also link to it in the footer on my site:
| https://suricrasia.online/iceberg/ :)
| noofen wrote:
| This is fantastic. My only wish is to be able to export them
| as a PNG... maybe add a small watermark so people can find
| you.
| 7373737373 wrote:
| If you scroll down there is "Download as Image" :)
|
| I'll try to create an unobtrusive watermark
| noofen wrote:
| Oh, I see. Perfect!
| SavantIdiot wrote:
| See! Irony at work: it wasn't good enough for you so you
| wanted a feature. That's where it all starts. I'm not
| dissing you, I'm pointing out how innocuous feature creep
| can be.
| LeifCarrotson wrote:
| I appreciate that "making a ****ing iceberg chart" is at the
| bottom of the Hobbies iceberg :)
| [deleted]
| Oddskar wrote:
| Having touched adjacent technologies to this as well, I could not
| shake the feeling that text editing on the web, and WYSIWYG text
| editors especially, would be _very_ well served by some sort of
| common understanding and agreement of output given certain
| inputs. As alluded to in the article, the devil really is in the
| details in this domain. When one knows what to look for, most
| rich text inputs really miss the mark in understanding intent and
| doing something reasonable on behalf of the users.
|
| An interesting example is the recent trend to start interpreting
| selection of text + pasting of a link as "turn this text into a
| link using the URL in the clipboard". It just makes complete
| sense. When would I ever want it to be "please delete the
| selection, and instead paste the URL"? Probably not very often.
| This is just one tiny example, but there are lots and lots of
| those in text editing.
|
| My gut feeling is a lot of the time this is all left to
| individual engineers to try to decipher the user intent; I would
| assume for the most part they either copy their peers or do a
| best effort guess.
|
| What if there was some sort of test suite one could run instead?
| Like a large number of test cases built upon interactions with
| actual users.
| breischl wrote:
| >selection of text + pasting of a link as "turn this text into
| a link using the URL in the clipboard"
|
| Seems like an interesting UX debate. It's a handy shortcut, but
| it makes "paste" modal depending on what's in the clipboard.
| Pasting might replace the selected text, or might link it. And
| because the behavior depends on whether the clipboard text
| "looks like" a URL, there's an element of DWIM (Do What I Mean)
| in there. Does it only handle http:// links? What about www.?
| Or mailto:? etc.
| Steltek wrote:
| I haven't experienced the behavior described but reading it,
| I instantly hate it. It would differ from every other program
| I use.
|
| I'd counter with there should be two different paste actions
| in every program: plain and smart. I almost always don't want
| to preserve rich formatting when I paste text. It looks like
| my cat walked over the keyboard while I was typing. The
| action to paste as plain text versus a fancier/DWIMy method
| is often different from program to program.
| ptr wrote:
| Slack does it, and I had it happen to me once. It was
| unexpected and added extra frustration when I was already
| stressed.
| ska wrote:
| This is why you eventually end up with Word's paste
| modifier icon....
| crazygringo wrote:
| > _all left to individual engineers to try to decipher the user
| intent_
|
| When it comes to a lot of text _rendering_ , Unicode does
| specify most of it along with test suites.
|
| While text _input_ is really mainly two large teams: one at
| Microsoft and one at Apple. While they probably don 't talk to
| each other much, they probably do wind up copying each other
| for the benefit of users.
|
| I'm not really sure what open-source GUI's do, but probably
| mainly try to copy Microsoft+Apple.
| deckard1 wrote:
| Regarding the vertical cursor movement, back in the day there was
| an alternative behavior. You can see this in
| QuickBASIC/QBasic[1]. Here, Microsoft treated the entire screen
| as a grid. I always thought that was a great UI. It hides the
| fact that there are line endings (\n on Unix or \r\n for DOS).
| And why shouldn't it? That's an implementation detail. And as
| evident by DOS using CR+LF it goes back to the days where you had
| an actual physical carriage on a typewriter. Nearly every modern
| text editor you have to type out the spaces/tabs you want to
| reach the area you what to add text. In QBasic, you just move the
| cursor wherever you want on the screen with arrow keys and start
| typing. Because, unlike a typewriter, a computer screen is 2D.
| Vim has block mode but, AFAIK, can only work on selections. Of
| course, this is not universal and only works with monospace fonts
| in certain languages. But back in the day it made it easy to
| create ASCII/ANSI diagrams and art.
|
| Modern text editing is a multilayered mess. Rendering, input
| methods, variable width fonts, and the special codes (markdown,
| etc.). On some sites it's not even self-consistent. Take Jira.
| Last I checked, they have one editor for creating a ticket and an
| entirely different editor for editing that same ticket[2] (one of
| these editors sucks more than the other, but I can never remember
| which... but neither one is remotely what I would consider a
| "good" interface). How they got there is truly the 8th Wonder of
| the World.
|
| [1] https://archive.org/details/msdos_qbasic_megapack
|
| [2] https://community.atlassian.com/t5/Jira-Software-
| questions/H...
| crazygringo wrote:
| Sadly, that's not a possible alternative behavior for a world
| where proportional fonts exist. It's for monospace only.
| deckard1 wrote:
| as I said
|
| > Of course, this is not universal and only works with
| monospace fonts in certain languages.
|
| But even then, monospace didn't go away. Most developers are
| working with code in monospace right now.
| megameter wrote:
| Monospace is the more sensible option as an editing medium
| for symbolic content. It's in having "WYSIWYG" editors that
| do everything in one modeless widget that we start getting
| this particular kind of feature creep.
|
| And considering how awful it tends to be to navigate a
| complex word processing task in Word or LibreOffice even
| now - mystery-meat selections abound - I'm not sure this is
| the right feature to support all of the time.
| crazygringo wrote:
| Speak for yourself.
|
| Proportional fonts are more aesthetically pleasing and
| legible (the entire reason for their existence).
|
| When I'm editing "symbolic content", I like it to be easy
| on my eyes. If I'm constantly re-reading what I've just
| written, I appreciate the added legibility.
|
| (With the exception of heavily punctuation-based computer
| code, of course, where monospace results in greater
| legibility.)
| pessimizer wrote:
| I rarely care about my position on the "page" unless I'm
| typesetting something (otherwise I'm just typing from X
| number of tabs in), and when I'm typesetting, I'm not going
| to use a monospaced font very often.
|
| I liked doing ANSI art back in the 80s, but that's not
| really interesting outside of terminal connections to a
| BBS.
| qsort wrote:
| > you have to type out the spaces/tabs you want to reach the
| area you what to add text
|
| If you move the cursor to an empty area and start typing,
| should the missing characters be tabs or spaces then? Or NULs?
|
| Also, how do you insert spaces/newlines/tabs in between other
| text? Everything would be implicitly modal.
|
| It's good UI for some things, but it's not as good for a
| general editor like vim. I'm not looking forward to write
| Python with it, for example :)
|
| IIRC the Commodore 64 did something similar with its built-in
| Basic prompt.
| deckard1 wrote:
| Fun fact: Python and QBasic both came out in 1991. Though
| QuickBASIC is a few years older.
|
| > should the missing characters be tabs or spaces then?
|
| I'm not sure what QBasic does. But it's irrelevant since they
| control the format and the display. All Microsoft needed to
| care about is whether the file displays the same as before
| when loaded.
|
| But it's really no different than text editors that let you
| switch a tab character to insert 2/4/8 spaces. If you've ever
| had the misfortune of working on a code base that allowed
| both tabs and spaces (fake tabs) then you'll be keenly aware
| that plaintext has always been modal. Your editor either has
| to figure out how many spaces to display a tab character, or
| how many spaces to insert on the tab key. Even line endings,
| CR+LF vs. LF. I think Mac even just used a single CR once
| upon a time.
|
| Makefile is another format that is particular about requiring
| an actual tab character. The first time I "discovered" this I
| had the urge to toss my computer out the window. That was
| probably the late '90s when that sort of information was a
| bit more difficult to come across.
| billforsternz wrote:
| I think this feature is called 'virtual space'. I like it too
| and would always look for it and turn it on if available in any
| text editor I used. But it's not as common as it once was.
| skymt wrote:
| Vim supports the style of editing you describe; see the
| documentation for the 'virtualedit' option.
|
| https://vimhelp.org/options.txt.html#%27virtualedit%27
| genpfault wrote:
| Previously: https://news.ycombinator.com/item?id=21384158
| floatingatoll wrote:
| Also "Text Rendering Hates You", referenced by this post,
| previously: https://news.ycombinator.com/item?id=21105625
| jll29 wrote:
| A good article, which shows that even plain text editing (without
| any formatty) is already way more complex than a layperson may
| appreciate.
|
| For the developer, there are some gems to be discovered when
| writing a text editor; recall that using regular expressions
| coverted to finite state machines saw the light as part of
| editing, and I remember being given a very cool paper (from the
| 1960s!) by my undergrad compiler construction professor that
| proposed an efficient algorithm for testing whether a string
| containing a line of text can possibly be a substring of any
| valid Pascal program (it was a piece of theory invented while and
| for a syntax-aware Pascal editor, possibly from IBM but not
| sure). Another thing is data structures: I learned of ropes, an
| alternative to strings for representing text (optimized for fast
| editing) in the context of text editing:
| https://dl.acm.org/doi/10.1002/spe.4380251203
| jmcphers wrote:
| There's a new(ish) editor called Xi that's built on the rope
| data structure: https://github.com/xi-editor/xi-editor
| reificator wrote:
| Just a heads up: That editor project, while conceptually
| interesting, is currently abandoned.
| Narishma wrote:
| I don't think that's still actively developed.
| PaulHoule wrote:
| You know, every text editing system I've seen that knocks off
| word (has those "bold", "italic", etc.) selectors has something
| anomalous in how selections are handled.
| mihi wrote:
| Yes! So much this. I usually wish they'd just give me markdown
| or similar and only convert after I'm done. Slack is a
| prominent offender there.
| pood wrote:
| I went to collage with this fella. He is a smart cookie. If you
| have not checked out his other blog posts they're all p good.
| pcwalton wrote:
| > Jonathan Blow, in a talk about how software is getting worse,
| points to the example of Ken Thompson's text editor, which Ken
| built in a single week.
|
| This kind of sentiment drives me crazy. Yes, internationalization
| makes things harder and more complex than they were in the old
| days. But, back then, only people who lived in one small part of
| the world were able to usefully use computers in their language.
| (Simply supporting the Unicode character set is not enough.)
| Nostalgia for the simplicity of the past ends up having ugly
| cultural implications. It's easy to say "let's go back to the
| time when things were simple"; it's a lot harder to say "folks in
| (e.g.) Israel shouldn't be able to type in their native
| language".
| hannasanarion wrote:
| Especially since the text editor in question is `ed`, which is
| not exactly a pinnacle of utility. We're really comparing
| apples to moon rockets here.
| qsort wrote:
| `ed` was developed in 1969. That's a remarkably uncharitable
| take, considering `ed` itself and its derivatives (like
| `sed`) are still useful today.
| hannasanarion wrote:
| No more uncharitable than saying that modern developers
| suck at their jobs because they can't make Sublime Text in
| the same time as it took Ken Thompson to make ed.
| qsort wrote:
| That's not the point of the article, not even remotely.
| colllectorof wrote:
| _> Nostalgia for the simplicity of the past ends up having ugly
| cultural implications. It's easy to say "let's go back to the
| time when things were simple"; it's a lot harder to say "folks
| in (e.g.) Israel shouldn't be able to type in their native
| language"._
|
| This is a _ridiculous_ mischaracterization of what Jonathan
| Blow was talking about.
|
| Here is the full presentation. Very much worth watching in its
| entirety and thinking about:
|
| https://www.youtube.com/watch?v=pW-SOdj4Kkk
| slmjkdbtl wrote:
| > This is a ridiculous mischaracterization of what Jonathan
| Blow was talking about.
|
| I watched the full presentation and agree with almost
| everything he said, but I can't find a part matching the
| conflict between "Simple text editor Vs. Complicated
| character encoding scheme / rendering / formatting". How
| would JB make a text editor that works with any kind of
| character?
| phkahler wrote:
| On the emoji color (skintone) modifier... A normal person wants
| to select their emoji from a set. Only a programmer would allow
| the user to input a tiny program with a symbol and a color
| modifier and then interpret it.
|
| If you want to make text editing a little easier, treat every
| character along with any style applied to it as a single entity.
| This way you avoid a lot of potential problems like in TFA as
| well as things like nesting of modifiers that may not be allowed
| to overlap - output those when all the characters are complete.
| In other words, don't track tags but generate them as a post-
| process when storing the data.
| akersten wrote:
| Yeah, the "Bad #2" example, how Chrome does it, makes perfect
| sense and seems correct to me. Modifiers get removed when the
| character they're modifying is removed. I would say _leaving_
| the modifier and applying it to the previous character would be
| certainly incorrect (unless you 're in a hex editor, in which
| case combining the bytes as emoji at all is questionable).
| Imagine it were two different emojis and a skin color modifier
| after the last one (and somehow, through a rendering bug, the
| skin color modifier hadn't auto-combined) - OP's precedent for
| what happens when deleting the middle emoji would move the
| modifier to the first emoji! Clearly wrong, especially if it
| then decides to auto-combine.
|
| I mean, the example is pretty contrived in the first place:
|
| > Whoops, I didn't mean to put the a there.
|
| How in the world are you typing emoji such that you have to add
| the skin color modifier separately that would even afford an
| opportunity for an errant character to get inserted between?
| Windows numpad alt codes?
| Hackbraten wrote:
| Please add (2019) to the title.
| dang wrote:
| Added. Thanks!
___________________________________________________________________
(page generated 2021-05-21 23:00 UTC)