blob: 847dfac44faac9c2759819475714708c5f3fedc9 (
plain) (
tree)
|
|
WEBVTT
00:00:00.000 --> 00:00:02.399
at the end we are right on time so I'm
00:00:02.399 --> 00:00:03.760
sorry if you have a lot of questions
00:00:03.760 --> 00:00:04.319
before
00:00:04.319 --> 00:00:06.960
you had some so many questions and I
00:00:06.960 --> 00:00:08.559
couldn't answer all of them and I'm
00:00:08.559 --> 00:00:10.080
really happy about it but I'm also
00:00:10.080 --> 00:00:11.599
really sad that I don't have enough time
00:00:11.599 --> 00:00:12.719
to do so
00:00:12.719 --> 00:00:15.040
so I'm gonna try to do a better job this
00:00:15.040 --> 00:00:17.119
time of leaving you a little more time
00:00:17.119 --> 00:00:20.240
for the questions so just before
00:00:20.240 --> 00:00:22.960
a little addendum because I did screw up
00:00:22.960 --> 00:00:24.400
in the previous presentation
00:00:24.400 --> 00:00:27.439
you remember I tried to rename the file
00:00:27.439 --> 00:00:28.800
and it didn't work
00:00:28.800 --> 00:00:31.599
well it turns out uh I had two file name
00:00:31.599 --> 00:00:32.559
baz so
00:00:32.559 --> 00:00:34.480
my software works great thank you very
00:00:34.480 --> 00:00:36.000
much uh
00:00:36.000 --> 00:00:38.800
all right so now what I'm gonna do
00:00:38.800 --> 00:00:40.239
during this presentation
00:00:40.239 --> 00:00:43.040
is that I'm going to oops I didn't stop
00:00:43.040 --> 00:00:44.399
my timer just give me
00:00:44.399 --> 00:00:47.520
a little second and let's subtract
00:00:47.520 --> 00:00:50.719
one minute okay good so
00:00:50.719 --> 00:00:52.239
what I'm going to do right now it's a
00:00:52.239 --> 00:00:54.079
little different from the previous
00:00:54.079 --> 00:00:56.879
talk I've gave you and different even
00:00:56.879 --> 00:00:58.239
from what nura gave you
00:00:58.239 --> 00:01:00.480
there's like uh scaling the mountain as
00:01:00.480 --> 00:01:02.399
far as difficulty is concerned and on
00:01:02.399 --> 00:01:03.359
this one
00:01:03.359 --> 00:01:04.879
I will be telling you about the
00:01:04.879 --> 00:01:06.799
technical aspects of orgrim
00:01:06.799 --> 00:01:09.360
because you know I've been telling you
00:01:09.360 --> 00:01:11.119
about the general philosophy
00:01:11.119 --> 00:01:13.119
of the notes and the general philosophy
00:01:13.119 --> 00:01:14.560
of organization
00:01:14.560 --> 00:01:16.159
but right now I really want to get into
00:01:16.159 --> 00:01:18.479
the nitty gritty about or grow
00:01:18.479 --> 00:01:22.640
so if we go in the git repository
00:01:22.640 --> 00:01:25.759
this at the very core is all grown and
00:01:25.759 --> 00:01:27.920
for some of you who have no experience
00:01:27.920 --> 00:01:28.960
whatsoever
00:01:28.960 --> 00:01:31.280
uh developing stuff or programming or
00:01:31.280 --> 00:01:32.880
anything along those lines
00:01:32.880 --> 00:01:36.000
this is how all the development around
00:01:36.000 --> 00:01:36.720
the world
00:01:36.720 --> 00:01:40.000
is working you have a repository a
00:01:40.000 --> 00:01:42.159
git repository where you have all the
00:01:42.159 --> 00:01:44.399
files all the libraries you're using
00:01:44.399 --> 00:01:46.399
all the programs all the commands
00:01:46.399 --> 00:01:48.720
everything is inside your files
00:01:48.720 --> 00:01:52.240
and in a way this is the organ project
00:01:52.240 --> 00:01:53.759
you can see that we have many files we
00:01:53.759 --> 00:01:55.600
have organ buffer capture compat
00:01:55.600 --> 00:01:57.040
completion dailies
00:01:57.040 --> 00:02:00.399
etc etc so
00:02:00.399 --> 00:02:02.000
before we dive a little deeper I just
00:02:02.000 --> 00:02:04.079
want to give you a lay of the land so to
00:02:04.079 --> 00:02:04.640
speak to
00:02:04.640 --> 00:02:08.160
to know where we're heading so
00:02:08.160 --> 00:02:11.680
orgro is built on top of old mode
00:02:11.680 --> 00:02:15.599
and org mode gives us plenty of tools
00:02:15.599 --> 00:02:17.760
to play around with the files I'm moving
00:02:17.760 --> 00:02:18.800
the glass I'm
00:02:18.800 --> 00:02:20.080
I'm starting to move my hands a little
00:02:20.080 --> 00:02:21.360
bit you know when I get excited about
00:02:21.360 --> 00:02:22.959
something I move my hand
00:02:22.959 --> 00:02:26.640
and then that stuff happens so
00:02:26.640 --> 00:02:29.360
in all chrome we have org mode and
00:02:29.360 --> 00:02:31.360
augment gives us plenty of tools which
00:02:31.360 --> 00:02:33.360
are incredibly useful
00:02:33.360 --> 00:02:36.560
for writing stuff so you know we already
00:02:36.560 --> 00:02:37.440
have the links
00:02:37.440 --> 00:02:39.440
we already have the hierarchy which is
00:02:39.440 --> 00:02:40.560
given by having
00:02:40.560 --> 00:02:43.360
trees within trees within trees we have
00:02:43.360 --> 00:02:43.760
uh
00:02:43.760 --> 00:02:45.760
quote blocks we have babel blocks we
00:02:45.760 --> 00:02:48.000
have so much stuff we have an arsenal of
00:02:48.000 --> 00:02:49.680
tools that have been developed
00:02:49.680 --> 00:02:53.519
for the last 15 years and
00:02:53.519 --> 00:02:56.640
when you think about it all chrome just
00:02:56.640 --> 00:02:59.760
wants to create backlinks but it sounds
00:02:59.760 --> 00:03:01.360
something very simple but the problem is
00:03:01.360 --> 00:03:02.239
that we need
00:03:02.239 --> 00:03:05.519
to play nicely with all of those
00:03:05.519 --> 00:03:06.400
intricate
00:03:06.400 --> 00:03:09.360
pieces and the fact is it takes quite a
00:03:09.360 --> 00:03:10.879
lot of expertise to be able to do so
00:03:10.879 --> 00:03:11.440
because
00:03:11.440 --> 00:03:14.400
if right now we are in the brain of all
00:03:14.400 --> 00:03:15.200
grow
00:03:15.200 --> 00:03:18.959
but if I show you the brain of org mode
00:03:18.959 --> 00:03:21.599
so this is the brain of org mode and it
00:03:21.599 --> 00:03:23.280
looks very simple like this because I
00:03:23.280 --> 00:03:25.519
haven't entered the less folder
00:03:25.519 --> 00:03:28.000
but I'm just going to enter it I'm going
00:03:28.000 --> 00:03:29.120
to
00:03:29.120 --> 00:03:32.000
zoom out a little bit don't worry if you
00:03:32.000 --> 00:03:32.959
don't see everything
00:03:32.959 --> 00:03:35.519
but I just want you to get a fear the
00:03:35.519 --> 00:03:37.519
sheer feel of magnitude
00:03:37.519 --> 00:03:41.280
that is um org mode so right now we are
00:03:41.280 --> 00:03:42.640
in a very small size what I'm gonna do
00:03:42.640 --> 00:03:43.760
I'm going to skip
00:03:43.760 --> 00:03:47.519
one page okay one two
00:03:47.519 --> 00:03:51.040
three we have let's just check how many
00:03:51.040 --> 00:03:52.319
lines we have
00:03:52.319 --> 00:03:54.640
okay let me just revert to a fairly
00:03:54.640 --> 00:03:56.480
readable side
00:03:56.480 --> 00:03:58.560
at the bottom you can see that we have
00:03:58.560 --> 00:03:59.599
oh it's not showing because it's a
00:03:59.599 --> 00:04:00.959
little small okay I'm just going to
00:04:00.959 --> 00:04:03.840
resize the window a little bit
00:04:03.840 --> 00:04:06.959
it's not showing up give me a second I
00:04:06.959 --> 00:04:08.720
can't see how many lines I have okay so
00:04:08.720 --> 00:04:10.159
let's do it to get away
00:04:10.159 --> 00:04:11.840
I'm going to go back at the beginning of
00:04:11.840 --> 00:04:14.000
the buffer and we're going to count
00:04:14.000 --> 00:04:16.160
how many lines we have so the bottom in
00:04:16.160 --> 00:04:17.840
a midi buffer and the mini buffer is
00:04:17.840 --> 00:04:18.880
this area
00:04:18.880 --> 00:04:22.320
we have 377 lines
00:04:22.320 --> 00:04:25.919
which means 377
00:04:25.919 --> 00:04:29.759
libraries within org mode and mind you
00:04:29.759 --> 00:04:31.520
that's not counting all the modules that
00:04:31.520 --> 00:04:32.960
we have on the side which
00:04:32.960 --> 00:04:36.240
come on top of volt mode now when you
00:04:36.240 --> 00:04:37.360
try to think
00:04:37.360 --> 00:04:40.639
about something so elemental
00:04:40.639 --> 00:04:44.400
as links you have to think about how to
00:04:44.400 --> 00:04:45.520
play well
00:04:45.520 --> 00:04:48.560
with every single one of these modules
00:04:48.560 --> 00:04:50.000
now obviously not
00:04:50.000 --> 00:04:53.759
the 370 370. sometimes you know
00:04:53.759 --> 00:04:56.080
one module it's not going to do anything
00:04:56.080 --> 00:04:57.680
like I'm not sure op car could be doing
00:04:57.680 --> 00:04:58.639
anything with it
00:04:58.639 --> 00:05:00.080
but it's something that we have to keep
00:05:00.080 --> 00:05:03.039
in mind and so
00:05:03.039 --> 00:05:04.720
really early on when we started
00:05:04.720 --> 00:05:07.520
developing all grown with jethro kwan my
00:05:07.520 --> 00:05:10.080
co-maintainer you know we had this idea
00:05:10.080 --> 00:05:10.639
that
00:05:10.639 --> 00:05:13.520
we wanted to develop something that was
00:05:13.520 --> 00:05:14.639
optimized
00:05:14.639 --> 00:05:18.240
something that would you know scale very
00:05:18.240 --> 00:05:20.160
nicely whether or not you had
00:05:20.160 --> 00:05:21.600
you know something that would work as
00:05:21.600 --> 00:05:24.560
fast if you had 10 files
00:05:24.560 --> 00:05:27.680
or if you had 100 files or if you had
00:05:27.680 --> 00:05:30.880
10 000 files and maybe more so the
00:05:30.880 --> 00:05:32.080
problem when you do this
00:05:32.080 --> 00:05:34.400
and I'm doing some callbacks to the talk
00:05:34.400 --> 00:05:36.320
I gave you earlier today about
00:05:36.320 --> 00:05:41.280
few small few big files this is many
00:05:41.280 --> 00:05:44.800
I got confused few big files versus many
00:05:44.800 --> 00:05:45.919
small files
00:05:45.919 --> 00:05:49.280
the problem with this is that we need to
00:05:49.280 --> 00:05:51.600
think about optimization from the get go
00:05:51.600 --> 00:05:53.680
and so one of the decision we took when
00:05:53.680 --> 00:05:54.800
we got started
00:05:54.800 --> 00:05:59.199
with orgrum is that if I go in my
00:05:59.199 --> 00:06:02.479
test repository so that's the one in
00:06:02.479 --> 00:06:04.240
which we were right before
00:06:04.240 --> 00:06:08.000
we have a file which is called orgrumdb
00:06:08.000 --> 00:06:11.600
now if I open it it's not it's a
00:06:11.600 --> 00:06:14.160
little garbage because uh it's a binary
00:06:14.160 --> 00:06:15.120
but what we have
00:06:15.120 --> 00:06:18.560
is a database with which we communicate
00:06:18.560 --> 00:06:21.919
via sorry it's an sql database
00:06:21.919 --> 00:06:25.120
and what this allows us to do
00:06:25.120 --> 00:06:28.479
is we store all the information we need
00:06:28.479 --> 00:06:31.919
inside this sql database which allows us
00:06:31.919 --> 00:06:34.720
to speed up a lot of the operations that
00:06:34.720 --> 00:06:35.360
are
00:06:35.360 --> 00:06:37.840
necessary for the functioning of our
00:06:37.840 --> 00:06:38.479
ground
00:06:38.479 --> 00:06:40.240
so for instance if I go back to the
00:06:40.240 --> 00:06:41.759
index file that I had before
00:06:41.759 --> 00:06:43.440
let's just go back to who actually this
00:06:43.440 --> 00:06:45.680
way you'll see a little more on the side
00:06:45.680 --> 00:06:47.919
so you see that on the side we have
00:06:47.919 --> 00:06:48.720
whoops
00:06:48.720 --> 00:06:50.319
two links I'm not going to click on them
00:06:50.319 --> 00:06:51.759
otherwise I'm going to open them but we
00:06:51.759 --> 00:06:53.199
have two links
00:06:53.199 --> 00:06:56.319
now there are many implementations of
00:06:56.319 --> 00:06:58.240
the zettol casten method inside
00:06:58.240 --> 00:07:00.800
Emacs and inside and with old mode but
00:07:00.800 --> 00:07:02.400
what we've decided to do
00:07:02.400 --> 00:07:04.639
is that every time you have a link so if
00:07:04.639 --> 00:07:05.520
we go to
00:07:05.520 --> 00:07:08.479
the index again here at point we have
00:07:08.479 --> 00:07:09.120
the link
00:07:09.120 --> 00:07:12.400
foo every time we create a link we
00:07:12.400 --> 00:07:14.160
update our database
00:07:14.160 --> 00:07:16.800
to say okay so we have a link in the
00:07:16.800 --> 00:07:17.919
file
00:07:17.919 --> 00:07:21.080
index which is leading to the file
00:07:21.080 --> 00:07:24.319
fu.org and it is situated
00:07:24.319 --> 00:07:27.840
under the heading a heading and
00:07:27.840 --> 00:07:29.840
if you check the site buffer you see
00:07:29.840 --> 00:07:31.440
that all this all these information
00:07:31.440 --> 00:07:33.120
which I just highlighted to you
00:07:33.120 --> 00:07:42.639
are present right here
00:07:42.639 --> 00:07:45.599
oh well sorry I forgot this thank you
00:07:45.599 --> 00:07:46.400
okay
00:07:46.400 --> 00:07:50.879
so let's see log okay I'm going to split
00:07:50.879 --> 00:07:53.039
actually I'm going to split like this
00:07:53.039 --> 00:07:54.960
I'm going to go back there
00:07:54.960 --> 00:07:56.960
the problem is that I can't show my
00:07:56.960 --> 00:07:58.720
keystrokes at the same time as a machine
00:07:58.720 --> 00:08:02.080
I'm showing the site buffer so I'll
00:08:02.080 --> 00:08:03.599
keep it right now for your own
00:08:03.599 --> 00:08:05.199
discretion anyway getting back to the
00:08:05.199 --> 00:08:07.039
talk
00:08:07.039 --> 00:08:10.160
so the thing is we have this
00:08:10.160 --> 00:08:12.720
sql database and the goal is to keep it
00:08:12.720 --> 00:08:13.520
optimized
00:08:13.520 --> 00:08:16.400
now why is it better optimized than just
00:08:16.400 --> 00:08:17.039
using
00:08:17.039 --> 00:08:20.960
orgrom sorry just using default org mode
00:08:20.960 --> 00:08:23.520
so in my talk about many big files
00:08:23.520 --> 00:08:24.080
versus
00:08:24.080 --> 00:08:26.879
a few I keep getting you know you got
00:08:26.879 --> 00:08:28.080
what I was saying I'm not going to
00:08:28.080 --> 00:08:29.120
repeat it
00:08:29.120 --> 00:08:32.240
by the way it is uh 10 to 10.
00:08:32.240 --> 00:08:35.200
I'm starting really to be tired now so
00:08:35.200 --> 00:08:36.399
uh moving on to
00:08:36.399 --> 00:08:39.279
um what did I want to show you so it was
00:08:39.279 --> 00:08:40.800
almost yes all the elements
00:08:40.800 --> 00:08:44.959
so what I'm going to do I'm going to
00:08:44.959 --> 00:08:47.200
see I believe it's org element pass
00:08:47.200 --> 00:08:48.399
buffer
00:08:48.399 --> 00:08:51.040
so I was telling you about all elements
00:08:51.040 --> 00:08:51.920
before
00:08:51.920 --> 00:08:53.600
and the main command sorry the main
00:08:53.600 --> 00:08:55.760
function that is used by org element
00:08:55.760 --> 00:08:58.560
is pass buffer what it does and you can
00:08:58.560 --> 00:08:59.760
see the dock string is that it
00:08:59.760 --> 00:09:01.040
recursively passed
00:09:01.040 --> 00:09:03.279
the buffer and return structure
00:09:03.279 --> 00:09:04.959
structure being all the information that
00:09:04.959 --> 00:09:06.320
we have in this buffer
00:09:06.320 --> 00:09:07.680
so just to show you a little more we're
00:09:07.680 --> 00:09:09.600
going to move into a scratch buffer
00:09:09.600 --> 00:09:10.880
and what we're going to do is that we're
00:09:10.880 --> 00:09:12.800
going to write this command
00:09:12.800 --> 00:09:16.320
pass buffer and we're going to check the
00:09:16.320 --> 00:09:17.760
output of this command
00:09:17.760 --> 00:09:19.600
oh sorry not this one we're going to go
00:09:19.600 --> 00:09:22.000
in the index so the index file you have
00:09:22.000 --> 00:09:23.680
a title you have a heading you have a
00:09:23.680 --> 00:09:25.120
link etc etc
00:09:25.120 --> 00:09:26.880
so what I'm going to do I'm going to
00:09:26.880 --> 00:09:28.560
evaluate this text
00:09:28.560 --> 00:09:30.800
and now at the bottom in the midi buffer
00:09:30.800 --> 00:09:32.560
in the mini buffer sorry
00:09:32.560 --> 00:09:36.160
you see an ast an abstract
00:09:36.160 --> 00:09:37.600
obviously don't remember what the s
00:09:37.600 --> 00:09:39.839
stands for semantic
00:09:39.839 --> 00:09:42.720
huh interesting anyway a representation
00:09:42.720 --> 00:09:43.519
of the data
00:09:43.519 --> 00:09:45.279
in a way that is exploitable by a
00:09:45.279 --> 00:09:47.600
machine now what I'm going to do
00:09:47.600 --> 00:09:49.839
syntax thank you so what I'm going to do
00:09:49.839 --> 00:09:52.000
I'm going to paste it inside the buffer
00:09:52.000 --> 00:09:54.480
in a way that is humanly readable and
00:09:54.480 --> 00:09:56.399
you can see that we have plenty of
00:09:56.399 --> 00:09:58.800
information we have a section which
00:09:58.800 --> 00:10:00.560
starts at the char
00:10:00.560 --> 00:10:05.040
1 which ends at the character 45
00:10:05.040 --> 00:10:07.040
we have the content so he makes scratch
00:10:07.040 --> 00:10:08.240
oh actually no
00:10:08.240 --> 00:10:10.240
never mind I did something wrong I run
00:10:10.240 --> 00:10:11.279
it in the wrong buffer
00:10:11.279 --> 00:10:13.040
so actually what I'm going to do we're
00:10:13.040 --> 00:10:14.399
going to run this command
00:10:14.399 --> 00:10:17.519
with the selected window next
00:10:17.519 --> 00:10:21.120
window okay that's a bit of live
00:10:21.120 --> 00:10:23.760
elise writing for you right now okay so
00:10:23.760 --> 00:10:24.640
now if I
00:10:24.640 --> 00:10:26.240
evaluate this and paste the content of
00:10:26.240 --> 00:10:28.480
the buffer
00:10:28.480 --> 00:10:31.600
it is doing its bidding so now what we
00:10:31.600 --> 00:10:32.399
have
00:10:32.399 --> 00:10:34.959
we have a section we have the keyword
00:10:34.959 --> 00:10:36.720
title which you see right here you have
00:10:36.720 --> 00:10:38.160
the value
00:10:38.160 --> 00:10:39.920
if we scroll down a little bit we have a
00:10:39.920 --> 00:10:41.360
heading which is right here we have the
00:10:41.360 --> 00:10:42.480
contents
00:10:42.480 --> 00:10:44.800
which should be yes the content is not
00:10:44.800 --> 00:10:46.320
listed exactly here but you have a
00:10:46.320 --> 00:10:48.079
paragraph which is this
00:10:48.079 --> 00:10:50.640
and then you have a link etc etc it is
00:10:50.640 --> 00:10:51.200
all
00:10:51.200 --> 00:10:53.839
uh parenthesis if you're not used to
00:10:53.839 --> 00:10:54.640
e-list
00:10:54.640 --> 00:10:56.320
like right now I've selected only the
00:10:56.320 --> 00:10:58.640
content of the parenthesis link
00:10:58.640 --> 00:11:00.399
I can move like this etcetera etcetera
00:11:00.399 --> 00:11:01.680
I'm not it's not a needle
00:11:01.680 --> 00:11:03.760
lessons that I'm doing right now but
00:11:03.760 --> 00:11:05.279
basically
00:11:05.279 --> 00:11:08.399
if we were to use the default tooling of
00:11:08.399 --> 00:11:09.120
orgrom
00:11:09.120 --> 00:11:10.880
org mode sorry I keep getting too
00:11:10.880 --> 00:11:12.480
confused sorry for that
00:11:12.480 --> 00:11:14.240
uh it would be extremely slow to do what
00:11:14.240 --> 00:11:16.399
we're doing some people
00:11:16.399 --> 00:11:19.760
are doing so some implementations of the
00:11:19.760 --> 00:11:22.240
zettelkassen method inside Emacs have
00:11:22.240 --> 00:11:23.040
opted
00:11:23.040 --> 00:11:26.480
for this method but the problem is that
00:11:26.480 --> 00:11:27.360
we think
00:11:27.360 --> 00:11:30.160
that it scales poorly now some other
00:11:30.160 --> 00:11:30.560
people
00:11:30.560 --> 00:11:33.920
have decided to not do with a database
00:11:33.920 --> 00:11:35.600
and what they do is that they use a tool
00:11:35.600 --> 00:11:37.200
which is called rip grep
00:11:37.200 --> 00:11:38.800
you might know grep which is a tool that
00:11:38.800 --> 00:11:41.279
allows you to search
00:11:41.279 --> 00:11:43.440
a file the content of a file for a line
00:11:43.440 --> 00:11:46.560
so for instance if we open v term here
00:11:46.560 --> 00:11:49.680
uh let's see so I've opened the term I
00:11:49.680 --> 00:11:51.839
am in this repository what I'm going to
00:11:51.839 --> 00:11:54.399
do is that I'm going to
00:11:54.399 --> 00:11:58.000
load the content of the file uh
00:11:58.000 --> 00:12:00.480
how am I going to do this oh um I need
00:12:00.480 --> 00:12:02.480
to move to bash
00:12:02.480 --> 00:12:06.160
let's do crap
00:12:06.160 --> 00:12:08.000
for the line which links do we did we
00:12:08.000 --> 00:12:09.519
have grep foo
00:12:09.519 --> 00:12:11.600
inside the file is it three I can
00:12:11.600 --> 00:12:13.760
remember okay let's do this
00:12:13.760 --> 00:12:18.079
am I working no
00:12:18.079 --> 00:12:21.279
let's go for four why is it eight
00:12:21.279 --> 00:12:22.800
ah damn it oh you know what I'm just
00:12:22.800 --> 00:12:24.320
going to copy the name
00:12:24.320 --> 00:12:28.240
up there we go no
00:12:28.240 --> 00:12:33.680
ah problem with live presentation always
00:12:33.680 --> 00:12:34.800
you know what I'm struggling so I'm
00:12:34.800 --> 00:12:36.720
going to drop this point anyway
00:12:36.720 --> 00:12:38.560
so grep is a simple tool that allows you
00:12:38.560 --> 00:12:40.000
to search the content of a file but
00:12:40.000 --> 00:12:42.480
rig grep is a solution that is written
00:12:42.480 --> 00:12:44.160
in rust and which is supposed to be
00:12:44.160 --> 00:12:45.920
well not supposed which is far more
00:12:45.920 --> 00:12:48.880
capable now
00:12:48.880 --> 00:12:50.639
I'd like to talk to you about the future
00:12:50.639 --> 00:12:52.320
of orgrim right now I've told you about
00:12:52.320 --> 00:12:54.720
the general concept which is about using
00:12:54.720 --> 00:12:58.399
uh this sql database and about
00:12:58.399 --> 00:13:01.519
playing nicely with old mode but
00:13:01.519 --> 00:13:03.279
we think that there's something great
00:13:03.279 --> 00:13:05.200
that we can do about orgrim
00:13:05.200 --> 00:13:08.320
now I've been talking with the a lot of
00:13:08.320 --> 00:13:10.320
people who are behind org mode and you
00:13:10.320 --> 00:13:10.880
know
00:13:10.880 --> 00:13:14.000
they've told us do you think that
00:13:14.000 --> 00:13:16.880
orgrom could have something to bring to
00:13:16.880 --> 00:13:18.320
old mode let's say
00:13:18.320 --> 00:13:20.160
backlinks is there something that we
00:13:20.160 --> 00:13:21.600
could be doing to
00:13:21.600 --> 00:13:25.600
import backlinks into old mode and
00:13:25.600 --> 00:13:27.200
we thought about it with jethro and the
00:13:27.200 --> 00:13:29.200
problem is uh
00:13:29.200 --> 00:13:30.800
we've always tried to have an
00:13:30.800 --> 00:13:32.720
experimental ground a very
00:13:32.720 --> 00:13:35.360
uh can a very isolated portion of your
00:13:35.360 --> 00:13:36.320
system
00:13:36.320 --> 00:13:37.920
where we could track backlinks and
00:13:37.920 --> 00:13:40.320
that's why we use um
00:13:40.320 --> 00:13:42.320
a slipbox directory so that we only
00:13:42.320 --> 00:13:44.880
track backlinks in one specific place
00:13:44.880 --> 00:13:47.040
but now because there seems to be so
00:13:47.040 --> 00:13:48.639
much interest about the method and we
00:13:48.639 --> 00:13:50.079
have so much backing
00:13:50.079 --> 00:13:52.480
on uh you know on github we have like
00:13:52.480 --> 00:13:53.120
200
00:13:53.120 --> 00:13:56.399
2 600 stars which is mind-boggling to us
00:13:56.399 --> 00:13:59.760
because we have so much success but
00:13:59.760 --> 00:14:02.399
we have plenty of ideas about the future
00:14:02.399 --> 00:14:03.360
one of the key
00:14:03.360 --> 00:14:06.000
parts of development being the writing
00:14:06.000 --> 00:14:08.480
of an external parser for orgrim
00:14:08.480 --> 00:14:09.680
so I've been telling you about org
00:14:09.680 --> 00:14:11.839
element org elements runs
00:14:11.839 --> 00:14:15.279
inside Emacs but what if
00:14:15.279 --> 00:14:19.519
we wrote a background process
00:14:19.519 --> 00:14:23.600
that could read a file an augment file
00:14:23.600 --> 00:14:25.760
extract the same type of data that you
00:14:25.760 --> 00:14:27.440
see on your screen right now
00:14:27.440 --> 00:14:30.240
so that we could use to update a
00:14:30.240 --> 00:14:30.959
database
00:14:30.959 --> 00:14:33.279
so that we could use to compute the
00:14:33.279 --> 00:14:34.959
links so that we could use it
00:14:34.959 --> 00:14:37.360
to show you know orgrim server all the
00:14:37.360 --> 00:14:39.519
connections between your nodes
00:14:39.519 --> 00:14:41.360
now there is a path of improvement here
00:14:41.360 --> 00:14:44.320
that is extremely important to us
00:14:44.320 --> 00:14:47.360
but you know that's the technical aspect
00:14:47.360 --> 00:14:48.639
and I'm out of time I'm just going to
00:14:48.639 --> 00:14:50.079
take one more minute to finish on this
00:14:50.079 --> 00:14:51.360
point
00:14:51.360 --> 00:14:54.560
but we believe
00:14:54.560 --> 00:14:57.680
that orgrim has the potential to be a
00:14:57.680 --> 00:14:58.399
think tank
00:14:58.399 --> 00:15:00.639
in a way for org mode and the way we
00:15:00.639 --> 00:15:01.920
think about
00:15:01.920 --> 00:15:04.079
note-taking in general I've stressed a
00:15:04.079 --> 00:15:06.079
great deal in my first presentation
00:15:06.079 --> 00:15:10.240
sorry the one I did before neura that
00:15:10.240 --> 00:15:12.480
all chrome is really great as a way to
00:15:12.480 --> 00:15:14.639
think organically about knowledge
00:15:14.639 --> 00:15:17.600
and honestly we kind of want to put the
00:15:17.600 --> 00:15:19.279
theory into practice with orgrim
00:15:19.279 --> 00:15:22.079
we are holding something which has the
00:15:22.079 --> 00:15:23.440
potential to be
00:15:23.440 --> 00:15:25.120
a great factor of innovation for the
00:15:25.120 --> 00:15:27.279
future whether it be or org mode
00:15:27.279 --> 00:15:29.600
or even for software in general you know
00:15:29.600 --> 00:15:31.440
the way to think about
00:15:31.440 --> 00:15:34.880
build nodes of knowledge in a way
00:15:34.880 --> 00:15:37.440
and the way to represent all those ids
00:15:37.440 --> 00:15:38.240
with the graph
00:15:38.240 --> 00:15:40.560
the way to basically have a note-taking
00:15:40.560 --> 00:15:41.600
system that
00:15:41.600 --> 00:15:43.360
corresponds to the research that
00:15:43.360 --> 00:15:45.839
corresponds to the way you think
00:15:45.839 --> 00:15:49.120
so yeah I believe we are
00:15:49.120 --> 00:15:51.839
really excited about this and if you
00:15:51.839 --> 00:15:53.519
want to keep track of the development of
00:15:53.519 --> 00:15:55.360
all chrome
00:15:55.360 --> 00:15:57.600
I on my youtube channel which is already
00:15:57.600 --> 00:15:59.279
linked a little earlier
00:15:59.279 --> 00:16:02.639
inside this present inside the pad sorry
00:16:02.639 --> 00:16:04.240
I do have a youtube channel where I try
00:16:04.240 --> 00:16:06.079
to present novelties
00:16:06.079 --> 00:16:09.519
or the new stuff inside um orgrim
00:16:09.519 --> 00:16:11.519
but I also be recording videos about the
00:16:11.519 --> 00:16:13.360
technical aspects about the direction
00:16:13.360 --> 00:16:15.519
that we're taking with orgrim
00:16:15.519 --> 00:16:18.000
and if you want to talk with us we are
00:16:18.000 --> 00:16:18.560
always
00:16:18.560 --> 00:16:22.160
available either on isc channel orgrom
00:16:22.160 --> 00:16:23.680
I believe there's a dash between org and
00:16:23.680 --> 00:16:25.279
rome but also
00:16:25.279 --> 00:16:27.279
on the discourse and I'll be putting all
00:16:27.279 --> 00:16:29.440
the links inside the conversation
00:16:29.440 --> 00:16:31.199
and that's me done so thank you for
00:16:31.199 --> 00:16:32.880
listening and now I'll be taking
00:16:32.880 --> 00:16:34.560
three minutes of questions so as to be
00:16:34.560 --> 00:16:37.360
right on time
00:16:37.360 --> 00:16:39.920
mini thanks for your awesome talk leo
00:16:39.920 --> 00:16:41.120
thank you
00:16:41.120 --> 00:16:43.040
so I'm just refreshing the page and I'm
00:16:43.040 --> 00:16:44.959
going to scroll down to my
00:16:44.959 --> 00:16:49.600
talk if I can find the right section
00:16:49.600 --> 00:16:53.120
let me just scroll a little bit
00:16:53.120 --> 00:16:55.600
uh reproducible Emacs no I think it's
00:16:55.600 --> 00:16:57.120
slower
00:16:57.120 --> 00:16:59.279
god we have so many questions so at the
00:16:59.279 --> 00:17:00.639
same time I'm pissed because I can't
00:17:00.639 --> 00:17:01.120
find it
00:17:01.120 --> 00:17:02.639
but I'm really really impressed by the
00:17:02.639 --> 00:17:05.360
number of questions that we had oh yeah
00:17:05.360 --> 00:17:07.760
um which is about I think about line 600
00:17:07.760 --> 00:17:08.260
or so
00:17:08.260 --> 00:17:09.919
[Music]
00:17:09.919 --> 00:17:13.199
yes got it splendid
00:17:13.199 --> 00:17:16.400
so um the questions so why not run a
00:17:16.400 --> 00:17:18.160
background Emacs for passing instead of
00:17:18.160 --> 00:17:19.919
implementing a new parser
00:17:19.919 --> 00:17:22.559
so I believe we've had this question uh
00:17:22.559 --> 00:17:24.480
I was giving a similar talk
00:17:24.480 --> 00:17:27.600
earlier this week and this week
00:17:27.600 --> 00:17:31.679
I'm not french this week sorry and
00:17:31.679 --> 00:17:33.280
someone asked me this question and the
00:17:33.280 --> 00:17:35.679
thing is running a background Emacs
00:17:35.679 --> 00:17:38.320
process you know it sounds great
00:17:38.320 --> 00:17:40.400
but it's also very limited because all
00:17:40.400 --> 00:17:41.760
the problems we have
00:17:41.760 --> 00:17:45.520
about concurrency about threads in Emacs
00:17:45.520 --> 00:17:48.160
well yes we can forward all our calls to
00:17:48.160 --> 00:17:49.200
background Emacs
00:17:49.200 --> 00:17:51.760
just like uh you know when you export a
00:17:51.760 --> 00:17:52.240
file
00:17:52.240 --> 00:17:56.400
with uh um sorry
00:17:56.400 --> 00:17:57.840
I mean could you mute microphone when
00:17:57.840 --> 00:17:58.799
you're speaking it's a little hard for
00:17:58.799 --> 00:18:01.520
me to concentrate
00:18:01.520 --> 00:18:03.600
that's fine don't worry you are now uh
00:18:03.600 --> 00:18:04.640
so um
00:18:04.640 --> 00:18:06.960
dammit where was I I'm sorry the
00:18:06.960 --> 00:18:07.679
question yes
00:18:07.679 --> 00:18:09.280
so basically forwarding all the
00:18:09.280 --> 00:18:11.840
questions uh sorry all our queries to uh
00:18:11.840 --> 00:18:13.039
background Emacs
00:18:13.039 --> 00:18:16.000
that is what uh org export is doing like
00:18:16.000 --> 00:18:17.960
you have the ability to
00:18:17.960 --> 00:18:20.799
asynchronously export latex documents
00:18:20.799 --> 00:18:22.080
odt documents from
00:18:22.080 --> 00:18:24.480
org mode and it uses a very minimal
00:18:24.480 --> 00:18:26.000
version of Emacs to do that but the
00:18:26.000 --> 00:18:28.240
problem is that we think that it's not
00:18:28.240 --> 00:18:30.320
going to scale as well as a true
00:18:30.320 --> 00:18:33.039
genuine background process and since we
00:18:33.039 --> 00:18:34.480
have been talking a lot
00:18:34.480 --> 00:18:36.000
as far as the old mode development is
00:18:36.000 --> 00:18:38.160
concerned about
00:18:38.160 --> 00:18:40.640
writing a proper parser writing a proper
00:18:40.640 --> 00:18:41.760
documentation
00:18:41.760 --> 00:18:43.440
for the passing of old mode file and
00:18:43.440 --> 00:18:46.000
writing a proper document standard
00:18:46.000 --> 00:18:48.400
that says okay this is how the old mode
00:18:48.400 --> 00:18:50.000
format works you know to
00:18:50.000 --> 00:18:52.000
basically have a way to not fall into
00:18:52.000 --> 00:18:55.120
the traps of markdown which has many
00:18:55.120 --> 00:18:56.559
many standards
00:18:56.559 --> 00:18:58.480
we need to think about this and we
00:18:58.480 --> 00:19:00.000
believe that all grown has
00:19:00.000 --> 00:19:01.360
the ability to think about these
00:19:01.360 --> 00:19:03.120
questions and as a
00:19:03.120 --> 00:19:04.640
as a person I'm also really interested
00:19:04.640 --> 00:19:06.400
about this so
00:19:06.400 --> 00:19:07.840
I can take the question I mean so don't
00:19:07.840 --> 00:19:10.160
worry about feeding them to me so how
00:19:10.160 --> 00:19:11.760
often does the
00:19:11.760 --> 00:19:13.679
db index get updated in order to contain
00:19:13.679 --> 00:19:14.799
changes within the
00:19:14.799 --> 00:19:17.360
files so we have two ways either we
00:19:17.360 --> 00:19:19.440
update as soon as you save a file
00:19:19.440 --> 00:19:22.160
or we have a timer which is an idle
00:19:22.160 --> 00:19:23.600
timer which waits okay
00:19:23.600 --> 00:19:25.600
the user has not imputed inputted
00:19:25.600 --> 00:19:26.960
anything in the last
00:19:26.960 --> 00:19:29.360
five seconds so it's time to queue a
00:19:29.360 --> 00:19:30.080
database
00:19:30.080 --> 00:19:33.039
passing a rebuild of the data not a an
00:19:33.039 --> 00:19:33.919
incrementation
00:19:33.919 --> 00:19:37.120
of the database I should say so
00:19:37.120 --> 00:19:38.799
did you ever think of uh I believe I
00:19:38.799 --> 00:19:40.320
have one more one more minutes and then
00:19:40.320 --> 00:19:42.240
I'll hand it to the other folks
00:19:42.240 --> 00:19:43.440
do you ever think of opening up or
00:19:43.440 --> 00:19:45.440
designing the sqldb as a general all
00:19:45.440 --> 00:19:47.200
speed up tool outside of orgrom so that
00:19:47.200 --> 00:19:48.160
other libraries
00:19:48.160 --> 00:19:49.919
that do execute complex queries are able
00:19:49.919 --> 00:19:51.679
to use it well
00:19:51.679 --> 00:19:52.960
a lot of people have been working on
00:19:52.960 --> 00:19:54.640
this and I believe alpha papa has been
00:19:54.640 --> 00:19:56.480
thinking quite a lot about this you know
00:19:56.480 --> 00:19:57.679
all ql
00:19:57.679 --> 00:20:01.120
is the ql stands for language
00:20:01.120 --> 00:20:03.679
and I I can't remember now what's uh
00:20:03.679 --> 00:20:04.720
what's the backend
00:20:04.720 --> 00:20:08.080
is for all ql but the idea is relatively
00:20:08.080 --> 00:20:10.080
relatively the same you know it's about
00:20:10.080 --> 00:20:13.039
finding ways to optimize the way we
00:20:13.039 --> 00:20:14.880
store the data about an old mode file
00:20:14.880 --> 00:20:16.640
and how we retrieve it
00:20:16.640 --> 00:20:20.400
and sql for us seems to seem to be a
00:20:20.400 --> 00:20:22.159
good idea now obviously
00:20:22.159 --> 00:20:24.240
maybe we could do something about old
00:20:24.240 --> 00:20:26.080
mode but the problem is I think a
00:20:26.080 --> 00:20:27.360
background process
00:20:27.360 --> 00:20:30.799
is not necessarily um in
00:20:30.799 --> 00:20:32.960
the core mentality of old mode but it's
00:20:32.960 --> 00:20:34.000
definitely a
00:20:34.000 --> 00:20:36.080
something that we could suggest uh when
00:20:36.080 --> 00:20:37.679
we are a little more mature because well
00:20:37.679 --> 00:20:40.960
orgrom was started last february and so
00:20:40.960 --> 00:20:41.679
it's a fairly
00:20:41.679 --> 00:20:44.480
young project in a way so uh I see
00:20:44.480 --> 00:20:45.840
plenty more questions but
00:20:45.840 --> 00:20:48.400
I'm out of time folks so I'm not sure uh
00:20:48.400 --> 00:20:50.559
the other speaker is probably ready
00:20:50.559 --> 00:20:52.559
so what I'll do is I'll probably try to
00:20:52.559 --> 00:20:54.000
answer your questions when I get the
00:20:54.000 --> 00:20:55.360
time inside the pad
00:20:55.360 --> 00:20:58.960
but feel free to ping me on isc
00:20:58.960 --> 00:21:01.039
or on the different channels we have
00:21:01.039 --> 00:21:02.320
foreground and
00:21:02.320 --> 00:21:04.000
I answer them with you know as much
00:21:04.000 --> 00:21:05.520
energy as I can gather
00:21:05.520 --> 00:21:07.600
all right thank you so much you are now
00:21:07.600 --> 00:21:08.880
unmuted
00:21:08.880 --> 00:21:11.760
thank you again very much leo and that
00:21:11.760 --> 00:21:13.120
was me done for today so you'll see me
00:21:13.120 --> 00:21:14.000
at the end but I'm
00:21:14.000 --> 00:21:15.840
officially done and I am free of
00:21:15.840 --> 00:21:17.840
thoughts I can focus on
00:21:17.840 --> 00:21:22.640
sleeping probably awesome
00:21:22.640 --> 00:21:27.760
all right see you guys later bye bye
|
