Regroup filetypes by letter #3977
Conversation
|
Will hopefully inspect and maybe even try "soon" but am re-building my development machine after an SSD death, and then will have to catch up the lost time first, but a couple of comments. As said elsewhere, (many times over years) these days the distinction of programming vs script vs AOT vs JIT vs interpretor are meaningless for the language, they apply to the implementation, and in some cases there are multiple implementations, so those categories in the menu are meaningless for the filetype.
Speculatively, perhaps there should be an "Other" for non-ASCII names, maybe the new language is named "Åland" for example. |
What happens right now is that those languages starting with a non-ASCII letter are placed to the top-level menu and not within the A-Z submenus. But, yes, some "Other" would probably be better. |
|
There's also some more discussion in #2087 which I just found. I still think alphabetical sorting is the easiest to understand rather than some "Pascal-like" or "Python-like" groups. |
|
Agree that alphabetic is the only sensible default menu division. To illustrate categories, look at the Wikipedia categorical section, and look at how many categories each language appears in. It is meaningless. The Geany team should be humble enough to not be programming language wizards and enforce some categorisation, just use alphabetic. If somebody is soooo convinced that they need non-alphabetical they can make a separate PR built on this that reads a conf file to replace alphabetic and they can do whatever they want. |
Done in the latest commit. |
|
LGBI, will try to make time to test in a few days, but if others test it don't wait for me. |
|
Looks good. I kinda liked the idea of separating languages by categories but honestly that simply wasn't feasible. Question. How is this handled in different locales? Will the types be in the English placement, or in the localized one? By removing the "source file" suffix you avoided most of the trouble this could cause (e.g. in Spanish nearly all languages are called "Archivo de fuente <type>" or "Archivo <type>", and they'd all be filed under A), but there are still a few localized names (e.g. "Cascading Stylesheet" = "Hoja de estilo en cascada"). Probably the most reasonable approach is to not translate the names, and to use "short names" (e.g. "CSS" rather than "Cascading Stylesheet") in all locales. |
It will be the localized one.
Even if the prefix/suffix stayed there, it would be grouped by
Yes, I was thinking about this too. The following language names are translatable now:
So it means these could appear under different letters depending on the used locale. And as you said, at least for CSS, it would be better to use "CSS" (not sure how common it's to translate Shell or Makefile). |
|
I would've thought "Assembly" would've been translatable too ("Ensamblador" in Spanish), but at least in Geany it's not translated. Cascading Stylesheet should probably be left as "CSS", and Gettext translation as "Gettext". Just the language. (About "config"… yeah that's hard since I'm not even sure it has a standard name, and there are billions of slightly different implementations.)
OK, I probably confused "internal name" and "name displayed on the menu". |
There are 2 types of translatable strings. One denoting the kind of file
and then the actual translation of the language which is inserted inside one of the above 4 strings (i.e. those 5 languages I mentioned above). The placement into the alphabetic groups is based on the translation of the language, not the translation of the kind of file (which is gone with this patch anyway) |
|
Looks good to me, tested with English and German locale (for German "Config" is actually translated to "Konfigurationsdatei". I noticed one issue in the So, I'd also vote for making those five filetype names untranslatable and rename them accotding to the suggestion in #3977 (comment). |
Yeah, good point, done. Also, the human-readable name (of those several filetypes that contain it) should start by the same letter as the filetype name for the very same reason. So
|
|
I've also updated the documentation (i.e. removed stuff related to filetype group configuration). I hope I haven't missed anything. There don't seem to be any screenshots showing the groups so no need to update those. |
|
The latest changes look good and especially Conf/Ini works well. After resolving the merge conflict, I think we are good to merge. |
techee
force-pushed
the
filetype_groups
branch
2 times, most recently
from
7b05c95
to
7e3da8c
Compare
Done. For merging, I'd just squash the commits into one. |
This patch converts the currently used groups like "Programming languages", "Scripting languages", etc. to groups based on the starting letter of the language only. There are two main reasons for this change: 1. Some languages are hard to categorize by some semantic group name and the group names are not really fitting. In addition, the currently used group name "Programming languages" isn't very good as "Scripting languages" are also a subset of programming languages. On the other hand it's hard to find a good substitute for "Programming languages" - mostly these are "Compiled languages" but not always and some languages allow to be both interpreted and compiled which complicates the situation. 2. The "Programming languages" group is too big and the menu is so long that it doesn't fit the display on smaller screens and one has to scroll the menu to get to the right item which isn't user friendly. Things will get only worse as there are still many "Programming languages" that Geany does not support yet and that might be added to the editor in the future. The newly introduced alphabetic groups are: A-B C D-E-F G-H-I J-K-L M-N-O P-Q R-S T-U-V-W X-Y-Z These allow roughly even distribution of existing languages into smaller groups with enough space for possible future language additions. While it would be possible to make the group names more symmetrical, e.g. by having "R-S-T", "U-V-W", I found that the asymmetry helps quicker navigation as one remembers the group with his favorite language is e.g. "the one before the long group" without thinking where exactly in the alphabet the letter is. Some notes to the implementation: 1. It mostly follows the existing implementation trying to do minimal changes and doing things in a "dumb and straightforward way". This means that group names are hard coded (they could also be autogenerated, possibly auto-attempting to distribute languages into evenly sized groups). 2. Technically this change breaks API as it modifies GeanyFiletypeGroupID which is used for the group member of GeanyFiletype which is accessible to plugins. However, this member isn't documented to plugins and no existing plugin from geany-plugins uses it so probably not a big problem. 3. Because grouping happens automatically now, the [Groups] section from filetype_extensions.conf can be removed and is not read any more. 4. Because grouping happens automatically now, the [5] argument from FT_INIT() can be removed. 5. In addition, this patch also removes the [4] argument from FT_INIT() which determined the suffix in the filetype menu like "C++ source file" - IMO the "source file", "file", etc. suffix for all the languages in the menu introduced just a visual clutter and made legibility worse. In addition with the removal of [Groups] from filetype_extensions.conf in (3), it would not be possible to determine the right suffix for custom file types. 6. The newly introduced groups are untranslatable strings - there should be no need to translate those. 7. If users create a non-builtin filetype starting with a non-alphabetic character, it will be placed into a group called Other. This group won't be displayed if there are no such filetype. 8. Human-readable names of languages are converted to non-translatable strings because otherwise their placement into groups may be confusing. Also, these names should start with the same letter like the language name itself otherwise the grouping in Tools->Configuration Files-> Filetype Configuration might not correspond to the language name.
techee
force-pushed
the
filetype_groups
branch
from
7e3da8c
to
8fad65c
Compare
Accidentally removed in geany#3977.
This patch converts the currently used groups like "Programming languages", "Scripting languages", etc. to groups based on the starting letter of the language only. There are two main reasons for this change:
The newly introduced alphabetic groups are:
These allow roughly even distribution of existing languages into smaller groups with enough space for possible future language additions. While it would be possible to make the group names more symmetrical, e.g. by having "R-S-T", "U-V-W", I found that the asymmetry helps quicker navigation as one remembers the group with his favorite language is e.g. "the one before the long group" without thinking where exactly in the alphabet the letter is.
Some notes to the implementation:
For some more context, see #3938 (comment) and below.
A few screenshots with the new grouping: