I tried to improve a bit the wikipediafs python script, but there are some small basic design mistakes. Beside those, it is impossible to have a list of all the article. Therefore I would use the api.php like
http://<YOURPEDIA>/api.php?action=query&list=allpages&apfrom=B&format=json
I would then precreate (by the driver) a directories called _allfiles, _search. Under the _allfiles I would then precreate directory names (A, B, C … Z, or if there would be too many articles under one directory AA, AB, … BA, BB… ZZ), and would use the above mentioned script to populate these directories with articles beginning with the corresponding name.
I am a <search everywhere> obsessed with vim. However I miss a lot the feature to be able to (incremental) search in lists exactly as one searches in windows. Such lists are useful concepts in vim, mainly as they are similar to modal dialogs as you do not want to see them all the time, just when you need them.
:messages
:map
:ll
Usecase1… in my daily work it is always interesting to go back to old messages… I have a keyboard shortcut for the messages list (ctrl _lm)… but here the story ends. What I would love to do is to be able to search in this list.
Usecase2… MRU. I know there are lot of MRU implementations, but all of them they open a window and they destroy the layout of the windows… however what I think would be clever is to have a list with MRU shown, incremental search in it, enter, list is closed, and open file in the latest window as a new buffer… Similar way it would be powerfull to search in a loaded tags list, or why not, imagine a concatenated source file with all your source code. In such a buffer of concatenated files, you could incrementally search (I am using it often, but opened in a window), and once you identified the correct line, enter, and the file that represents that part of the concatenation would be opened on your last window.
Custom lists would be very interesting, and some commands to read a list from a file (elements of the list would be obviously the lines).
Another maybe exaggerated idea would be a feature to search inside completion lists… I press ctrlx f/i, thousands of files listed, or items listed, would be nice to have a shortcut that would bring me into incremental search mode, and select faster the item I am interested in…
I would like to propose a little architectural improvement for the tbbmalloc. (lack of time does not allow me to double-check if what I post here is true:) )
As I described in some of my previous posts on my blog, integrating the tbbmalloc is a little problematic, as tbb relies on malloc. This means that a complete replacement of the malloc with tbbmalloc is impossible.
Custom malloc implementations try to link with the host application before libc, thus implementing the symbols of the malloc family. This linking (in case of shared libraries) can happen at runtime as well.
An elegant combination of malloc with tbbmalloc would be by extending the signature of the tbbmalloc functions by adding an extra formal parameter a pointer to the default malloc family function. Thus all calls in the custom malloc definition could be redirected to the tbbmalloc tegether with a pointer to the pointer the libc (wtih getsymbol etc.). tbb could decide if that allocation his job (small block), if not,redirect the call to the passed function. Eventually if the pointer is null, call malloc itself, allowing thus more flexibility.
so the malloc would look:
void * malloc(size_t size)
{
if(!libc_malloc) //check if libc_malloc symbol found
{
libc_malloc=find_libc_malloc();\
}
return tbb_malloc(libc_malloc,size);
}