Currently, the filetype is autodetected only when a new document is opened. If a user adds a filetype shebang line, the only way to redetect the filetype is to close and reopen the document. (While the user could manually change the filetype, the purpose of the shebang line is to avoid manual filetype selection, which is cumbersome because of the multiply nested menus.)
The following change could address this issue without affecting most other users:
* Re-detect filetype on reload, but change filetype only when the current filetype is None or a shebang line is used. - Users are unlikely to change the filetype to None. - Users are unlikely to keep a shebang line for the wrong type.
There is a PR (not yet merged) for the project organizer plugin that changes the filetype of header files to match the corresponding source file. It currently does so only on the document-open signal, so changing the filetype on could cause the "wrong" filetype to be reassigned to the header. However, since the change would be restricted to when the current filetype is None or a new type is determined by shebang, incorrect filetype reassignment is unlikely.
This functionality cannot be implemented in a plugin because `filetypes_detect_from_file` does not report whether the filetype was detected from filename or shebang line.
I don't understand the use-case here. The purpose of a shebang is to specify the program to execute the script, not to specify the filetype to IDEs. For example a script that is written in Python might want to specify `pypy`, or `pyston` as the shebang, but those are not recognised by Geany.
If a filetype has been detected wrongly by Geany, currently the user can edit the shebang (if its wrong for the executable program) or the filetype regex to one Geany understands and:
1. set the filetype manually (even before editing the shebang or filetype regex if they wish) and keep editing until they need to save
or
1. close with save 2. reopen (`menu->recent files->the one at the top` or `Alt+R`) and all detection methods are used, checking what will be detected next time opened after close
IIUC your proposal is that if the user has edited the shebang they need to:
1. save the file before reloading, or they lose their edits so the detection will be wrong again 2. reload the file wherein only the shebang would be recognised, not the filetype regex or extension
So its not just a reload action, its a minimum of two user actions to invoke the proposed behaviour.
So its not significantly fewer user actions than close/reopen, but more user actions than simply setting the filetype manually.
Note that filetype detection is run on first save of a new file so nothing is needed then.
It seems to me this proposal adds nothing but complication and special cases for no significant gain.
The purpose of a shebang is to specify the program to execute the script... currently the user can edit... the filetype regex to one Geany understands...
Comments in the code that detects filetype refer to "checking for a shebang". Since I didn't have anything better to call the first line when it is used for filetype detection, I just called it a "shebang".
The "filetype regex" is a string that Geany uses to extract filetypes from the first line of files. Users normally shouldn't need to change it just for a single file.
set the filetype manually
As already described. Navigating the multi-nested menus is a pain.
close with save reopen (menu->recent files->the one at the top or Alt+R) and all detection methods are used, checking what will be detected next time opened after close
This still involves navigating nested menus. Alt+R does nothing on my computer.
save the file before reloading, or they lose their edits so the detection will be wrong again
That can be accomplished in a single step, typically Ctrl+S.
reload the file wherein only the shebang would be recognised, not the filetype regex or extension
As described above, my use of the term "shebang" (which was adopted from apparent usage in the comments of Geany's code) refers to all filetype detection using the first line of the file.
The reason to limit changing filetype is to minimize the effect on users who may have set the filetype manually. Otherwise, reload could detect filetype the same way open does.
File extensions can be ambiguous, so the shebang/regex take precedence anyway.
So its not just a reload action, its a minimum of two user actions to invoke the proposed behaviour.
Only code directly associated with reload needs be modified. If an external program modifies the file, a minimum of zero actions are required, since Geany can be configured to automatically reload documents.
So its not significantly fewer user actions than close/reopen...
Setting filetype manually involves navigating four menu items plus searching for the filetype among a lists of options. Plus it has to be repeated everytime the file is loaded. So the number of steps is 4*number of times the file is opened. If the file is opened twice, that is 8 steps to set the filetype manually twice.
With modified reload behavior, the user would edit the first line of the file. Save and reload. Three steps. Plus the next time the file is opened, it would autodetect filetype correctly. Four steps, which is a 50% reduction. As the number of times the file is reopened approaches infinity, the reduction in steps approaches 75%.
Using the recents menu involves navigating three menu items. Plus editing, saving, and closing, is six steps. But the next time the file is opened, filetype will be detected correctly. So seven steps (to open the file twice). This is a 50% increase in steps over the modified reload behavior. But if this has repeated for different documents, as the number of documents approaches infinity, the number of extra steps approaches double infinity, which is an annoyingly huge number of extra steps.
It seems to me this proposal adds nothing but complication and special cases for no significant gain.
Changing reload to unconditionally autodetect would involve removing a few lines of code. Changing the filetype only when the current filetype is None would require changing one line.
To be very clear, Geany keeping the filetype fixed after opening, or first save of a new file, is a _feature_ not a fault.
The presumption is that the majority of files recognise their filetype correctly either because of the shebang, or the XML marker, or an extracted filetype, or the extension, or the user has deliberately set the filetype to something different. This is why you have to close the file to forget the filetype, closing Geany or the project with the file still open will remember the current filetype when the session is reloaded.
If a file is not detected correctly I totally agree the user needs to edit the file (or change the extension), but that is likely to be rare and breaking the filetype guarantee on reload is not an acceptable tradeoff for the few times the workaround of "close&save, reload last" is needed.
Its not clear you understand that "shebang" is a well known term, not just a function in Geany. In case you havn't encountered it outside the name of the `find_shebang()` function in Geany, see [here](https://en.wikipedia.org/wiki/Shebang_(Unix)#Syntax).
So using "shebang" for all the ways Geany detects a filetype was therefore confusing, its only one of them. A better term for the whole gamut of methods is "internal filetype detection" (even if `filetypes_detect_from_file_internal()` also checks the extension, sigh).
I think I returned the confusion by using the term "filetype regex" to mean "the filetype extracted by the regex", so (assuming the default regex) I was meaning for example the user should edit the comment in the file to say "-*-Python-*-" if their shebang is `#!pypy`, not that they should edit the regex, sorry for the confusion.
Alt+R does nothing on my computer.
Ahh sorry thats a keybinding I set myself for the "Re-open last closed tab" action. You can bind it yourself, then it will allow you to avoid the ... menu!!! (gasps of horror).
The presumption is that the majority of files recognise their filetype correctly either because of the shebang, or the XML marker, or an extracted filetype, or the extension, or the user has deliberately set the filetype to something different.
Not a good presumption. Most mentions of filetype in the manual are related to modifying the default behavior.
... that is likely to be rare ... few times the workaround of "close&save, reload last" is needed.
Not that rare. Most of the geany-plugins README files are "detected" as None.
... breaking the filetype guarantee on reload is not an acceptable tradeoff ...
I did not find this "filetype guarantee" in the manual. It is a 74-page document, so maybe I missed it.
Since "None" is the fallback filetype, it's a good candidate for another detection attempt. Always auto-detect on reload would also be reasonable because reloads are forced by the user or external changes.
FYI, from the Geany `filetypes.h` API documentation: ```C GeanyFiletype *filetypes_detect_from_file(const gchar *utf8_filename) Detects filetype based on a shebang line in the file or the filename extension. ```
Detects filetype based on a shebang line in the file or the filename extension.
Which was correct until someone decided to add the html/xml stuff and didn't update it.
Not a good presumption. I did not find this "filetype guarantee" in the manual.
All projects as old (the oldest release tag in git is 2005 when the project was moved from CVS to SVN but that clearly wasn't the start of the project) as Geany have some undocumented presumptions of how the project works and how things are intended to work. One of the skills in contributing to open source is to listen and learn those unwritten presumptions.
Unconditionally changing the filetype (if detected) from a reloaded file means a user specified filetype will be overridden, and people do reload for all sorts of things, there is even an automatic reload option used by some for dynamic things like logfiles or program outputs. An accidental filetype detection on reload would keep changing the user set filetype for those.
If there is an argument for re-running the filetype detection on an open file then a menu item (which can have a keybinding so you can avoid that horrible menu thing :-) should be added to do that. Do not to connect two separate actions and force users to accept both when they only want one.
changing the filetype (if detected) from a reloaded file means a user specified filetype will be overridden
What happened to the "presumption is that the majority of files recognise their filetype correctly"? Given how annoying changing filetypes is, I doubt many users bother to manually change it.
... there is even an automatic reload option used by some for dynamic things like logfiles or program outputs. An accidental filetype detection on reload would keep changing the user set filetype for those.
If program output includes filetype identification, the filetype should be changed to match. For log files, the filetype is unlikely to change because logs are usually appended. If the filetype is changed only when the type is None, it's even less likely that a manually selected filetype would be changed.
Do not to connect two separate actions and force users to accept both when they only want one.
Reload + detect filetype could easily be put behind a flag in various. Then whoever wants it can just check a box.
Given how annoying changing filetypes is, I doubt many users bother to manually change it.
You overstate that, its simply a multi-level menu, just because you don't like them does not mean they are an issue for most people.
Geany is a GUI program with keyboard shortcuts for common things, menus are the main UI method. I'm not saying the UI is brilliant, feel free to suggest a better UI but in a separate issue.
The filetype menu is multi-level because the number of options is so large a single menu could overflow smaller screens (there was a mailing list query Nov 8 that even existing (unspecified) menus are too large for Raspberry pi resolutions so it already happens for some menus).
For log files, the filetype is unlikely to change because logs are usually appended.
So every reload will re-detect the same wrong filetype.
Reload + detect filetype could easily be put behind a flag in various. Then whoever wants it can just check a box.
Just make re-detect filetype a menu option separate from reload, not another mysterious option, `Document->Set Filetype->Redetect` with a keybinding. It could even be useful for users having trouble setting the `-*-XXX-*-` comment.
Just make re-detect filetype a menu option separate from reload...
The menus are already too cluttered, and there are already too many keybindings to remember.
It could even be useful for users having trouble setting the `-*-XXX-*-` comment.
How? Without the filetype specifier, the same filetype would be detected.
github-comments@lists.geany.org