gemini:// space

> The only gripe I have is the possibility to introduce ASCII diagrams, which usually aren't accessible.

CAD software exports .stl files which can be processed into instructions for machines. That is, there is already software that can take lines on a screen and convert it to instructions for a machine. There's probably a way to annotate ASCII images of drawings (schematics, architectural) and output text "text* drawing of an object 14 centimeters by 5 centimeters, ..." Stuff like vinyl cutters (and even the proprietary cricut) can take vector graphics and convert them to instructions for a machine. so it, in theory, might be possible to just paste the ascii drawing text into some software: render ascii as .svg/vector, convert to 2d stl ("a layer"), convert stl to descriptive text. Since the software renders, you don't need OCR for the annotations, which are mostly instructions.

if there's no annotation, assume the '-', '_', '|', etc are to scale, and just use "units" as the dimensions instead of centimeters or whatever. |----| = 'two verticals separated with a 4 unit line'

Am i crazy?

> People being able to use software (which presumably is what gemini is about??) is important for everyone, obviously.

Yes, and a minority of those users are visually impaired, hence it is a niche. Maybe you considered "niche" to mean "preference" or "novelty"?

" niche, adjective

denoting products, services, or interests that appeal to a small, specialized section of the population. "

>Cold engineering logic drove us to see that everything is just bytes and so everything can be served over HTTP.

>The same logic is used in the retail world to optimize away culture and quirk and nuance and difference: everything is just a product, so everything can be sold in just one superstore.

That seems an odd aspersion to cast on a protocol that gave Hacker News the culture and quirk and nuance and difference of the early web it's so nostalgic for.

If you surveyed people on what features were missing from Gemini and got 10,000 responses how many people do you think would mention "semantic tags for when the language switches mid document" and at what priority when mentioned? Now the same for the top item on the list? Now pick 5 random responses only mentioned once, do you think there is one that could theoretically be used by a large percentage of the population if implemented but even if you had thrown it in the survey itself but still wouldn't have been selected by many people or as a high priority?

I.e. it's not enough for something to be possibly usable by a large portion of people - the userbase have to actually be interested in utilizing it and consider it more important than other things instead. I strongly think if you follow this logic you'll find it's a very niche group that cares this deeply about the semantic language tags. Maybe you truly strongly don't and consider it something everyone would love if only it was there.

That is a really good point, and a really good way of phrasing that point, but I still have two semi-objections.

First, I do think this kind of thing falls into a category of... maybe 'polish', for lack of a better word?

This is something that you're not going to notice you're missing until you think "I want to write one of these quick and dirty display clients that I've been encouraged to build over the weekend, and wow, embedded Japanese is just literally impossible to render well." If you have a document format that's designed to be adaptable and flexible, predicting what you're going to need is difficult.

So maybe the idea is that you're not going to throw transcriptions for comics/manga into this, and nobody would need to search documents for embedded passages in other languages, and stuff like auto-translations in a client wouldn't be useful. But to me it kind of just smacks of, "this is designed for the use cases we could think of right now." I don't know what features will be critically important until I try to do something creative, that's why I value a tightly constrained format that's simple to understand but still offers at least some flexibility.

The other objection that keeps coming up in my mind is: is Gemini actually swamped for feature requests right now? Are they being forced to prioritize features? I'll definitely concede that if you surveyed 10,000 people using Gemini, stuff like a hard limit of 2 subheaders is very likely annoying more people right now than anything to do with language types. But Gemini also doesn't look like it's trying to fix its subheader limit. The impression I get from the FAQ is that this is not a spec that's actively evolving much right now.

And that kind of loops me back around to thinking about polish again. On one hand, I'm inclined to think you're right, this is probably not the first thing on anyone's mind. But on the other hand, "a document with multiple languages in it" is a reasonably common thing that will show up in multiple settings. So I'm still looking at a text format that even just on the surface level doesn't seem to be very good at describing text, even in cases where the solutions seem pretty simple. Having a language switch tag in the spec or just allowing multiple top-level media types in the document doesn't seem like it would complicate the parser spec or make it any harder for me to build a client.

Part of this is, if I'm going to adopt a format, I want it to be well thought out -- I want the authors to have spent more time thinking about it than I have. So if I can immediately see problems before I even start using the spec, it makes me wonder what else I'm going to run into where I'll just be scratching my head over why it was designed that way.

On some level I get where you're coming from, and rendering multiple languages is not the end of the world. You can even potentially work around it, maybe. But it would also be very, very easy to get this right, and I don't understand why the first thought from a spec designer putting together a content type header wouldn't be "what if the content type changes mid-document". This is maybe unfair, but the immediate thing that it makes me think is, "these are people who have not spent much time considering how text documents work, even for simple cases."

But if Gemini was in heavy active development, my opinion would probably be different. I don't know, maybe it is? Are they actively evolving the spec right now? Maybe I'm just being over-critical. But I feel like I shouldn't be able to immediately think of use cases involving basic text that Gemini just can't handle, it should take me longer to see the limitations of a general-purpose text format.