starting the recording here in the chat, and I see some
questions already coming in. So thank you so much for your
talk, Zach, and I'll step out of your way and let you field
some of these questions.
Sounds good. All right, so let's see. I'm going off of the
question list. So the first one is about having reduced
version of the functionality integrated into iSearch. So
yeah, with the way things are set up, it is essentially a
framework. So
you can create a candidate. So just a review from the talk. So
you have these candidate generators which generate search
candidates. So you can have a file system candidate which
generates these file documents, which have text content in
them. In theory, you could have like a website candidate
generator, and it could be like a web crawler. I mean, so
there's a lot of different options. So one option, it's on my
mind, and I hope to get to this soon, is create a defund, like a
defund candidate generator. So basically it takes a file,
splits it up into like defunds, kind of like just like what
iSearch would do. and then use each of those, the body of
those, as a content for the search session. So, I mean,
essentially you could just, you could start up a session,
and there's like programmatic ways to start these up too. So
you could, if such a candidate generator was created, you
could easily, and just like, you know, one command. Get the
defunds, create a search session with it, and then just go
straight to your query. So, definitely, that's something
just like this. is in the works. And I guess another thing is
interface.
The whole dedicated buffer is helpful for searching, but
with this iSearch case, there's currently not a way to have a
reduced UI, where it's just like, OK, I have these function
defunds for the current file. I just want them to pop up at the
bottom so I can quickly go through it. So currently, I don't
have that. But such a UI is definitely, yeah, thinking about
how that could be done.
Alright, so yeah. So next question. Andy, how we how this
will work with personal information like subtle casting.
So this is, this is like, I mean, it's essentially usable as
is with subtle casting method. So, I mean, that I mean
basically what like for example org-roam and I think other
ones like denote they have they put all these files in the
directory and so with the already existing file system
candidate generator all you'd have to do is set that to be the
directory of your Zettelkasten system and then it would
just pick up, it would just pick up all the files in there and
then add those as search candidates. So you could easily
just search your, I mean, whatever system you have. And
based off of the ways it's set up, if you had maybe your
dailies you didn't want to search, it's just as easy to add a
criteria saying, I don't want dailies to be searched. Like
give, like just eliminate the date, like the things from the
daily from the sub directory. And then there you go. you have
your Zettelkasten search engine, and you could just copy
the, you know, there's, I mean, I need, I'm working on
documentation for this to kind of set this up easily, but,
you know, you could just create your simple command, just
like, your simple command, just like, just take in a text
query, run it through the system, and then just get your
search results right there. So yeah, definitely that is a
use case that's on top of my mind. So next one, how good does a
search work for synonyms, especially if you use different
languages? Okay, this is a good question because with the
way that VM25 works, it's essentially just like trying to
find where terms occur and just counts them up.
I mean, this is something I couldn't get into. There's just
too much on the topic of information retrieval to kind of go
into this, but there is a whole kind of field of just like, how
do you, given a search term, how do you know what you should
search for? So like popular kind of industrial search
engines, like they have kind of this feature where you can
like define synonyms, define, term replacement. So
whenever you see this term, it should be this. And it even
gets even further. If someone searches for a plural string,
how do you get the singular from that and search for that? So
this is a huge topic that currently Psearch doesn't
address, but it's on the top of my mind as to how. So that's one
part. The next part is or different languages, one thing
that kind of seems like it's promising is vector search,
which, I mean, with the way psearch is set up, you could
easily just create a vector search prior, plug it into the
system, and start using it. The only problem is that kind of
the vector search functions, like you have to do like cosine
similarity, like if you have like 10,000 documents, If
you're writing elisp to calculate the cosine similarity
between the vectors, that's going to be very slow. And so now
the whole can of worms of indexing comes up. And how do you do
that? And is that going to be native elisp? And so that's a
whole other can of worms. So yeah, vector search seems
promising. And then hopefully maybe other traditional
synonyms, stemming, that kind of stuff for alternate
terms, that could also be incorporated.
Okay, next one. When searching by author, I know authors may
set up a new machine and not put the exact same information.
Is this doing anything to combine these two in one author?
Okay, so for this one, it's not. So it's like the way the get
prior is currently set up is that it just does like a get
command to get all the get authors. You select one and then it
just uses that. But the thing is, is if you knew the two emails
that user might have used, the two usernames, you could just
set up the
two priors. One for the old user's email, and then just add
another prior for the new user's email. And then that would
be a way to just get both of those set up. So that's kind of a
running theme throughout Psearch is that It's made to be
very flexible and very kind of like Lego block ish kind of
like you can just, you know, if you need, you know, if
something doesn't meet your needs, you know, it's easy to
put pieces in, create new, new, new components of the search
engine. Let's see, the cool powerful grab rack to maybe have
some good ideas. I have searches record code while
searching. Okay. So. Okay, that's interesting. I'll have
to look into this
tool. I haven't seen that. I do kind of keep my eyes out for
these kind of things. One thing I have seen that was kind of
that, I mean, looked interesting was kind of like AST, like
the TreeSitter, the TreeSitter grep tools. But like, you
can grep for a string in the language itself. So that's
something I think would be cool to implement either,
because I mean, there's TreeSitter in Emacs, so it's
possible to do a new list. If not, there are those kind of like
TreeSitter So that's, that's something that I think would
be cool to incorporate.
Let's see. Have you thought about integrating results from
using cosine similarity with a deep learning based vector
embedding? Yeah, exactly. So yeah, this kind of goes back to
the topic before it. Definitely the whole semantic search
with vector embeddings, that's something that, I mean, it
would be actually kind of trivial to implement that in
psearch. But like I said, computing the cosine similarity
in elisp, it's probably too slow.
And then also there's a whole question of how do you get the
embeddings?
like, how do you get the system running locally on your
machine if you want to run it that or, I mean, so that's
actually another kind of aspect that I need to look into.
Okay, so let's see.
Okay, next question. Let's see. I'm sorry to talk about my
cover. Is it possible to say bookmark searches or search
templates so they can be used again and again? Exactly. So
just recently I added bookmarking capabilities. So you can
essentially just bookmark whatever search session you
have. And yeah, and it's just, it was just a bookmark. You can
just open and just like reopen that, rerun that search from
where you left off. So there's that. And then also, I tried to
set this up so that there is a one-to-one mapping of a Lisp
object to the search session. So from every search session
you make, you should be able to get a, there's a command to do
this, to get a data representation of the search. So it would
just be like some plist. All you have to do is just take that
plist, call this function psearch setup buffer with that
data. And then that function should set up the session as you
left off. So then like, you know, you could make your
commands easy. You can make custom search commands super
easy. You just get the data representation of that search,
find what pieces you want the user to be able to, you know, the
search term, make that a parameter in the command the
interactive, in the interactive code. So you'd have like
print on top and then there you go. You have, you have a
command to do the search just like just right there. So, so
there's a lot of those things and there's a lot more that
could be done. Like maybe having, you know, there's kind of
in the works and like thinking about having groups of groups
of these things, like maybe you can set up like, Oh, I always
add these three criteria together. So I, you know, maybe I
can make a preset out of these and make them easy, easily
addable. So yeah. A lot of things like that are, you know, I'm
thinking about a lot of things about that, so.
Okay, so next question. You mentioned about candidate
generators. Could you explain about what the score is
assigned to? Is this to a line or whatever the candidate
generates? How does it work with our junior demo? Okay,
yeah, so this is a, this is, so actually I had to implement, I
had to rewrite psearch just to get this part right. So the
candidate generator generates documents. Documents have
properties. So the most notable property is the content
property. So essentially what happens is that when you
create a file system candidate generator and give it a
directory, the code goes into the directory, kind of
recursively goes through all the directories, and
generates a candidate, which is just like a simple list
form. It's saying, this is a file, the file path is this. So
that's the document ID. So this is saying, this is a file,
it's a file, and its file path is this. And so from that, you
get all of the different properties, the sub properties. If
you're given that, you know how to get the content. If you're
given that, you know how to... So all these properties come
out. And then also the candidate generator is the thing that
knows how best to search for the terms. So for example, there
is a buffer candidate generator. What that does is it just
puts all your buffers as search candidates. So obviously
you can't you can't run rip grip on buffers like you can't you
can't do that you can't run rip grip on just like yeah just
just like buffers that don't have files attached or, for
example, maybe there's like an internet search. candidate
generator, like a web crawler thing. You just imagine it
goes to a website, kind of crawls all the links and all that,
and then just gets your web pages for the candidates.
Obviously, you can't use ripgrep for that either. So, every
candidate generator knows how best to search for the terms
of what candidate it's generating. So, the file system
candidate generator will say, okay, I have a base
directory, So, if you ask me, the file system candidate
generator, how to get the terms, it knows it's set up to use
rip prep. And so, it runs rip prep, and so then it goes
through, it runs the command, gets the counts, and then
store those counts. So, the lines have nothing. At this
point, the lines have nothing. There's no notion of lines at
all. It's just document, document ID with the amount of
times it matched. And that's all you need to run this BM25
algorithm. But then when you get the top results, you
obviously want to see the lines that matched. And so there's
another thing, another method to kind of get the exact
thing, to kind of match out the particular lines. And so
that's a separate mechanism. And that can be done in Elist,
because if you're not displaying, that's kind of a design
decision of Psearch, is that it only displays like maybe 10
or 20. It doesn't display all the results. So you can have
Elist just go crazy with just like highlighting things,
picking the best kind of pieces to show. So yeah, that's how
that's set up.
So, here's perhaps a good moment for me to just jump in and
comment that in a minute or so we will break away with the live
stream to give people an hour of less content to make sure
everybody goes and takes their lunch and break a little bit.
But if you would like to keep going in here, Love to love to
take as many questions. And, of course, the will include
that all when we publish the Q and a. Sounds good. Yeah, I go.
And stick around on the stream as we cut away, as we've got a
little video surprise we've all prepared to play, just some
comments from an Emacs user dated in 2020 or something like
this. I forget the detail. Thank you again so much, Zach, for
your fascinating talk.
Yeah, so, okay. This makes me really think about the
emergent workflows with Denote and easy filtering with
Wordless.
Did this or something like this help influence the design of
Psearch? Yeah, exactly. So, I mean, yeah, I mean, there's
just so many different searches. Like, it's just kind of
mind boggling. Like, you could search for whatever you want
on your computer. Like, there's just so much, like, you
can't, yeah, you can't just like, you can't just like hard
code any of these things. It's all malleable. Like maybe
somebody wants to search these directories. And so, yeah,
like
exactly like that use case of having a directory of files
where
they contain your personal knowledge management system.
Yeah, that use case definitely was at the top of my mind.
Let's see.
Let's see, so Git covers the multiple names thing itself.
Okay, yeah,
so something about not much with Psearch UI. Actually,
interestingly, I think not much is, I haven't used it
myself, but that's the, email something about yeah so i mean
this is like these things are just like these these kind of
extensions could kind of go go forever but one thing i
thought about is like i use um you for e for email and that uses
a full-fledged index. And so having
some method to kind of reach into these different systems
and kind of be kind of like a front end for this. Another thing
is maybe SQL database. You can create a candidate generator
from a SQLite query and then Yeah,
I've had tons of ideas of different things you could
incorporate into the system. Slowly,
they're being implemented. Just recently, I implemented
an info file candidate generator. So it lists out all the
info files, and then it creates a candidate for each of the
info nodes. So it turns out, yeah, I mean, it works pretty, I
mean, just as well as Google. So I'm up for my own testing.
Let's see, you can search a buffer using ripgrep feeding in
as standard in to the ripgrep process, can't you? Yep, yeah,
you can definitely search a buffer that way. So, yeah, I
mean, based off of I mean, if this, yeah, so one thing that
came up is that the system wants, I mean, I wanted the system
to be able to search a lot of different things. And so it came
up that I had, you know, implementing,
doing these search things, having an Elist
implementation, despite it being slow, would be
necessary. So like anything that isn't represented as a
file, Elist, there's a mechanism in Psearch to search for
it.
So, yeah, so having that redundancy kind of lets you get into
the, you know, using kind of RipGrep for the big scale
things. But then when you get to the individual file, you
know, just going back to Eliffs to kind of get the finer
details seems to, you know, seems to end up working pretty
well.
Thank you all for listening. Yeah, sounds like we're about
out of questions. Hi, Zack. I have a question or still a
question. I just want to thank everybody one more time for
their participation, especially you for speaking, Zack. I
look forward to playing with P-Search myself. Thank you.
Yeah, there might be one last question. Is there someone?
Yes, there is. I don't know if you can understand me, but
thank you for making this lovely thing
I feel inspired to try it out and I'm thinking about how to
integrate it because it sounds modular and nicely thought
out. One small question. Have you thought about Project L
integration? And then I have a little bigger question about
the interface.
Yeah, Project L integration, it's used in a couple of ways.
It's kind of used to kind of as like kind of like a default.
This is the directory I want to search for the default
psearch command. It does, yeah, it kind of goes off of
Project L. If there is a project, it kind of says, okay, this,
I want to search this project. And so it kind of, it used that
as a default. So there's that. Because I use the project grab
or get grab search a lot and maybe this is a better solution to
the search and the interface you have right now for the
search results. How happy are you with it and have you
thought about improving or have you ideas for
improvements? Yeah, well actually what you see in the demo
in the video isn't there's actually there is is an
improvement in the current code. And so basically what it
does is it it scans there's the current default as it scans
the entire file for all of the searches and it finds the it
finds the window that that has the highest score. So it kind
of goes through entire file and just says And it kind of finds
like the piece of the section of text that has the most
matches with the terms that score the best. So it's, I mean,
that section is pretty good. I mean, that, so yeah, that,
that ends up working pretty well. So I mean, in terms of other
UI stuff, there's, there's tons, there's tons more that
could be done, like, especially like debug ability or like
introspection. Like, so this, this result, like, for
example, this result ranks really high. Maybe you don't
know why though. It's like. Because of this, this text query
arrow, was it because of this criteria? So there's, I think
there's some UI elements that could kind of help the user
understand why results are scoring high or low. So that's
definitely. And that makes a lot of sense to me. You know, a
lot of it is demystifying, like understanding what you're
learning better and not just finding the right thing. A lot
of it is, you know, kind of exploring your data. I love that.
Thanks. Okay. I'm not trying to hurry us through either by
any stretch. I would be happy to see this be a conversation. I
also want to be considerate of your time. And I also wanted to
make a quick shout out to everybody who's been updating and
helping us capture the questions and the comments and the
etherpad. That's just a big help to the extent that people
are jumping in there and you know, revising and extending
and just doing the best job we can to capture all the
thoughtful remarks.
Yeah, thank you, Zach. I'm not too sure what to ask anymore,
but yes, would love to try it out now. Yeah, I mean,
definitely feel free to, any feedback is my mail or issues
yeah i mean i'm happy to get any any feedback it's still it's
still in the early stages so still kind of a lot of
documentation that needs to be writing and so there's a lot
there's a lot on the roadmap but yeah i mean hopefully it
could even publish this to alpha and have a nice i have a nice
manual so yeah hopefully yeah those come soon epic that
sounds great yes
The ability to save your searches kind of reminds me of like
the GPT-L package for the AI, where you can save searches,
which makes it feel a lot more different. And yeah, we don't
have something for that with search, but yeah, that's a
whole different dynamic where it's like, okay, yeah. And
makes it a unique tool that is, I guess would be unique to
Emacs where you don't see that with like this AI package
where the GPTL is kind of unique because it's not just throw
away. It's how did I get this? How did I search for it? And be an
organic search, kind of like the orderless and vertical
and.
Yeah, that's a good, I mean, that brings me to another thing
in that, so,
I mean, you could easily, I could, I mean, there's, I mean,
you could create bridges from psearch to these different
other packages, like, for example, kind of a rag search,
like there's this rag, there's this thing called a rag
workflow, which is kind of popular these days. It's like
retrieval augmented generation. So, you do a search and
then based off the search results you get, then you pass
those into LLM. So, the cool thing is that like you could use
psearch for the retrieval. And so you could even like, I
mean, you could even ask an LM to come up with the search terms
and then have it search. And then there's no like
programmatical interface now to do this exact workflow.
But I mean, there's another kind of direction I'm starting
to think about. So like you could have, yeah, like maybe like
a question answer kind of workflow where it's like, it does
like an initial search for the terms and then you get the top
results and then you can put that through maybe GPTL or all
these other different systems. So that's, and that seems
like a promising thing. And then another thing is like,
well, you mentioned
like. The ability to save a search. One thing I've noticed
kind of like with the DevOps workflows is like I'll write a
CLI command that I do or like a calculator command. Then I end
up in the org mode document, write what I wrote, had the
results in there, and then I'll go back to that. It's like,
oh, this is why, this is that calculation I did and this is why
I did it. And I'll have like run the same tool three different
times to get three different answers. if it was like a
calculator, for example.
But yeah, that's a very unique feature that isn't seen and
will make me look at it and see about integrating it into my
workflow. Yeah, I think you get on some interesting, you
know, kind of what makes Emacs really unique there and how
to, you know, interesting, you know, kind of ways to exploit
Emacs to learn in the problem. So like, I'm seeing a number of
ways you're getting at that. For example, if I think about
like an automation workflow, and there's just a million
we'll say, assumptions that are baked into a search
product, so to speak, like represented by a Google search or
Bing or what have you. And then as I unpack that and repack it
from an Emacs workflow standpoint, thinking about, well,
first of all, what is the yak I'm shaving? And then also, what
does doing it right mean? How would I reuse this? How would I
make the code accessible to others for their own purposes in
a free software world kind of way? and all of the different
sort of say like orthogonal headspacey kind of things,
right? Emacs brings a lot to the table from a search
standpoint because I'm going to want to think about. I'm
going to want to think about where does the UI come in? Where
might the user want to get involved interactively? Where
might the user want to get involved declaratively with
their configuration, perhaps based on the particular
environment where this Emacs is running? And there's just a
lot of what Emacs users think about that really applies.
I'll use the word again, orthogonally across all my many
workflows as an Emacs user. You know, the search is just such
a big word. Yeah, that's actually, this exact point I was
thinking about with this. It's like, I mean, it seems kind of
obvious, like just like using rep or something, just like to
get search counts, like, okay, you can just run the command,
get the term counts and you could just run it through a
relatively simple algorithm. to get your search score. So
if it's this easy, though, why don't we see this in other? And
the results are actually surprisingly good. So why don't we
see this anywhere, really? And it occurred to me that just
the amount of configuration The amount of setup you have to
do to get it right. It's like above and it's, it's like an,
it's above this threshold that you need something like
Emacs to kind of get pushed through that configuration. So
like, for example, that's why I rely heavily on transient
set to set up the system. Cause like, if you want to get good
search results, you're going to have to like configure a lot
of stuff. Like I want this directory. I want this, I don't
want this directory. I want these search terms, you know,
there's a lot to set up. And in most programs, I mean, they
don't have an easy way to, I mean, they'll often try and try to
hide all this complexity. Like they say, okay, our users
too, you know, we don't wanna, you know, we don't wanna, you
know, make our users, we don't wanna scare our users with
like, complicated search engine configuration. So we're
just going to do it all in the background and we're just not
going to let the user even know that it's happening. I mean,
that's the third time you've made me laugh out loud. Sorry
for interrupting you, but yeah, you're just spot on there.
You're some people's users. Am I right? like, you know, and
also some people's workflows. And, you know, another case
where just like, if you're thinking about Emacs, you either
have to pick a tunnel to dive into and be like, no, this is
going to be right for my work, or your problem space is never
ending in terms of discovering the ways other people are
using Emacs and how that breaks your feature. and how that
breaks your conceptualization of the problem space,
right? Or you just have to get so narrowed down that can
actually be hard to find people that are quite understand
you, right? You get into the particular, well, it solves
these three problems for me. Well, what are these three
problems again? And this is a month to unpack. You have Emacs
and I don't know, it's like you got a lot of, they all agree is
like we're going to use elisp to set variables every emacs
package is going to do that we're going to use elisp and have a
search in place to put our documentation and like it does
also eliminate a lot of uh confusion and gives a lot of
expectations of what they want. One thing that I'm
surprised I haven't seen elsewhere is you have the consult
Omni package which allows you to search multiple websites
simultaneously for multiple web search engines. and put
them in one thing and it's like, and then you use orderless.
Why would you use orderless? Because that's what you
configured and you know exactly what you wanna use and you
use the same font and your same mini buffer and you use all
that existing configuration because, well, you're an
Emacs user or like you're a command line user. You know how
you want these applications to go. You don't want them to be
reinvented the wheel 1600 times in 1,600 different ways,
you want it to use your mini buffer, your font, your et
cetera, et cetera, et cetera. But I haven't
seen a website where I can search multiple websites at the
same time in something like Emacs before. And it's like,
yeah, with my sorting algorithm,
Yeah, exactly. Yeah. Yeah. Yeah. I mean, just setting the
bar for configuration and set up just like, yeah, you have to
have a list. Yeah. I mean, it, it does, obviously it's not,
it's not most beginner beginner friendly, but I mean, it,
yeah, it definitely widens the amount of the solution space
you can have to such problems. Oh my gosh, you used the word
solution space. I love it. But on the flip side, it's like,
why does Emacs get this consult Omni package? Or let's see,
you have L feed YouTube where it will put a flowing
transcript on a YouTube video or you got your package. Why
does it get all these applications? And I don't see
applications like this as much outside of Emacs. So there's
a way that it just makes it easier. It's because user
interface is the, you know, it's the economy stupid of
technology, right? If you grab people by the UX, you can sell
a million of any product that solves problem that I didn't
think technology could solve, or that I didn't think I had
the patience to use technology to solve, which is a lot of
times what it comes down to. And here exactly is the, you
know, the the EMAX sort of conundrum, right? How much time
should I spend today updating my EMAX so that tomorrow I can
just work more, right? And, you know, I love that little
graph of the EMAX learning curve, right? Where it's this
concentric, it becomes this concentric spiral, right? The
VIM learning curve is like a ladder, right? Or, you know, and
And the nano learning curve is like just a flat plane, you
know, or a ladder, a vertical ladder or a horizontal ladder.
There we go. And the Emacs learning curve is this kind of
straight up line until it curves back on itself and
eventually spirals. And the more you learn, the harder it is
to learn the next thing. And are you really moving forward at
all? Like, it just works for me. What a great analogy. And
that's my answer, I think. Yeah. You know, it's because
we... The spiral is great. Sorry. There are each of these
weird little packages that some of us, you know, it solves
that one problem and lets us get back to work. And for others,
it makes us go, gosh, now that makes me rethink a whole bunch
of things because there's... Like I don't even know what
you're talking about with some of your conceptualizations
of UI Maybe it comes from what's a visual studio and I've not
used that or something So for you, it's a perfectly normal UX
paradigm that you kind of lean on for others. It's like you
know occupying some screen space and I don't know what the
gadgets do and when I open them up they They're thinking
about you know they have the they imply their own
abstractions let's say logically against a programming
language this would be tree setter right if i'm not used to
thinking in terms of an abstract abstract syntax tree some
of the concepts just aren't as natural for me if i'm used to
like emacs at a more fundamental level is or the old modes
right we're used to them thinking in terms of Progressing
forward through some text, managing a stack of markers into
the text, right? It's a different paradigm. The world
changes. Emacs kind of supports it all. That's why all the
apps are built there. That's why when you're talking about
that spiral, what that hints at is that this is really just a
different algorithm that you're transferring out that
makes some things a lot easier and some things a lot harder.
That's why I was bringing in those three packages, because
in some way it's making these search terms with reusable
Let's see savable buffers or interactive buffers in a way
that it in a way that is Bigger than what I think it should have
especially in comparison to like how many people use
YouTube, but I don't see Very many YouTube apps that will
show Rolling subtitle list that you can click on to move up
and down the video even though YouTube's been around for
years and Why does Emacs have a very good implementation
that was duct taped together? So before I let you respond to
that, Zach, let me just say we're coming up on eating up a
whole half hour of your lunchtime and thank you for giving us
that extra time. But let me just say, let's, you know, if I
could ask you to take like up to another five minutes and then
I'll try to kick us off here and make sure everybody does
remember to eat.
Yeah, so yeah, it looks like there's one other question. So
yeah, do you think Emacs being kind of slow will get in the way
of being able to run a lot of scoring algorithms? So this is
actually a thought I had. Yeah, Emacs, because the code
currently kind of does, I mean, it kind of does, it's kind of
dumb in a lot of places. a lot of times it just, it does just go
through all the files and then just compute some score for
them. But I'm surprised that it's, that part actually isn't
that slow. Like, like it turns out like, okay, like if you
take, for example, Emacs, like the Emacs directory or the
Emacs Git repository, or maybe another big Git repository,
like you could have an elisp function enumerate those. and
multiply some numbers, maybe multiply 10 numbers
together. And that isn't that slow. And that's the bulk of
what the only thing that Elisp has to do is just like multiply
these numbers. Obviously, if you have to resort to Elisp to
search all the files and you have like 10 or 100,000 files,
then yeah, Emacs will be slow.
to manually search, like if you're not using rip prep or any
faster tool and you have, and you have millions of files and
yeah, it will be slow. But what I noticed though is like, for
example, let's say you want to search for, let's say you want
to search like info directory, like info files for Emacs and
the Emacs info file and the Elisp info file. So those are two
decently sized kind of books, kind of like reference
material on Emacs.
relying on Elisp to search both of those together, it's
actually pretty, it's actually like almost instant. I
mean, it's, it's, it's not slow enough. So I think that's
another thing is like scale. Like I think on, on kind of like
individual human level scales, I think Elisp can be good
enough. if you're going on the scale of like enterprise,
like all the repositories, all the Git repositories of an
enterprise, then yeah, that scale might, it might, it might
be too much. But I think on, on the scale of what most
individuals have to deal with on a daily basis, like for
example, maybe somebody has some, yeah, I mean, I think it
should, I think it hopefully should be enough. And if not,
there's always room for optimizations.
Yeah, so so I'll redirect you a little bit because I based on a
couple of things I got into, you know, or if you want to be done
be like, you know, give me the high sign by all means and we can
we can shut up shop, but I'm curious, you know, what are what
are your boundary conditions? What what tends to cause you
to to to write something more complicated and what what
causes you to? So to work around it with more complex
workflow in Emacs terms, like where do you break out the big
guns? Just thinking about, like search, we talked about,
maybe that's too abstract a question, but just general
usage. Search is an example where almost all of us have
probably written something to go find something, right?
Yeah, I mean, this is a good question. I'm actually of the
idea, at my work, for example, I tried to get rid of all, I
mean, this is probably a typical Emacs user thing, but like,
I mean, I think that just like getting, just like having
Emacs expand to whatever it can get into and whatever it can
automate, like any task, any, like, just like the more you
can kind of get that coded, I actually find that kind of like,
I mean, it is kind of like a meme. Like, yeah, I have to
configure my Emacs until it's fun, and then I'll do it. But I
actually I actually think that maybe for like a normal
software developer, if you invest, if you invest, maybe,
maybe you have like some spare time after you've done all
your tasks, if you invest all that time in, in just like kind
of going through all the workflows, all the, you know, just,
just getting all of that in, in Amex, then I think that that,
that acts as kind of like a, it kind of like a productivity
multiplier. And so. So I found that, I mean, I found to not
have those boundaries. I mean, obviously there's things
you can't do, like web-based things. I mean, that's a hard
boundary, but that's more because... Yeah, there's really
not much to do about that. Nobody's written a front-end
engine, and too much of the forebrain is occupied with
things that should happen on the quote-unquote end-users
infrastructure, so to speak. So with like 40 seconds left, I
was going to say a minute, but I guess, any final thoughts?
Yeah, I mean, just thank you for listening, and And thank you
for putting this on. It's a really nice conference to have,
and I'm glad things like this exist. So thank you. Yeah, it's
you and the other folks on this call. Thank you so much,
PlasmaStrike, and all the rest of you for hopping on the BBB
and having such an interesting discussion. Keeps it really
fun for us as organizers. And thanks, everybody, for being
here.