laloch / xontrib-fzf-widgets Goto Github PK

Greetings, great work.

It works wonderfully, but when trying to find Files or Directories it tries to show the colors, and this gives a bad display of the directory name, this can be seen in the attached image

Thanks

When I set

$fzf_history_binding = "c-r"

and I type Ctrl-R still the normal xonsh backward search comes up.

Is this a compatebilty issue? Here all the steps I have done:

1. I have installed fzf. It is now on my path: Typing fzf opens the fzf selector.
2. I install the xontrib-fzf-widgets extension via xpip install xontrib-fzf-widgets.
3. I load the extension via xontrib load xontrib-fzf-widgets.
4. I issue in my xonsh shell $fzf_history_binding = "c-r".
5. I type Ctrl-r.

And here the versions involved:

The way FZF_DEFAULT_COMMAND is handled here is a little odd to me:

For one thing, I think env = dict(os.environ) would be better because I think that the point here is to change the value of FZF_DEFAULT_COMMAND just for the single subprocess? The way it works now os.environ is permanently changed, though os.environ is kind of weird in Python -- not everything uses it. Its values are not linked to the values in ${...} for example. Even better than env = dict(os.environ) would be env = ${...}.detype() (unless I am missing some reason to favor os.environ over ${...}).

What prompted me to open this issue is that my FZF_DEFAULT_COMMAND generated a command with color codes. I tried changing it in my .xonshrc but the change was not taking effect because I was in a xonsh subshell where the parent still had my old FZF_DEFAULT_COMMAND set. Since os.environ gets set when os is imported and doesn't get further updates, my settings in .xonshrc were not applied to os.environ.

So to summarize, I am mainly suggesting a one line change to use env = ${...}.detype() but perhaps there is a different way to address the issue I was encountering.

I have a problem using fzf-tmux with xonsh. I am not actually sure what the problem is but when I call fzf-tmux inside of a tmux session started from xonsh a window opens, some kind of traceback appears, and then the window disappears before I can read it. I had never tried to use fzf-tmux before using this xontrib, so this problem had never bothered me. With the published xontrib, the key bindings don't work inside of tmux for me because they try to use the problematic fzf-tmux. #1 fixes the problem for me but only because it introduced a bug that prevents fzf-tmux from ever being used. This line:

should really be:

    if 'TMUX' in ${...} and $(which @(fzf_tmux_cmd)):

What would your preference be for addressing this? I can think of three options:

1. Remove all support for fzf-tmux. Just use fzf.
2. Replace fzf-tmux support with a $fzf_bin variable that when set is used instead of fzf (then the user could choose between fzf and fzf-tmux in .xonshrc).
3. Retain fzf-tmux support but also implement the $fzf_bin variable which would override it.

What I hope you don't choose is just to implement the @(...) fix I described above because that will lead to the xontrib always using (the broken, for me) fzf-tmux instead of fzf inside of tmux.

There is a nifty xontrib free-cwd that allows not to lock a current folder:

Windows only xontrib, to release the lock on the current directory whenever the prompt is shown. Enabling this will allow the other programs or Windows Explorer to delete or rename the current or parent directories. Internally, it is accomplished by temporarily resetting CWD to the root drive folder while waiting at the prompt. This only works with the prompt_toolkit backend and can cause cause issues if any extensions are enabled that hook the prompt and relies on os.getcwd()

