Please can we avoid emotive language and stick to constructive criticism? I'm anxious, my heart is beating fast as I type this. It just makes collaboration more difficult.

Wasn't meant to upset you, but frankly you are still talking from your point of view of languages and their characteristics.

add C Family and Functional. These categories are known by their users.

Are they?

What do you mean by "C family"? Is it just direct descendents, eg C, C++ and D? Or is it all {} languages including Java and its descendents (eg Groovy Kotlin etc) and Javascript and the other ECMAscript languages and PHP etc? And what about Rust? And Go? And why are "C family" so "important" that they get their own category the user asks?

If you look at the number of categories each language appears in here it becomes clear that a simple categorisation is always going to be confusing.

And that also shows that nearly all of the "C family" (except C itself :) can also be counted as impure functional languages, so why are they not in that category?

I also started out thinking that there was a single "sensible" way to define the groups, but after other discussions and some investigation I changed my mind. There is no good subdivision based on only a few programming language characteristics alone.

If I want JS, I can't instantly know which sub menu it is. It doesn't take long though, but it's nice to avoid this for UX.

they would hopefully pick up the distinction by inspecting the contents.

Sure with an alphabetical range a user might have to stop for a moment and think "is j for javascript in h-l" (or whatever the letter range is) but thats better UX than having to find out by guess and experiment, which is your suggested alternative. And just like the guess and experiment method, you will get to know it if you use it commonly. But if you don't use it commonly you will not have to grope in the menus each time you do use it.

I don't think users will bother to redefine these groups, why support that?

They may not redefine the alphabetical groups, but they may create a "My common languages" group. With a redefinable menu nothing says a language needs to be in only one group.

Also did you see my 2nd comment about user-set ungrouped filetypes?

Yes, I know that filetypes that are not in the built in filetypes table are grouped by the filetype.extensions file, and in case it wasn't clear its just suggested that that capability be extended to all filetypes, and with groups defined in that file. There is no suggestion that builtin filetypes become custom filetypes, they are still mostly defined in the filetypes table, just it loses the group column.

And once grouping is out of the filetypes table where only one group is possible, then a language can appear in any groups that a user thinks are appropriate.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.