refactor/enhancement: Added "[default theme]" suffix to the --list-themes command-line option and cleaned up the duplicate code.

[sumagnadas]

This PR adds the suffixes [default theme] to the listed themes. The first suffix is applied to the theme zt_dark which is the default theme for Zulip Terminal.

This PR also combines the two places with a function which lists themes hence cleaning up the duplicate code present because of the addition of the --list-themes command-line option.

A follow up to PR #803.

[neiljp]

@sumagnadas Thanks for the follow-up. As below, I've merged one commit with minor adjustments already, but it would be useful to not have a valid config file in order just to list themes.

[sumagnadas]

I kept the user_preference suffix to denote the theme which is either specified on the command-line or the zuliprc config file. So its there because of the command-line option specification.

[sumagnadas]

I also removed the FAQ commit to squash the initial commit and the "code refactor" commit into one.

[neiljp]

@sumagnadas Thanks for taking the function approach. This is looking closer to the use of common code for --list-themes and the 'bad theme' case now that I had envisaged in an earlier response 👍

With the current way that the rest of the code is structured in this file - the prompting for server details and so on being inside other functions, if the configuration file isn't found to be valid - then I think we should leave the has_config and specified-theme parameters for now:

• --list-themes being above, can't have this information without adjusting the way these other functions work
• in the case of an invalid theme, then passing the theme won't achieve anything, as by definition it is invalid!

So, we can still use the new function at the top (just for args.list_themes) and below (just for the invalid theme), but completely separately for now.

[sumagnadas]

I also edited the first commit to not include the [user preference] because, in the second commit, it was removed.

[sumagnadas]

@neiljp Anything I should change in any of the commits?

[neiljp]

@sumagnadas I think it'd work best with the two commits squashed together with a reworded commit text. The overall code looks good in the 'files changed' tab of the PR, and the commit text can reflect that 👍

My reasoning for suggesting squashing is based on the overall result of this PR in the 'files changed' tab - each current commit doesn't seem to build towards it.

[sumagnadas]

See if this works. Sorry if the commit text is not appropriate. I am still trying to get the hang of working with Github repos, commits and the other stuff of open source contribution.

[neiljp]

@sumagnadas Thanks for working on this 👍 I've slightly reworded the commit text and merged it otherwise as-is 🎉

If you want to see the differences in the commit title/description and aren't sure how to go about that, I'd recommend learning about git range-diff.

I also merged #810 - if you have any questions or other feedback on if that would have helped with writing the commits, we'd be happy to know :) (see mainly the GitLint section)