Created attachment 7256 [details] lineedit: improve long prompt first redraw, clear screen, ctrl-c cursor These are actually three 1-line patches for independent subjects. Feel free to ask me to split it to several patches or file a new bugs for each. From the commit message: ------------------------ - Fix vertical alignment of first redraw(..) with long prompt, caused by possibly incorrect initial cursor calculation which assumed width is 80. Now we try to read the terminal width a bit earlier. - Clear-screen (^L) now actually clears the screen after the cursor is reset, because \n in multiline PS1 are non destructive when printed. - Ctrl-c now moves the cursor to the end of input: - Doesn't clutter it with "^C", e.g. it's possible to do selections. - Doens't obscure it with the next prompt if it spans multiple lines and the cursor is at the top (e.g. ctrl-c while in history search). ----------------------- Other than comments you may have, I have one question of my own: I'm not entirely confident about the change which reads the terminal width a bit earlier (literally 5 lines of code up). It's easy to get identical fix without reading it earlier (e.g. by re-calculating cmdedit_x and cmdedit_y right after reading it the first time and before we enter the main loop), but the cleaner fix, if there are no negative side effects, is to read it earlier IMO. I did look at other applets and they do read the width very early, and lineedit too called it even before it becomes interactive and before terminal signals are handled, but it was still after the prompt is already printed and the cursor was calculated with width of 80. So is it OK to read it where my patch puts it?
Just examples for the issues: 1. Getting the term width earlier: - Set the prompt to 85 chars and resize the terminal to 90 or 100. - enter 'ls' to get some output - press arrow up to fetch 'ls' from history expected result: the input is 'ls' and the prompt stays on the same line (85 chars prompt + 2 for ls fits at the terminal width). actual result: the prompt and the input render 1 line higher than expected. The other side of the same issue: resize the terminal to 60 and set the prompt width to 70. entering history (same 'ls') will now render one line below the original rendering (scrolling the terminal up - incorrectly). The next history navigation don't have this issue because 'redraw(...)' calculates the height again after it renders, but for the first calculation - 80 was assumed without this patch. 2. for the clear screen patch: - set the prompt to have few lines, e.g. export PS1="\n\n\n\n$ " - fill the screen with some output. - press ^L expected result: the screen is clean, and "$ " is rendered at the 5th line. actual result: whatever was on the first 5 lines stay there after the clear.
(In reply to avih from comment #0) - Fix vertical alignment of first redraw(..) with long prompt, caused by possibly incorrect initial cursor calculation which assumed width is 80. Now we try to read the terminal width a bit earlier. - Clear-screen (^L) now actually clears the screen after the cursor is reset, because \n in multiline PS1 are non destructive when printed. - Ctrl-c now moves the cursor to the end of input: - Doesn't clutter it with "^C", e.g. it's possible to do selections. - Doens't obscure it with the next prompt if it spans multiple lines and the cursor is at the top (e.g. ctrl-c while in history search). Can you give examples of $PS1 strigns for each change so that the improvement can be reproduced?
bash does not move cursor to the end of line on ^C. So that part is not taken. Fixed in git. Thanks!
Apologies for not replying earlier (even if my second comment did have steps to reproduce). Thank you for merging it!