search

jankrepl / mltype

Command line tool for improving typing skills (programmers friendly)
https://mltype.readthedocs.io
MIT License
448 stars 29 forks source link

Add config file and cache_dir property #89

Closed AbhayAysola closed 4 years ago

AbhayAysola commented 4 years ago

I added a config.ini file and changed get_cache_dir() in utils to get cache_dir from the config file. Let me know if it's okay.

jankrepl commented 4 years ago

Nice work! I will try to extend the idea and add a few commits to this!

AbhayAysola commented 4 years ago

All right. Currently every time the cache directory is changed, a new config file is made inside the new cache directory. I've realised that it could cause some problems that way. So it could be better to only have one config file inside the .mltype directory which points to the cache directory that is currently being used.

jankrepl commented 4 years ago

I still need to add some docs, but let me describe quickly the way this works:

One can define a config.ini file that is by default lying in ~/.mltype folder. Its location can be also passed dynamically to all subcommands via --config flag.

The supported section names are identical to all the subcommands of mlt (ls, sample,...). Additionally, there is a general section.

So what can this config do?

  1. Setting reasonable defaults for the CLI options (e.g. number of characters in sample, target WPM in raw,...). How are conflicts resolved (same option specified both in the config file and as a CLI option)? The CLI argument has a preference over the config file.
  2. One can define custom parameters in the general section that can be read anywhere in the code. Currently I only implemented the models_dir parameter that determines where ls and sample look for models. If not defined it defaults to the current behavior - ~/.mltype/languages folder.

Example

[general]
models_dir =  /home/my_models

[sample]
# one needs to use underscores instead of hyphens
n_chars = 500
target_wpm = 70

[raw]
instant_death = True

The changes should not break backward compatibility. @AbhayAysola feel free to try it out if you have some time:)

AbhayAysola commented 4 years ago

That's pretty cool! I've checked it out and it works well. I will look at the code soon. Looks like mine was refactored (it was kinda bad code anyways).

jankrepl commented 4 years ago

I am going to merge it. Hopefully it does not introduce weird bugs or behavior. It seems to work nicely both based on unit tests and manual testing.

Closes #7 - currently it does not support the color changes, however, this can be done in a separate PR Closes #58