Better Reading Function

Now I know this can be created in Lua, but I still thought it would be useful since the function is used in the shell etc. What I had in mind is a pretty simple idea, and that is to remake the read function to support shortcuts such as CTRL+A to select text, shift+left/right and all that other stuff.
I know this is possible, because well.. This has been made by other people on the forums before, but it would be pretty useful to have it natively built-in.
It can be tedious if you have typed lots of stuff and then realise it's wrong, and then have to hold backspace and wait for it all to disappear, it'd be easier to just have to press CTRL+A and then backspace. And I'd say this would improve the edit program a lot aswell.

This is just want I think, if anyone else feels the same then please feel free to post so that Dan sees this, and hopefully responds with his thought about it.
And I've also posted a very basic idea, I'm sure that someone else can elaborate some more and find more useful functions for it and what it can be useful for.

List of features

• Keyboard Shortcuts( some basic shortcuts, bash shortcuts … )
• Selecting Text
• Mouse Support( For advanced computers only obviously )
• Alt-Code support
• Only allow certain characters

Since you mention it, I'd been thinking just the other day that alt-code support would be cool.

Messing with read() won't affect the edit script much, mind you. That'd need to be tweaked separately.

If this does not get implemented, you could always overwrite the read function to suite your needs at startup, that way everything that uses the default read function uses yours

Bomb Bloke, on 21 January 2016 - 11:28 PM said:

Since you mention it, I'd been thinking just the other day that alt-code support would be cool.

Messing with read() won't affect the edit script much, mind you. That'd need to be tweaked separately.

Yeah I feel like this would be really useful, and when I think closer about it I remember that the edit program handles input it's own way.

wilcomega, on 22 January 2016 - 07:39 AM said:

If this does not get implemented, you could always overwrite the read function to suite your needs at startup, that way everything that uses the default read function uses yours

I know this can be done like this, but this is something that will affect everyone, and it'll probably make it much easier for everyone aswell

I'd really like to add bash's Ctrl+U/K (delete everything before/after cursor) to the list. There are several other shortcuts from bash which might be useful.

SquidDev, on 22 January 2016 - 09:07 AM said:

I'd really like to add bash's Ctrl+U/K (delete everything before/after cursor) to the list. There are several other shortcuts from bash which might be useful.

I'll add those as soon as I get home, which is in about 4-5 hours

It took a while longer than I expected, but I'm finally home and I've updated the original post.

Bomb Bloke, on 21 January 2016 - 11:28 PM said:

Since you mention it, I'd been thinking just the other day that alt-code support would be cool.

Messing with read() won't affect the edit script much, mind you. That'd need to be tweaked separately.

Alt codes? Why not Control+Shift+u <codepoint>?


I'd also like to mention zsh's modal line editing.

FUNCTION MAN!, on 27 January 2016 - 10:09 AM said:

Alt codes? Why not Control+Shift+u <codepoint>?

I suppose the main problem there is that CC's Unicode support is fairly limited - each code incorporated would need to be translated (in Lua) to CC's character set. It could be done, sure, but it'd be more trouble to make as well as to use.

Bomb Bloke, on 27 January 2016 - 10:41 AM said:

FUNCTION MAN!, on 27 January 2016 - 10:09 AM said:

Alt codes? Why not Control+Shift+u <codepoint>?

I suppose the main problem there is that CC's Unicode support is fairly limited - each code incorporated would need to be translated (in Lua) to CC's character set. It could be done, sure, but it'd be more trouble to make as well as to use.

I have to side with BB here and say that alt codes would be easier to implement and such, but the one it comes down to, to decide, is ofcourse Dan.
I don't know how often he checks the suggestions board, but ultimately he's the one to decide what gets added.