Giters

fidian / ansi

ANSI escape codes in pure bash - change text color, position the cursor, much more

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Couple of questions

Hologos opened this issue · comments

commented

Hi,

I made a formatting library when developing my own dotfiles and now came across this awesome library (thanks to awesome-shell). I am thinking about migrating to your library because I am in the middle of refactoring it and I would almost certainly ended up doing what you have already done.

I have 2 questions, though:

  1. It seems your library doesn't support debugging (I guess since it's been 'on the market' for a long time, all bugs has been squished) in a sense of outputting raw data (aka eg. \e[1m\e[38;5;33mJiří Málek\e[m). Are you planning to implement that?

  2. I tried using your library for formatting prompt and it works with no issues. When I was developing mine, it had a nasty bug which caused cursor to behave weird. It would jump around and stuff. I was able to find the cause (after reading a lot of zsh manual) and the fix was to enclose all formatting in prompt with %{ and %} (eg. %{\e[1m\e[38;5;33m%}Jiří Málek%{\e[m%}). It didn't matter if I was generating escape sequences with tput or manually. Did you ever come across this issue?

Thank you

commented

Sorry for not getting back to you sooner. The email got lost in my inbox during some really hectic time.

You're right that my library doesn't really support debugging, but I don't even know what kinds of debugging would be possible. One can already capture the escape codes and verify that they are exactly what you expect. I also often would use set -x to see the commands that are being executed or use a debugging library that employs the DEBUG trap or PS4 to print commands. Maybe I'm not seeing what you'd do with the debugging or the technique you'd use to debug an issue. Can you explain more?

I came across that type of issue when setting the terminal title in my prompt. This is because Bash calculates the length of the prompt with the escape characters, so I had to ignore those extra things by wrapping them in \[ and \], as seen here and explained here. I feel that this might be the same for you and zsh, especially after reading this page.

commented

Closing after a month. Feel free to follow up with a new issue. Hope I answered your questions.

commented

Hi,

finally remembered to answer to you.

ad 1) I got bash debugger finally working in my IDE so I don't have to debug the code like that anymore. What I meant can be seen in my formatting library. If debug mode is on, it prints unescaped output to STDERR with informations about what formatting is being set.

ad 2) So it means that your library doesn't do anything to prevent this behaviour? That's weird, because I used your to format the prompt and the cursor behave like it is supposed to. Maybe it's caused only by tput output. I have to test that again.

commented

I may consider adding a debug mode to simply write things like "enabling red" and "turning off bold", but I find that using the program to generate pretty images on my screen is a better test of the functionality of the program. In the meantime, I think I'll ponder the situations where the debugging would be beneficial and see if I can convince myself that the slowness added by extra conditions is a fair trade for the value that's provided.

Thanks for following up and providing a great example. Sorry that I can't help much about the prompts. It is possible that proper escape sequences are already caught and that tput's are formatted weird or something, but I honestly doubt it. I wish I could give you a pointer for something to research.

commented

I think it is not necessary to implement debug mode anymore. Your library is well tested. I am recommending it wherever I can. It's a great piece of software.