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.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.