It would be desirable for a github workflow to automatically build and upload binaries for releases for the three major platforms.

There was a suggestion to rename the project to mockingparrot. I like it.

Configuration should be displayed more pretty and have a more friendly and intuitive way to modify.

The config toml file should be located in a user directory (e.g. ~/.config/hummingparrot/config.toml) and be updated when modified in the UI.

Every conversation should start with a message by the "system" user role, which supposedly has a greater weight. The user should be able to write system instruction presets and select one for every conversation.

This is how we fix overscrolling. It does so by clamping the scroll value based on how many lines the widget needs to be rendered. This was implemented like so because it was the most straightforward approach: seeing how many lines the widget needs as it is being rendered. However, this requires passing to the UI rendering function a mutable reference to the State object, which seems quite smelly.

This will likely continue being an issue as the UI requires more scrollbars and other complex UI widgets.

I suggest considering some sort of approach such as separating the UI rendering into 3 parts:

1. Calculating the UI layout
2. Fix overscrolling and any other layout-based adjustments
3. Render the widgets into the layout from step 1

There is API for Dall-E text-to-image models. This can be supported by the client (separately from the conversation).

Currently the user can type their message in the conversation UI. They should be able to edit their message in a visual editor.

Hotkeys are hardcoded and not documented anywhere. They should be configurable in config.toml.

Every API call to ChatGPT returns the token count. This should be recorded and tallied. This can also be used to calculate the cost.

One thing I haven't figured out yet is dynamically retrieving the cost via API call. Last I checked it was not available in the API, but ideally it should be retrieved as to avoid hardcoding it (especially since the cost per token can change).

Each hotkey needs to have a UI scope in which it is active. E.g. the chat model configuration controls should only be active when the UI is focused on the config tab.

The project could use a GitHub workflow to make sure new code passes linters and is formatted before merging to master.

The client should save conversations and allow loading conversations from history.

Furthermore, conversation history should be searchable. (this will be a separate issue)

Currently, the style config looks like this:

[ui.colors]
conversation.background = "#020414"
conversation.foreground = "#33DD88"
conversation_names = "#DD4400"
prompt.background = "#110000"
prompt.foreground = "#DDCC04"
config.background = "#020414"
config.foreground = "#FF5511"
debug.background = "#020414"
debug.foreground = "#5511FF"

Which leads to either inconsistent styling or lots of repetition. I suggest consolidating on a more unified style with a single color for text fg/bg, and also adding colors for scroll bars, title bars, status bars, highlighting, etc.

Currently, the API call is being made with both, but the API reference recommends against this:

We generally recommend altering temperature or top_p but not both.

Not sure if this is an issue, and if so with what approach to fix this. The user may alter both if they like, but if the user alters one and the default is used for the other, this may not be an issue.

A more intuitive syntax in the configuration would be desirable.

E.g. Control + Shift + T or ^!t. Currently this is { code = "t", modifiers = "CONTROL | SHIFT" }.