As a user, I'd like more command mode functions to reduce typing #146

Open
opened 2020-05-16 03:00:25 +00:00 by asdf · 4 comments
Collaborator

When in command mode, hotkeys could be made available to provide additional functionality that would reduce typing and increase speed of use. Some examples:

  • a hotkey to repeat the previous command or cycle through command history (e.g. up arrow)
  • a hotkey to autocomplete a command, and then cycle through available commands (e.g. tab)
  • hotkeys to enable to cursor, so it can be positioned for fixing typos in a command (e.g. left and right arrows)

History and improved command editing can be provided already by executing Bombadillo with rlwrap (i.e. rlwrap bombadillo).

This is something that might be nice to have, but is not urgent at all.

When in command mode, hotkeys could be made available to provide additional functionality that would reduce typing and increase speed of use. Some examples: - a hotkey to repeat the previous command or cycle through command history (e.g. up arrow) - a hotkey to autocomplete a command, and then cycle through available commands (e.g. tab) - hotkeys to enable to cursor, so it can be positioned for fixing typos in a command (e.g. left and right arrows) History and improved command editing can be provided already by executing Bombadillo with rlwrap (i.e. `rlwrap bombadillo`). This is something that might be nice to have, but is not urgent at all.
asdf added the
enhancement
non-urgent
labels 2020-05-16 03:00:25 +00:00
Owner

While I agree with the utility of readline or readline-like capabilities I am pretty dedicated to not having any dependencies outside fo the standard go lib. Moving away from that stance would enable more than just readline, but would add in arrow keys, read timeouts, all kinds of awesome things... only, I just am really against adding dependencies. It is good to know that rlwrap works though! I had not thought of trying it.

Outside of adding dependencies I have looked into writing basic editline functionality and with the current way both bombadillo is built and the currently available standard lib it would be a prohibitively large and hacky undertaking.

If we can find a good option for non-blocking reads within the standard lib (I am certain it would have to include syscalls and building some level of termios mini-lib) I would genuinely welcome these features. Since currently all reads are blocking there is no way to perform any action during a read, so that is a hurdle that could be handled by setting the equivalent of VMIN and VTIME in the c termios lib. In theory we could use C in go to handle this... though it is often frowned upon by the go community and we would likely have to switch over to gcc from the go compiler.

While I agree with the utility of readline or readline-like capabilities I am pretty dedicated to not having any dependencies outside fo the standard go lib. Moving away from that stance would enable more than just readline, but would add in arrow keys, read timeouts, all kinds of awesome things... only, I just am really against adding dependencies. It is good to know that rlwrap works though! I had not thought of trying it. Outside of adding dependencies I have looked into writing basic editline functionality and with the current way both bombadillo is built and the currently available standard lib it would be a prohibitively large and hacky undertaking. If we can find a good option for non-blocking reads within the standard lib (I am certain it would have to include syscalls and building some level of termios mini-lib) I would genuinely welcome these features. Since currently all reads are blocking there is no way to perform any action during a read, so that is a hurdle that could be handled by setting the equivalent of VMIN and VTIME in the c termios lib. In theory we could use C in go to handle this... though it is often frowned upon by the go community and we would likely have to switch over to gcc from the go compiler.
Author
Collaborator

I agree with your aim to avoid non-standard dependencies. Also, it sounds like the amount of effort and code required to get this working might too heavy.

It looks like the closest thing might be the terminal library in the crypto sub-repository. You may have similar thoughts about dependencies in the sub-repositories, in addition to the work required to rewrite bombadillo to utilise this library and then deal with any limitations it might have (and it may not even do what we would want - I have not used it, just had a quick look at it).

Maybe there are other suggestions from the community on how this could work?

I agree with your aim to avoid non-standard dependencies. Also, it sounds like the amount of effort and code required to get this working might too heavy. It looks like the closest thing might be the [terminal](https://golang.org/pkg/cmd/vendor/golang.org/x/crypto/ssh/terminal/) library in the crypto [sub-repository](https://golang.org/pkg/#subrepo). You may have similar thoughts about dependencies in the sub-repositories, in addition to the work required to rewrite bombadillo to utilise this library and then deal with any limitations it might have (and it may not even do what we would want - I have not used it, just had a quick look at it). Maybe there are other suggestions from the community on how this could work?
Owner

I've looked around a lot and it usually boils down to "use a library". I think for Bombadillo 2.x.x we are maybe where it is going to be in terms of terminal handling. For 3.x.x I would like to work in a lot more concurrency/channels and message passing between modules on different "threads". I dont know when work on 3.x.x should begin. I still feel like 2.x.x is pretty new and I'm still enjoying its functionality. Maybe we should put up a discussion in the issues about 3.x.x wish lists and ideas and maybe do some brainstorming over the coming months to really figure out what the priorities would be and how best to handle them?

I've looked around a lot and it usually boils down to "use a library". I think for Bombadillo 2.x.x we are maybe where it is going to be in terms of terminal handling. For 3.x.x I would like to work in a lot more concurrency/channels and message passing between modules on different "threads". I dont know when work on 3.x.x should begin. I still feel like 2.x.x is pretty new and I'm still enjoying its functionality. Maybe we should put up a discussion in the issues about 3.x.x wish lists and ideas and maybe do some brainstorming over the coming months to really figure out what the priorities would be and how best to handle them?
Author
Collaborator

Yeah something like this would be a good candidate for a 3.x.x wishlist.

Yeah something like this would be a good candidate for a 3.x.x wishlist.
sloum added this to the 3.0.0 milestone 2020-09-06 15:24:15 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/bombadillo#146
No description provided.