eviks

> Fortunately, thousands of years of writing systems walked so emoji could run .

This fortune is imaginary, otherwise you would've skipped "the inventory phase" with emojis because you've supposedly learned to walk thousands of times in those thousans of years

> I usually propose that we unify the common subsets of the Cyrillic, Greek, Latin, and Mathematical glyphs which usually finally drives home the point.

That would be an awesome compact encoding scheme (and also help with the next 4million emojis)! And given the relatively higher importance of those CyrGrLat, it would force wider proper support that would resolve the issues you raised, which are all app-dependent

> But, they are invisible to the end user

Apps make them visible, some even do that for whitespace chars to highlight the difference

> can disappear while copying and pasting

broken clipboards can be fixed? They somehow manage to retain rich text formatting, surely they cna retain language markers?

> you have to rely on the original author even putting them there in the first place!

Nope, the author's input app can handle that just like the original author doesn't need invisible joiners to use composed emojis

Egui is an order of magnitude more common than iced

Why do you say 0 tests? Are the other statements similarly precise?

If you're dreaming, why would you stop at that when you could dream of much more visually compelling solid left thick border in a single symbol

┠

or more explicitly

├2

that'd be perfectly paired with a dream-like visual designer that doesn't exist?

My claim was much simpler, you've just ignored it as a junior who's never seen an app deteriorate over time because that's technically impossible, progress only marches forward!

But to your point - sure they are, not only in RAM, but also disk space, battery use, and startup speed etc. Some parts of them are fast, but in that suboptimal stuck-in-a-slow-niche kind of way like V8, which a better alternative would just get rid of (no doubt, great engineering once you learn about the almighty "trade-offs" that can excuse any performance failure)

Firefox is much worse in customizations in basics like keyboard and mouse controls

> I'm sure they'll run more efficiently than the rendering engines that have been refined and tweaked over the course of now multiple decades.

What top-level engineering experience led you to believe the magic of multiple decades guaranteeing improvements?

Think still has no accessibility, and given that the public framework is abandoned might not get there

One improvement could be a better way to group and elide units, e.g.

Instead of

.border_1().border_color(rgb(0x0000ff))

You get

.border(1 0x0000ff)

(guess, this can only be in a macro)

Or at least have "color" which understands that it's allied to border instead of having to repeat "border"

> I don't think that it can be substantially better

Don't give up too early, there is no way it can't be, we don't really have any good systems optimized for ergonomics to reach anything great

> downloaded a tampered Homebrew installation “to install a popular AI coding tool after searching for it on a search engine,”

Decades of operating system development and you still don't have a simple way to install apps...

It's not a version of obsidian, which is unlikely to ever get as powerful and fast as the better code editors

Indeed it feels like that - still waiting for a cross-platform support...

What do you need to click to edit it?

> Users will get a “customize menu” button that controls what commands appear when they right-click their mouse

Good, though doesn't seem to be include the ability to control icons, name and accelerator keys, so still a long way to reach the user ergonomic heaven...

but still unreasonable. In the presence of issues for each of the two options, you pick the correct one unless you have rather strong reasons, which they don't:

> U+2800 is clearly used as a symbol, to indicate the presence of a space when describing a Braille sequence corresponding to a symbol or punctuation, similar to the use of ␣

Why is that? Have you perhaps forgotten to add "␣" equivalent for Braille? So maybe do that instead so people can us a mark to mark something?

> Especially in cases where it is used in a trailing position, as in the [UNE13] example, it is clear that it would be inappropriate for this symbol to disappear

Nothing disappears in the cited example, the line is very short , how is it possible to reject a fix when you can't even find an example of that fix breaking someone?

> last changed in

and this approach is why we can't have nice things and generations of computer users continue to suffer due to some dumb oversight decades ago. And it's not like we get a payoff of great stability, not, that standard is uber complicated and changes all the time

> We define some bar

Go on - define a bar here.

> just that it needs to exceed a threshold

Same. Be specific.

Do you have any examples illustrating how it's better?

But an evil midllman will relatively easily be able to give you non-free version, so that feeling should be fleeting

That would also be trivial for a syntax-tree-based tool, right?

Yes, but also wrong. Normalization like the one mentioned in the post is the mistake, not Unicode characters

Indeed, the ossification of this old absurdity can be helpful, also for visual alignment within names.

This prompted me to finally dig a bit and find the official reference why they didn't fix the bug despite a plea from some Braille council

https://www.unicode.org/L2/L2025/25183-utc184-properties-rec...

That's new

> For example, U+200B ZERO WIDTH SPACE was originally classified as a space character (General_Category=Zs), but it was reclassified as a Format character (General_Category=Cf) to clearly distinguish it from space characters in its function as a format control for line breaking.

> some bugs you don't want to find

The key thing you forgot, which makes this approach non-sensible, is the omniscience, without which you have no clue whether your posture towards a new bug-finding tool is good or not, since you don't know whether it will mostly find those bugs that are not worth fixing and the time wasted on fixing them is detrimental.

Similarly, how is ignorance better than informed decision when ignorance also includes missing critical security bugs?

Why wouldn't their review system see a published extension and determine the very second it's published that it didn't match the results of a standard workflow?

It was safety-contrained from being able to realize its full potential.

What would be the careful way of installing the official extension?

That's literally impossible, with all the access to the frontier software development tools at their disposal they can ship features securely at 100x

> Points of correctness are useless without points of connection.

There are two points in a connection, and one way to sever it is to follow author's advice to "ignore them". Or you could try to learn and maybe even engage.

(also, the "non-coward" way would be to actually link to the comment so that we could try to understand how toxic / irrelevant expert peons are)

You forgot to exclude the "not usual" factors that allow monopolies to hold their position to rule Google out of the group.

For example, non-regulatory attempts at blocking of competitors, which Google does engage in due to their dominant position in mobile (of course, that's also just another better product)