jbonjean / re-search Goto Github PK

Hi,

I have a weird but with re-search. It's working very well when searching backward, but when I find the result I want to execute, I press C-e or right arrow and enter but nothing happens.
Do you know why ?

clang: error: cannot specify -o when generating multiple output files

in order to compile on osx i had to remove "config.h" dependency file from Makefile line 7.
probably is working without it on linux too.

Currently when pressing an unsupported key combination like Ctrl-a re-search goes one step further in the history (in the current search direction).
This is quite an unexpected behaviour. It should do nothing instead.

For example:
This is the current situation (while in a history search)

It is currently at the first history entry.
After pressing Ctrl-a it is

It jumped to the second history entry.
However, it should have remained at the first history entry.

Instead of pressing a keyboard shortcut I would like this to be enabled by default, thus replacing the autocompletion mode provided by fish.

Is it possible to change the accept result keybinding to C-e? That would feel much more natural to me than using the arrows.

Maybe you could add -O2 to CFLAGS?

If you have a line such as echo "\*" bob in your history, re-search will fetch it back as echo "\*" boo - that is, it duplicates the last character.

Do you have to run your fish_user_key_bindings each time?

Or are you doing something like what I attempted here: fish-shell/fish-shell#1495

How do you overcome that?

The fish bind needs to have a function to describe the bindings.

Key bindings are not saved between sessions by default. Bare bind statements in config.fish won't have any effect because it is sourced before the default keybindings are setup. To save custom keybindings, put the bind statements into a function called fish_user_key_bindings, which will autoloaded

Therfore, it needs to have, else the file ~/.config/fish/functions/fish_user_key_bindings.fish have to sourced each time

function fish_user_key_bindings
    bind \cr re_search
end

Just an idea after having written the PR about the changed prompt colors.

If you don't like the idea, feel free to close this issue.

I would be nice if the appearance of the prompt could be configured by the user without recompliation, either via environment variable or as commandline parameter.

My idea is to provide a formatting string that contains

• placeholders for the strings generated by re-search (direction, search string, search result, result id)
• color codes for coloring the prompt
• additional characters to add before/after/around the placeholders

See the following example as a possible formatting string that resembles the current prompt:

export RE_SEARCH_PROMPT='\033[32m<${direction}> \033[36m${search_term} (${history_index})[\033[0m${result}\033[36m]'

The placeholders are all surrounded by ${}. Characters outside such placeholders are used as is (including the ANSI color codes). The placeholders themseleves are replaced by the actual values calculated by re-search.

Here is a colorized variant to make it easier to distinguish the parts of the formatting string.

blue: color codes
red: placeholders
black: additional characters

One thing I am not sure about is whether to provide the ability to set the formatting string via environment variable or as parameter on calling re-search or both.
It would be nice to provide both, but I don't know which one should override the other. Maybe that's a reason to provide only one of them.

Advantage of environment variable: It can easily changed on the fly by just changing that environment variable (like e.g. PS1 for bash). But the definition of the prompt and the mapping to re-search are separated.
Advantage of commandline parameter: It can be defined where the mapping to re-search is defined. But it is harder to change it on the fly.

When thinking more about it, I have a slight preference to the environment variable.

Anyways, it should be optional and the current one (or the above mentioned example) should be provided as default if not redefined by the user.

What do you think about that?