pope / sublimeyetanothercodesearch Goto Github PK

cindex doesn't have any flags to exclude a folder from being indexed from a path like ST can exclude directories from a project path. But, it should be doable to expand the one path in ST to the directories and paths that ST has in the project.

Take the following directory structure

project/
  |- dir-a/
  |    |- foo/
  |    |- bar/
  |    `- file.txt
  |- dir-b/
  |    `- bar/
  |- foo/
  |    `- bar/
  `- file.txt

If I wanted to index project, yet exclude foo, I could transform this into the following paths for cindex to search:

project/dir-a/bar/
project/dir-a/file.txt
project/dir-b/
project/file.txt

This does add a lot of expansion, and I don't think cindex should have any issues with this, but it's worth keeping an eye out for.

Right now, we will pull up the search results with an error message. It might be better to just forego the error message and create a more friendly one informing the user of the situation.

I followed the instructions for installation, but I get this titular error when I try to index via the command pane. One assumes I've done something wrong, but this error message doesn't help in the slightest.

Hi there,
The exclude folders makes sense. But for me I need to manually include only those fewer folders. For which I need to index. Hopefully this kind of a request also makes sense to other people.

Can this be done? I am hoping also [somehow] for there to be a future possibility of eventually adding a context menu entry, right click the folder in sidebar. To access that future hook in a convenient way.

This seems easy on the surface, but there is no selector query, as is the case with keymaps. So then this just starts muckin' with ALL of the mouse clicks.

I've seen some hacks by searching around, so I could try those. When I did a simple test, it was waaaay to kludgy to not be annoying.

It's pretty easy to create Go binaries for Windows, OSX, Linux, and FreeBSD; so maybe we can eliminate an installation step for the user by just keeping copies of the binaries in the project.

CodeSearch hasn't seen a lot of change, so there doesn't appear to be a lot of re-syncing that needs to be done. It also means that there's a version of the csearch and cindex app that have been verified to work with the plugin, which could mean less bugs if there was a big change into those apps.

One question that will need to be answered is if the binaries should be stored within git and served via Package Control with the .no-sublime-package file or if I should just host a .sublime-package for the plugin code an an executable package for the bins.

Sometimes you accidentally type a a query that will match the world (looking at you .) and you don't want to wait for that to finish before you can type the real query. It would be good to cancel the existing search if a user immediately brings tries searching again or if the user closes the results buffer.

Additionally, it might be good to have a command to kill the indexing process.