-
Notifications
You must be signed in to change notification settings - Fork 722
New cursor types for the prompt widget. #5713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Historically the different cursor types have indicated insert / delete modes, do you have plans to implement that? |
|
Good point, I was just thinking about the different visuals and was not planning the implement different editing modes. The underline that is now the default represents replace mode (in vim at least) but it works as insert mode in the current version. I'm not even sure that different editing modes would make sense for a short input field like this one. I hope that this is not an issue. I have found an issue however, that if you have a "<" in the input and you move your cursor next to it, it messes up the Pango markup rendering. I will try to fix this, and the formatting issue that came up during the check in the following days. I have marked this as a draft for now, and will convert it back after the fixes. |
68c1781 to
f2a124c
Compare
|
I have found an fixed the issue with the input character escaping. The for text in (txt1, txt2, txt3):
text = pangocffi.markup_escape_text(text)This does not modify the original variables. I have changed this, and also removed some redundant lines. |
|
Yeah, I was mostly just curious. I don't have a strong opinion about the editing modes. Can you add a test for this as well? |
f2a124c to
2836808
Compare
|
I will try my best, but it might take me some time to figure that out. |
Added a new option `cursor_type` to the prompt widget. By default it is set to 'line', which is the regular appearance of the cursor. The other option is 'block' which inverts the color of the character the cursor is on, instead of drawing and underline.
Added a new possible value for the `cursor_type` option, with value 'none'. If this is selected, no cursor appears, but the cursor color is still applied to the selected character.
Added a new value to option `cursor_type` of the prompt widget. The bar cursor is just a Unicode character. Therefore it looks good at the end of text, but the illusion break if the cursor is moved.
Added a missing trailing comma.
The user input was not properly sanitised for mango markup, meaning that inputting any of <>& had the possibility of messing up the formatting. Escaping is done properly now, and these characters cause no issue.
2836808 to
fd71946
Compare
I have added a new option
cursor_typeto the prompt widget. Depending on the value, the visual of the cursor is different. There are 4 options:line: The original underline, and colored character.block: A block cursor, that works similarly to the underline. It sets the background to the desired cursor color, and makes the foreground transparent, basically inverting the colors in this way. It supports blinking withcursorblink.none: A cursor with no visual, except the color. This might be useful for a minimalist setup. Just the color is maybe enough if you only occasionally go back to edit stuff. It does not blink, respecting that the color did not blink in the original scenario. (Maybe it would be more feature full to make it blink, but I think it just makes it more confusing.)bar: A vertical cursor bar simulated with a Unicode character. It looks nice if you have it at the end of the input, but the illusion break if you move it inside the text. Supports blinking, but the color only applies to the cursor itself and not to characters.I think the
blockandnoneoptions are nice. I'm honestly a bit conflicted on thebarversion. Please let me know what you think. I tried to execute some black magic with theletter_spacingargument I found in the Pango markup refrence by setting it to a negative value. This does not cause any errors, and does shift the next character left, but getting the spacing right is probably impossible, as the width of a single character is not easily calculated from the height of said character. If it is possible, it would probably be really hacky.I have not squashed the commits yet on purpose, so that I can separate them easily if I need to.
I have a few question:
I have tested these changes in a virtual machine first, then on my main system with a lot of different setting combinations. I have not found any issues with it. Please mess around with it a bit and see if I have missed something.