Re: project-find-file: switch to include non-tracked files

[Dmitry Gutov <dgutov@yandex.ru>]

On 15.10.2021 08:24, Manuel Uberti wrote:
> On 14/10/21 23:55, Dmitry Gutov wrote:
>> If we end up adding a new user option for this, what would you call it?
> 
> Not sure actually. I see a project-ignores and a project-vc-ignores 
> already, maybe these can be leveraged instead of adding a new option?

Both of these are for the default project-files behavior.

How would we leverage them?

>> We should probably try to handle this is a more transparent way, 
>> showing the exact error message to the user (when the buffer contains 
>> lots of output as well, the message becomes next to useless).
>>
>> Could you try applying the patch below, removing your recent 
>> customization and seeing whether the error message is better now?
>>
>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index 79d2e050d9..7c3bb9229d 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -322,7 +322,15 @@ project--files-in-directory
>>                (process-file-shell-command command nil t))
>>               (pt (point-min)))
>>           (unless (zerop status)
>> -          (error "File listing failed: %s" (buffer-string)))
>> +          (goto-char (point-min))
>> +          (if (and
>> +               (not (eql status 127))
>> +               (search-forward "Permission denied\n"))
>> +              (let ((end (1- (point))))
>> +                (re-search-backward "\\`\\|\0")
>> +                (error "File listing failed: %s"
>> +                       (buffer-substring (1+ (point)) end)))
>> +            (error "File listing failed: %s" (buffer-string))))
>>           (goto-char pt)
>>           (while (search-forward "\0" nil t)
>>             (push (buffer-substring-no-properties (1+ pt) (1- (point)))
> 
> I did as you described and I got this message when I did C-u C-x p f:
> 
> File listing failed: find: ‘./tmp/db’: Permission denied
> 
> Two advantages of your approach:
> - the message came up quickly
> - it hinted directly to the problem

Thanks for checking, I've pushed the patch (slightly tweaked).

Perhaps ideally, we'd just ignore such directories, leaving it to the 
user to figure out why the files are not showing up. But 'find' doesn't 
make it easy. First, adding

   -o -type d -a ! -readable

kinda works, but it's a GNU extension, not available on e.g, macOS, so 
it's a no-go. And even with the '-type d' qualifier it adds some runtime 
cost, somehow.

I suppose we could just redirect stderr to null (like vc-git--out-ok 
does) and check for success by the presence of \0 chars in the output, 
but that's both quite lax and leaves us unable to print the error 
message when indeed some other kind of error happens. I guess 
redirecting stderr to a file is the remaining option...