Files with the `.h` extension are currently treated as C source code. However, the extension is also used for C++. It would be nice if Geany filetype auto detection switched the header type to C/C++ based on whether a corresponding source file is found.
For instance, many projects match `.cc` and `.h` files. If both `filename.cc` and `filename.h` exist, it would be reasonable to expect the `.h` file to be a C++ header. But if `filename.c` is found instead, the `.h` file is most likely a C header.
Since there are fewer C file extensions to check (just `.c`), the default could be for `.h` files to be treated as C++ and switched to C if a corresponding `.c` file is found. There is a potential issue when isolated `.h` files are loaded. I don't know how bothersome it would be fore users to have C files treated as C++.
Another option is to treat `.h` files as C and to switch filetype when a `.cc` file is detected, since that seems to be the most common mismatched pair.
Notes:
* I searched and read parts of the manual related to file types, but did not see anything that indicated this has already been implemented in Geany. I apologize if I missed it. But the manual is over 70 pages long when printed.
* This feature could be implemented in a plugin. But the plugins related to managing source code and projects didn't appear to have it.
* I have implemented this feature in a personal plugin, so whether this is implemented in the main program doesn't really affect me personally. However, I do wonder whether this would be appropriate as a standard feature.
* This functionality can likely be implemented as a Lua script. However, I am concerned about the longevity of the GeanyLua plugin because Lua 5.1 is over 9 years past EOL.
Yes, `.h` files are a known problem. C and C++ are not the same language, so getting it wrong means symbols and possibly highlighting will be wrong. Treating C header files as C++ is more likely to work (but not guaranteed) and as Geany treats C and C++ symbols as interchangable they will show in both C and C++ autocomplete.
Emacs has the same problem and uses the `-*-type-*-` in a first line comment to identify them. On the system here almost all system include files have it, sometimes subtly, the following example line one is from my `libffi.h` :-) It is also necessary for system C++ includes that have no extension.
``` /* -----------------------------------------------------------------*-C-*- ```
The standard Geany filetype regex recognises and uses these marks, see the default `extract_filetype_regex` in various prefs. This would be the recommended solution for your own headers if for some reason you can't use `.hpp` or `.hxx` for C++ headers.
Defaulting to C is the right(ish) thing to do for `.h` unless its marked.
Looking for a file with a C or C++ filetype with the same name will only work if the C or C++ file is already open when the header is opened since many/most projects put .h files in an `include` directory separate from the body files. So Geany won't know where to look for body files.
The suggestion of adding the feature to one/all the project plugins would be a better idea since they usually know where files related to the project live, thats their purpose after all. So they know where to search, or may even already have a list of project files they can lookup.
I am concerned about the longevity of the GeanyLua plugin because Lua 5.1 is over 9 years past EOL.
Unfortunately unless somebody ports GeanyLua to a newer Lua then I would have to agree with you that any script will likely have a limited lifetime.
That's a nice feature. I'll definitely start adding that marker to my personal header files and propose it to projects that could benefit. I totally missed it in the manual. Even after knowing what it is, it took me a while to figure out what I was looking at. Opened a pull request to add an example to the manual: #2947
I'll have to set aside some time to figure out how the project management features/plugins work.
... unless somebody ports GeanyLua to a newer Lua...
I'm tempted to *try*, but don't currently have enough knowledge. Something like peasy seems like an easier base to work from since most of the interface is automatically generated. (I learned that libpeas also uses Lua 5.1. Since it's part of the GNOME project, there's a reasonable chance distros will keep Lua 5.1 around as long as GNOME continues to use it.)
The thing is Peasy has a different API to Geanylua, so scripts will stop working, even if Lua 5.1 is used.
The thing is Peasy has a different API to Geanylua, so scripts will stop working, even if Lua 5.1 is used.
Yes... There will be pain... Without the spyware though, don't know if more than two users would be affected. 🕵️
I'm looking at the Geany project feature. It looks good with the project organizer plugin ( @techee ). (So many features I haven't been using...) Seems like an option could be added to the project organizer to indicate the primary programming language. Then that could assign filetype for ambiguous `.h` files. Options could be... Let Geany autodetect, Try to find corresponding C/C++ file, Always treat as C, Always treat as C++...
Remember the regex is not fixed, it is editable in the Various prefs, recognising emacs marks is just a useful default, a savvy user could edit it to anything, so hardcoded tooltips risk being wrong (although savvy users may not care). Probably best to open an issue on the geany-plugins repo to discuss with @techee, you can reference this to save repeating it.
A comment from another source re Lua 5.1 is that some places are deprecating it as a command line app in favour of luajit, the library may still be available as you said.
Just a final point. How much effort you want to use on the filetype detection depends on your useage, for your own files you can use sensible extensions or emacs marks (please use sensible extensions). But if you use other peoples projects they may do neither (looking at you Scintilla :), so it depends on your use-case if you find it important enough to do something complicated and nobody to date has found it so, an occasional annoyance of a manual filetype selection and thats all.
use sensible extensions or emacs marks
Sensible... file extensions? ... wow. 😮 I just opened up the scintilla source. Never seen that combination before.
I'll go open an issue in geany plugins to see if the project organizer plugin would be a good place for this.
@xiota maybe the Codenav plugin could also be a suitable place, did you consider it? https://github.com/geany/geany-plugins/tree/master/codenav
It says about itself:
This plugin adds some facilities for navigating in code files. [...] Switch between header and implementation
So, I'd assume there is already some code there to find `.c` and `.h` files matching each other.
I'll take a look at codenav. I've been using a modified version of project organizer.
If it's a feature that belongs/ends up in multiple plugins that people might want to use together, should it be something that Geany itself would handle? So that plugins are not interfering with each other?
Also, I have some plugin PRs that I haven't heard from anyone about. How long should I wait before pinging the maintainers again? Or if they've gone MIA, how to move forward?
If it's a feature that belongs/ends up in multiple plugins that people might want to use together, should it be something that Geany itself would handle? So that plugins are not interfering with each other?
I think it should be implemented only in one plugin, whichever fits best.
Also, I have some plugin PRs that I haven't heard from anyone about. How long should I wait before pinging the maintainers again? Or if they've gone MIA, how to move forward?
https://github.com/geany/geany-plugins/pull/1123 GeanyLua: Update glspi_sci.h -> is active
https://github.com/geany/geany-plugins/pull/1122 Project Organizer: Set header filetype to match source filetype -> is in discussion if appropriate at all, otherwise @techee is usually quite responsive
https://github.com/geany/geany-plugins/pull/1112 GeanyLua: Enable running scripts for all signals -> is also for GeanyLua which is orphaned according to `MAINTAINERS` but you nominated a new maintainer yourself :D
https://github.com/geany/geany-plugins/pull/1111 Markdown: Restore scrollbar position for webkit2gtk -> not sure about that, @codebrainz didn't appear for some time but this might change again, hopefully
I think it should be implemented only in one plugin, whichever fits best.
Since CodeNav basically has a subset of Project Organizer's features, users are unlikely to need to use both at the same time. So both plugins could check headers within the scope of their operation with little chance of interfering with each other.
These are the plugins I looked at:
* Project Organizer – I've been using a modified version with some header matching code that searches only files inside the project. It could be extended to also check side-by-side files.
* CodeNav – Looks like it just adds some menu items and keybindings to switch between files. Project Organizer also has this feature. Since it doesn't have a project index, it would only be able to check side-by-side files. (It probably shouldn't be searching the rest of the filesystem.)
* Workbench – Looks like it keeps track of multiple projects. Don't know if it does any indexing on its own. I don't know how to use it. Which project is "open" from Geany's perspective? How to switch projects? Double clicking pops up an error about unsaved files, even though everything looks saved. It looks like it has some overlapping features with Project Organizer. I'm not too interested in it.
* GeanyPrj – I don't understand this plugin. It's an alternative project system, but how to use it? What is it supposed to do different from Geany's built-in projects? I'm not too interested in it, unless it's somehow amazingly better than the built-in projects + project organizer.
@xiota you have just realised that there is more than one way to skin a project cat [1] and so there are several project plugins with differing use-cases. Thats the beauty of plugins, people can make them to fit their use-case or personal preference without fighting others use-cases and preferences. There are several competing approaches to what a "project" is and what an IDE should do about it. Geanys built-in "projects" are extremely simple (essentially named session files) so they don't compete with plugins.
I guess that the place to add your new feature first is whichever plugin you use.
[1] "skin a cat" is a figure of speech, no animals were harmed in the making of project plugins :smile:
@elextr All the cats on YouTube thank you for not harming any of them... Why is "skin a cat" not some other animal?
I already have some PRs for Project Organizer. (geany-plugins: [1122](https://github.com/geany/geany-plugins/pull/1122), [1125](https://github.com/geany/geany-plugins/pull/1125), [1126](https://github.com/geany/geany-plugins/pull/1126))
I looked at the CodeNav code... I have difficulty following what it's doing. It uses `goto`. Don't think I want to touch it.
As I said everybody has a different idea how "projects" should work, so just contribute to the one(s) you are happy with.
I think we can close this as "workaround available" referring to using sensible extensions or marking files, ok?
All the cats on YouTube thank you for not harming any of them...
There are no cats on the internet [1]
Why is "skin a cat" not some other animal?
Its quite an old saying, from 1840, see [here](https://www.phrases.org.uk/meanings/there-is-more-than-one-way-to-skin-a-cat...) and IIUC Mark Twain also used it, which could account for the popularity.
[1] there are actually quite a lot of cats on the internet, but there are more dogs, and so as the numbers of dogs approaches infinity the smaller number of cats effectively becomes zero in the limit [end math misuse]
Closed #2946.
@elextr To correct misuse, just add the word ["almost"](https://www.quora.com/What-does-almost-everywhere-mean-in-Mathematics).
github-comments@lists.geany.org