However, this breaks fzf file/folder search within the current folder as the current folder is reset to root, so the fzf search also starts from root :(

Is there any way to marry the two by somehow getting the current folder value before it's reset?
If not, might be worth documenting this limitation

I'm used to cancelling readline history search with CtrlC
However, when I do that with your great xontrib, I instead get an error and xonsh quits
How do I fix this so that CtrlC simply returns to prompt?
Thanks!

  Traceback (most recent call last):
  File "C:\Python\Scripts\xonsh-script.py", line 33, in <module>
    sys.exit(load_entry_point('xonsh==0.9.26', 'console_scripts', 'xonsh')())
  File "C:\Python\lib\site-packages\xonsh\__amalgam__.py", line 22505, in main
    _failback_to_other_shells(args, err)
  File "C:\Python\lib\site-packages\xonsh\__amalgam__.py", line 22474, in _failback_to_other_shells
    raise err
  File "C:\Python\lib\site-packages\xonsh\__amalgam__.py", line 22503, in main
    sys.exit(main_xonsh(args))
  File "C:\Python\lib\site-packages\xonsh\__amalgam__.py", line 22541, in main_xonsh
    shell.shell.cmdloop()
  File "C:\Python\lib\site-packages\xonsh\ptk_shell\shell.py", line 338, in cmdloop
    line = self.singleline(auto_suggest=auto_suggest)
  File "C:\Python\lib\site-packages\xonsh\ptk_shell\shell.py", line 307, in singleline
    line = self.prompter.prompt(**prompt_args)
  File "C:\Python\lib\site-packages\prompt_toolkit\shortcuts\prompt.py", line 1013, in prompt
    return self.app.run(set_exception_handler=set_exception_handler)
  File "C:\Python\lib\site-packages\prompt_toolkit\application\application.py", line 848, in run
    return loop.run_until_complete(
  File "C:\Python\lib\asyncio\base_events.py", line 642, in run_until_complete
    return future.result()
  File "C:\Python\lib\site-packages\prompt_toolkit\application\application.py", line 650, in run_async
    assert not self._is_running, "Application is already running."
  AssertionError: Application is already running.

To make find-directory do something different from find-file, one needs to set $fzf_find_dirs_command.

However, setting it to fd -t d (as suggested in the README) is noticably slower. This also goes for $fzf_find_command = "fd". I haven't yet been able to figure out which find command produces similar output to fd -t d, unfortunately.

I am using the keybindings recommended in the readme, in particular:

$fzf_dir_binding = "c-g"      # Ctrl+G

However, using ctrl-g without any more setup results in files, not dirs, being matched. Of course this is inconvenient for performing a cd (that fails). For example:

After a bit of digging and looking at the code, I now understand what the reason for that is. Namely, for the dir binding to have any special effect, the $fzf_find_dirs_command described a bit later in the readme needs to be set. The readme shows the exmaple of setting it with fd. A couple of comments here, as I was confused at first: 1) one could use find, or any other tools, though agree that fd is really nice, but it needs to be installed (guess it is this fd you were thinking about? or even another one? :) https://github.com/sharkdp/fd ). 2) if this is well the fd you think about, the command name on my ubuntu seems to be actually fdfind, not fd (but guess you may be using another fd tool :) ).

In the end, all works good, but this required a bit of profficiency from my side. Wondering if the readme could be made easier on people who are a bit less tech-savvy by guiding a bit more the user and / or having some default script / default config to make the xonfig install fully sufficient :) . What do you think?

Hi! Thank you for the xontrib!

If you open xontrib topic on Github and scroll down you'll see the cute preview images for some xontribs. This is "Social preview" image that could be uploaded in the Settings of the repo.

Please take a common screenshot and put it to the preview image.

Thanks!

How do you feel about supporting the keybinding variables used by upstream fzf as described here? Mainly, I am thinking of FZF_CTRL_T_OPTS and FZF_CTRL_R_OPTS.

For what it's worth, I mainly want this to override the --reverse in fzf_insert_history() because I am used to the default behavior of the bash keybindings that don't use --reverse.

Hi! Thank you for the useful xontrib!

Please add xonsh and xontrib tags to the repo:

It helps spread the word about xontrib on Github.

Thanks!

The ssh-binding does not find hosts in other files, when ~/ssh/config contains Include directives, e.g.:

$ cat ~/.ssh/config
Include ~/.ssh/work_config ~/.ssh/home_config ~/.ssh/branch_config

The ssh-binding includes hosts from ~/.ssh/config that contain wildcards. These are useless in most circumstances.

$ cat ~/.ssh/config
Host *
    ServerAliveInterval 60
    PreferredAuthentications publickey,keyboard-interactive,password,hostbased,gssapi-with-mic
    VisualHostKey yes

Host *+*
    ProxyCommand ssh $(echo %h | sed 's/+[^+]*$//;s/\([^+%%]*\)%%\([^+]*\)$/\2 -l \1/;s/:/ -p /') exec nc -w1 $(echo %h | sed 's/^.*+//;/:/!s/$/ %p/;s/:/ /')

Host Normal_Host
  HostName host.example
  User confus

Here * and *+* are returned in addition to Normal_Host.