ble.sh: [Bash 3.2 in macOS] keymap 'emacs' is not defined.
ble version:
3.0.0
Bash version:
I’m on MacOS and have installed bash via Homebrew
$ bash -c 'echo $BASH_VERSION'
5.0.11(1)-release
$ echo $BASH_VERSION
3.2.57(1)-release
When I add follow the instructions for configuring bleh.sh with .bashrc (except that I’m using .bash_profile) I get an error.
usage: sleep seconds
$ ... ~ $ ble.sh: Failed to load the default keymap. keymap 'emacs' is not defined.
Use "logout" to leave the shell.
Oddly enough if I manually source /bleh.sh then bleh.sh does load the first time. If I start a new session and try to source again I’ll get the same error.
Just wanted to add though that this is a cool project!
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 33 (15 by maintainers)
Oh, OK. Thanks.
yep all seems good again so thanks for swift response
The feature works great in ble-0.4 series, but in case you didn’t know an error message does pop up when loading ble.sh.
Ah, you clearly explained this before and I overlooked that point. Thanks!
Thanks for all the help!
Thank you very much for your feedback!
This is actually my preference and was an intended one. I added an option to configure the delimiters c294e31 (in
master
branch not in ble-0.3 because this is a new feature). You can configure the characters to be used for word breaks of <kbd>M-right</kbd> by the following settings.Thanks for looking into those details and providing the escape codes! I have now have
S-RET
others working correctly.Wow, thanks for the thorough explanation. Let me be more specific and you can tell me if the behavior I have is the expected one:
Given terminal input
cd d
and an autocomplete suggestion ofcd do/a/thing
I thought that enteringM-right
would select and move the cursor the first end of the first path segment (i.e changing the current terminal input tocd do/
). This is the behavior I get if I useTab
. However instead enteringM-right
completes to the whole segmentcd do/a/thing
. I think this is not the expected behavior since normally a/
is treated as a delimiter - at least currently in iTerm2 using Natural Text Editing respects the/
delimiters with regular (non-autcomplete suggested) Terminal line editor content.However it’s interesting that
M-right
observe spaces as delimiters in autocomplete suggestions. For example, If I entere
and get a suggestion ofecho hello world
I can then useM-right
to move one word at a time - i.e I would need to enterM-right
3 times to reach the end of the autocomplete suggestions.I followed your instructions and entered
ble-edit/detach
and got an error that looked something like-bash:ble-decode is not ...
. Unfortunately I’m not sure if that’s correct because when I entered the same command again it closed the session, losing the error text. Every time afterwards that I’ve enteredble-edit/detach
after sourcing I get a different error message-bash: syntax error near unexpected token;
.From that state I ran the commands that you requested. Here’s the output:
Before I noted that after a fresh unzipping of the directory I’m able to source
bleh.sh
exactly once before subsequent sourcings return the emacs keymap error. Once thing I forgot to note is the first command post successful source always returns a ` prompt_command_array’ error.