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

Open
opened 11 months ago by asdf · 4 comments
asdf commented 11 months ago
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
label 11 months ago
asdf added the
non-urgent
label 11 months ago
sloum commented 11 months ago
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.
asdf commented 11 months ago
Poster
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?
sloum commented 11 months ago
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?
asdf commented 11 months ago
Poster
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 7 months ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.