🚀 go-pugleaf

While at the Amy Forum in Dallas yesterday, I mentioned file requesters
to a few folks and received another few ideas, among them was to have
the requester implement a keyboard shortcut as well as the other stuff
I had suggested earlier.  Also, have pattern matching of sorts, so as
to show only particular kinds (or NOT show) of files. E.G. don't list
the .info files and remember this next time.

So, for example, if string-gadget for file name or for path-name
is NOT active, interpret keyboard entries as the first, second etc
character of the file we wanna find and have the file listing jump
to put the selected file name at the top of the (alphabetical) list
of files that become selectable.

For the other case, setting file requester preferences would enable
or disable the pattern matching to a user's specs.

Re Chuck's comment about having the file requester manage everything,
thereby keeping the program simple... that is exactly what I WAS proposing,
but with the re-entrant approach, give the program the OPPORTUNITY to
receive pointers to these lists of files and the controlling structure
THAT THE FILE REQUESTER ITSELF creates and destroys for you, and USES
when you pass that pointer to it.  Maybe I did not make that point
clear enough in the original posting.   And if one makes the file
requester code a part of a sharable (reentrant) library, the function
"malloc" could be used to allocate these buffers in the first place
so that the user code need never even "free" the buffers on exit
since this is usually done when a program exists anyhow.  Of course
it is not good programming practice but if one forgets to tell the
file requester to deallocate all of the cached file buffers, if the
filereq.library used malloc, it should not cause any problems.

Rob Peck