Currently there are 30+ "programming languages", 20+ "scripting languages", 9 "markup languages" and some "Misc" languages.
The first two categories are so big the menu (Document->Set Filetype->) won't fit on screen (at least with a laptop).
Especially the first should be broken up. This is a call for suggestions of how that should be done.
Otherwise I will make a pull request breaking them up in a reasonable but somewhat arbitary way, rough popularity measure and degree of support. :grin:
I haven't thought deeply on this, but for programing/scripting languages, one way could be to break them up in their general syntax style, for an incomplete example:
* Pascal-style - Ada - Pascal - Coffeescript - Lua - Ruby
* C-style - C - C++ - C# - D - Go - JS - Java - Rust - Vala
* Python-style - Python - Genie - Nim
* Lisp & Functional-style - Lisp - Scheme - Clojure - Erlang - Haskell
It wouldn't be perfect, and the "C-style" group would have a lot of languages, but at least it's better than the incorrect/non-existent distinction of "Programming" vs "Scripting".
Another more obvious way would be to group them alphabetically, collapsing ranges of letters together where there aren't very many languages (to avoid a large 26 item menu with few items in each submenu).
Just a couple ideas.
Also it might be worth surveying what other editors/IDEs do to see if there's any other good approaches.
Also it might be worth surveying what other editors/IDEs do to see if there's any other good approaches.
A limited survey of those I could find online docs for is either alphabetical menu (atom, eclipse) or type it yourself (vim and emacs) or no such command (or their online docs are #$%^ so I didn't find it) (sublime, qt creator, anjuta)
Another more obvious way would be to group them alphabetically, collapsing ranges of letters together where there aren't very many languages (to avoid a large 26 item menu with few items in each submenu).
Yeah, and the advantage of alphabetical is that nobody can complain that their favourite language is disadvantaged by calling it a "script" language not a "programming language", or calling something like Julia a Pascal language, yes yes I know Julia isn't in Geany yet, but its an example of an up and coming language with a different syntax style, there will always be new styles invented.
Especially the first should be broken up. This is a call for suggestions of how that should be done.
I like support for lots of different languages. A change that may be quite simple may be to let the user keep some kind of "defaults" for the main languages in used; something a bit like keeping a number that seems reasonable... like, max up to 15 languages or 12 or something like that; and the others could be displayed in a side pane, such as "show more languages" or something like that.
Allowing a user to customize these results won't necessarily fix the original goal asked by elextr - but it would allow users to arrange it to their personal preferences (and ideally store this in a text file too, so that the user can keep this configuration for easy re-use).
I don't think breaking it up into "syntax style" makes a lot of sense for an end user's point of view. I don't know how pascal syntax works, so this information gives me less compared to the current status quo (even though I also find the grouping somewhat arbitrary). For the most part, I only focus on a few languages, and ignore the rest mostly (although simple colour highlighting is always nice to have, even for languages I am unfamiliar with).
It wouldn't be perfect, and the "C-style" group would have a lot of languages, but at least it's better than the incorrect/non-existent distinction of "Programming" vs "Scripting".
I think that both distinctions aren't great, but I definitely prefer programming/scripting as opposed to an even more arbitrary "syntax style".
Another more obvious way would be to group them alphabetically
This would actually also be better - that way people would easily be able to expect perl appearing before python appearing before ruby ... is simple. :)
I think most people will understand alphabetic sorting since it is so simple.
To the question how other editors/IDEs do it - bluefish used to just group via "text php python html" but you could arbitrarily select that to get the colour highlighting applied onto the current file in the main buffer.
Actually, in the long run, what would be ideal would be to have users be able to customize which colour/syntax highlighter could be used too, but I understand that this is outside the scope of this issue - just thought to mention it.
I guess alphabetic sorting is about the simplest solution. A customized/customizable view would be great too; for example, I don't think I may ever need pascal or COBOL or such entries. Anyway just my 2 cc. :)
I like support for lots of different languages. A change that may be quite simple may be to let the user keep some kind of "defaults" for the main languages in used; something a bit like keeping a number that seems reasonable... like, max up to 15 languages or 12 or something like that; and the others could be displayed in a side pane, such as "show more languages" or something like that.
Something like that make sense to me. Most people won't use most of the languages anyway. But showing maybe 5 languages by default (or none), and on that same menu, have an option like "set visible languages", which opens a prefs page that has checkboxes for each language (and that prefs page would be scrollable).
I would like to retract my suggestion for language family-based menus. It would only work if everyone was a programming language nerd, and even then it would be annoying.
I think the best way would be to have it read completely from a `.conf` file (as it does now for custom filetypes) so that users could choose their own organization and/or hide languages they do not use, as suggested by @rubyFeedback (and previously discussed with @elextr offline). The default `.conf` file would of course use a sane organization (ex. alphabetical) for those who don't care to fiddle with it.
The default .conf file would of course use a sane organization (ex. alphabetical)
Alphabetical means a long menu to move the (mouse) cursor through. I think we can make categories work. The Pascal style group is not intuitive, particularly Lua and Ruby, I don't know the others. For C style Go and Rust are not intuitive (e.g. function and variable declarations), and even JS and Java are unexpected there. Instead I would like: * C family - C, C++, Objective-C, C#, D * Static - Other statically typed * Dynamic - Perl, Python, Ruby, JS - these are general purpose rather than mainly functional * Functional - as @codebrainz suggested * Scripting - Batch, PowerShell, Shell; Make, NSIS - anything that runs programs by a command line and is not used as a general purpose dynamic language * Markup, Misc - as present
I don't see a problem with some categories being more specific, e.g. having C family separate from Static. That was the philosophy behind having the Programming vs Scripting divide - it was not implying that scripting is not programming, just providing a way to group languages in an obvious place, scripting is more specific than programming.
Note that YAML and JSON should go under Markup but are in Misc ATM. Markup could be renamed something like Structured Text, but markup WFM.
users could choose their own organization and/or hide languages they do not use
We can already have filetypes listed underneath the group menus, e.g. for custom filetypes that haven't set a group. We could support this for non-custom filetypes too. (Making all filetypes custom might not be possible if Geany uses the filetype enum IDs for special handling). This allows the user to make their common languages available from the first menu level. I don't think it's worth supporting custom filetype groups.
Alphabetical means a long menu to move the (mouse) cursor through
No it doesn't, it means one submenu level "a-f", "g-m", "n-p", "q-z" or whatever gives roughly even numbers in the leaf menus. Thats no different to the current menu, except everybody knows the first letter of the language they want, and don't need to be a "programming language nerd" to guess a category (as @codebrainz put it).
But whatever is the default, for gods sake don't hard code some set of groups, its just plain arrogance on the developers part to think they know how the user understands their languages, so make it user definable, probably in filetypes.extensions,. Then after a suitable bikeshed a default layout for the builtin languages can be provided using that.
it means one submenu level "a-f", "g-m", "n-p", "q-z"
This is hard to internalise, learning the arbitrary ranges. 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.
don't need to be a "programming language nerd" to guess a category
My categories are clearer than Matthews, but yes probably some users won't know about static Vs dynamic typing - they would hopefully pick up the distinction by inspecting the contents. Or we could keep the status quo and add C Family and Functional. These categories are known by their users.
don't hard code some set of groups,
I don't think users will bother to redefine these groups, why support that? Also did you see my 2nd comment about user-set ungrouped filetypes?
for gods sake its just plain arrogance on the developers part
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.
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](https://en.wikipedia.org/wiki/List_of_programming_languages_by_type) 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.
I would be curious to find out from people who use another natural language, especially one dissimilar to Germanic/Latin type languages, whether alphabetic sorting makes sense and/or is practical. For example if the menus were translated to Simplified Chinese, the range `h-l` might be translated `艾尺-艾勒` but I'm guessing that the name "Javascript" is always left in English. I have no idea how common it is to group English words in ranges of Chinese characters meant to represent the Roman/Latin alphabet.
@codebrainz good point, but _most_ of the filetype names are not translated, only the descriptive ones like "Cascading Stylesheet" see [here](https://github.com/geany/geany/blob/95c0c06cba3dc0d988c2c0a74c5d52fa2e9f3a93...) column [3].
One of the advantages of reading the group names from file is that they can be translated (or not) consistent with the filetype names.
Right, I was referring to the alphabetic group names being translated, and having English programming language names organized into translated letter groups and whether that makes sense in all languages.
Given that most of the filetype names are not translated, they remain ASCII alphabetic, translating alphabetic groups probably makes no sense in any language, and, as you intimated, I suspect most users run Geany in a Latin alphabet based locale where the alphabetic groups still work.
Are they?
Yes.
What do you mean by "C family"? Is it just direct descendents, eg C, C++ and D?
Yes, as I wrote.
Or is it all {} languages including Java and its descendents (eg Groovy Kotlin etc) and Javascript and the other ECMAscript languages and PHP etc?
No they have C style syntax but are completely different, they don't have such close mapping to the machine hardware.
And why are "C family" so "important" that they get their own category the user asks?
They're not, it's just a way of reducing the Programming [Static] category. There could be a JVM languages category too.
a simple categorisation is always going to be confusing.
Humans categorise. Is a peanut a nut or a legume? Most humans call it a nut.
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?
Because most code in those languages is imperative.
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.
That's the difference, with letter ranges the user isn't going to learn the ranges. With categories, the user may only inspect the categories *once or twice* and remember what the categories are. The user then knows where to look next time, for any language they happen to use.
they may create a "My common languages" group.
Why make a submenu for that, they can just put their common languages under the submenus.
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
No, I'm saying that without a group set custom filetypes show up in the top-level menu. This is useful for commonly-used filetypes, and is already implemented.
filetypes show up in the top-level menu
I realized that reassigning filetype groups works for built-in filetypes too - see #2175 to update the docs.
github-comments@lists.geany.org