thieman / better-search Goto Github PK

I assume because they are rendered as the path from the folder you searched in rather than the project root.

Considering doing this myself, so posting this in case the developer has feedback before I open a PR. This is a blocker for me to move to VSCode from Sublime. This plugin is great, but really falls on its face flat when it makes me use my mouse to navigate between results. Suggestions are basically from my favorite iteration of this plugin for Sublime. https://github.com/aziz/BetterFindBuffer

• Navigating results with J/K in the read only buffer
• Better highlighting of results and cleaner formatting of the buffer as a whole

Here is an example of what sublime in BFB looks like searching for "amet" in Lorem ipsum. I can also navigate between the red highlighted items with J and K.

Need to add another scope to the keybinding probably

this plugin does not seem to work :/

On Windows 10 with Git Bash.
In search results window, ctrl+click on underlined file name or line number - an error message pops up with Unknown (FileSystemError).
For instance, ctrl+click on File: package.json:
Unable to open 'package.json': Unable to read file (Unknown (FileSystemError): Error: UNKNOWN: unknown error, stat '\\d:\Dev\Test\proj\Dev\Test\proj\package.json').

It looks like the path is being added twice to the file name. Also an erroneous double slash is added before the path. Instead of:
\\d:\Dev\Test\proj\Dev\Test\proj\package.json
It should have been:
d:\Dev\Test\proj\package.json

would be nice to have an option to exclude folders, as the normal search

Remove the process execution to do searching and remove it with the new search API tht was added.

Details are here... microsoft/vscode#55406

This extension looks great! I can't get it to work - I run Quick Find and enter any query and get 0 results. Anything I can do to help debug it?

It also looks like it only ships the windows version of the ripgrep binary. VS Code extensions have to include native dependencies for all platforms, then select the correct version at runtime. vscode-ripgrep only downloads the version for the current platform, because it was written for vscode where we build separately for each platform.

An easy workaround for you might be to run npm install vscode-ripgrep at runtime to get the right version for the user's platform.

Hello, thank's for your extension, it really helps, but can you add a new (optional maybe) provider, based on commd:
git log --format=%aen --ignore-blank-lines --pickaxe-regex -U0 -w -600 --no-prefix -S${query}

Searching for something like <Div css={ returns no results when it should otherwise. This is on OSX.

The VSCode maintainers have recently made progress on the long-standing issue to bring something like Better Search into VSCode natively: microsoft/vscode#23931

If they continue their work and it turns out well, there will likely be no reason for this extension to continue to exist. In that event, I will likely declare end of life (EOL) for the extension and discontinue any further work. In that event, anyone is welcome to pick up the extension and run with it per its MIT license.

Please use this issue for any discussion on this issue. I'll update it as things change on VSCode's end.

Hello! Thanks for such an amazing plugin! Really enjoy using it! ❤️

I'm working on JS project and some of language syntax highlighting are not correct:

You can see that document headed renders partly in red, and code is also mostly red.

I've been checking out source code and found where the problem is:

  async provideDocumentLinks(
    document: TextDocument,
    token: CancellationToken
  ): Promise<DocumentLink[]> {
    // Hack, not sure where the best place is to run this. Can't run it
    // in the content provider since I don't have an actual TextDocument yet
    const language = this._languages[document.uri.toString()];
    if (language !== undefined) {
     // right here!
      await languages.setTextDocumentLanguage(document, language as string);
    }
    this._readyToDispose[document.uri.toString()] = true;
    // End hack

setTextDocumentLanguage method sets document language and syntax highlight, but it adds syntax highlighting for the whole document instead of just adding it for search result. That's what causes highlighting to be inconsistent across search.

Would be cool if we find a way to apply syntax highlighting only to search results in scope, ignoring surrounding results.

This issue is not critical, but still it'd be nice to have that fixed someday.

Thanks!

Hi there!

I've tried running your extension on a Windows 10 machine with Windows Subsystem for Linux. I don't think the Linux subsystem part matter, except that it gives me very long paths.

I fail to do any of the searches, and after some troubleshooting, I find the following error in the developer tools:

Error: Command failed: 'c:\Users\myuser\AppData\Roaming\Code\User\globalStorage\travisthieman.better-search\vscode-ripgrep\package\bin\rg.exe' hej --color never --no-heading --column --line-number --context 5
The filename, directory name, or volume label syntax is incorrect.

	at ChildProcess.exithandler (child_process.js:303:12)
	at ChildProcess.emit (events.js:182:13)
	at maybeClose (internal/child_process.js:961:16)
	at Process.ChildProcess._handle.onexit (internal/child_process.js:248:5)

I have gone with Powershell to the cwd.location and executed $RG_PATH\rg.exe hej and that works well. Any thoughts on what could be wrong?

/Magnus

Hello, thanks for this great plugin.

Would it be possible to add a toggle/option to activate/desativate case sensitive search ? Currently it seems this is turned ON

Thanks!

From a dickish 1-star review in the marketplace. Not sure how VSCode handles chords but it'd make sense that this prevents a subset chord from working.

Not sure what makes sense as a "default" keybinding since everyone's going to have different preferences. I use Emacs keybindings which is why I didn't even think about C-x being something people use for cut.