magmax/python-inquirer

Discussion: solving multiline text render issues

guysalt opened this issue · 7 comments

hi there,

i see there is a lot of issues about solving the render bugs that appear when a line is longer then the terminal width.
i really want to help this repo to be better, and i think i have enough time to do so.
so i'm wanting to try to fix these bugs and making pr's for this.
and i wanted to ask in advance if it's ok before i'm starting to put a lot of hours in these. and also how can i communicate with you if i have any questions about anything in the code?

thank you :)

Hey, we would be happy to accept PRs on this (and its a really big issue and fixing would be a great advancement)

However keep in mind that this will probably more work, as it might require rewriting the renderer pretty much completely.


As for questions, feel free to ask questions you have here and if you have a working example, open a PR and we can discuss it there. I can also open a development branch for this feature, which you can target with your PRs (if you plan on multiple PRs)

My knowledge on the codebase is not super deep though. I mostly know about the handeling of input and the interactions with readchar (which I maintain). Staticdev is leaving the project right now and the original author is very rarly available.

great!

yea i understand this will require a lot of work and rewriting and that why i ask before starting to work.

and i think it will be great to open a development branch that i can target!

thank you!

msg_template = (
"{t.move_up}{t.clear_eol}{tq.brackets_color}[" "{tq.mark_color}?{tq.brackets_color}]{t.normal} {msg}"
)

def print_str(self, base, lf=False, **kwargs):
if lf:
self._position += 1
print(base.format(t=self.terminal, **kwargs), end="\n" if lf else "")
sys.stdout.flush()

hey,

there is a specific reason why the print_str formatting instead of just get the message and print it?

i think it will be better if print_str function just print the output and handle the position attribute. and everything that relate to the formatting will be outside the function...

I dont know why it was done this way.

I assume there where plans on making this more cabale of different output devices (for example, to files or non-tty consoles or similar). This way the theming would be present in all higher functions and only the last step would be specific to a rendering device and implement how to apply the theming.

But I think its safe to assume a TTY output and work from there (readchar also requires it for the most part)

hey, do you want to open a development branch?

i have already some changes you can look at and i think it will be great to go over features/bug fixes one by one for convenience

i can do all the changes in one branch and open a pr to main, but it will be include more than one issue... so it's for your decision :)

No, i will open a dev branch. But I am currently on holiday and didn't bother to to it on mobile. Will do it in the weekend