Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to turn off the nsearch [(nsearch#1: << !1170 ) `']? #80

Closed
carv-silva opened this issue Jan 5, 2021 · 9 comments
Closed

How to turn off the nsearch [(nsearch#1: << !1170 ) `']? #80

carv-silva opened this issue Jan 5, 2021 · 9 comments
Labels
Information Needed NYI/NewFeat Not yet implemented or New Feature

Comments

@carv-silva
Copy link

Theres one workaround like exec_errexit_mark= to hide (nsearch#1: << !1170 ) `'?
print001

@akinomyoga
Copy link
Owner

May I ask what kind of behavior would you expect in detail? I think I first need to make it clear whether you intentionally use the non-incremental search (nsearch) through some key bindings such as C-x up orC-x p, or use it through, for example, up or C-p defined in some template settings (like oh-my-bash) without knowing the behavior of nsearch? If you use nsearch without knowing it, I'll explain the behavior of nsearch. Then, we can talk about the design!

@carv-silva
Copy link
Author

Please, can u explain me the default behavior of nsearch? because I do not expect any verbosity from him.

@akinomyoga
Copy link
Owner

akinomyoga commented Jan 7, 2021

OK. So, I guess you use nsearch through up or C-p through some custom settings? I'm actually not sure how you start nsearch, so I need to explain every possible case...

Starting nsearch

The purpose of nsearch is to search command-history entries that contain a particular string. The searched string and how the string matches depend on how you start nsearch: There are three types of widgets (text editing commands) that can be used to start nsearch.

  • history-search-backward, history-search-forward: Searches the string in the command line before the cursor. Matches with the history entry that starts from the searched string. The two widgets -backward and -forward search strings in the backward (older commands) and forward (newer commands) direction for the initial match.
  • history-substring-search-backward, history-substring-search-forward: Searches the string in the command line before the cursor. Matches with the history entry that contains the searched string.
  • history-nsearch-backward, history-nsearch-forward: Accept input from the user for the searched string. Matches with the history entry that starts from the searched string.

The default key bindings in ble.sh for these widgets can be found in this section of the manual. Optionally one may also bind other keys to these widgets through .inputrc, bind or ble-bind. Some Bash config frameworks contain such bindings by default. For example, oh-my-bash contains the following lines which configure to start nsearch by the keys up or down.

bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'

It is also widely used to configure C-p and C-n for nsearch:

bind '"\C-p": history-search-backward'
bind '"\C-n": history-search-forward'

The description of this kind of custom settings can also be found in the following places:

After these widgets for nsearch are called, ble.sh enters the nsearch mode.

In nsearch mode

In nsearch mode, you can move between the next or previous matches using the key up/down or C-p/C-n (The detail mapping is described in the manual). In the nsearch mode, the following status line is shown:

(nsearch#N: << !M >>) `NEEDLE'

where N indicates that the current match is the Nth match. M shows the current position in the command history. NEEDLE shows the searched string. << >> shows the lateset search direction; when it is <<      , the latest search direction was backward. When it is       >>, the latest search direction was forward.

In your case, NEEDLE is the empty string. In this case, it moves history entries one-by-one because the empty string matches any history entry, which is similar to the default bindings of up/down (when not in multiline mode).


So, to achieve the behavior that you like, we want to discuss what is the current situation and want to discuss what is the behavior you like. Let's start with the following questions:

  • Q1. Do you intentionally use nsearch?
  • Q2. When you see (nsearch#1: << !1170 ) `', you are in the nsearch mode. How do you enter the nsearch mode? Edit: In particular, which key did you use?

Thank you

@akinomyoga
Copy link
Owner

Hi! Do you have any new information on this? Thank you!

@Alyetama
Copy link

Would it be possible to, for example, run the previous line by just hitting up then enter once? The current default behavior is that when I use the key up, I see the previous line and something like this (nsearch#1: << !1057 ) `', then if I hit enter once, it selects the previous line, then I have to hit enter again to run the previous line that I have just selected.

I would like to know if there is a way to bypass this and instead just hit up then enter to run the previous line (the normal bash behavior)?

@akinomyoga
Copy link
Owner

akinomyoga commented Apr 24, 2021

@Alyetama Thank you for your feedback!

Would it be possible to, for example, run the previous line by just hitting up then enter once?

I'm sorry, but could I confirm what you mean by the previous line? The reason why I ask is that a considerable number of people seem to unintendedly set up the non-incremental search (nsearch) and requesting the behavior that just cancels their settings.

  • If you just want to run the previous line in the history, you can remove the custom bindings for up in your .bashrc files. In ble.sh default, up enter will already run the previous line. The reason that you see nsearch and that you need to hit enter twice is that you have settings of the non-incremental search in your .bashrc.

    # remove settings something like:
    bind '"\e[A": history-search-backward'
    bind '"\e[B": history-search-forward'
  • If you want to run the previous line that matches your non-incremental search, you can use C-j to run the command. If your terminal supports a distinct key sequence for C-enter (modifyOtherKeys), you can also use C-enter. You can find the details of nsearch mode in the manual to run the command.

  • If you want to change the keybindings in nsearch (knowing what you are doing), you can bind nsearch/accept-line to RET and C-m in the nsearch keymap:

    # In ~/.blerc
    
    ble-bind -m nsearch RET nsearch/accept-line
    ble-bind -m nsearch C-m nsearch/accept-line

    For the details of the keybinding settings, you can read the manual §3.


The current behavior exiting the nsearch mode by RET/C-m was actually an intended change from the default Bash behavior. When you search a string through the history, the user cannot predict the search result usually. Also, sometimes we want to slightly edit the search result before running it. So I thought it is better that RET should just exits the nsearch mode. The behavior is different from Bash's one, but ble.sh's nsearch explicitly shows (nsearch#N: << !XXX) `NEEDLE' so that it is clear that we are in a different mode and it wouldn't cause confusion.

But I was thinking that maybe we can change the behavior when the nsearch is started by an empty string because the search result is predictable, i.e., just the previous line in history. But I need some opinion from users for the detailed behavior for that special treatment, so I wanted feedback from users for this issue, but @carv-silva seemed to have disappeared. Do you have any opinion on this possible special treatment for the empty-string nsearch?

  • One possible behavior for the empty-string nsearch is just to go to the previous line in the history as with the default settings of ble.sh. The problem is that it is different from the default Bash; nsearch for an empty string in the default Bash just loads the previous-line content without actually moving to the previous line in the history.
  • Another option is to keep the current behavior but just turns off the status-line message of (nsearch#1: << !XXX ) `'. The problem is that we appear to be in normal status even though the behavior is different in the nsearch mode (e.g., enter as you have pointed out).
  • Or we keep the current behavior.
  • Or we make it configurable. In that case, we still need to choose the default behavior though.
  • Any other idea?

@Alyetama
Copy link

Or we make it configurable. In that case, we still need to choose the default behavior though.

I think this is the best option. I have been looking for a configuration before I posted my comment, but have found none. If there is one, then I would have just used it. I would recommend that you keep the default as it is, and document the option in README.md and .blerc files. Alternatively (and this might be an overkill), you could create a configuration wizard that runs by default during installation, like powerlevel10k's configuration wizard for example.

@akinomyoga
Copy link
Owner

Alternatively (and this might be an overkill), you could create a configuration wizard that runs by default during installation, like powerlevel10k's configuration wizard for example.

It's slightly different from the installation time configuration wizard, but TUI configuration utility is the scope of the future version ble-0.5. Later maybe I'll open a new issue to show my plan and also to collect opinions on the detailed design. Thank you!

@akinomyoga
Copy link
Owner

@carv-silva As written in #101 (comment), now non-incremental search (nsearch) accepts detailed options including the one to hide the status. Or, if you don't want to use nsearch with up/down, you can simply remove the corresponding user settings from e.g. your oh-my-bash.

Now I close this issue. If you have additional questions or suggestions on nsearch, you are always welcome to open new issues. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Information Needed NYI/NewFeat Not yet implemented or New Feature
Projects
None yet
Development

No branches or pull requests

3 participants