Thank you for the suggestion.

I agree that sometimes dividing into parts makes things clear,
especially for the testing.

On the other hand, I don't plan to split files for now,
as one file mode has more portability and I think it is better for users who just use the script.

Understandable about users that just use the script. However I imagine that most people would run the script from the cloned repo, so they can update it easier and track any changes. (If they have ahk installed, they are probably developers who write other scripts too, right?)
Otherwise they would just use the exe.
If they have the whole folder anyway, then they can still run one script and the others will automatically get called.

Would this be solved if the exe was kept up to date? (ie through ci)?

It seems to me that the script is never going to be super portable because you need to have a portable ahk install anyway, meaning the additional complexity of this being multiple scripts instead of one is relatively smaller.
I think that, for a portable version, we should focus on the exe, which is truly portable.

Would you consider this some more now that the exe is being kept up to date? (Which solves the portability issue, to a large extent?)

Yes.
I could not find the good practice to make a structure for AHK scripts,
but maybe we can start with vim.ahk at top and lib/xxx.ahk?

I concur. Feel free to check out my fork to see how I did it, and I believe one of the other contributors split it a different way.

For example, mappings should be separate from settings code.

Possibly separate out code for the model as well, like what the current mode is? May not have enough stored state for this to be worth it though

ok, I'll employ the policy for development.
As you mentioned, separated into each mode may not only make the code seems better
but also give some futures available.

Can I do this and open a PR? Or are you happy to? (I really want this done, especially after the work I just did)

Closed as #40 was closed.