noticeably slower than built-in search, since it doesnāt use index but actually reads files instead
requires git to be installed on the server, but thatās already a part of the Docker image
The repository which includes installation instructions is here:
The Plug system was a pleasure to work with, and using a well-tested external software possible due to one of SilverBulletās superpowers: āitās just files on disk broā. Once again, congratulations to on the overall design of the app!
It would be fairly trivial to just add ripgrep to the distributed docker image. We canāt keep adding random cli tools to it, but if there is demand we can a few useful ones. Thatās why git is there. By the way, have you considered using git grep?
I was planning on using git diff similarly, but didnāt even know git grep exists, thanks!
The only downside would be losing the links to specific location, since we canāt link to a line number, and I donāt see the byte offset option in git grep
ā¦Unless I PR in links like GitHub in the form of [[Page#L123]], that would go to the line if you donāt have # L123 header on the page. Could be useful for other command line tools.
How about [[Page@L123]]? Thatās consistent with whatās already in SilverBullet, avoids collision with headers, and wonāt change behaviour for existing notes. Letās .gitignore GitHub in this case.
And optionally [[Page@L123C12]]to place the cursor in a given column, start of the line if omitted.
Not sure how this should be implemented but in Logseq, any bullet you link to gets an id:: uuid added to it and then you can refer to that bullet using ((uuid)). They have a nice UI to hide the uuid and replace it with the bullet text. Sub-bullets show up when you hover. This is non-standard markdown of course.
Not sure if line number is perfect cause changing the note can change the location.
+1 for adding [[Page@L123C12]] syntax. I think line numbers make more sense than byte positions a lot of the time, and look better imo for search results.
@shashlick In logseq, do those id:: attributes get added to the actual markdown file? Iām not sure Iād like them being added automatically, but maybe Anchors can be used for something similar? Or something like [[Page?id:blah]] where id could be any attribute.
There are very attractive reasons to start to put unique IDs in documents. Even to give unique IDs to pages, or just name them by ID. It would simplify a lot of things. It would also clutter up the markdown files and affect portability. To some degree youāre already locking yourself in to SilverBullet by using any non-standard Markdown features (especially all the templates and queries), but starting to litter document with IDs would make that even worse.
LogSeq decided to do this anyway (and I think Obsidian also has some sort of block reference feature that uses IDs), which is their choice, but I prefer to avoid it in SilverBullet. You can indeed use Markdown/Anchors, but those are more opt in.
Just installed this and itās nice! I may just rebind my full-text search keyboard shortcut to this one
What Iām not 100% sure about is the GREP RESULT page. This works, but itās a different pattern than used in full text search (creating a page on the fly). On purpose?
I did start with this solution because it was simpler to set up, but afterwards I noticed I like it this way:
The regex pattern can get quite elaborate, with it being essentially a program on its own, that I debug a bit before it does what I want. Also, this isnāt as instantaneous as your index-based search. For both of these reasons I found it nice to be able to see the page again after I browse one of the results, like a single-entry command history. And thanks to Meta Pages I donāt feel that Iām cluttering the space this way.
You might want to recommend adding it to .gitignore in the README. I just realized Iāve been committing multiple version of the GREP RESULTS page to git.
Maybe SB can have a standard _tmp directory which is added to .gitignore by default, similar to _plug.
We only need to keep the name of the source page for each search result. We can give the page a |š alias, which will maintain the functionality of jumping to the corresponding position upon clicking.
There should be a dividing line between different sources to make it easier to read.
grep:
# by default shows results in a virtual page, like the built-in search
saveResults: true
# visually distinguish >>>matched part<<< in shown context
surround:
left: "=="
right: "=="
Very comfortable with this having found that changing >>> and <<< for surround to == allows me to highlight the sought word in results:
Still not quite sure what the saveResults setting does though. Whatās a āvirtual pageā?
