Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have seen a history-livesearch with a preview, that shows the 10 first matches in the history in a list below the BUFFER-line, which is updated on every keystroke, and acts like the standard ctrl+r search the rest of the time. (But the user who has that feature is gone for 3 weeks and unreachable)

tl;dr: Does anyone know this plugin/script and can link it to me

or help me programm it with updating the list properly?

my current code looks like that, but has no updating (just the static list from the start and the search does not look totally naturally)

zle -N search

bindkey "^R" search

search () {
echo "";
fc -ln -30 | grep $(printf "%q\n" "$BUFFER");
<standard-history-backwards-search-widget>; #not on linux atm
}
share|improve this question

2 Answers 2

You may already know zsh-history-substring-search.

It does not do preview you have seen, as far as I can tell, but otherwise it seems to be very similar.

If you do not know it, it's worth trying.

zsh-history-substring-search is closely based in the history search of the fish shell. fish has some pretty advanced features in terms of interaction, certainly worth learning from. It is unfoutunately not suitable as a general purpose shell, because it's syntax is pretty different from shells like bash or zsh.


Also not a solution, but closely related:

The zsh distribution contains the widget history-beginning-search-menu, which is doing part of what you look for - but not with the usability:

autoload -Uz history-beginning-search-menu
zle -N history-beginning-search-menu
bindkey '^P' history-beginning-search-menu

It lists history lines which start with the current inpu, in a list to choose from by number.

Pressing Control+P at the location |:

$ dialog  -| 
Enter digit:
1 dialog  --infobox text 5 15| sed 's/...104..//'
2 dialog  --yesno SomeText 0 0
3 dialog  --yesno text 0 0
4 dialog  --yesno text 5 15
share|improve this answer
    
the preview of the first x substring matches is the feature I'm looking for, because I'm new to linux and seeing what I'm searching for after 2-3 letters is a good substitute to calling history all the time –  LinuxNoob1337 Aug 27 at 21:16
1  
Yes, no doubt. As of now, I'm looking for it just the same! And I'm not at all new to Linux - it's a very useful feature either way. –  Volker Siegel Aug 27 at 21:17
    
Well, in 3 weeks I will be able to obtain this feature as my coworker who has it will be back at work, I will share the link here, as of now I just can't find it, eventhough I can access his folders via ssh, any suggestions where/how to search ? as far as I have seen when I try to access /.zshrc it just shows my own config file –  LinuxNoob1337 Aug 27 at 21:46

Answering the alternative part of your question,
"...help me programm it with updating the list properly":

You can directly use the functions that list completion items, update the list, or clear it; That's zle -R.
To write out your own "unmanaged" text, there is zle -M.
From pinfo zsh:

zle -R [ -c ] [ DISPLAY-STRING ] [ STRING ... ]
zle -M STRING
[ ... ]

    -R [ -c ] [ DISPLAY-STRING ] [ STRING ... ]
          Redisplay the command line; this is to be called from within
          a user-defined widget to allow changes to become visible.  If
          a DISPLAY-STRING is given and not empty, this is shown in the
          status line (immediately below the line being edited).

          If the optional STRINGs are given they are listed below the
          prompt in the same way as completion lists are printed. If no
          STRINGs are given but the -c option is used such a list is
          cleared.

          Note that this option is only useful for widgets that do not
          exit immediately after using it because the strings displayed
          will be erased immediately after return from the widget.

          This command can safely be called outside user defined
          widgets; if zle is active, the display will be refreshed,
          while if zle is not active, the command has no effect.  In
          this case there will usually be no other arguments. [...]

    -M STRING
          As with the -R option, the STRING will be displayed below the
          command line; unlike the -R option, the string will not be
          put into the status line but will instead be printed normally
          below the prompt.  This means that the STRING will still be
          displayed after the widget returns (until it is overwritten
          by subsequent commands).

The details of the layout are configured with zstyle ':completion:*' ... somehow, I'm sure.

Some options of the shell builtin print that could help either in itself, or by creating a string that is then printed below the command line using zle -M:
From pinfo zsh:

print [ -abcDilmnNoOpPrsSz ] [ -u N ] [ -f FORMAT ] [ -C COLS ]
[ -R [ -en ]] [ ARG ... ]
     With the '-f' option the arguments are printed as described by
     printf.  With no flags or with the flag '-', the arguments are
     printed on the standard output as described by echo, with the
     following differences: the escape sequence '\M-X' metafies the
     character X (sets the highest bit), '\C-X' produces a control
     character ('\C-@' and '\C-?' give the characters NUL and delete),
     and '\E' is a synonym for '\e'.  Finally, if not in an escape
     sequence, '\' escapes the following character and is not printed.

    [  ...  ]
    -a
          Print arguments with the column incrementing first.  Only
          useful with the -c and -C options.

    -b
          Recognize all the escape sequences defined for the bindkey
          command, see *note Zle Builtins::.

    -c
          Print the arguments in columns.  Unless -a is also given,
          arguments are printed with the row incrementing first.

    -C COLS
          Print the arguments in COLS columns.  Unless -a is also given,
          arguments are printed with the row incrementing first.

    -l
          Print the arguments separated by newlines instead of spaces.

    -m
          Take the first argument as a pattern (should be quoted), and
          remove it from the argument list together with subsequent
          arguments that do not match this pattern.

    -n
          Do not add a newline to the output.

    -o
          Print the arguments sorted in ascending order.

    -p
          Print the arguments to the input of the coprocess.

    -P
          Perform prompt expansion (see *note Prompt Expansion::).

    -s
          Place the results in the history list instead of on the
          standard output.  Each argument to the print command is
          treated as a single word in the history, regardless of its
          content.

    -S
          Place the results in the history list instead of on the
          standard output.  In this case only a single argument is
          allowed; it will be split into words as if it were a full
          shell command line.  The effect is similar to reading the
          line from a history file with the HIST_LEX_WORDS option
          active.

    -u N
          Print the arguments to file descriptor N.

    -z
          Push the arguments onto the editing buffer stack, separated
          by spaces.

    [  ...  ]

I remember one hard to get-by obstacle when the completion values contain spaces: Most of the completion mechanism works on whitespace-separated words. So that may need care, workarounds or hacks to get around.
But I would not mind if the spaces in the interactive-realtime-ten-line-history-preview would be a different kind of space characters... or very small center dots, or black on black...

share|improve this answer
    
hmm, haven't been able really to progress, just produced some weird things that we're kind of what I wanted but extremely "buggy", so I don't understand this commands effects thoroughly yet –  LinuxNoob1337 Aug 28 at 21:28
    
Oh, good that you're reminding me - I later noticed that the print buildin can be used in a very similar way - which was actually what I had expected. I did not get what the difference is in terms of how/when to use. –  Volker Siegel Aug 28 at 21:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.