Let user choose which code theme to use in markdown

[PraxTube]

Currently, the markdown uses code_theme="monokai" (the default). However this looks really bad in light themed terminals:

As you can see, the inline code looks ugly, but at least readable. However the

code block

is unreadable in light theme. The rest of the colors get picked up automatically by the terminals system colors, so we don't have to care about those (at least for now). The neat thing is, that you can set the code_theme of the markdown with

rich.Markdown(msg, code_theme="monokai")

here are a few examples of possible color themes. Note that this for some reason only works on the code blocks but not for the inline code. I think this is a bug, so I filed an issue at the rich repo (though there weren't any responses yet). The other problem I have is how to let the user set the theme. One possible and in my opinion elegant solution would be to use the .config/chatgpt-cli/config.yaml file, which the user needs to configure anyways. We could create a new section like

theme:
  code_theme: monokai

However the problem I face when trying to implement this solution, is how to parse it to the utils/io.py file. Using utils/file.py doesn't work because it imports io.py which leads to a circular import. And reading in the config.yaml file from io.py also seems like a rather hacky solution. Maybe you have any ideas (this issue is not super urgent)?

[efJerryYang]

Alright, I understood. I will work on the configuration part first, and I also encountered the problem to render inline code in a light theme but unfortunately did not find a solution (so I skipped it earlier).

[efJerryYang]

Finding a proper solution in this situation is truly a little challenging. The issue of "circular import" persists when trying to use printmd in file.py. To address this issue, one solution is to remove all the usage of printmd. This is because the current problem is generally caused by flaws in the package structure, and restructuring the modules and refactoring the code would be time-consuming.

Therefore, to resolve this issue, I use colorama instead for file.py to display information related to warning, error, and success. This is a temporary solution, and I am not sure whether it is worth reorganizing the messy code for this small tool.

[PraxTube]

Yes I agree. It is very difficult to implement it in the current state of the project. Though I wonder if that means that the current structure isn't the best? Not really sure how to fix it either.

[efJerryYang]

You are right that the project structure needs better organization and planning. However, I am occupied with several coursework projects at the moment, and cannot allocate the time required to replan and rewrite the project. Therefore, I tend to leave it as it is without making significant changes. If you are interested in restructuring the project, please feel free to do so. However, I must caution that restructuring will require a considerable amount of time and effort, which may distract from the original purpose of developing a handy cli tool for daily usage.

[PraxTube]

Yes indeed. I didn't mean to put pressure on you by requesting a restructure. I just wanted to point out that the code structure could need rethinking and I am glad that you are aware of it. That said, it would be indeed quite time consuming to restructure and I will also have my hands full with uni courses starting in two weeks.

Leaving it as is won't hurt too much I think. Also, who knows, with how development is going right now, we might be able to let an AI restructure this project in a couple months 🙃