Will Goku consider add generate separate file feature？

[suliveevil]

Edit a separate edn file is a better way to manage multiple profiles.

[yqrashawn]

May I ask what's your use cases of profile?

I've considered implementing multiple profiles with multiple files. But once you have shared rules in multiple profiles, it can't be easily maintained among multiple files. The current implementation supports assigning rules to profiles in a really flexible way.

The problem can be solved by using .clj file instead of .edn file. Thus we can introduce clojure namespace into config system. But that will be too much for normal user.

[suliveevil]

A separate EDN file (as a profile) will coexist with separate personal JSON format config files and easier to share with others, just like how karabier.json contains all contents of separate personal JSON format config files and you can share personal JSON format config file.

It would be the perfect solution to manage edn and JSON config file if Goku can manage JSON files (write file contents into karabiner.json)

单独的 edn 格式文件可以和 json 文件共存并方便分享，就像 karabiner.json 包含了 多个单独的用户 json 文件的内容。

如果 Goku 能直接管理 JSON 文件并写到 karabiner.json 里的话就真的是完美的 KE 配置文件解决方案了。

[webappzero]

As I understand it, Goku presently converts .edn formatted rules into .json format then injects them into the karabiner.json. This appears to be a one way process which requires people to plumb through the json file to find any rules they wish to remove.

Perhaps the option to experiment with separate files would reduce this friction, encouraging more experimentation while learning. It would for me.

What do you think about adding the option of using .clj files for power users without disrupting the present .edn-based "API"?

Thank you for Goku!

[webappzero]

Aero's readme provides a warning against using turing complete language files such as .clj as config.

[yqrashawn]

The current problem is that users can't use .json and .edn config at the same time.

Maybe I can add some kind of goku_id into the .json config so that goku can figure out which rules are from .edn config. And then I can try implementing the sperate files feature.

For using separate files, I need to check karbiner's code which generating the file name of sperate configs.

[webappzero]

That sounds workable.

I was also thinking about the problem and trying to figure out how to leverage Karabiner's existing workflow and GUI. Per the docs, Karabiner watches the directory ~/.config/karabiner/assets/complex_modifications for changes.

This means Karabiner is already expecting separate .json files there and you can immediately see the rule when clicking on Add Rule within the Complex Modifications Tab of the of the Karabiner-Elements Preferences GUI.

This also allows the user to enable/disable each rule for each profile through the GUI. Powerful!

At a minimum, we could add a command-line switch which would scan the directory ~/.config/karabiner/assets/complex_modifications for .edn files and produce any missing .json of the same root filename (i.e. the filename minus extension). I verified the import directory quietly ignores the addition of .edn files (i.e. no errors or warnings to Karabiner Log).

For more automation we could watch the import directory for .edn files to be exported to the .json import directory. Or add a unique directory to avoid conflicts with Karabiner.

Do you see any downsides to such an approach?

[yqrashawn]

Well, users have to use mouse to manipulate plugins.

[yqrashawn]

Just for the record, the json file name in assets is a timestamp.

[webappzero]

Just for the record, the json file name in assets is a timestamp.

Yes, I noticed that Karabiner produces a filename based on the timestamp of the import. But I also tested the case of manually creating a more descriptive filename which Karabiner happily processes via its watcher.

Well, users have to use mouse to manipulate plugins.

Good point! That's a severe limit on the general usefulness of my proposal. Even still, a command line option implementing my proposal would still be nice to have in addition to your proposed implementation. Let me know if you're interested and I could try coding my proposal and submit a PR with any suggestions you might have.

[webappzero]

I'll wait to see how things flesh out with what you implement. I might be able to hack a workflow together using existing tools such as jq to modify the output of existing goku command line options into the properly keyed json imports.

[yqrashawn]

That's a severe limit on the general usefulness of my proposal.

It's not that severe since user only needs to use mouse when adding or remove rules. I believe most user won't do that often once things setup.