Open project file macro and new open local symbol macro

[chrisant]

Yes, some of the minor improvements I've still to make are adding a few options.

[asandler]

@chrisant: Nice idea. It should be much faster comparing to slick-c only macro.

I urge you to use my original idea for the filtering specification. The problem with asterisks and question marks is that people don't use them when they think. Often, you only remember part of the file name and perhaps part of its location in the project. Use it to filter out irrelevant files.

I am now testing a version with more or less final version of the "language". It has three basic rules:

• Every plain word in the pattern considered to be part of the file-name.
  I.e. pattern "aaa bbb" will match "aaa_bbb_ccc.c" and "bbb_ccc_aaa.h".
• Once you type in period, everything from the period to the end of the word is an extension.
  I.e. pattern "aaa bbb.c" will match "aaa_bbb_ccc.c", but will not match "bbb_ccc_aaa.h".
• Every word that has a slash (or back-slash) character in it, considered to be part of the path name.
  I.e. xxx/ matches all files sitting in the xxx directory in the project/workspace.

Also, I always consider word in the pattern to be only a part of the file-name/extension/path. So, .c will match all files with .cpp extension as well.

The filtering routine has three parts, first testing file-name, second testing extension (if specified) and third testing path (if specified). This ends up to be a very elegant routine.

So if you are looking for a some_dir/another_dir/main_cpp_file.cpp, you will have to type "main some/ .cpp" or ".cpp main some/" or "main.cpp some/". All of these will match the file.

[hs2]

@asandler: I also prefer your more 'fuzzy' filter spec. as used in 'opf'/'ols'. So I'm looking forward to chrisant's release including the sources and I hope I can make use of it for the 'ols' macro. Maybe it's a good idea to extend the DLL with an alternative tree filter function and re-post it...
@chrisant: I'm just curious: Do you filter and manipulate a tree control with your DLL function(s) ?
HS2

[chrisant]

asandler:  At some point I may make it accept multiple patterns separated by spaces (maybe even soon).  But honestly I don't filter that way.  I have about 25,000 files to filter through.  I tend to use uniqueness to filter, rather than figuring out regular expressions or multiple sets of strings to use.  I know exactly what file I want to open, and I just want to reduce the amount of typing to a few characters -- I don't want to use a filtering syntax, that takes too much thought (and I have 15+ years of neural pathways trained to use short unique phrases to filter the list).  Nevertheless I may add support for something similar to how opf works at some point.

Also, my filter assumes prefix matching unless you prefix the text with a star.  So just by typing normally I can match by prefix or sub string or use normal wildcards.  A major design goal I had was to avoid some kind of special syntax, and just filter naturally.

hs2:  Yes, the entire dialog is implemented in the DLL (but it gets the list of project/workspace files by calling back into Slick-C).  In order to get good performance I needed to use a virtual listview, which was only possible in DLL code.  Filtering 25,000+ files is instanteous on my 2GHz laptop.  Also, the filtered list is just an array of backpointers to the unfiltered list, so it takes less processing to build the filtered list.  The down side is that unless I resort to some hackery, it can only be a modal dialog (not a floating or docked toolbar).  But that's fine for my purposes.


Actually ultimately I don't even want tabs, but I'm experimenting with that UI metaphor first since there seems to be such a pervasive distinction between project and workspace file lists in SlickEdit.  As the UI evolves I'm really looking to reduce the modes (tabs), or perhaps to automatically deduce when to look directly in the file system, or perhaps even just merge in file system matches with workspace file list matches.  I like the idea of merging the workspace file list with the file system file list (e.g. relative to the cwd or whatever path has been typed), as it fits nicely with my goal of just typing naturally and having the filtering quickly reduce to what I was looking for, without having to think about or select tabs, and without having to think about how to use a special filtering syntax.  I don't know how that will turn out, but I'll certainly experiment with it.

[chrisant]

Ok wow.  There is a bug in the forums:  if I try to include the word "s u b s t r i n g" in the message text then I get a 501 error.  It took me a few weeks to finally figure out why sometimes I get 501 errors.

[Graeme]

In order to get good performance I needed to use a virtual listview, which was only possible in DLL code

My GFileman toolbar has a multicolumn "virtual" listview using listboxes but unfortunately I'm not able to capture mouse wheel scroll events which is annoying, but it's only for open buffers, not workspace or project files so I don't need to scroll very often.

Graeme

[chrisant]

My GFileman toolbar has a multicolumn "virtual" listview using listboxes but unfortunately I'm not able to capture mouse wheel scroll events which is annoying, but it's only for open buffers, not workspace or project files so I don't need to scroll very often.

Oh, thanks.  I downloaded and reviewed the sources for GFileman, but I don't understand where it's using a virtual listbox (I see it calling _lbitem_add, for example, which never occurs in a virtual listbox).  Can you point me at the code?  Or maybe we mean different things by "virtual listbox"?  I'm talking about where you set a listview or listbox (etc) to not store a list of items, and instead have it to call back into your own code whenever it needs to retrieve an item or draw an item, etc.  How are you getting Slick-C to call you back for retrieving and drawing items?  It would be useful to know how to do that in Slick-C code.

Here is a quick explanation of a "virtual listbox" lifted from some .NET documentation:

One of these is the LBS_NODATA style. As the name suggests, when a ListBox has the LBS_NODATA style, the control no longer stores any data for items, instead you simply tell it how many items should be displayed and it calls back whenever an item needs to be displayed using the DrawItem method. Of course, that means that the data must be held externally, and in a way that can be accessed based on the row number of the item to be displayed.

[Graeme]

Ah, sorry.  We sort of mean similar things I guess.  I don't store all the data in the list-boxes.  The only data that's stored in the list-boxes is what can be seen on the screen  - otherwise I can't get the multi-column behaviour.  I handle mouse clicks and selection explicitly and disallow scrolling.

Graeme