Some files in search path not appearing?

[Andreilys]

Checklist

• [x ] I updated.

• [x ] NV_note_handler cannot fix my issue.

Summary of Problem

This plugin has been great, very handy for searching files.

Recently I've noticed that while some newly created files appear, others do not (Even when they are in the same directory). I'm not sure if I need to rebuild the index, or what would be required to make sure all files given the search path appear

[Andreilys]

Here's an example, you can see player_piano.md and professional_writing.md show up in thesearch, but personal_poems.md and personal_writing.md do not, despite all four being in the same directory.

[alok]

Are any of the files empty? It filters out blank lines

On Sun, Nov 15, 2020 at 1:11 PM Andrei Lyskov ***@***.***> wrote: Here's an example, you can see player_piano.md and professional_writing.md show up in thesearch, but personal_poems.md and personal_writing.md do not, despite all four being in the same directory. [image: Screen Shot 2020-11-15 at 1 09 32 PM] <https://user-images.githubusercontent.com/8299248/99196893-f0223d80-2743-11eb-8883-3aa765408a29.png> [image: Screen Shot 2020-11-15 at 1 09 43 PM] <https://user-images.githubusercontent.com/8299248/99196892-f0223d80-2743-11eb-9200-68ba98c001e4.png> [image: Screen Shot 2020-11-15 at 1 09 49 PM] <https://user-images.githubusercontent.com/8299248/99196890-ef89a700-2743-11eb-81f1-a61e785eea77.png> [image: Screen Shot 2020-11-15 at 1 10 04 PM] <https://user-images.githubusercontent.com/8299248/99196889-eef11080-2743-11eb-87fc-c8266b703454.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7QUTFASDJWDAS3R22CXNTSQA7XJANCNFSM4TWNLGAQ> .

--

…

--- Alok

[Andreilys]

Nope both files have content inside them

[alok]

gonna be a while before i can devote proper attention to this, just fyi. busy these days

…

--- Alok

On Sun, Nov 15, 2020 at 4:39 PM Andrei Lyskov ***@***.***> wrote: Nope both files have content inside them — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#77 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7QUTA4UTFYS7HLTWLUWITSQBYCPANCNFSM4TWNLGAQ> .

[clenio]

Facing the same issue here.

[clenio]

Facing the same issue here.

In my case, a pdf file in the directory crashed the "indexing process". I removed that specific file and returned to working normally.

[Brutus11111]

I'm having the same issue here.

Two terminals next to each other. One with vim. I search for workorder and the file doesn't show up. In the other terminal I open fzf manually and type workorder and it does show up. It's a document I actively use and contains data.

[heikete]

I have the same issue. I've checked with bare fzf I can find the filename, however the plugin doesn't list it. Maybe the error is caused by some illegal byte in assumed utf8 file? I tried to narrow the problem by searching a pattern in listed/omitted files, but didn't have time to debug the script. Is there a simple option to debug the script by printing the data in some intermediate state? It looks like some exception is silently ignored. I can zip my txt files directory and share for debugging.

[konstantinstadler]

Had the same problem. It was caused by a folder containing binary data. Excluding the directory through the ignore_pattern flag solved the issue

[Brutus11111]

Had the same problem. It was caused by a folder containing binary data. Excluding the directory through the ignore_pattern flag solved the issue

I can confirm that this is the issue. After moving all binary files out of the directory, it can suddenly find all the files.

For anyone else that wants to get it working right now, go to the directory, type 'grep -rIL .' to find those files.

It would be nice if this could somehow be solved in the addon. I'm not capable of fixing it myself. Somehow ignoring binary files should do the trick.

[kwbr]

The problem seems to be shorten_path_for_notational_fzf.py:

It uses for line in stdin: to read lines. This fails if the line contains characters that can not be converted to a unicode string (the systems sys.getdefaultencoding()) and the script stops at this point.

I currently disabled this feature by setting g:nv_use_short_pathnames = 0.

While working on a fix I am clueless what is the best way to handle this. It might be better to treat the lines as pure bytes not as strings and leave them as they are.

if __name__ == "__main__":
    for line in sys.stdin.buffer:
        try:
            line = line.decode("utf-8")
            print(process_line(line))
        except:
            # What to do here?
            pass