As a user, I'd like more command mode functions to reduce typing #146
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#146
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When in command mode, hotkeys could be made available to provide additional functionality that would reduce typing and increase speed of use. Some examples:
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.
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.
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'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?
Yeah something like this would be a good candidate for a 3.x.x wishlist.