fzf.el icon indicating copy to clipboard operation
fzf.el copied to clipboard

Freaks out in 29.x

Open mcampbell opened this issue 1 year ago • 10 comments

The display of "things" to find (at least for fzf-find-file) is all borked up in any of the 29.x branches, and also in the released 29.1.

Anyone else notice this?

mcampbell avatar Jul 31 '23 12:07 mcampbell

What OS are you using?

pierre-rouleau avatar Aug 09 '23 12:08 pierre-rouleau

MacOS, but I think it did the same on WSL2 under Windows (Ubuntu guest VM)

mcampbell avatar Aug 09 '23 12:08 mcampbell

Same here on macOS 13.5.2, running Emacs 29.1 in wezterm.

Running M-x fzf-find-file, for example, results in:

Screenshot 2023-09-19 at 17 22 08

In text format:

*Async-native-compile-log* ✕    *compilation*<emacs> ✕    *Native-compile-Log* ✕    *scratch* ✕    *doom* ✕    *Messages* ✕    *clangd::stderr* ✕    *clangd* ✕    *fzf* ✕  +

>   < 55/55 (0) \342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342\224\200\342$
> .clang-format                                                                                                                                                                                               \342\2$
  .clang-tidy
$ doom version
GNU Emacs     v29.1            nil
Doom core     v3.0.0-pre       grafted, HEAD -> master, origin/master, origin/HEAD 2be3cf4b 2023-09-17 05:07:52 +0200
Doom modules  v23.09.0-pre     grafted, HEAD -> master, origin/master, origin/HEAD 2be3cf4b 2023-09-17 05:07:52 +0200

miguno avatar Sep 19 '23 15:09 miguno

Could this be related to https://github.com/bling/fzf.el/issues/109 ?

miguno avatar Sep 19 '23 15:09 miguno

Could this be related to #109 ?

At least in my case I don't think so; I don't use colors.

mcampbell avatar Sep 20 '23 15:09 mcampbell

I am seeing something similar when using a recent enough fzf version and emacs runs with a non-UTF locale for example LANG=C or unset $LANG.

It is triggered by this change in fzf version 0.35.0 and newer:

- Info panel (match counter) will be followed by a horizontal separator by
  default
    - Use `--no-separator` or `--separator=''` to hide the separator
    - You can specify an arbitrary string that is repeated to form the
      horizontal separator. e.g. `--separator=╸`
    - The color of the separator can be customized via `--color=separator:...`
    - ANSI color codes are also supported

Emacs term mode (which fzf.el uses to run the fzf command) doesn't seems handle the escape sequences used unless we are in a UTF locale. Or maybe it's a coding system issue.

Most users are using UTF locales nowadays so they would not run into this.

imarko avatar Dec 25 '23 13:12 imarko

I have just had the opportunity to test it on:

  • macOS 14.2.1
  • in emacs 29.1
  • running inside a macOs Terminal running the macOS zsh, with LANG is en_CA.UTF-8
  • fzf installed with Homebrew is: 0.45.0 (brew)

I don't see the problem. It works fine in that environment (in text mode). I was not able to test the graphics version of Emacs yet.

Are problem related to running emacs in graphics mode or in terminal mode or both? When you see the problem inside Emacs, do you also see the problem in your shell? For this problem, please identify:

  1. the OS type & version,
  2. emacs type and version,
  3. shell type and version, and the value of LANG environment variable
  4. fzf version.

Test fzf directly inside a OS shell, then inside Emacs.

pierre-rouleau avatar Jan 08 '24 23:01 pierre-rouleau

@pierre-rouleau I can only reproduce it in non-UTF8 locales for example LANG=C. With that it happens with both terminal and X11

imarko avatar Jan 08 '24 23:01 imarko

@imarko I tried using LANG=C by just setting it in the zsh shell and used Emacs 29.1 in terminal mode in macOs Sonoma.
I can see the trailing lines showing escaped octal data with several fzf commands. M-x fzf does the same.

It looks as if the last 'separator line' shown after the 2 counts is not displayed properly. But fzf is displaying it fine when launched directly from the shell.

At this point I don't know enough about the screen output mechanism of Emacs to do more. I wonder if other operations experience the same type of problems with Emacs 29.1. I'd have to search a little in that area. I might have a bit of time later this month.

Has anyone experienced this problem on Emacs 28 or 30? Or with another command or package?

pierre-rouleau avatar Jan 09 '24 04:01 pierre-rouleau

As author of the bug report, this all seems to be working FOR ME, now.

Both terminal mode emacs and GUI emacs.

Steps I made to success:

MacOS Sonoma 14.2.1 fzf version: 0.45.0 (brew)

  • Downloaded and uncompressed: emacs-29.1.tar.xz
  • ./configure --with-ns --prefix=/usr/local --disable-ns-self-contained
  • make && sudo make install

Ran both with straight setup and the following fzf config.

(use-package fzf
  :config
  (setq fzf/args "-x --color bw --print-query --margin=1,0 --no-hscroll"
        fzf/executable "fzf"
        fzf/git-grep-args "-i --line-number %s"
        ;; command used for `fzf-grep-*` functions
        ;; example usage for ripgrep:
        ;; fzf/grep-command "rg --no-heading -nH"
        fzf/grep-command "ggrep -nrH"  ;; ggrep is brew's install of gnu grep
        ;; If nil, the fzf buffer will appear at the top of the window
        fzf/position-bottom t
        fzf/window-height 15))

(Edit: Unless other people are having the problem, this can be closed as far as I am concerned.)

mcampbell avatar Jan 10 '24 21:01 mcampbell