Do you write the code itself in a language other than English? Localizations typically are in different files.

I do see a handful of people using non-ASCII identifiers in their code, but that's rare. Much more common is explanatory comments, docstrings, etc. in the local language. To require those to be ASCII would be a non-starter.

Most people do need time to shift focus from and to work. You can do groceries during that time, or administrative work like sending letters or going to the citizens office... .

I still have a slightly older laptop that has, proving that it is totally possible to fit the keys in the size constraints. That is one of THE features that let me refrain from buying a new laptop even if I would kind of need to, but modern ones waste space with just filler space between keys, bigger keys or just empty sides.

> a never ending fight for the Greek term or the Latin term.

Oh, that never occurred to me. Now the two party system is even more ridiculous. Thanks for the insight.

A classic phone has a form factor that allows you to hold it with your neck.

It got deprecated only in 3.10 and you can compile against that and link it with the latest Gtk+ 3 library. I do this for my programs, because I don't like it when the widget toolkit ignores my OS settings.

Cropping IS a destructive operation. If the program isn't throwing information away, then it doesn't actually do cropping, but some different operation instead.

From a user perspective I wouldn't like it, if I were to crop something and the data would be still there afterwards. That would be a data leak waiting to happen.

I genuinely can't empathize with this objection. To me it's basically the same as arguing against Undo/Redo in a text editor because someone could come along and press Undo on my keyboard after I've deleted sensitive data.

What percentage of users sends around raw project files from which they've cropped out sensitive data to users who shouldn't see that data, vs. what percentage of users ever wants to adjust the crop after applying other filters? The latter is basically everyone, the earlier I'm guessing at most 1%?

but nobody argues against undo/redo in gimp!

going by your text editor analogy, we are arguing against implementing undo/redo as a "non-destructive delete", based on adding backspace control characters within the text file. I want infinitw undo/redo, but i also want that when I delete a character it is really gone, not hidden!

Sorry, but I still don't see it - the text editor analogy is stretched far too thin. If I share a project file, I want the other user to see all this stuff. If I don't want them to see all this stuff, I send them an export.

It would be a true shame if every useful feature was left out due to 1% of use cases becoming slightly different.

When does the final calculation happen then, at file save/export? Will be unexpected. Or does it end up in the final format? That's going to be a nightmare, because then you can't use GIMP to redact data anymore.

When your language has neither name-mangling nor namespaces, a simple grep gets you a long way, without language specific support. Ma editor (not sure if it counts as IDE?) uses only words in open documents for completions and that is generally enough. If I feel like I want to use a lot of methods from a particular module I can just open that module.

He already knows C, so I don't think this is the unique selling point.