Support for Bold style in prompt

[coreyja]

I really like this project and want to start using it for my bash prompt! I starting getting a config setup and realized that my current setup uses BOLD typefaces for some of my prompt and I couldn't find a way to do that with promptconfig. My current prompt (https://github.com/coreyja/dotfiles/blob/master/.bash_prompt) uses tput to set a bold style.

tput can be used to look up the color escape codes. As I understand it, it provides better interoperability with different terminals which may use different escape codes.
StackOverflow about tput: https://stackoverflow.com/a/20983251

[coreyja]

I am working on getting an PR out to work on this and wanted to bounce some ideas off ya!

I thought I might as well add support for using tput to look up colors, as well as use it to set BOLD styles. It seems to be best practice to check if tput exists, and use it if it does. Falling back to hard coded escape codes.

Do you think this would be a good solution for promptconfig? Or do you think we want to add some configurability around this? Do you want to people to opt in to this feature? Do you want three options (use tput always, use tput with fallback, use escape code always)?

If we make it configurable do you think we should do the configuration at for the entire prompt, or should we do it for each individual color/component? I think each color fits easier into the current configuration mode (Edit: they might both be fairly easy to implement actually as I explore the code more), but I think it makes more sense that a User would want to choose for everything not for any individual color.

At the moment I have a branch that just switches to using tput, but I think at least adding fallback support makes sense, but wanted to get your ideas!

[brandonweiss]

Hey! Thanks for your interest!

Ah, I genuinely did not consider styling other than color 🤔 In addition to bold, it looks like there is also dim, underline, inverse, and background colors. There is also italic and strikethrough, although those are apparently not well-supported.

Regarding tput, I’ve never heard of it before and the man page is unintelligible to me 😭 Is it… a convenience around escape sequences? What I’m trying to understand is, if a fallback is necessary, what’s the point of using tput at all?

[coreyja]

Is it… a convenience around escape sequences?

I think that is part of it! The other part, which I will admit is probably a more theroretical argument, is that is provides better portability. I believe the escape codes we all currently used we're designed for the VT100 terminal emulators and became the ANSI standard.
While it seems unlikely a new terminal emulator gets popular that is NOT based of vt100 it is possible. In those cases there is no guarantee that the escape codes will work on either system.
Enter tput which would look up the correct escape code for the terminal it is running in

But this is fairly theoretical, cause I suspect vt100/ANSI escape codes are here to stay lol.

What I’m trying to understand is, if a fallback is necessary, what’s the point of using tput at all?

That's a totally fair point! Here is how I was thinking about it! As a user of this repo, I shouldn't need to think about tput or escape codes at all!
This project essentially does a 'compile' step to create the end result. I think this compiled version should work on 'any' terminal, and the best way to do this is to use tput for the styling.
There are apparently old systems where tput is not available, so to work on as many terminals as possible we should support tput but fallback if it's not installed.

Another thought I had was using tput at compile time to find the right error codes and then just hard code them. The problem with this approach is that you are then tieing your bash profile to whatever terminal it was compiled with. Maybe this isn't a huge issue, but seemed sub optimal to me

So all that to say, if someone was hand writing a bash prompt I'm not sure how necessary the fallback is, but for a 'compiler' in essence I think it might make sense, but would love to hear your thoughts!

Does that all make sense? Written out on mobile on the train, so I apologise for any typos or errors!

[brandonweiss]

Sorry it took me so long to get back to you. I know how annoying it is when you want to contribute to a project and the maintainer is absent/slow. 😓

Thanks for explaining about tput!

Conceptually, I like the idea of supporting as many emulators as possible. But, in practice I’m very… practical 😂 with my time and I have strong bias for simplicity.

For example, there are libraries that detect what colors are supported (16, 256, or millions) and will use the appropriate escape codes. But after doing some research, millions of colors seem to not be universally supported yet (and isn’t really necessary for this tool anyways) and I couldn’t find any common emulators that only support 16 colors. Only supporting 256 colors allowed me to avoid the use of a dependency and to simplify the code and interface quite a bit, which seems worth it to me.

Back to tput. I basically ask myself two questions.

1. How currently common is the scenario where someone’s prompt doesn’t work on an emulator because the escape sequences are wrong?
2. How much simpler is using tput than what we currently do?

It seems the answer to the first question is that it’s extremely uncommon (or doesn’t actually happen)? Let me know if I’m wrong!

I don’t actually know the answer to the second question as I found it really difficult to find easy to understand examples of using tput anywhere, but even if it was actually simpler, the fact that there are some systems that don’t have tput and thus necessitate a fallback means any gains in simplicity would be nullified.

Given that, using tput doesn’t seem to make sense to me. 😕

That said, your root suggestion about adding styling other than colors does seem very useful! I didn’t even consider bold/underline/etc. because I don’t use any of those in my prompt. 🤦🏼‍♂️ If you have interest in implementing that I’d happily accept a PR!