I don't think that should be integrated into ido or at least only if
it builds upon a more general feature.
I fully agree. I am all for generality. My main point was to warn against limiting ourselves to static lists.
The basic feature would be to specify additional lists for ido besides
recent files, so one could specify other groups of files too for
completion.
As I see it the basic ido framework is an ordered list of sets of names. ido presents a completion list built by collecting - in list order - match candidates from each set of names. My suggestion is these sets of names may be concrete (e.g. actual buffers, recentf's files list, user provided list, etc) or they may be lazy (e.g. a function conforming to an ido defined API). Lazy evaluation has the added virtue that it is less likely to impact emacs start up.
I sometimes look into emacs .el source files,
so I would create a list of all emacs lisp source files, so I could
simply switch to any of them without having to use find-file
My solution is to append to load-path source directories which have be separated from their corresponding .elc's. (Emacs still loads a .elc in preference to a .el or .el.gz even when the .elc shows up further down the path.) After that I can open emacs source via ilocate-library-find-source (
https://github.com/emacsmirror/ilocate-library.git) using only the file name. And I get completion support.
BTW, if this generic feature is added then ido should also use the
code in the uniquify package, so it can indicate the difference
if two files with the same names are matching, but they
are in different directories. In this case the file name without
directory is not enough to know which file is which.
Absolutely.
/john