Multiple code repo search

[junkblocker]

From @suntong on January 18, 2017 19:18

Expanding on the idea from #9, I think the best solution is to separate different code repo into different indexes, because after all, developers working on a single project is rather rare -- I personally need to do code search on many different code repos.

I propose just adding a -name to both index and search program, to separate different indexes.

Further, it's not only apply to different code repo, but even within the same repo, you can use -name to divide them into logical groups whatever you like, if you find eliminating a section is constantly needed.

Copied from original issue: junkblocker/codesearch-pre-github#12

[junkblocker]

@suntong , does the already available -indexpath option not meet this requirement for you?

[junkblocker]

From @suntong on January 18, 2017 19:33

Not quite, in the sense of usability. Consider the following:

csearch -name myproj2 regexp

and

csearch -indexpath /the/crazy/path/I/need/to/set/in/order/to/get/to/index/.myproj2 regexp

I think most people would agree that the first approach is more user friendly.

The -name will only adding a small portion to $CSEARCHINDEX, not overriding it.

[junkblocker]

I wrote the response below but realized you are on windows so this doesn't work for you. But here it is anyway for unix folks.

---

I don't use the project model that a lot of people seem to use. There are two options that can solve your requirement easily.

1. You can create a quick wrapper which will be even shorter which grabs names from a flat file. e.g. (untested)

% cat ~/.config/projects
myproj1=/the/crazy/path/I/need/to/set/in/order/to/get/to/index/.myproj2
theirproject2=/some/other/entirely/different/location/altogether

% cat csproj
#!/bin/sh
name="$1"
shift
source ~/.config/projects
csearch -indexpath "$name" "$@"

% csproj myproj2 regexp

1. When working on specific projects I work in the directory of the project itself. I combine that with the following script which incrementally looks for the first index file in current or higher directories and uses that without needing to specify a path.

#!/usr/bin/env bash
findup() {
  local what thisdir
  what="$1"
  [ -z "$what" ] && return 1
  thisdir="$(pwd)" || return 1
  cd "$thisdir" || return 1
  thisdir="$(pwd)" || return 1
  while [ -n "$thisdir" ]; do
    if [ -e "$thisdir/$what" ] || [ -L "$thisdir/$what" ]; then
      echo "$thisdir/$what"
      return 0
    fi
    [ "$thisdir" = "/" ] && return 1
    thisdir="$(/usr/bin/dirname "$thisdir")" || return 1
  done
  return 1
}
if [ -n "$GOPATH" ]; then
  echo "$GOPATH" | sed -e 's/:/\
/g' | while read -r line ; do
    eval "PATH=\"\$line/bin:\$PATH\""
  done
else
  GOPATH="$HOME/work/go"
  PATH="$HOME/work/go/bin:$PATH"
fi
PATH="$HOME/bin:$PATH"
PATH=$PATH:$HOME/bin:$HOME/work/go/bin
export PATH
export GOPATH

[[ ! -e .csearchindex && ! -h .csearchindex ]] && echo ".csearchindex file is not present in current directory." >&2

deepest="$(findup .csearchindex)"
if [ -n "$deepest" ]; then
  /usr/bin/env "CSEARCHINDEX=$deepest" csearch -f "$(pwd)" "$@"
else
  csearch -f "$(pwd)" "$@"
fi

[junkblocker]

From @suntong on January 18, 2017 20:7

Thanks for the code.

Yeah I need codesearch on windows only. Under Linux I use glimpse, which "uses a very small index – in most cases 2-4% of the size of the text", and it is super easy to break into different indexes.

So again, on windows, since none of above is available, adding the feature to codesearch seems more desirable. I can do it myself, since the -name will only adding a small portion to $CSEARCHINDEX -- the change will be very small and straightforward, but I'm wondering if you accept patches like this.

[junkblocker]

Patches are always welcome but when adding new options I need to evaluate many things. In this case, mainly:

1. New options should not conflict with existing options.
2. They should not lead to user experience bloat e.g. introduce multiple ways of doing the same thing.
3. They should not lead to unnecessary code complexity.
4. They should try to be consistent with existing tools out there.
5. They should be implemented to not diverge too much from the original codesearch project. (Yes, I still dream it will come alive someday somehow despite years of indication otherwise :) )
6. Maybe do both or pick between this and Figure out why go get something gets upstream codesearch instead of this fork #9 in one shot.

Unfortunately, my time is limited due to a busy day job so not sure when I can participate more than casually in such discussions/development. But it's open source so you can modify it as you please even if I can't find time. Using the Makefile you can do cross platform builds and get Windows binaries easily.