WEBVTT
00:00:00.000 --> 00:00:03.559
...starting the recording here in the chat, and I see some
00:00:03.560 --> 00:00:06.039
questions already coming in. So thank you so much for your
00:00:06.040 --> 00:00:09.359
talk, Zac, and I'll step out of your way and let you field
00:00:09.360 --> 00:00:10.279
some of these questions.
00:00:10.280 --> 00:00:21.999
Sounds good. All right, so let's see. I'm going off of the
00:00:22.000 --> 00:00:22.969
question list.
NOTE Q: Do you think a reduced version of this functionality could be integrated into isearch?
00:00:22.970 --> 00:00:25.839
So the first one is about having reduced
00:00:25.840 --> 00:00:31.999
version of the functionality integrated into iSearch. So
00:00:32.000 --> 00:00:37.919
yeah, with the way things are set up, it is essentially a
00:00:37.920 --> 00:00:42.679
framework. So
00:00:42.680 --> 00:00:46.279
you can create a candidate. So just a review from the talk. So
00:00:46.280 --> 00:00:49.919
you have these candidate generators which generate search
00:00:49.920 --> 00:00:54.559
candidates. So you can have a file system candidate which
00:00:54.560 --> 00:00:58.519
generates these file documents, which have text content in
00:00:58.520 --> 00:01:01.799
them. In theory, you could have like a website candidate
00:01:01.800 --> 00:01:06.399
generator, and it could be like a web crawler. I mean, so
00:01:06.400 --> 00:01:10.519
there's a lot of different options. So one option, it's on my
00:01:10.520 --> 00:01:15.039
mind, and I hope to get to this soon, is create a defun, like a
00:01:15.040 --> 00:01:18.599
defun candidate generator. So basically it takes a file,
00:01:18.600 --> 00:01:22.279
splits it up into like defunds, kind of like just like what
00:01:22.280 --> 00:01:26.279
iSearch would do. and then use each of those, the body of
00:01:26.280 --> 00:01:30.959
those, as a content for the search session. So, I mean,
00:01:30.960 --> 00:01:35.359
essentially you could just, you could start up a session,
00:01:35.360 --> 00:01:39.479
and there's like programmatic ways to start these up too. So
00:01:39.480 --> 00:01:42.599
you could, if such a candidate generator was created, you
00:01:42.600 --> 00:01:49.559
could easily, and just like, you know, one command. Get the
00:01:49.560 --> 00:01:54.599
defunds, create a search session with it, and then just go
00:01:54.600 --> 00:02:01.439
straight to your query. So, definitely, something
00:02:01.440 --> 00:02:06.919
just like this is in the works. And I guess another thing is
00:02:06.920 --> 00:02:08.239
interface.
00:02:08.240 --> 00:02:17.079
The whole dedicated buffer is helpful for searching, but
00:02:17.080 --> 00:02:21.919
with this isearch case, there's currently not a way to have a
00:02:21.920 --> 00:02:27.839
reduced UI, where it's just like, OK, I have these function
00:02:27.840 --> 00:02:32.239
defuns for the current file. I just want them to pop up at the
00:02:32.240 --> 00:02:35.799
bottom so I can quickly go through it. So currently, I don't
00:02:35.800 --> 00:02:41.199
have that. But such a UI is definitely, yeah, thinking about
00:02:41.200 --> 00:02:45.359
how that could be done.
NOTE Q: Any idea how this would work with personal information like Zettlekastens?
00:02:45.360 --> 00:02:50.359
Alright, so yeah. So next question. Any idea how this
00:02:50.360 --> 00:02:52.599
will work with personal information like Zettelkasten?
00:02:52.600 --> 00:02:58.319
So this is, this is like, I mean, it's essentially usable as
00:02:58.320 --> 00:03:04.559
is with Zettelkasten method. So, I mean, that I mean
00:03:04.560 --> 00:03:08.279
basically what like for example org-roam, and I think other
00:03:08.280 --> 00:03:12.159
ones like Denote, they put all these files in the
00:03:12.160 --> 00:03:15.919
directory, and so with the already existing file system
00:03:15.920 --> 00:03:19.679
candidate generator all you'd have to do is set that to be the
00:03:19.680 --> 00:03:23.199
directory of your Zettelkasten system and then it would
00:03:23.200 --> 00:03:26.799
just pick up all the files in there and
00:03:26.800 --> 00:03:28.799
then add those as search candidates. So you could easily
00:03:28.800 --> 00:03:33.279
just search whatever system you have.
00:03:33.280 --> 00:03:36.039
Based off of the ways it's set up, if you had maybe your
00:03:36.040 --> 00:03:40.999
dailies you didn't want to search, it's just as easy to add a
00:03:41.000 --> 00:03:44.519
criteria saying, I don't want dailies to be searched. Like
00:03:44.520 --> 00:03:47.599
give, like just eliminate the date, like the things from the
00:03:47.600 --> 00:03:51.679
daily from the sub directory. And then there you go. you have
00:03:51.680 --> 00:03:57.799
your Zettelkasten search engine, and you could just copy
00:03:57.800 --> 00:03:59.999
the, you know, there's, I mean, I need, I'm working on
00:04:00.000 --> 00:04:03.519
documentation for this to kind of set this up easily, but,
00:04:03.520 --> 00:04:06.679
you know, you could just create your simple command, just
00:04:06.680 --> 00:04:10.679
like, your simple command, just like, just take in a text
00:04:10.680 --> 00:04:14.359
query, run it through the system, and then just get your
00:04:14.360 --> 00:04:19.599
search results right there. So yeah, definitely that is a
00:04:19.600 --> 00:04:22.040
use case that's on top of my mind.
NOTE Q: How good does the search work for synonyms especially if you use different languages?
00:04:22.041 --> 00:04:23.239
So next one, how good does a
00:04:23.240 --> 00:04:26.439
search work for synonyms, especially if you use different
00:04:26.440 --> 00:04:30.719
languages? Okay, this is a good question because with the
00:04:30.720 --> 00:04:34.719
way that VM25 works, it's essentially just like trying to
00:04:34.720 --> 00:04:41.119
find where terms occur and just counts them up.
00:04:41.120 --> 00:04:43.999
I mean, this is something I couldn't get into. There's just
00:04:44.000 --> 00:04:46.919
too much on the topic of information retrieval to kind of go
00:04:46.920 --> 00:04:52.879
into this, but there is a whole kind of field of just like, how
00:04:52.880 --> 00:04:58.279
do you, given a search term, how do you know what you should
00:04:58.280 --> 00:05:02.519
search for? So like popular kind of industrial search
00:05:02.520 --> 00:05:07.519
engines, like they have kind of this feature where you can
00:05:07.520 --> 00:05:11.039
like define synonyms, define, term replacement. So
00:05:11.040 --> 00:05:14.079
whenever you see this term, it should be this. And it even
00:05:14.080 --> 00:05:15.091
gets even further.
NOTE Plurals
00:05:15.092 --> 00:05:19.439
If someone searches for a plural string,
00:05:19.440 --> 00:05:22.279
how do you get the singular from that and search for that? So
00:05:22.280 --> 00:05:27.559
this is a huge topic that currently p-search doesn't
00:05:27.560 --> 00:05:33.519
address, but it's on the top of my mind as to how. So that's one
00:05:33.520 --> 00:05:33.882
part.
NOTE Different languages
00:05:33.883 --> 00:05:38.999
The next part is for different languages, one thing
00:05:39.000 --> 00:05:42.839
that kind of seems like it's promising is vector search,
00:05:42.840 --> 00:05:47.399
which, I mean, with the way p-search is set up, you could
00:05:47.400 --> 00:05:51.159
easily just create a vector search prior, plug it into the
00:05:51.160 --> 00:05:54.599
system, and start using it. The only problem is that kind of
00:05:54.600 --> 00:05:58.879
the vector search functions, like you have to do like cosine
00:05:58.880 --> 00:06:03.639
similarity, like if you have like 10,000 documents, If
00:06:03.640 --> 00:06:06.679
you're writing Elisp to calculate the cosine similarity
00:06:06.680 --> 00:06:09.879
between the vectors, that's going to be very slow. And so now
00:06:09.880 --> 00:06:14.159
the whole can of worms of indexing comes up. And how do you do
00:06:14.160 --> 00:06:17.479
that? And is that going to be native elisp? And so that's a
00:06:17.480 --> 00:06:21.839
whole other can of worms. So yeah, vector search seems
00:06:21.840 --> 00:06:25.959
promising. And then hopefully maybe other traditional
00:06:25.960 --> 00:06:33.439
synonyms, stemming, that kind of stuff for alternate
00:06:33.440 --> 00:06:40.199
terms, that could also be incorporated.
NOTE Q: When searching by author I know authors may setup a new machine and not put the exact same information. Is this doing anything to combine those into one author?
00:06:40.200 --> 00:06:43.719
Okay, next one. When searching by author, I know authors may
00:06:43.720 --> 00:06:47.119
set up a new machine and not put the exact same information.
00:06:47.120 --> 00:06:49.519
Is this doing anything to combine these two in one author?
00:06:49.520 --> 00:06:54.399
Okay, so for this one, it's not. So it's like the way the get
00:06:54.400 --> 00:06:58.119
prior is currently set up is that it just does like a get
00:06:58.120 --> 00:07:01.999
command to get all the get authors. You select one and then it
00:07:02.000 --> 00:07:07.959
just uses that. But the thing is, is if you knew the two emails
00:07:07.960 --> 00:07:12.519
that user might have used, the two usernames, you could just
00:07:12.520 --> 00:07:14.279
set up the
00:07:14.280 --> 00:07:19.799
two priors. One for the old user's email, and then just add
00:07:19.800 --> 00:07:24.079
another prior for the new user's email. And then that would
00:07:24.080 --> 00:07:29.279
be a way to just get both of those set up. So that's kind of a
00:07:29.280 --> 00:07:32.959
running theme throughout p-search is that It's made to be
00:07:32.960 --> 00:07:36.239
very flexible and very kind of like Lego block ish kind of
00:07:36.240 --> 00:07:39.959
like you can just, you know, if you need, you know, if
00:07:39.960 --> 00:07:41.919
something doesn't meet your needs, you know, it's easy to
00:07:41.920 --> 00:07:45.959
put pieces in, create new components of the search
00:07:45.960 --> 00:07:51.799
engine. Let's see, a cool powerful grep "Rak" to maybe have
00:07:51.800 --> 00:07:58.839
some good ideas. I have searches record code while
00:07:58.840 --> 00:08:04.039
searching. Okay. So. Okay, that's interesting. I'll have
00:08:04.040 --> 00:08:05.239
to look into this
00:08:05.240 --> 00:08:15.279
tool. I haven't seen that. I do kind of keep my eyes out for
00:08:15.280 --> 00:08:18.199
these kind of things. One thing I have seen that was kind of
00:08:18.200 --> 00:08:24.439
that, I mean, looked interesting was kind of like AST, like
00:08:24.440 --> 00:08:29.519
the treesitter, the treesitter grep tools. But like, you
00:08:29.520 --> 00:08:35.359
can grep for a string in the language itself. So that's
00:08:35.360 --> 00:08:37.959
something I think would be cool to implement either,
00:08:37.960 --> 00:08:41.359
because I mean, there's treesitter in Emacs, so it's
00:08:41.360 --> 00:08:44.519
possible to do a new list. If not, there are those kind of like
00:08:44.520 --> 00:08:47.719
treesitter. So that's, that's something that I think would
00:08:47.720 --> 00:08:50.719
be cool to incorporate.
NOTE Q: Have you thought about integrating results from using cosine similarity with a deep-learning based vector embedding?
00:08:50.720 --> 00:08:58.279
Let's see. Have you thought about integrating results from
00:08:58.280 --> 00:09:00.999
using cosine similarity with a deep learning based vector
00:09:01.000 --> 00:09:06.679
embedding? Yeah, exactly. So yeah, this kind of goes back to
00:09:06.680 --> 00:09:09.759
the topic before it. Definitely the whole semantic search
00:09:09.760 --> 00:09:12.679
with vector embeddings, that's something that, I mean, it
00:09:12.680 --> 00:09:15.479
would be actually kind of trivial to implement that in
00:09:15.480 --> 00:09:20.239
p-search. But like I said, computing the cosine similarity
00:09:20.240 --> 00:09:25.959
in elisp, it's probably too slow.
00:09:25.960 --> 00:09:34.879
And then also there's a whole question of how do you get the embeddings?
00:09:34.880 --> 00:09:36.919
Like, how do you get the system running locally on your
00:09:36.920 --> 00:09:41.239
machine if you want to run it that or, I mean, so that's
00:09:41.240 --> 00:09:48.879
actually another kind of aspect that I need to look into.
00:09:48.880 --> 00:10:01.939
Okay, so let's see.
NOTE Q: Is it possible to save/bookmark searches or search templates so they can be used again and again?
00:10:01.940 --> 00:10:06.319
Okay, next question. Let's see. I'm sorry if this has been
00:10:06.320 --> 00:10:09.079
covered. Is it possible to save/bookmark searches or search
00:10:09.080 --> 00:10:14.559
templates so they can be used again and again? Exactly. So
00:10:14.560 --> 00:10:18.199
just recently I added bookmarking capabilities. So
00:10:18.200 --> 00:10:21.119
you can essentially just bookmark whatever search session you
00:10:21.120 --> 00:10:26.359
have. And yeah, and it's just, it was just a bookmark. You can
00:10:26.360 --> 00:10:29.839
just open and just like reopen that, rerun that search from
00:10:29.840 --> 00:10:36.119
where you left off. So there's that. And then also, I tried to
00:10:36.120 --> 00:10:40.559
set this up so that there is a one-to-one mapping of a Lisp
00:10:40.560 --> 00:10:44.759
object to the search session. So from every search session
00:10:44.760 --> 00:10:49.519
you make, you should be able to get a, there's a command to do
00:10:49.520 --> 00:10:55.199
this, to get a data representation of the search. So it would
00:10:55.200 --> 00:11:00.079
just be like some plist. All you have to do is just take that
00:11:00.080 --> 00:11:04.479
plist, call this function p-search-setup-buffer with that
00:11:04.480 --> 00:11:09.119
data. And then that function should set up the session as you
00:11:09.120 --> 00:11:12.599
left off. So then like, you know, you could make your
00:11:12.600 --> 00:11:15.359
commands easy. You can make custom search commands super
00:11:15.360 --> 00:11:18.919
easy. You just get the data representation of that search,
00:11:18.920 --> 00:11:22.519
find what pieces you want the user to be able to, you know, the
00:11:22.520 --> 00:11:26.333
search term, make that a parameter in the
00:11:26.334 --> 00:11:29.079
command, in the interactive code. So you'd have like
00:11:29.080 --> 00:11:31.906
print on top and then there you go. You have,
00:11:31.907 --> 00:11:34.327
you have a command to do the search
00:11:34.328 --> 00:11:35.759
just like just right there. So, so
00:11:35.760 --> 00:11:38.519
there's a lot of those things and there's a lot more that
00:11:38.520 --> 00:11:40.999
could be done. Like maybe having, you know, there's kind of
00:11:41.000 --> 00:11:45.479
in the works and like thinking about having groups of groups
00:11:45.480 --> 00:11:48.959
of these things, like maybe you can set up like, Oh, I always
00:11:48.960 --> 00:11:51.919
add these three criteria together. So I, you know, maybe I
00:11:51.920 --> 00:11:54.559
can make a preset out of these and make them easy, easily
00:11:54.560 --> 00:11:58.079
addable. So yeah. A lot of things like that are, you know, I'm
00:11:58.080 --> 00:12:02.799
thinking about a lot of things about that, so.
NOTE Q: You mentioned about candidate generators. Could you explain about to what the score is assigned to?
00:12:02.800 --> 00:12:06.079
Okay, so next question. You mentioned about candidate
00:12:06.080 --> 00:12:08.479
generators. Could you explain about what the score is
00:12:08.480 --> 00:12:12.199
assigned to? Is this to a line or whatever the candidate
00:12:12.200 --> 00:12:17.079
generates? How does it work with our junior demo? Okay,
00:12:17.080 --> 00:12:21.799
yeah, so this is a, this is, so actually I had to implement, I
00:12:21.800 --> 00:12:26.719
had to rewrite p-search just to get this part right. So the
00:12:26.720 --> 00:12:31.159
candidate generator generates documents. Documents have
00:12:31.160 --> 00:12:36.919
properties. So the most notable property is the content
00:12:36.920 --> 00:12:40.599
property. So essentially what happens is that when you
00:12:40.600 --> 00:12:42.879
create a file system candidate generator and give it a
00:12:42.880 --> 00:12:45.919
directory, the code goes into the directory, kind of
00:12:45.920 --> 00:12:49.079
recursively goes through all the directories, and
00:12:49.080 --> 00:12:51.559
generates a candidate, which is just like a simple list
00:12:51.560 --> 00:12:55.679
form. It's saying, this is a file, the file path is this. So
00:12:55.680 --> 00:13:00.799
that's the document ID. So this is saying, this is a file,
00:13:00.800 --> 00:13:05.559
it's a file, and its file path is this. And so from that, you
00:13:05.560 --> 00:13:09.279
get all of the different properties, the sub properties. If
00:13:09.280 --> 00:13:11.719
you're given that, you know how to get the content. If you're
00:13:11.720 --> 00:13:15.439
given that, you know how to... So all these properties come
00:13:15.440 --> 00:13:18.839
out. And then also the candidate generator is the thing that
00:13:18.840 --> 00:13:25.439
knows how best to search for the terms. So for example, there
00:13:25.440 --> 00:13:29.159
is a buffer candidate generator. What that does is it just
00:13:29.160 --> 00:13:34.759
puts all your buffers as search candidates. So obviously
00:13:34.760 --> 00:13:37.879
you can't, you can't run ripgrep on buffers like you can't you
00:13:37.880 --> 00:13:41.759
can't do that, you can't run ripgrep on just like yeah just
00:13:41.760 --> 00:13:44.319
just like buffers that don't have files attached or, for
00:13:44.320 --> 00:13:47.559
example, maybe there's like an internet search candidate
00:13:47.560 --> 00:13:51.279
generator, like a web crawler thing. You just imagine it
00:13:51.280 --> 00:13:55.759
goes to a website, kind of crawls all the links and all that,
00:13:55.760 --> 00:13:58.119
and then just gets your web pages for the candidates.
00:13:58.120 --> 00:14:01.159
Obviously, you can't use ripgrep for that either. So, every
00:14:01.160 --> 00:14:04.679
candidate generator knows how best to search for the terms
00:14:04.680 --> 00:14:08.919
of what candidate it's generating. So, the file system
00:14:08.920 --> 00:14:12.359
candidate generator will say, okay, I have a base
00:14:12.360 --> 00:14:17.239
directory. So, if you ask me, the file system candidate
00:14:17.240 --> 00:14:21.239
generator, how to get the terms, it knows it's set up to use
00:14:21.240 --> 00:14:25.199
ripgrep. And so, it runs ripgrep, and so then it goes
00:14:25.200 --> 00:14:29.439
through, it runs the command, gets the counts, and then
00:14:29.440 --> 00:14:32.359
store those counts. So, the lines have nothing. At this
00:14:32.360 --> 00:14:35.999
point, the lines have nothing. There's no notion of lines at
00:14:36.000 --> 00:14:40.559
all. It's just document, document ID with the amount of
00:14:40.560 --> 00:14:43.839
times it matched. And that's all you need to run this BM25
00:14:43.840 --> 00:14:47.519
algorithm. But then when you get the top results, you
00:14:47.520 --> 00:14:51.359
obviously want to see the lines that matched. And so there's
00:14:51.360 --> 00:14:56.399
another thing, another method to kind of get the exact
00:14:56.400 --> 00:15:00.559
thing, to kind of match out the particular lines. And so
00:15:00.560 --> 00:15:03.159
that's a separate mechanism. And that can be done in Elist,
00:15:03.160 --> 00:15:05.719
because if you're not displaying, that's kind of a design
00:15:05.720 --> 00:15:09.319
decision of P-Search, is that it only displays like maybe 10
00:15:09.320 --> 00:15:12.519
or 20. It doesn't display all the results. So you can have
00:15:12.520 --> 00:15:16.679
Elist just go crazy with just like highlighting things,
00:15:16.680 --> 00:15:22.719
picking the best kind of pieces to show. So yeah, that's how
00:15:22.720 --> 00:15:27.359
that's set up.
00:15:27.360 --> 00:15:38.279
So, here's perhaps a good moment for me to just jump in and
00:15:38.280 --> 00:15:42.079
comment that in a minute or so we will break away with the live
00:15:42.080 --> 00:15:47.439
stream to give people an hour of less content to make sure
00:15:47.440 --> 00:15:50.639
everybody goes and takes their lunch and break a little bit.
00:15:50.640 --> 00:15:55.039
But if you would like to keep going in here, Love to love to
00:15:55.040 --> 00:15:59.839
take as many questions. And, of course, we will include
00:15:59.840 --> 00:16:06.159
that all when we publish the Q and A. Sounds good. Yeah, I'll go
00:16:06.160 --> 00:16:12.199
and stick around on the stream as we cut away, as we've got a
00:16:12.200 --> 00:16:15.999
little video surprise we've all prepared to play, just some
00:16:16.000 --> 00:16:19.359
comments from an Emacs user dated in 2020 or something like
00:16:19.360 --> 00:16:29.679
this. I forget the detail. Thank you again so much, Zac, for
00:16:29.680 --> 00:16:30.959
your fascinating talk.
00:16:30.960 --> 00:16:32.301
Yeah, so, okay.
NOTE Q: easy filtering with orderless - did this or something like this help or infulce the design of psearch?
00:16:32.302 --> 00:16:33.359
This makes me really think about the
00:16:33.360 --> 00:16:35.999
emergent workflows with Denote and easy filtering with
00:16:36.000 --> 00:16:36.639
orderless.
00:16:36.640 --> 00:16:42.039
Did this or something like this help influence the design of
00:16:42.040 --> 00:16:47.359
p-search? Yeah, exactly. So, I mean, yeah, I mean, there's
00:16:47.360 --> 00:16:49.919
just so many different searches. Like, it's just kind of
00:16:49.920 --> 00:16:52.519
mind-boggling. Like, you could search for whatever you want
00:16:52.520 --> 00:16:54.599
on your computer. Like, there's just so much, like, you
00:16:54.600 --> 00:17:01.199
can't, yeah, you can't just like, you can't just like hard
00:17:01.200 --> 00:17:04.159
code any of these things. It's all malleable. Like maybe
00:17:04.160 --> 00:17:09.279
somebody wants to search these directories. And so, yeah,
00:17:09.280 --> 00:17:10.639
like
00:17:10.640 --> 00:17:18.399
exactly like that use case of having a directory of files
00:17:18.400 --> 00:17:18.959
where
00:17:18.960 --> 00:17:25.919
they contain your personal knowledge management system.
00:17:25.920 --> 00:17:33.479
Yeah, that use case definitely was at the top of my mind.
00:17:33.480 --> 00:17:35.879
Let's see.
00:17:35.880 --> 00:17:56.959
Let's see, so Git covers the multiple names thing itself.
NOTE Q: Notmuch with the p-search UI
00:17:56.960 --> 00:18:00.359
Okay, yeah,
00:18:00.360 --> 00:18:09.599
so something about notmuch with p-search UI. Actually,
00:18:09.600 --> 00:18:16.399
interestingly, I think notmuch is, I haven't used it
00:18:16.400 --> 00:18:22.759
myself, but that's the, email something about yeah so i mean
00:18:22.760 --> 00:18:25.679
this is like these things are just like these these kind of
00:18:25.680 --> 00:18:30.479
extensions could kind of go go forever but one thing i
00:18:30.480 --> 00:18:33.369
thought about is like i use mu4e for email
00:18:33.370 --> 00:18:41.119
and that uses a full-fledged index. And so having
00:18:41.120 --> 00:18:44.879
some method to kind of reach into these different systems
00:18:44.880 --> 00:18:47.938
and kind of be kind of like a front end for this.
00:18:47.939 --> 00:18:52.000
Another thing is maybe SQL database.
00:18:52.001 --> 00:18:55.823
You can create a candidate generator from a SQLite query
00:18:55.824 --> 00:19:01.919
and then... yeah...
00:19:02.583 --> 00:19:05.519
I've had tons of ideas of different things you could
00:19:05.520 --> 00:19:09.559
incorporate into the system. Slowly,
00:19:09.560 --> 00:19:13.599
they're being implemented. Just recently, I implemented
NOTE Info
00:19:13.600 --> 00:19:17.039
an info file candidate generator. So it lists out all the
00:19:17.040 --> 00:19:21.559
info files, and then it creates a candidate for each of the
00:19:21.560 --> 00:19:26.759
info nodes. So it turns out, yeah, I mean, it works pretty, I
00:19:26.760 --> 00:19:32.559
mean, just as well as Google. So I'm up for my own testing.
00:19:32.560 --> 00:19:39.999
Let's see, you can search a buffer using ripgrep feeding in
00:19:40.000 --> 00:19:44.759
as standard in to the ripgrep process, can't you? Yep, yeah,
00:19:44.760 --> 00:19:50.039
you can definitely search a buffer that way. So, yeah, I
00:19:50.040 --> 00:19:56.359
mean, based off of I mean, if this, yeah, so one thing that
00:19:56.360 --> 00:19:59.039
came up is that the system wants, I mean, I wanted the system
00:19:59.040 --> 00:20:03.559
to be able to search a lot of different things. And so it came
00:20:03.560 --> 00:20:05.999
up that I had, you know, implementing,
00:20:06.000 --> 00:20:10.159
doing these search things, having an Elist
00:20:10.160 --> 00:20:13.079
implementation, despite it being slow, would be
00:20:13.080 --> 00:20:17.399
necessary. So like anything that isn't represented as a
00:20:17.400 --> 00:20:21.639
file, Elisp, there's a mechanism in p-search to search for
00:20:21.640 --> 00:20:23.319
it.
00:20:23.320 --> 00:20:29.719
So, yeah, so having that redundancy kind of lets you get into
00:20:29.720 --> 00:20:32.799
the, you know, using kind of ripgrep for the big scale
00:20:32.800 --> 00:20:37.759
things. But then when you get to the individual file, you
00:20:37.760 --> 00:20:40.999
know, just going back to Elisp to kind of get the finer
00:20:41.000 --> 00:20:47.199
details seems to, you know, seems to end up working pretty
00:20:47.200 --> 00:21:04.239
well.
00:21:04.240 --> 00:21:27.399
Thank you all for listening. Yeah, sounds like we're about
00:21:27.400 --> 00:21:31.279
out of questions. Hi, Zacc. I have a question or still a
00:21:31.280 --> 00:21:34.119
question. I just want to thank everybody one more time for
00:21:34.120 --> 00:21:37.719
their participation, especially you for speaking, Zack. I
00:21:37.720 --> 00:21:41.239
look forward to playing with p-search myself. Thank you.
00:21:41.240 --> 00:21:44.039
Yeah, there might be one last question. Is there someone?
00:21:44.040 --> 00:21:48.519
Yes, there is. I don't know if you can understand me, but
00:21:48.520 --> 00:21:50.359
thank you for making this lovely thing
00:21:50.360 --> 00:21:57.919
I feel inspired to try it out and I'm thinking about how to
00:21:57.920 --> 00:22:04.199
integrate it because it sounds modular and nicely thought
00:22:04.200 --> 00:22:09.799
out. One small question. Have you thought about Project L
00:22:09.800 --> 00:22:13.719
integration? And then I have a little bigger question about
00:22:13.720 --> 00:22:14.879
the interface.
NOTE project.el integration
00:22:14.880 --> 00:22:20.799
Yeah, project.el integration, it's used in a couple of ways.
00:22:20.800 --> 00:22:25.719
It's kind of used to kind of as like kind of like a default.
00:22:25.720 --> 00:22:31.279
This is the directory I want to search for the default
00:22:31.280 --> 00:22:33.639
p-search command. It does, yeah, it kind of goes off of
00:22:33.640 --> 00:22:37.119
project.el. If there is a project, it kind of says, okay, this,
00:22:37.120 --> 00:22:40.319
I want to search this project. And so it kind of, it used that
00:22:40.320 --> 00:22:46.119
as a default. So there's that. Because I use the project-grep
00:22:46.120 --> 00:22:50.679
or git-grep search a lot and maybe this is a better solution to
00:22:50.680 --> 00:22:55.319
the search and the interface you have right now for the
00:22:55.320 --> 00:22:56.476
search results.
NOTE Q: How happy are you with the interface?
00:22:56.477 --> 00:22:58.719
How happy are you with it and have you
00:22:58.720 --> 00:23:02.599
thought about improving or have you ideas for
00:23:02.600 --> 00:23:06.639
improvements? Yeah, well actually what you see in the demo
00:23:06.640 --> 00:23:09.199
in the video isn't... There's actually, there is an
00:23:09.200 --> 00:23:13.959
improvement in the current code. Basically, what it
00:23:13.960 --> 00:23:17.239
does is it scans there's the current default as it scans
00:23:17.240 --> 00:23:20.054
the entire file for all of the searches.
00:23:20.055 --> 00:23:25.959
It finds the window that that has the highest score. So it kind
00:23:25.960 --> 00:23:29.599
of goes through entire file and just says... And it kind of finds
00:23:29.600 --> 00:23:33.479
like the piece of the section of text that has the most
00:23:33.480 --> 00:23:37.919
matches with the terms that score the best. So it's, I mean,
00:23:37.920 --> 00:23:40.119
that section is pretty good. I mean, that, so yeah, that,
00:23:40.120 --> 00:23:44.519
that ends up working pretty well. So I mean, in terms of other
00:23:44.520 --> 00:23:46.879
UI stuff, there's, there's tons, there's tons more that
00:23:46.880 --> 00:23:50.159
could be done, like, especially like debug ability or like
00:23:50.160 --> 00:23:53.799
introspection. Like, so this, this result, like, for
00:23:53.800 --> 00:23:57.119
example, this result ranks really high. Maybe you don't
00:23:57.120 --> 00:24:01.719
know why though. It's like, because of this, this text query
00:24:01.720 --> 00:24:04.479
arrow, was it because of this criteria? I think
00:24:04.480 --> 00:24:09.039
there's some UI elements that could kind of help the user
00:24:09.040 --> 00:24:12.519
understand why results are scoring high or low. So that's
00:24:12.520 --> 00:24:15.639
definitely... And that makes a lot of sense to me. You know, a
00:24:15.640 --> 00:24:19.039
lot of it is demystifying, like understanding what you're
00:24:19.040 --> 00:24:22.719
learning better and not just finding the right thing. A lot
00:24:22.720 --> 00:24:26.519
of it is, you know, kind of exploring your data. I love that.
00:24:26.520 --> 00:24:31.639
Thanks. Okay. I'm not trying to hurry us through either by
00:24:31.640 --> 00:24:36.599
any stretch. I would be happy to see this be a conversation.
00:24:36.600 --> 00:24:42.359
I also want to be considerate of your time. And I also wanted to
00:24:42.360 --> 00:24:45.479
make a quick shout out to everybody who's been updating and
00:24:45.480 --> 00:24:50.479
helping us capture the questions and the comments and the
00:24:50.480 --> 00:24:53.639
etherpad. That's just a big help to the extent that people
00:24:53.640 --> 00:24:57.199
are jumping in there and you know, revising and extending
00:24:57.200 --> 00:24:59.799
and just doing the best job we can to capture all the
00:24:59.800 --> 00:25:00.799
thoughtful remarks.
00:25:00.800 --> 00:25:14.839
Yeah, thank you, Zac. I'm not too sure what to ask anymore,
00:25:14.840 --> 00:25:20.559
but yes, would love to try it out now. Yeah, I mean,
00:25:20.560 --> 00:25:22.076
definitely feel free to...
00:25:22.077 --> 00:25:25.679
any feedback, here's my mail, or issues...
00:25:25.680 --> 00:25:29.039
I mean I'm happy to get any any feedback. It's
00:25:29.040 --> 00:25:31.679
still in the early stages, so still kind of a lot of
00:25:31.680 --> 00:25:35.599
documentation that needs to be writing. There's a lot.
00:25:35.600 --> 00:25:38.439
There's a lot on the roadmap, but yeah, I mean, hopefully, I
00:25:38.440 --> 00:25:42.759
could even publish this to ELPA and have a nice
00:25:42.760 --> 00:25:47.727
manual so yeah hopefully yeah those come soon. Epic.
00:25:47.728 --> 00:25:50.279
That sounds great, yes.
NOTE gptel
00:25:50.280 --> 00:25:59.359
The ability to save your searches kind of reminds me of like
00:25:59.360 --> 00:26:05.119
the gptel package for the AI, where you can save searches,
00:26:05.120 --> 00:26:10.799
which makes it feel a lot more different. And yeah, we don't
00:26:10.800 --> 00:26:14.839
have something for that with search, but yeah, that's a
00:26:14.840 --> 00:26:19.279
whole different dynamic where it's like, okay, yeah, and
00:26:19.280 --> 00:26:24.679
makes it a unique tool that is, I guess would be unique to
00:26:24.680 --> 00:26:28.079
Emacs where you don't see that with like this AI package
00:26:28.080 --> 00:26:31.119
where the gptel is kind of unique because it's not just throw
00:26:31.120 --> 00:26:37.039
away. It's how did I get this? How did I search for it? And be an
00:26:37.040 --> 00:26:40.319
organic search, kind of like the orderless and vertico
00:26:40.320 --> 00:26:43.039
and...
00:26:43.040 --> 00:26:46.279
Yeah, that's a good, I mean, that brings me to another thing
00:26:46.280 --> 00:26:48.239
in that, so,
00:26:48.240 --> 00:26:53.199
I mean, you could easily...
00:26:53.200 --> 00:26:57.399
you could create bridges from p-search to these different
00:26:57.400 --> 00:27:01.519
other packages, like, for example, kind of a RAG search,
00:27:01.520 --> 00:27:04.679
like there's this RAG, there's this thing called a RAG
00:27:04.680 --> 00:27:06.879
workflow, which is kind of popular these days. It's like
00:27:06.880 --> 00:27:11.639
retrieval augmented generation. So, you do a search and
00:27:11.640 --> 00:27:14.199
then based off the search results you get, then you pass
00:27:14.200 --> 00:27:20.359
those into LLM. So, the cool thing is that like you could use
00:27:20.360 --> 00:27:25.119
p-search for the retrieval. And so you could even like, I
00:27:25.120 --> 00:27:28.799
mean, you could even ask an LM to come up with the search terms
00:27:28.800 --> 00:27:32.079
and then have it search. There's no
00:27:32.080 --> 00:27:35.439
programmatical interface now to do this exact workflow.
00:27:35.440 --> 00:27:39.039
But I mean, there's another kind of direction I'm starting
00:27:39.040 --> 00:27:43.199
to think about. So like you could have maybe
00:27:43.200 --> 00:27:47.759
a question answer kind of workflow where it does
00:27:47.760 --> 00:27:51.639
like an initial search for the terms and then you get the top
00:27:51.640 --> 00:27:57.199
results and then you can put that through maybe gptel or all
00:27:57.200 --> 00:27:59.759
these other different systems. So that's, and that seems
00:27:59.760 --> 00:28:01.479
like a promising thing. And then another thing is like,
NOTE Saving a search
00:28:01.480 --> 00:28:10.594
well, you mentioned the ability to save a search.
00:28:10.595 --> 00:28:11.479
One thing I've noticed
00:28:11.480 --> 00:28:15.359
kind of like with the DevOps workflows is, I'll write a
00:28:15.360 --> 00:28:20.519
CLI command that I do, or like a calculator command. Then I end
00:28:20.520 --> 00:28:23.999
up in the org mode document, write what I wrote, had the
00:28:24.000 --> 00:28:26.943
results in there, and then I'll go back to that.
00:28:26.944 --> 00:28:31.966
It's like, oh, this is why, this is that calculation I did
00:28:31.967 --> 00:28:34.007
and this is why I did it.
00:28:34.008 --> 00:28:36.959
I'll have run the same tool three different
00:28:36.960 --> 00:28:40.519
times to get three different answers, if it was like a
00:28:40.520 --> 00:28:41.799
calculator, for example.
NOTE Workflows
00:28:41.800 --> 00:28:49.319
But yeah, that's a very unique feature that isn't seen and
00:28:49.320 --> 00:28:53.959
will make me look at it and see about integrating it into my
00:28:53.960 --> 00:28:59.079
workflow. Yeah, I think you get on some interesting, you
00:28:59.080 --> 00:29:03.159
know, kind of what makes Emacs really unique there and how
00:29:03.160 --> 00:29:07.399
to... interesting kind of ways to exploit
00:29:07.400 --> 00:29:12.439
Emacs to learn in the problem. I'm seeing a number of
00:29:12.440 --> 00:29:15.799
ways you're getting at that. For example, if I think about
00:29:15.800 --> 00:29:18.999
like an automation workflow, and there's just a million
00:29:19.000 --> 00:29:22.719
we'll say, assumptions that are baked into a search
00:29:22.720 --> 00:29:26.719
product, so to speak, like represented by a Google search or
00:29:26.720 --> 00:29:31.639
Bing or what have you. And then as I unpack that and repack it
00:29:31.640 --> 00:29:35.159
from an Emacs workflow standpoint, thinking about, well,
00:29:35.160 --> 00:29:39.079
first of all, what is the yak I'm shaving? And then also, what
00:29:39.080 --> 00:29:43.759
does doing it right mean? How would I reuse this? How would I
00:29:43.760 --> 00:29:47.679
make the code accessible to others for their own purposes in
00:29:47.680 --> 00:29:52.439
a free software world kind of way? and all of the different
00:29:52.440 --> 00:29:57.479
sort of say like orthogonal headspacey kind of things,
00:29:57.480 --> 00:30:00.079
right? Emacs brings a lot to the table from a search
00:30:00.080 --> 00:30:03.719
standpoint because I'm going to want to think about. I'm
00:30:03.720 --> 00:30:07.799
going to want to think about where does the UI come in? Where
00:30:07.800 --> 00:30:11.399
might the user want to get involved interactively? Where
00:30:11.400 --> 00:30:14.359
might the user want to get involved declaratively with
00:30:14.360 --> 00:30:16.919
their configuration, perhaps based on the particular
00:30:16.920 --> 00:30:21.359
environment where this Emacs is running? And there's just a
00:30:21.360 --> 00:30:24.879
lot of what Emacs users think about that really applies.
00:30:24.880 --> 00:30:28.359
I'll use the word again, orthogonally across all my many
00:30:28.360 --> 00:30:33.239
workflows as an Emacs user. You know, the search is just such
00:30:33.240 --> 00:30:38.519
a big word. Yeah, that's actually, this exact point I was
00:30:38.520 --> 00:30:43.159
thinking about with this. It's like, I mean, it seems kind of
00:30:43.160 --> 00:30:46.319
obvious, like just like using grep or something, just like to
00:30:46.320 --> 00:30:49.359
get search counts, like, okay, you can just run the command,
00:30:49.360 --> 00:30:51.439
get the term counts and you could just run it through a
00:30:51.440 --> 00:30:55.959
relatively simple algorithm. to get your search score. So
00:30:55.960 --> 00:31:01.759
if it's this easy, though, why don't we see this in other... And
00:31:01.760 --> 00:31:06.919
the results are actually surprisingly good. So why don't we
00:31:06.920 --> 00:31:10.559
see this anywhere, really? And it occurred to me that just
00:31:10.560 --> 00:31:16.399
the amount of configuration... The amount of setup you have to
00:31:16.400 --> 00:31:20.039
do to get it right.
00:31:20.040 --> 00:31:24.599
It's above this threshold that you need something like
00:31:24.600 --> 00:31:27.856
Emacs to kind of get pushed through that configuration.
NOTE Transient and configuration
00:31:27.857 --> 00:31:30.799
So for example, that's why I rely heavily on transient
00:31:30.800 --> 00:31:34.119
to set up the system. 'Cause like, if you want to get good
00:31:34.120 --> 00:31:36.079
search results, you're going to have to configure a lot
00:31:36.080 --> 00:31:38.519
of stuff. I want this directory. I want this, I don't
00:31:38.520 --> 00:31:41.559
want this directory. I want these search terms, you know,
00:31:41.560 --> 00:31:48.159
there's a lot to set up. And in most programs, I mean, they
00:31:48.160 --> 00:31:52.079
don't have an easy way to, I mean, they'll often try and try to
00:31:52.080 --> 00:31:55.039
hide all this complexity. Like they say, okay, our users
00:31:55.040 --> 00:31:59.199
too, you know, we don't want to, you know, we don't wanna, you
00:31:59.200 --> 00:32:02.719
know, make our users, we don't wanna scare our users with
00:32:02.720 --> 00:32:06.879
like, complicated search engine configuration. So we're
00:32:06.880 --> 00:32:09.079
just going to do it all in the background and we're just not
00:32:09.080 --> 00:32:12.599
going to let the user even know that it's happening. I mean,
00:32:12.600 --> 00:32:15.119
that's the third time you've made me laugh out loud. Sorry
00:32:15.120 --> 00:32:17.879
for interrupting you, but yeah, you're just spot on there.
00:32:17.880 --> 00:32:22.999
You're some people's users. Am I right? like, you know, and
00:32:23.000 --> 00:32:25.390
also some people's workflows.
NOTE Problem space
00:32:25.391 --> 00:32:27.719
And, you know, another case
00:32:27.720 --> 00:32:30.799
where just like, if you're thinking about Emacs, you either
00:32:30.800 --> 00:32:33.279
have to pick a tunnel to dive into and be like, no, this is
00:32:33.280 --> 00:32:37.759
going to be right for my work, or your problem space is never
00:32:37.760 --> 00:32:40.879
ending in terms of discovering the ways other people are
00:32:40.880 --> 00:32:45.839
using Emacs and how that breaks your feature. and how that
00:32:45.840 --> 00:32:49.679
breaks your conceptualization of the problem space,
00:32:49.680 --> 00:32:53.559
right? Or you just have to get so narrowed down that can
00:32:53.560 --> 00:32:57.119
actually be hard to find people that are quite understand
00:32:57.120 --> 00:33:00.279
you, right? You get into the particular, well, it solves
00:33:00.280 --> 00:33:03.039
these three problems for me. Well, what are these three
00:33:03.040 --> 00:33:08.639
problems again? And this is a month to unpack. You have Emacs
00:33:08.640 --> 00:33:12.639
and I don't know, it's like you got a lot of, they all agree is
00:33:12.640 --> 00:33:16.559
like we're going to use elisp to set variables every emacs
00:33:16.560 --> 00:33:21.199
package is going to do that we're going to use elisp and have a
00:33:21.200 --> 00:33:25.479
search in place to put our documentation and like it does
00:33:25.480 --> 00:33:32.559
also eliminate a lot of confusion and gives a lot of
00:33:32.560 --> 00:33:37.719
expectations of what they want. One thing that I'm
00:33:37.720 --> 00:33:39.855
surprised I haven't seen elsewhere is you have the
NOTE consult-omni
00:33:39.856 --> 00:33:44.239
consult-omni package which allows you to search multiple websites
00:33:44.240 --> 00:33:49.799
simultaneously for multiple web search engines. and put
00:33:49.800 --> 00:33:52.799
them in one thing and it's like, and then you use orderless.
NOTE orderless
00:33:52.800 --> 00:33:55.159
Why would you use orderless? Because that's what you
00:33:55.160 --> 00:33:57.799
configured and you know exactly what you wanna use and you
00:33:57.800 --> 00:34:01.679
use the same font and your same mini buffer and you use all
00:34:01.680 --> 00:34:04.079
that existing configuration because, well, you're an
00:34:04.080 --> 00:34:07.599
Emacs user or like you're a command line user. You know how
00:34:07.600 --> 00:34:11.559
you want these applications to go. You don't want them to be
00:34:11.560 --> 00:34:17.399
reinvented the wheel 1600 times in 1,600 different ways,
00:34:17.400 --> 00:34:23.079
you want it to use your mini buffer, your font, your et
00:34:23.080 --> 00:34:28.159
cetera, et cetera, et cetera. But I haven't
00:34:28.160 --> 00:34:32.479
seen a website where I can search multiple websites at the
00:34:32.480 --> 00:34:35.159
same time in something like Emacs before. And it's like,
00:34:35.160 --> 00:34:38.319
yeah, with my sorting algorithm,
00:34:38.320 --> 00:34:49.359
Yeah, exactly. Yeah. Yeah. Yeah. I mean, just setting the
00:34:49.360 --> 00:34:57.079
bar for configuration and set up just like, yeah, you have to
00:34:57.080 --> 00:35:02.839
have a list. Yeah. I mean, it, it does, obviously it's not,
00:35:02.840 --> 00:35:05.839
it's not most beginner beginner friendly, but I mean, it,
00:35:05.840 --> 00:35:10.319
yeah, it definitely widens the amount of the solution space
00:35:10.320 --> 00:35:14.679
you can have to such problems. Oh my gosh, you used the word
00:35:14.680 --> 00:35:18.759
solution space. I love it. But on the flip side, it's like,
00:35:18.760 --> 00:35:25.119
why does Emacs get this consult-omni package? Or let's see,
00:35:25.120 --> 00:35:30.719
you have elfeed-youtube where it will put a flowing
00:35:30.720 --> 00:35:34.479
transcript on a YouTube video or you got your package. Why
00:35:34.480 --> 00:35:39.879
does it get all these applications? And I don't see
00:35:39.880 --> 00:35:45.679
applications like this as much outside of Emacs. So there's
00:35:45.680 --> 00:35:46.267
a way that it just makes it easier.
NOTE User interface
00:35:46.268 --> 00:35:47.479
It's because user
00:35:47.480 --> 00:35:51.439
interface is the, you know, it's the economy stupid of
00:35:51.440 --> 00:35:58.119
technology, right? If you grab people by the UX, you can sell
00:35:58.120 --> 00:36:01.679
a million of any product that solves problem that I didn't
00:36:01.680 --> 00:36:04.639
think technology could solve, or that I didn't think I had
00:36:04.640 --> 00:36:08.319
the patience to use technology to solve, which is a lot of
00:36:08.320 --> 00:36:12.159
times what it comes down to. And here exactly is the, you
00:36:12.160 --> 00:36:16.799
know, the the Emacs sort of conundrum, right? How much time
00:36:16.800 --> 00:36:20.759
should I spend today updating my Emacs so that tomorrow I can
00:36:20.760 --> 00:36:26.319
just work more, right? And, you know, I love that little
00:36:26.320 --> 00:36:29.839
graph of the Emacs learning curve, right? Where it's this
00:36:29.840 --> 00:36:33.399
concentric, it becomes this concentric spiral, right? The
00:36:33.400 --> 00:36:38.759
Vim learning curve is like a ladder, right? Or, you know, and
00:36:38.760 --> 00:36:44.119
And the nano learning curve is like just a flat plane, you
00:36:44.120 --> 00:36:49.279
know, or a ladder, a vertical ladder or a horizontal ladder.
00:36:49.280 --> 00:36:56.719
There we go. And the Emacs learning curve is this kind of
00:36:56.720 --> 00:36:59.799
straight up line until it curves back on itself and
00:36:59.800 --> 00:37:03.079
eventually spirals. And the more you learn, the harder it is
00:37:03.080 --> 00:37:05.839
to learn the next thing. And are you really moving forward at
00:37:05.840 --> 00:37:09.039
all? Like, it just works for me. What a great analogy. And
00:37:09.040 --> 00:37:15.279
that's my answer, I think. Yeah. You know, it's because
00:37:15.280 --> 00:37:20.199
we... The spiral is great. Sorry. There are each of these
00:37:20.200 --> 00:37:26.639
weird little packages that some of us, you know, it solves
00:37:26.640 --> 00:37:29.279
that one problem and lets us get back to work. And for others,
00:37:29.280 --> 00:37:32.439
it makes us go, gosh, now that makes me rethink a whole bunch
00:37:32.440 --> 00:37:35.239
of things because there's... Like I don't even know what
00:37:35.240 --> 00:37:37.719
you're talking about with some of your conceptualizations
00:37:37.720 --> 00:37:41.039
of UI. Maybe it comes from Visual Studio, and I've not
00:37:41.040 --> 00:37:44.679
used that or something. So for you, it's a perfectly normal UX
00:37:44.680 --> 00:37:48.799
paradigm that you kind of lean on for others. It's like you
00:37:48.800 --> 00:37:51.999
know occupying some screen space and I don't know what the
00:37:52.000 --> 00:37:57.759
gadgets do and when I open them up... They're thinking
00:37:57.760 --> 00:38:00.999
about... they have... they imply their own
00:38:01.000 --> 00:38:03.639
abstractions let's say logically against a programming
00:38:03.640 --> 00:38:06.999
language. This would be tree sitter, right. If i'm not used to
00:38:07.000 --> 00:38:11.719
thinking in terms of an abstract abstract syntax tree, some
00:38:11.720 --> 00:38:14.799
of the concepts just aren't as natural for me. If i'm used to
00:38:14.800 --> 00:38:19.039
like emacs at a more fundamental level is, or the old modes
00:38:19.040 --> 00:38:23.479
right, we're used to them thinking in terms of progressing
00:38:23.480 --> 00:38:26.959
forward through some text, managing a stack of markers into
00:38:26.960 --> 00:38:29.239
the text, right? It's a different paradigm. The world
00:38:29.240 --> 00:38:33.559
changes. Emacs kind of supports it all. That's why all the
00:38:33.560 --> 00:38:37.039
apps are built there. That's why when you're talking about
00:38:37.040 --> 00:38:40.759
that spiral. what that hints at is that this is really just a
00:38:40.760 --> 00:38:44.239
different algorithm that you're transferring out that
00:38:44.240 --> 00:38:47.319
makes some things a lot easier and some things a lot harder.
00:38:47.320 --> 00:38:51.719
That's why I was bringing in those three packages, because
00:38:51.720 --> 00:38:59.708
in some way it's making these search terms with reusable...
00:38:59.709 --> 00:39:07.083
Let's see... saveable buffers or interactive buffers in a way
00:39:07.084 --> 00:39:10.359
that... in a way, that is bigger than what I think it should have,
00:39:10.360 --> 00:39:15.479
especially in comparison to like how many people use
00:39:15.480 --> 00:39:20.319
YouTube, but I don't see very many YouTube apps that will
00:39:20.320 --> 00:39:26.279
show Rolling subtitle list that you can click on to move up
00:39:26.280 --> 00:39:27.315
and down the video
00:39:27.316 --> 00:39:30.139
even though YouTube's been around for years.
00:39:30.140 --> 00:39:33.359
Why does Emacs have a very good implementation
00:39:33.360 --> 00:39:37.159
that was duct taped together? So before I let you respond to
00:39:37.160 --> 00:39:40.439
that, Zac, let me just say we're coming up on eating up a
00:39:40.440 --> 00:39:43.879
whole half hour of your lunchtime and thank you for giving us
00:39:43.880 --> 00:39:47.879
that extra time. But let me just say, let's, you know, if I
00:39:47.880 --> 00:39:50.879
could ask you to take like up to another five minutes and then
00:39:50.880 --> 00:39:53.759
I'll try to kick us off here and make sure everybody does
00:39:53.760 --> 00:39:54.999
remember to eat.
00:39:55.000 --> 00:40:04.119
Yeah, so yeah, it looks like there's one other question. So
NOTE Q: Do you think the Emacs being kinda slow will get in the way of being able to run a lot of scoring algorithms?
00:40:04.120 --> 00:40:06.679
yeah, do you think Emacs being kind of slow will get in the way
00:40:06.680 --> 00:40:11.319
of being able to run a lot of scoring algorithms? So this is
00:40:11.320 --> 00:40:15.039
actually a thought I had. Yeah, Emacs, because the code
00:40:15.040 --> 00:40:19.919
currently kind of does, I mean, it kind of does, it's kind of
00:40:19.920 --> 00:40:24.039
dumb in a lot of places. a lot of times it just, it does just go
00:40:24.040 --> 00:40:27.599
through all the files and then just compute some score for
00:40:27.600 --> 00:40:30.679
them. But I'm surprised that it's, that part actually isn't
00:40:30.680 --> 00:40:34.799
that slow. Like, like it turns out like, okay, like if you
00:40:34.800 --> 00:40:40.759
take, for example, Emacs, like the Emacs directory or the
00:40:40.760 --> 00:40:44.879
Emacs Git repository, or maybe another big Git repository,
00:40:44.880 --> 00:40:49.079
like you could have an Elisp function enumerate those, and
00:40:49.080 --> 00:40:52.599
multiply some numbers, maybe multiply 10 numbers
00:40:52.600 --> 00:41:01.039
together. And that isn't that slow. And that's the bulk of
00:41:01.040 --> 00:41:05.799
what the only thing that Elisp has to do is just like multiply
00:41:05.800 --> 00:41:11.599
these numbers. Obviously, if you have to resort to Elisp to
00:41:11.600 --> 00:41:15.519
search all the files and you have like 10 or 100,000 files,
00:41:15.520 --> 00:41:18.759
then yeah, Emacs will be slow
00:41:18.760 --> 00:41:23.959
to manually search, like if you're not using ripgrep or any
00:41:23.960 --> 00:41:26.839
faster tool and you have, and you have millions of files and
00:41:26.840 --> 00:41:30.959
yeah, it will be slow. But what I noticed though is like, for
00:41:30.960 --> 00:41:35.119
example, let's say you want to search for, let's say you want
00:41:35.120 --> 00:41:40.199
to search like info directory, like info files for Emacs and
00:41:40.200 --> 00:41:46.039
the Emacs info file and the Elisp info file. So those are two
00:41:46.040 --> 00:41:49.279
decently sized kind of books, kind of like reference
00:41:49.280 --> 00:41:50.199
material on Emacs.
00:41:50.200 --> 00:41:55.999
Relying on Elisp to search both of those together, it's
00:41:56.000 --> 00:41:58.079
actually pretty, it's actually like almost instant. I
00:41:58.080 --> 00:42:00.639
mean, it's not slow enough. So I think that's
00:42:00.640 --> 00:42:03.679
another thing is like scale. Like I think on, on kind of like
00:42:03.680 --> 00:42:09.679
individual human level scales, I think Elisp can be good
00:42:09.680 --> 00:42:14.359
enough. if you're going on the scale of like enterprise,
00:42:14.360 --> 00:42:18.399
like all the repositories, all the Git repositories of an
00:42:18.400 --> 00:42:21.199
enterprise, then yeah, that scale might, it might, it might
00:42:21.200 --> 00:42:26.039
be too much. But I think on, on the scale of what most
00:42:26.040 --> 00:42:30.519
individuals have to deal with on a daily basis, like for
00:42:30.520 --> 00:42:34.719
example, maybe somebody has some, yeah, I mean, I think it
00:42:34.720 --> 00:42:36.959
should, I think it hopefully should be enough. And if not,
00:42:36.960 --> 00:42:39.639
there's always room for optimizations.
00:42:39.640 --> 00:42:55.999
Yeah, so so I'll redirect you a little bit because based on a
00:42:56.000 --> 00:43:00.279
couple of things I got into, you know, or if you want to be done
00:43:00.280 --> 00:43:04.759
be like, you know, give me the hi sign by all means and we can
00:43:04.760 --> 00:43:08.639
we can shut up shop, but I'm curious, you know, what are what
NOTE Boundary conditions
00:43:08.640 --> 00:43:13.079
are your boundary conditions? What what tends to cause you
00:43:13.080 --> 00:43:16.679
to to to write something more complicated and what what
00:43:16.680 --> 00:43:20.959
causes you to? So to work around it with more complex
00:43:20.960 --> 00:43:23.559
workflow in Emacs terms, like where do you break out the big
00:43:23.560 --> 00:43:27.919
guns? Just thinking about, like search, we talked about,
00:43:27.920 --> 00:43:31.439
maybe that's too abstract a question, but just general
00:43:31.440 --> 00:43:36.679
usage. Search is an example where almost all of us have
00:43:36.680 --> 00:43:39.599
probably written something to go find something, right?
00:43:39.600 --> 00:43:43.519
Yeah, I mean, this is a good question. I'm actually of the
00:43:43.520 --> 00:43:51.999
idea, at my work, for example, I tried to get rid of all, I
00:43:52.000 --> 00:43:54.879
mean, this is probably a typical Emacs user thing, but like,
00:43:54.880 --> 00:43:59.319
I mean, I think that just like getting, just like having
00:43:59.320 --> 00:44:02.559
Emacs expand to whatever it can get into and whatever it can
00:44:02.560 --> 00:44:08.839
automate, like any task, any, like, just like the more you
00:44:08.840 --> 00:44:13.719
can kind of get that coded, I actually find that kind of like,
00:44:13.720 --> 00:44:20.439
I mean, it is kind of like a meme. Like, yeah, I have to
00:44:20.440 --> 00:44:24.199
configure my Emacs until it's fun, and then I'll do it. But I
00:44:24.200 --> 00:44:27.959
actually I actually think that maybe for like a normal
00:44:27.960 --> 00:44:31.999
software developer, if you invest, if you invest, maybe,
00:44:32.000 --> 00:44:34.839
maybe you have like some spare time after you've done all
00:44:34.840 --> 00:44:39.679
your tasks, if you invest all that time in, in just like kind
00:44:39.680 --> 00:44:42.359
of going through all the workflows, all the, you know, just,
00:44:42.360 --> 00:44:46.279
just getting all of that in, in Emacs, then I think that that,
00:44:46.280 --> 00:44:52.039
that acts as kind of like a, it kind of like a productivity
00:44:52.040 --> 00:44:56.759
multiplier. And so. So I found that, I mean, I found to not
00:44:56.760 --> 00:44:59.519
have those boundaries. I mean, obviously there's things
00:44:59.520 --> 00:45:04.599
you can't do, like web-based things. I mean, that's a hard
00:45:04.600 --> 00:45:10.199
boundary, but that's more because... Yeah, there's really
00:45:10.200 --> 00:45:13.719
not much to do about that. Nobody's written a front-end
00:45:13.720 --> 00:45:18.759
engine, and too much of the forebrain is occupied with
00:45:18.760 --> 00:45:22.559
things that should happen on the "end-users
00:45:22.560 --> 00:45:29.839
infrastructure", so to speak. So with like 40 seconds left, I
00:45:29.840 --> 00:45:33.519
was going to say a minute, but I guess, any final thoughts?
00:45:33.520 --> 00:45:40.159
Yeah, I mean, just thank you for listening, and And thank you
00:45:40.160 --> 00:45:45.559
for putting this on. It's a really nice conference to have,
00:45:45.560 --> 00:45:50.679
and I'm glad things like this exist. So thank you. Yeah, it's
00:45:50.680 --> 00:45:54.639
you and the other folks on this call. Thank you so much,
00:45:54.640 --> 00:45:58.639
PlasmaStrike, and all the rest of you for hopping on the BBB
00:45:58.640 --> 00:46:03.119
and having such an interesting discussion. Keeps it really
00:46:03.120 --> 00:46:08.239
fun for us as organizers. And thanks, everybody, for being
00:46:08.240 --> 00:46:21.320
here.
