readline filename completion and dirent.d_type

[Eric Blake]

On systems where readdir provides d_type information, and either 
_rl_complete_mark_directories or rl_filename_completion_desired are set, bash 
is wasting a lot of time stat'ing directory entries returned by readdir() when 
it could have used the results from the d_type field.  Unfortunately, the 
current interface forces this - in readline/complete.c, 
rl_filename_completion_function discards the readdir results by returning a 
single char*, and rl_display_match_list only takes a list of strings, so the 
readdir d_type information has already been lost.

I am considering working on a patch that provides a new interface, where 
completion functions return a struct consisting of a char* and d_type value, 
rather than the current return of a single char*.  On platforms without d_type, 
and for completion functions that are not returning file names, the d_type 
field can be simply set to a placeholder DT_UNKNOWN, with no change in current 
semantics.  Likewise, the existing APIs can be rewritten as wrappers around the 
new API where the d_type field is supplied as DT_UNKNOWN.  But for filename 
completion and capable systems, using this extra information in a new API can 
be used to avoid a large number of stat calls, giving faster completion 
performance (particularly on filesystems where stat is slow).

Any thoughts on whether this sounds worthwhile, or what the new API names 
should look like?

-- 
Eric Blake