[Github-comments] [geany/geany] Filetype is not redetected on reload, even when current filetype is None (Issue #2996)

elextr notifications at xxxxx
Sat Nov 13 00:25:32 UTC 2021


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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2996#issuecomment-967742203
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211112/7e70a232/attachment.htm>


More information about the Github-comments mailing list