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.
For some more context, see https://github.com/geany/geany/issues/3938#issuecomment-2394477313 and below.
A few screenshots with the new grouping:
<img width="595" alt="Screenshot 2024-10-06 at 14 35 12" src="https://github.com/user-attachments/assets/e4812d3b-50b6-4831-827f-0cf0e41e2...;
<img width="787" alt="Screenshot 2024-10-06 at 14 36 18" src="https://github.com/user-attachments/assets/980c19a9-e59d-4cbf-8311-d32b237d5...;
<img width="865" alt="Screenshot 2024-10-06 at 14 37 18" src="https://github.com/user-attachments/assets/56829792-f244-46ae-9a6a-7d5f4b9b0...;
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3977
-- Commit Summary --
* Regroup filetypes by letter
-- File Changes --
M data/filetype_extensions.conf (8) M src/dialogs.c (47) M src/filetypes.c (276) M src/filetypes.h (14)
-- Patch Links --
https://github.com/geany/geany/pull/3977.patch https://github.com/geany/geany/pull/3977.diff
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.
1. agree the menu should be hard coded. Some automajik method that totally reorganised the menu just because a user tried a custom filetype would be very annoying. 2. As the structure member is not individually documented its not in the API so any plugin that uses them is its own fault, and so long as the new member is the same size it won't change the ABI either and so no problems. 3. agree 4. agree 5. personally I don't care about "source file" etc. I only care about the filetype name. Geany does not edit anything but (UTF-8) text and it won't ever edit anything but a "file" so never eg "C++ object file" so why say "C++ source file". Lets see if anyone else who cares can make a cogent argument for keeping the extra text. 6. agree
Speculatively, perhaps there should be an "Other" for non-ASCII names, maybe the new language is named "Åland" for example.
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 https://github.com/geany/geany/issues/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.
@techee pushed 1 commit.
dca20ba143780149c1bd3e89b9e1a37174de27d8 Add "Other" group containing filetypes not starting with letters
> Speculatively, perhaps there should be an "Other" for non-ASCII names, maybe the new language is named "Åland" for example.
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.
Question. How is this handled in different locales? Will the types be in the English placement, or in the localized one?
It will be 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)
Even if the prefix/suffix stayed there, it would be grouped by `<type>`.
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.
Yes, I was thinking about this too. The following language names are translatable now: - Shell (possibly keep untranslated) - Makefile (possibly keep untranslated) - Cascading Stylesheet (could become CSS) - Config (could become Ini/conf) - Gettext translation (???)
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. I suppose "Gettext translation" is translatable because of the "translation" part in the name. No idea about "Makefile". (And I don't think "shell" is meant to be translated as "cáscara" in Spanish) :)
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.)
Even if the prefix/suffix stayed there, it would be grouped by `<type>`.
OK, I probably confused "internal name" and "name displayed on the menu". (Or they're grouped by the untranslated name, even if they're displayed by the translated one, which is what I meant with my first question.)
(Or they're grouped by the untranslated name, even if they're displayed by the translated one, which is what I meant with my first question.)
There are 2 types of translatable strings. One denoting the kind of file - _("%s source file") - _("%s file") - _("%s script") - _("%s document")
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 `Tools->Configuration Files->Filetype Configuration`menu, there is `filetypes.conf` listed under `K` which might be unexpected.
So, I'd also vote for making those five filetype names untranslatable and rename them accotding to the suggestion in https://github.com/geany/geany/pull/3977#issuecomment-2481384893.
@techee pushed 2 commits.
95c0f9ecfbc26c7fabd764116992d0f59289b522 Make language names used for display non-translatable baf1ab27fe6a66066d6fdaea4aaeac39baf6fd96 Remove now unneeded hack for (O)Caml
I noticed one issue in the Tools->Configuration Files->Filetype Configurationmenu, there is filetypes.conf listed under K which might be unexpected.
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 - for "Po" I used "Po (Gettext)" - for "Conf" I used "Conf/Ini" - and changed "(O)Caml" to "Caml/OCaml" (thanks to which I could remove a special hack used to handle the braces)
@techee pushed 1 commit.
5440186297e082bfc8cbfeee66df76623339a791 Add comment clarifying naming of [3]
@techee pushed 1 commit.
eb22f9097d57d0ff800fbc77ed0ee80ebff637e1 Update documentation
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 pushed 6 commits.
6dacbf6c218b07dd60d8ec0e0bd5e950aa32da27 Regroup filetypes by letter d199b845e1aa28fb1b3b00229a1e565bdc4ca3e1 Add "Other" group containing filetypes not starting with letters da5efd45c22fb98003c4de182cc71a68d91fe8a2 Make language names used for display non-translatable 22ccd2226b1115cb94ba3ccf401f55033cc63a50 Remove now unneeded hack for (O)Caml d9df972b075f014dba3260ced957138c0343f086 Add comment clarifying naming of [3] 7b05c95ab334eeaa7ffaf45b3996f5b8426f40a0 Update documentation
@techee pushed 6 commits.
75a691caa61d3daf6e1852cc7138b35ba959247e Regroup filetypes by letter dbadde24e642813d17a75bf9c92f18321f9e2ece Add "Other" group containing filetypes not starting with letters dd59ce18cee245a98d9740b7b52fdeea18ab8625 Make language names used for display non-translatable fb5d9e14c2566a5d8ff42a6103dfc5dec02c2448 Remove now unneeded hack for (O)Caml 789249ace070c8a94b283465c90f44a24ebf544b Add comment clarifying naming of [3] 7e3da8cf7187c6b094ffa34252190305d266e76b Update documentation
After resolving the merge conflict, I think we are good to merge.
Done. For merging, I'd just squash the commits into one.
@techee pushed 2 commits.
0b4732d9f7fae9d7064c5330316f7ed654425294 Regroup filetypes by letter 8fad65c66c6f088a78eeae2c0397ab4c4f470bee Update documentation
Merged #3977 into master.
github-comments@lists.geany.org