How to implement magic-enter functionality in ble.sh?

[mattmc3]

OMZ has a pretty simple Zsh plugin called magic-enter. Magic-Enter detects when you have no command typed and it executes a default one instead. I'm so used to just hitting enter to run git status -sb . that I'm finding it hard to live without in bash, since I have a working version in zsh/fish.

I read #420 thinking it would be pretty close and I could figure it out, or I could override ble/widget/accept-line, but I just couldn't find enough examples to make any progress. Any suggestions?

[akinomyoga]

I haven't checked how the mentioned magic-enter precisely behaves, but here are examples:

If you want to replace just Enter,

# blerc

function ble/widget/blerc/magic-enter {
  if [[ ! $_ble_edit_str ]]; then
    ble/widget/execute-command 'git status -sb .'
  else
    ble/widget/accept-single-line-or-newline    # this is the default binding of C-m/RET
  fi
}
ble-bind -f C-m blerc/magic-enter    # for traditional keyboard protocol
ble-bind -f RET blerc/magic-enter    # for advanced keyboard protocol

If you want to hook into more places that executes the user's command,

# blerc

ble/function#advice around ble/widget/default/accept-line '
  if [[ ! $_ble_edit_str ]]; then
    ble/widget/execute-command "it status -sb ."
  else
    ble/function#advice/do
  fi
'

If you want to automatically input git status -sb . in the command line and execute it so that it is recorded in the command history,

# blerc

function ble/widget/blerc/magic-enter {
  if [[ ! $_ble_edit_str ]]; then
    ble/widget/insert-string 'git status -sb .'
    ble/widget/accept-line
  else
    ble/widget/accept-single-line-or-newline
  fi
}
ble-bind -f 'RET' 'blerc/magic-enter'
ble-bind -f 'C-m' 'blerc/magic-enter'

[mattmc3]

This worked perfectly! Here's what I ended up with. This is a fully compatible ble.sh implementation of magic-enter:

# Default commands
: ${MAGIC_ENTER_GIT_COMMAND:="git status -sb ."} # run when in a git repository
: ${MAGIC_ENTER_OTHER_COMMAND:="ls ."}           # run anywhere else

# This can be changed to handle all manner of magic-commands.
function ble/widget/blerc/magic-enter-command {
  # In a git directory, run a git command. Otherwise, run other command.
  local magic_cmd
  if command git rev-parse --is-inside-work-tree &>/dev/null; then
    magic_cmd="$MAGIC_ENTER_GIT_COMMAND"
  else
    magic_cmd="$MAGIC_ENTER_OTHER_COMMAND"
  fi

  # Run the command magically.
  ble/widget/execute-command "$magic_cmd"

  # Or, run the command more explicitly.
  # ble/widget/insert-string "$magic_cmd"
  # ble/widget/accept-line
}

function ble/widget/blerc/magic-enter {
  # If no command is given, run magic-enter-command. Otherwise, run the
  # ble.sh default binding for C-m/RET.
  if [[ ! $_ble_edit_str ]]; then
    ble/widget/blerc/magic-enter-command
  else
    ble/widget/accept-single-line-or-newline
  fi
}
ble-bind -f C-m blerc/magic-enter    # for traditional keyboard protocol
ble-bind -f RET blerc/magic-enter    # for advanced keyboard protocol

Thank you so much!! One quick follow up question - I don't understand what you meant by the middle example: "if you want to hook into more places that executes the user's command...". Any clarification/tips on how to learn more about advice and how that works and when to use it?

[akinomyoga]

"if you want to hook into more places that executes the user's command..."_. Any clarification/tips on how to learn more about advice and how that works and when to use it?

advice is used to modify an existing function. The function ble/widget/default/accept-line may be called by other places, such as C-j, C-Enter, C-o, M-#, etc., and also the custom keybindings set up by the user. The first example changes the C-m and RET bindings to another widget, so the calls of the shell function ble/widget/default/accept-line in other places are kept, and the behavior in other places is not affected. The second example changes the behavior of the shell function ble/widget/default/accept-line, so all the places that call ble/widget/default/accept-line are affected.

There is only a Japanese code document about ble/function#advice, which means that it would have been just an internal function that I use internally. I naively don't want to make too many shell functions a part of the public interface because making it a public interface means I cannot later adjust the behavior for compatibility reasons. However, maybe I should consider ble/function#advice as roughly a part of the public interface because I have already used it many times to answer users' questions/requests. Maybe, I'll have to document it (and other related functions) somewhere.

The utility ble/function#advice is motivated by Emacs Lisp's language feature advice, which is often used by Emacs packages/modules to customize the behavior of the text editor GNU Emacs. The effects are roughly as follows:

• ble/function#advice before effectively inserts additional processing before starting the evaluation of the specified function.
• ble/function#advice after likewise inserts processing after completing the evaluation of the specified function.
• ble/function#advice around can be used to insert processing before and after the original function content, or in other words, can be used to define an entire execution flow of the function, where the original function content can be called by ble/function#advice/do.

It should be noted that only one advice can be set to each advice type for a function (unlike the advice in GNU Emacs). Defining the same type of advice for a function removes the previous advice. The internal implementation is realized by just overwriting the function with a new function. When you call ble/function#advice around myfunc, the original content of myfunc is copied to a function ble/function#advice/original:myfunc, and the shell function myfunc would be replaced by the one defined by ble.sh. The added advice is saved to another function ble/function#advice/around:myfunc. For example,

$ myfunc() { echo 'Hello, world!'; }
$ type myfunc
myfunc is a function
myfunc ()
{
    echo 'Hello, world!'
}
$ ble/function#advice around myfunc 'echo "function called: ${ADVICE_WORDS[*]}"; ble/function#advice/do; echo "exit status: $ADVICE_EXIT"'
$ type myfunc
myfunc is a function
myfunc ()
{
    ble/function#advice/.proc "$FUNCNAME" "$@"
}
$ type ble/function#advice/original:myfunc
ble/function#advice/original:myfunc is a function
ble/function#advice/original:myfunc ()
{
    echo 'Hello, world!'
}
$ type ble/function#advice/around:myfunc
ble/function#advice/around:myfunc is a function
ble/function#advice/around:myfunc ()
{
    builtin eval 'echo "function called: ${ADVICE_WORDS[*]}"; ble/function#advice/do; echo "exit status: $ADVICE_EXIT"'
}

If you are interested in the detailed behavior for the advices, you can apply machine translation to the code document. In my experience, the translation quality is usually good for the description/definition of this kind of utility.