For data that isn't part of the document, you could use a write-through wrapper around the rope, with a secondary data structure mapping ranges of the document to this extra data.
From the wrapper's point of view, there's no difference between character and non-character data, and the whole buffer can be modeled as a collection of indices mapping ranges of the document to different kinds of data.
One of those indices could be a rope (mapping document ranges to character data, for the document text). Other kinds of indices could also be used. The important thing is that all edits go through the wrapper so that all the relevant indices get updated.
I’ve actually been using an almost identical filter for GraphViz markup in my university papers for the last year, except I added a leading exclamation point to the language tag to distinguish between included source and included markup:
```!dot
(Markup)
```
I wish they’d adopted something like that instead - I have no idea how you’d include highlighted Mermaid source in a GH markdown file.
I'm not a web dev, but I'd guess this is because the implementation relies on browser storage, which is removed when a private browsing session ends. So possibly it would work, but only until the tab / window was closed?
An alternate interpretation of the same data - if you're committed to writing a program in a language that requires a runtime / does a lot of work on startup, writing a program that prints "Hello, World!" does not make the most effective use of that language and runtime.
Put that way, most of this post seems like a tautology: if you misuse the tools you are given, of course you're going to get bad results!
It seems reasonable to me that a language should make the assumption that the programmer's use case matches the languages strengths, so by default any runtime setup / bookkeeping / teardown code should run. Failure to remove that extra "complexity" isn't a failure of the toolchain, it's a failure of the programmer to select the right tool for the job.
If the point the author was trying to make was that the complexity being added is never useful, this is not a post that argues that position. A cost / benefit discussion of the specific behaviours being supported by that complexity would be very interesting!
Does it though? iTerm2 is the most feature-rich terminal I've ever used, and even then it's several orders of magnitude smaller then Electron (cloc says it's around 111K lines of Objective-C, with around 38K more lines split across Python and C++).
Also, from what I can tell posts like this are a lot more high-profile than court cases. I haven't seen or heard of many court cases dealing with this, and when I have it's been via a blog post. Calling the police might be helpful in the specific case, but unless it really is high profile, it's not going to help change the culture.
Every time I see posts like this, I see people commenting on it with varying statement to the effect of "that's a shame, but most people in tech aren't like that", or "I'm so tired of seeing posts like this, quit making a fuss."
And that makes me so angry.
Sure, maybe not everyone in the industry is an arsehole. But enough people are, and those people are vocal enough, that a significant number of people feel disgusted and threatened. That should be enough to tell you that even if the majority are lovely people, the industry as a whole still has a problem.
(also, for anyone wondering whether the number of people affected really is "significant", I would consider even one person to be a significant number)
I also get really angry at posts like "This has never happened to me, so I'm sure it's all ok". This may come as a surprise, but individual experiences are not universal. That something has never happened to you doesn't mean it's never happened to anyone else.
And if you're getting tired of seeing posts like this, don't complain about the people making the posts. Complain about the people harassing them. It may seem counterintuitive, but the fastest and most effective way to stop posts like this turning up is actually to make more of them, until the harassment and abuse stop.
"This happens all the time" is never a valid excuse.
Except that both emacs and vi can be (and have been) ported to a number of other operating systems. Systemd is tied specifically to the Linux kernel and the Linux infrastructure, in much the same way as launchd is in Mac OS 10.x. It might be more correct to say that in the emacs vs. vi debate, systemd is TextMate.
Wide adoption isn't an indication of merit - look at the wide adoption of Windows for an example.
Anyway, for all the developer convenience and technical merit systemd has, it doesn't support an open OS environment - it restricts freedom in favour of convenience, which is precisely the opposite of what many users prefer Linux for.
From the wrapper's point of view, there's no difference between character and non-character data, and the whole buffer can be modeled as a collection of indices mapping ranges of the document to different kinds of data.
One of those indices could be a rope (mapping document ranges to character data, for the document text). Other kinds of indices could also be used. The important thing is that all edits go through the wrapper so that all the relevant indices get updated.