WEBVTT
00:01.520 --> 00:04.400
Hello, my name is Stefan Monnier,
00:04.400 --> 00:06.799
and I'm going to talk to you about--
00:06.799 --> 00:08.240
well, I'm going to present a bit
00:08.240 --> 00:11.840
of the life of a janitor.
00:11.840 --> 00:14.050
So by and large, there's just
00:14.050 --> 00:16.299
nothing to see here,
00:16.299 --> 00:17.199
and that's probably
00:17.199 --> 00:18.240
not super interesting,
00:18.240 --> 00:19.920
but some of you might actually like to
00:19.920 --> 00:00:23.050
see how I work, so I figured why not.
00:25.359 --> 00:27.279
Usually what I do just doesn't make any
00:27.279 --> 00:00:29.920
any significant difference,
00:00:29.920 --> 00:00:32.160
and so I basically take existing code
00:00:32.160 --> 00:00:35.040
that's working, and I try to change it
00:00:35.040 --> 00:00:37.680
hopefully without breaking it too much
00:00:37.680 --> 00:00:40.079
and make it slightly more...
00:40.079 --> 00:42.719
you know, following some of the more
00:42.719 --> 00:44.640
modern style, let's say,
00:44.640 --> 00:00:46.719
and sometimes along the way,
00:00:46.719 --> 00:00:50.399
it actually fixes some bugs.
00:50.399 --> 00:00:51.983
More concretely, the kind of things
00:00:51.983 --> 00:00:54.079
that I do is basically activate
00:00:54.079 --> 00:00:54.480
lexical scoping--
00:54.480 --> 00:56.239
that's really my main goal usually--
00:56.239 --> 00:58.960
but also do things like convert
00:58.960 --> 00:01:00.719
from `cl` to `cl-lib`,
00:01:00.719 --> 00:01:01.440
sometimes I have to
01:01.440 --> 01:03.760
fix some compilation dependencies,
01:03.760 --> 01:07.280
I might convert from `defadvice` to `advice-add`,
01:07.280 --> 01:11.439
and many of the things--
01:11.439 --> 00:01:13.119
in terms of number of changes,
00:01:13.119 --> 00:01:14.000
most of them are actually
00:01:14.000 --> 00:01:16.560
changing `quote fun` to `hash quote fun`
00:01:16.560 --> 00:01:17.360
because I prefer it,
01:17.360 --> 00:01:19.920
but also it often helps me
00:01:19.920 --> 00:01:21.439
have a better understanding
00:01:21.439 --> 00:01:23.920
of which function is called where,
01:23.920 --> 01:26.799
and so the warnings I get from it
01:26.799 --> 01:28.799
sometimes help me. You look concretely...
01:28.799 --> 00:01:30.880
it's not nothing really clear;
00:01:30.880 --> 00:01:33.360
it's more in terms of helping me
00:01:33.360 --> 00:01:35.759
have a mental image
00:01:35.759 --> 00:01:39.439
of how the package works.
01:39.439 --> 01:42.880
So let's take a look.
01:42.880 --> 00:01:45.840
I'm going to start with
00:01:45.840 --> 00:01:46.799
the package `heap`,
00:01:46.799 --> 00:01:50.560
which I saw had a few weird things in it,
00:01:50.560 --> 00:01:53.680
so I'm going to compile it.
01:53.680 --> 01:55.600
That's basically the way the way I work,
01:55.600 --> 00:01:57.840
right. I take a package.
00:01:57.840 --> 00:02:00.479
I just pass it to the byte compiler.
00:02:00.479 --> 00:02:02.159
I do that by just having
02:02.159 --> 02:04.560
a clone of the whole
02:04.560 --> 00:02:06.799
GNU ELPA repository,
00:02:06.799 --> 00:02:10.000
and so that's why I built them.
02:10.000 --> 02:11.520
I use the build rules
02:11.520 --> 02:15.120
from the GNU ELPA repository.
02:15.120 --> 00:02:16.720
These build rules enforce--
00:02:16.720 --> 00:02:17.680
make sure that the files
00:02:17.680 --> 00:02:19.680
are compiled in a clean environment
00:02:19.680 --> 00:02:21.920
so you get fairly good warnings.
00:02:21.920 --> 00:02:23.680
If you look at the warnings you see here,
00:02:23.680 --> 00:02:24.720
there's a lot of things
00:02:24.720 --> 00:02:26.480
which are completely irrelevant,
00:02:26.480 --> 00:02:28.400
which are due to details
00:02:28.400 --> 00:02:30.319
of the way I have my Emacs set up
00:02:30.319 --> 00:02:31.599
and some of the local changes
00:02:31.599 --> 00:02:34.319
I had in it so, you know,
00:02:34.319 --> 00:02:35.280
there's no point
00:02:35.280 --> 00:02:37.920
paying too much attention to it,
02:37.920 --> 02:40.400
but here we have a first warning.
02:40.400 --> 02:42.959
We see that this is using `cl`,
02:42.959 --> 02:45.040
so we want to change this to `cl-lib`,
02:45.040 --> 00:02:46.879
but that also means
00:02:46.879 --> 00:02:48.400
that we may have a new dependency
00:02:48.400 --> 00:02:49.920
on the `cl-lib` package,
00:02:49.920 --> 00:02:51.120
so we have to go check
00:02:51.120 --> 00:02:52.000
the start of the file
00:02:52.000 --> 00:02:54.080
to see if it already declares
00:02:54.080 --> 00:02:56.800
some dependency, and we see it doesn't,
02:56.800 --> 00:03:00.640
not even on a on a recent-enough Emacs,
00:03:00.640 --> 00:03:02.325
so we have to add--
00:03:02.325 --> 00:03:05.360
sorry, that's not going very well...
03:05.360 --> 03:06.480
oh...
03:06.480 --> 03:08.560
okay, we're going to get there somewhere...
03:08.560 --> 03:13.200
somehow...
03:13.200 --> 03:18.020
oh, that still wasn't it, wow, okay--
03:20.480 --> 03:22.159
and along the way...
03:22.159 --> 00:03:24.159
Of course, since we converted to `cl-lib`,
00:03:24.159 --> 00:03:26.159
we have to update the uses
00:03:26.159 --> 00:03:29.840
so `defstruct` shouldn't be used anymore.
03:29.840 --> 03:31.599
We may want to reindent this
03:31.599 --> 03:36.000
to get something a bit cleaner.
03:37.040 --> 00:03:40.589
We have here a missing quote...
00:03:40.589 --> 00:03:41.920
hash, sorry.
03:41.920 --> 00:03:46.480
We have `decf`, so `decf` is here,
03:46.480 --> 00:03:48.000
and that needs to be replaced
00:03:48.000 --> 00:03:49.920
with `cl-decf`.
00:03:49.920 --> 00:03:51.120
Sometimes it's worth doing
00:03:51.120 --> 00:03:53.360
a search-and-replace.
00:03:53.360 --> 00:03:54.799
Here I see there's only two,
00:03:54.799 --> 00:03:57.760
so it's not worth the trouble;
03:57.760 --> 00:04:00.711
I just do it by hand, and that's it.
00:04:00.711 --> 00:04:02.000
Well, that was easy.
04:02.000 --> 04:05.000
So let's recompile, see what it says.
04:10.159 --> 04:12.959
Ah, this is clean. Perfect!
04:12.959 --> 04:15.000
Let's.. we can go see...
04:15.000 --> 04:17.280
There is another one I had.
04:17.280 --> 04:20.239
Was it `counsel`, I think. Yes.
04:20.239 --> 00:04:24.160
So also I saw some funny things
00:04:24.160 --> 00:04:24.320
going on here.
04:24.320 --> 00:04:26.479
So I'm going to do
00:04:26.479 --> 00:04:31.040
the same procedure as before:
00:04:31.040 --> 00:04:32.800
I just compile the file
00:04:32.800 --> 00:04:35.000
and look at the warnings.
04:38.000 --> 04:40.479
Oh, we have many more here.
04:40.479 --> 04:43.120
So let's see...
04:43.120 --> 00:04:46.504
Okay, so we have missing quotes--
00:04:46.504 --> 00:04:49.240
oh, hashes. They're not really missing;
04:49.240 --> 04:54.639
it's just a personal preference.
04:54.639 --> 04:57.440
Oh, here... here's an important one:
04:57.440 --> 04:59.280
so as you know,
04:59.280 --> 05:00.639
if you look at the top of the file,
05:00.639 --> 00:05:02.240
you see that here
00:05:02.240 --> 00:05:04.960
it says it's using lexical binding,
05:04.960 --> 05:07.120
yet it's not fully using lexical binding,
05:07.120 --> 00:05:08.960
because as we just saw,
00:05:08.960 --> 00:05:11.039
there's a call to the `eval` function
00:05:11.039 --> 00:05:11.680
with only one argument,
05:11.680 --> 05:13.280
which means the second argument is nil,
05:13.280 --> 05:16.880
which means that the expression read
05:16.880 --> 00:05:19.520
by `read` here is going to be evaluated
05:19.520 --> 00:05:22.160
using the old dialects,
00:05:22.160 --> 00:05:24.240
which is only dynamic scoping.
00:05:24.240 --> 00:05:25.680
So here I like to just change this
00:05:25.680 --> 00:05:26.800
to use lexical scoping,
05:26.800 --> 00:05:28.080
which in most cases
00:05:28.080 --> 00:05:29.680
just doesn't make any difference.
00:05:29.680 --> 00:05:30.870
It just makes me feel better.
05:35.919 --> 05:40.160
So there's lots of those hashes
05:40.160 --> 05:41.759
all over the place.
05:43.680 --> 05:45.680
It's not strictly necessary, as you know,
05:45.680 --> 05:51.500
but I'm just going to add them anyway.
05:52.479 --> 00:05:53.199
Here we see
00:05:53.199 --> 00:05:54.800
it's not going to warn me here
00:05:54.800 --> 00:05:55.759
because it doesn't know
00:05:55.759 --> 00:05:57.600
that `ivy-make-magic-action`
00:05:57.600 --> 00:05:58.400
takes a function,
00:05:58.400 --> 00:06:02.319
but it's a pretty good guess that it does.
06:12.319 --> 06:14.479
And here's some more.
06:14.479 --> 06:16.080
What else do we have?
06:16.080 --> 06:19.120
Is that all we have here?
06:19.120 --> 06:21.440
Well, looks like it. Oh, I see a few...
06:21.440 --> 06:27.680
a few more here...
06:27.680 --> 06:30.639
and one more.
06:30.639 --> 06:33.039
And oh, this is more interesting.
06:33.039 --> 06:35.280
So here we have a use of `defadvice`,
06:35.280 --> 06:37.440
so if we go back
06:37.440 --> 06:38.479
to the beginning of the file,
06:40.720 --> 06:42.880
we see that it actually depends
06:42.880 --> 00:06:47.360
on Emacs 24.5, so it actually has
06:47.360 --> 00:06:49.280
the new advice system available
00:06:49.280 --> 00:06:51.520
without having to add any dependency,
00:06:51.520 --> 00:06:53.599
so there's really no good reason
00:06:53.599 --> 00:06:54.880
to keep this.
06:54.880 --> 00:06:56.160
So we just convert this
00:06:56.160 --> 00:06:58.560
to an `advice-add`,
06:58.560 --> 00:06:59.840
so it just says, you know,
00:06:59.840 --> 00:07:02.319
this is the function that's advised.
07:02.319 --> 07:04.560
This was a `before` advice.
07:04.560 --> 07:05.500
The `before` advice, sometimes,
07:05.500 --> 07:08.479
when we convert it to `advice-add`,
07:08.479 --> 07:11.199
need to be converted to `around` advice.
07:11.199 --> 07:13.280
This is when the function
07:13.280 --> 07:15.840
looks or modifies the argument.
07:15.840 --> 07:18.639
In this case, if I look at it,
07:18.639 --> 07:20.319
I see it doesn't seem to be using
07:20.319 --> 07:21.280
the arguments at all.
07:21.280 --> 00:07:25.280
So I'm just going to keep it
00:07:25.280 --> 00:07:27.520
as a `before` advice.
07:27.520 --> 00:07:28.672
And we have to give it a name.
00:07:28.672 --> 00:07:30.880
Well, we don't really have to,
07:30.880 --> 07:32.800
but it's convenient to give it a name
07:32.800 --> 07:34.800
to the new function.
07:34.800 --> 00:07:36.880
So here, they actually had
00:07:36.880 --> 00:07:38.080
given a name to the advice,
00:07:38.080 --> 00:07:39.599
so we're going to keep it,
00:07:39.599 --> 00:07:41.440
and indeed it's the only function.
00:07:41.440 --> 00:07:43.360
This name is not used as a function,
00:07:43.360 --> 00:07:44.160
so we can use it
00:07:44.160 --> 00:07:46.960
as the name of the function.
07:46.960 --> 00:07:49.039
I'm going to add a dash here
00:07:49.039 --> 00:07:51.120
because I think this function
00:07:51.120 --> 00:07:53.039
is really fundamentally
00:07:53.039 --> 00:07:54.639
an internal function.
07:54.639 --> 07:56.720
So here I just said I add the advice,
07:56.720 --> 07:58.000
but I still need to actually
07:58.000 --> 07:59.800
define the function.
08:02.879 --> 00:08:04.160
So that's what I do here,
00:08:04.160 --> 00:08:06.500
and we need here to list the arguments
08:06.500 --> 08:08.240
that are going to be taken.
08:08.240 --> 00:08:09.199
I don't know what these are,
00:08:09.199 --> 00:08:10.960
but I know we're not using them,
00:08:10.960 --> 00:08:13.759
so we'll just accept anything,
08:13.759 --> 08:16.560
and that will do the trick.
08:16.560 --> 08:19.199
It's a future-proof as well,
08:19.199 --> 08:22.240
so that should work.
08:22.240 --> 00:08:24.160
Oh, here we have another, so it's
00:08:24.160 --> 00:08:29.919
basically the same story, I think.
08:29.919 --> 00:08:31.599
It's a `before` advice as well.
00:08:31.599 --> 00:08:32.959
It doesn't seem to be using
00:08:32.959 --> 00:08:35.599
the argument at all,
08:35.599 --> 00:08:38.596
and let's see if this name is not taken.
00:08:38.596 --> 00:08:43.360
Yeah, good, so we can just do the same:
08:43.360 --> 08:46.880
turn this into an `advice-add`...
08:46.880 --> 08:48.300
`before`...
08:53.040 --> 08:55.000
I just add a dash here.
09:02.480 --> 00:09:05.440
And same thing--
00:09:05.440 --> 00:09:06.959
a function that just takes...
09:06.959 --> 09:08.240
because I don't know which arguments
09:08.240 --> 09:10.480
these are so...
09:10.480 --> 09:14.640
I think that should do the trick.
09:14.640 --> 00:09:16.080
Actually, we see that this function
00:09:16.080 --> 00:09:18.560
is very similar to the other one.
09:18.560 --> 09:23.000
Let's look at the two side-by-side...
09:31.519 --> 00:09:33.055
...it really is--
00:09:33.055 --> 00:09:36.097
oh, it's not exactly identical...
00:09:36.097 --> 00:09:39.120
it's, you know, we could try
09:39.120 --> 09:41.680
to merge them into a single function,
09:41.680 --> 09:43.279
but it's probably not worth the trouble
09:43.279 --> 09:45.920
so we can keep it this way.
09:45.920 --> 09:48.720
Okay, next warning: an `eval` again,
09:48.720 --> 09:50.640
so I could just add `t` here,
09:50.640 --> 00:09:55.120
but if you look at it a bit more,
00:09:55.120 --> 00:09:56.000
you see that the code
00:09:56.000 --> 00:09:57.760
we're going to evaluate
09:57.760 --> 00:09:59.279
using either lexical scoping
00:09:59.279 --> 00:10:00.560
or dynamic scoping
00:10:00.560 --> 00:10:03.440
is actually just evaluating a symbol,
00:10:03.440 --> 00:10:06.240
since we just call an `intern` here.
10:06.240 --> 00:10:07.839
So instead of replacing this
00:10:07.839 --> 00:10:09.279
by adding an argument,
00:10:09.279 --> 00:10:11.680
I'm just going to call `symbol-value`
00:10:11.680 --> 00:10:12.640
because that's exactly
00:10:12.640 --> 00:10:14.480
what we need to do here, right.
00:10:14.480 --> 00:10:16.320
I call this "strength reduction,"
00:10:16.320 --> 00:10:17.200
and I'm using
00:10:17.200 --> 00:10:19.680
a more primitive function instead,
00:10:19.680 --> 00:10:23.200
which does just what we need,
10:23.200 --> 10:25.680
and this one knows that it has to be
10:25.680 --> 00:10:30.640
accessed by dynamic scoping, of course.
10:30.640 --> 00:10:32.959
Here I have a `kmacro-ring`,
00:10:32.959 --> 00:10:35.600
so here I have a function that uses--
10:35.600 --> 00:10:37.360
`kmacro-ring` comes from
00:10:37.360 --> 00:10:39.760
the `kmacro` package, obviously,
10:39.760 --> 10:41.600
and we probably don't want to
10:41.600 --> 10:42.959
`require` `kmacro` package
10:42.959 --> 00:10:48.560
all over the place in `counsel` itself,
10:48.560 --> 00:10:50.240
because `counsel` can be used
00:10:50.240 --> 00:10:53.279
without `kmacro`.
10:53.279 --> 00:10:55.200
So I think we're just going to add
00:10:55.200 --> 00:11:04.000
a `defvar` to silence the warning.
11:05.519 --> 00:11:10.720
And we have several more. So we have
11:10.720 --> 00:11:14.000
`initial-counter-value`. (Sorry.)
11:20.480 --> 11:23.360
We have `kmacro-counter`.
11:23.360 --> 11:25.760
Do we have more?
11:25.760 --> 11:28.560
Oh, yes, we do.
11:28.560 --> 11:35.040
We have `kmacro-counter-value-start`
11:35.040 --> 11:40.839
and `kmacro-counter-format-start`.
11:40.839 --> 11:43.920
Okay.
11:45.040 --> 11:50.160
I hope this is it.
11:50.160 --> 11:52.880
`kmacro-ring`, `counter`, `ring`...
11:52.880 --> 11:54.959
blah blah blah.
11:54.959 --> 00:12:00.240
Here we have another one, `quote`.
12:00.240 --> 12:03.279
Here we have another hash missing.
12:03.279 --> 12:06.079
It's not missing...
12:06.079 --> 12:08.000
but same thing here.
12:12.079 --> 00:12:16.560
Okay, this is a function from `kmacro`.
12:16.560 --> 00:12:18.079
We could declare it
00:12:18.079 --> 00:12:20.880
just to silence the warning
12:20.880 --> 00:12:22.320
although we don't actually...
00:12:22.320 --> 00:12:24.480
normally, when we declare such things--
12:24.480 --> 00:12:25.279
same thing with variables--
00:12:25.279 --> 00:12:27.300
we should try to make sure that indeed
12:27.300 --> 12:28.760
by the time the code is executed,
12:28.760 --> 12:30.800
the function will be available,
12:30.800 --> 00:12:32.800
and then very often is
00:12:32.800 --> 00:12:34.320
because there's a `require`
00:12:34.320 --> 00:12:35.680
sometimes inside a function,
00:12:35.680 --> 00:12:36.399
and so we should put
00:12:36.399 --> 00:12:37.680
the `declare` function
00:12:37.680 --> 00:12:39.920
right after the `require`,
00:12:39.920 --> 00:12:41.839
but I don't think it's the case here.
12:41.839 --> 00:12:46.399
So I'm just going to to add this.
12:46.399 --> 12:49.040
I know this comes from `kmacro`,
12:49.040 --> 00:12:53.500
and I could actually check the arguments.
12:56.320 --> 00:12:58.480
It's just taking an optional argument
00:12:58.480 --> 00:13:00.880
so I'm going to put it there,
00:13:00.880 --> 00:13:06.720
so we have it complete.
13:06.720 --> 13:10.800
Okay, we can just recompile,
13:10.800 --> 00:13:14.800
see what is left
00:13:14.800 --> 00:13:17.760
from those warnings we've fixed,
00:13:17.760 --> 00:13:21.360
and we may have new warnings, in any case,
00:13:21.360 --> 00:13:25.440
because especially when we add the hashes,
00:13:25.440 --> 00:13:29.519
it tends to give us more warnings.
13:29.519 --> 00:13:31.200
So we have two more functions
00:13:31.200 --> 00:13:34.560
which are not known.
13:34.560 --> 13:39.440
You can just add them here...
13:39.440 --> 13:44.720
`set-format "kmacro"`
13:44.720 --> 13:48.160
and same thing for `set-counter`.
13:48.160 --> 13:50.000
Okay, whatever.
13:54.959 --> 00:13:57.120
This just takes a `format` argument,
00:13:57.120 --> 00:14:05.920
and this one just takes an `arg` argument.
14:05.920 --> 14:10.800
Okay, so let's see what this says now.
14:10.800 --> 14:15.519
Hopefully, there's no warnings anymore.
14:15.519 --> 14:17.839
We're done. Okay!
14:17.839 --> 00:14:20.079
Okay, the last one we're going to see
00:14:20.079 --> 00:14:23.440
is in `enwc`, I saw the other day...
14:23.440 --> 14:26.240
I think I have it here...
14:27.760 --> 14:29.680
here we go, yes...
14:29.680 --> 14:32.800
so `enwc` is an interesting package here
14:32.800 --> 14:35.680
because it has-- as you can see it has--
14:35.680 --> 14:37.760
it's lexical binding,
14:37.760 --> 14:39.760
but actually some of the files in it
14:39.760 --> 14:42.320
do not use lexical binding,
14:42.320 --> 14:44.320
so it has been partly converted
14:44.320 --> 14:46.160
but not completely.
14:46.160 --> 00:14:49.920
So here I'm going to
00:14:49.920 --> 00:14:54.160
enable lexical binding.
14:54.160 --> 14:58.880
I have also, I think, in `cm`...
14:58.880 --> 15:01.199
yes...
15:01.199 --> 15:04.000
so I enable it here,
15:04.000 --> 15:07.360
and also, I think, `test`.
15:07.360 --> 00:15:09.360
The test files are often
00:15:09.360 --> 00:15:11.839
somewhat problematic
00:15:11.839 --> 00:15:15.199
because very often they're not quite
15:15.199 --> 15:18.880
as heavily tested themselves, actually,
15:18.880 --> 00:15:20.320
or they only run
00:15:20.320 --> 00:15:22.160
in very specific contexts,
00:15:22.160 --> 00:15:24.399
and so they may have problems
00:15:24.399 --> 00:15:27.360
with missing `requires` or using packages
00:15:27.360 --> 00:15:29.199
which are not explicitly in the dependencies
15:29.199 --> 15:31.279
and those kinds of things.
15:31.279 --> 15:33.360
I think this is not the case here,
15:33.360 --> 15:35.440
but we'll see.
15:35.440 --> 15:38.880
`enwc`...
15:38.880 --> 15:42.320
Yes, I want to save this one and that one.
15:42.320 --> 15:45.000
Let's see what it says.
15:47.199 --> 15:51.440
Okay, unused lexical variable `x`...
15:51.440 --> 15:52.240
`x`...
15:52.240 --> 15:57.120
Yes, so here we have an unused variable,
15:57.120 --> 15:58.320
and indeed, it's not used.
15:58.320 --> 16:00.880
It probably had to be named before
16:00.880 --> 16:04.079
because it was...
16:04.079 --> 00:16:05.120
with dynamic scoping,
00:16:05.120 --> 00:16:06.399
the `dotimes` requires
00:16:06.399 --> 00:16:08.160
the variable to be named, actually,
00:16:08.160 --> 00:16:10.399
because it's used internally somehow,
16:10.399 --> 00:16:11.600
but with lexical scoping,
00:16:11.600 --> 00:16:12.320
that's not the case,
00:16:12.320 --> 00:16:14.079
so we can just put an underscore.
16:14.079 --> 00:16:15.199
I'm going to change this
00:16:15.199 --> 00:16:16.880
because I really don't like
16:16.880 --> 16:19.000
this three-part `dotimes`.
16:19.000 --> 00:16:21.360
I prefer to have
00:16:21.360 --> 00:16:23.040
the return value at the end.
16:23.040 --> 00:16:26.480
It's sort of stashed hidden in the middle.
16:26.480 --> 16:29.680
That's just a personal preference.
16:29.680 --> 16:31.920
Okay, what else... we have a `widget`.
16:31.920 --> 16:34.000
Okay, this argument here says that
16:34.000 --> 16:37.000
it's not used, so if we look at...
16:44.320 --> 00:16:47.040
We were here, right? Yes. Right here.
00:16:47.040 --> 00:16:50.480
Indeed, `widget` is really not used.
16:50.480 --> 16:51.230
(Sorry.)
16:53.600 --> 00:16:55.279
Here's what I get for using
00:16:55.279 --> 00:16:58.320
a somewhat vanilla configuration of Emacs,
16:58.320 --> 17:01.279
compared to the one I use...
17:01.279 --> 17:04.000
the personally tricked one.
17:04.000 --> 17:05.439
Actually, I can...
17:05.439 --> 17:07.919
so we can just mark this argument
17:07.919 --> 17:09.360
as unused,
17:09.360 --> 17:11.199
and we don't want to remove the argument
17:11.199 --> 00:17:12.480
probably, or maybe we could;
00:17:12.480 --> 00:17:15.679
we could see where the function is used,
17:15.679 --> 00:17:18.542
and here we see that it's passed
00:17:18.542 --> 00:17:20.959
to a higher-order function,
17:20.959 --> 17:24.480
basically, so it's going to be...
17:24.480 --> 00:17:25.360
We can't really change
00:17:25.360 --> 00:17:25.760
the calling convention
17:25.760 --> 17:27.120
so we have to mark the argument
17:27.120 --> 17:29.600
as being just an unused argument,
17:29.600 --> 17:34.000
but we're going to still receive it.
17:34.000 --> 00:17:35.360
And here it says same thing:
00:17:35.360 --> 00:17:38.240
that `widget` is not used in this function.
17:38.240 --> 17:40.000
Let's take a look at the function.
17:40.000 --> 17:42.400
Indeed it seems it's not used,
17:42.400 --> 17:44.000
and so we're just going to mark it
17:44.000 --> 17:46.480
as unused.
17:46.480 --> 00:17:48.320
This is the part of the conversion
00:17:48.320 --> 00:17:49.200
to lexical scoping
00:17:49.200 --> 00:17:51.280
that's somewhat tricky sometimes
00:17:51.280 --> 00:17:53.760
because we don't really know
00:17:53.760 --> 00:17:56.240
whether this variable should be using
00:17:56.240 --> 00:17:58.559
lexical scoping or dynamic scoping.
17:58.559 --> 00:18:00.480
The fact that it's not used
00:18:00.480 --> 00:18:02.320
is a hint that there's probably
00:18:02.320 --> 00:18:03.679
something going on,
18:03.679 --> 00:18:04.960
so either it's not used
00:18:04.960 --> 00:18:06.400
because it should be using
00:18:06.400 --> 00:18:07.200
dynamic scoping--
00:18:07.200 --> 00:18:08.080
it is going to be used
00:18:08.080 --> 00:18:10.480
by some other code somewhere else--
18:10.480 --> 00:18:11.840
or it's really not used
00:18:11.840 --> 00:18:14.000
because it's just not used, right,
00:18:14.000 --> 00:18:16.320
and so we need to distinguish the two,
00:18:16.320 --> 00:18:20.880
and for that, I basically use
00:18:20.880 --> 00:18:22.240
my own judgment.
18:22.240 --> 18:24.880
This is based typically on the fact that
18:24.880 --> 00:18:27.760
this is just a very short name,
00:18:27.760 --> 00:18:32.000
and most local identifiers use short names,
18:32.000 --> 18:34.400
whereas item values used for dynamic scoping
18:34.400 --> 18:36.720
typically have a package prefix
18:36.720 --> 00:18:37.679
or something like this.
00:18:37.679 --> 00:18:38.960
So the fact that it's a short name
00:18:38.960 --> 00:18:40.880
gives me a good idea.
18:40.880 --> 00:18:41.520
Here in this case,
00:18:41.520 --> 00:18:42.640
I actually look at the code,
00:18:42.640 --> 00:18:45.600
and we see that there's nothing in here
18:45.600 --> 00:18:47.039
that may actually refer
00:18:47.039 --> 00:18:48.080
to this variable `widget`,
00:18:48.080 --> 00:18:49.280
so I think it's safe,
18:49.280 --> 00:18:51.360
but in the general case,
00:18:51.360 --> 00:18:54.400
we may look here and be surprised,
18:54.400 --> 00:18:55.760
or, you know, you may call out
00:18:55.760 --> 00:18:58.320
the functions which may themselves end up
18:58.320 --> 19:00.080
referring to this variable.
19:00.080 --> 19:02.640
So sometimes we need to investigate a
19:02.640 --> 19:03.840
little more.
19:03.840 --> 19:05.919
We are most of the time not completely sure
19:05.919 --> 19:07.520
whether the result is correct or not,
19:07.520 --> 00:19:09.520
of course, so the other thing
00:19:09.520 --> 00:19:10.640
you may want to check
00:19:10.640 --> 00:19:12.160
is also uses of things
00:19:12.160 --> 00:19:14.400
like `eval` or `symbol-value`.
19:14.400 --> 19:17.200
So it's often a good idea to search,
19:17.200 --> 00:19:18.799
and you do a search of `eval`,
00:19:18.799 --> 00:19:21.490
and you see here it's using `eval`.
00:19:21.490 --> 00:19:24.160
Hmmm... Okay, so what does this `eval` do?
19:24.160 --> 00:19:25.760
It's evaluating expressions
00:19:25.760 --> 00:19:28.240
that appear in `args` here
19:28.240 --> 19:31.840
so you can see where those args come from,
19:31.840 --> 00:19:35.120
and we see here, these are expressions
00:19:35.120 --> 00:19:36.840
that don't do anything very special.
19:36.840 --> 19:41.520
It's just using `make-supplicant-choice`,
19:41.520 --> 19:44.960
and `make-supplicant-choice` itself
19:44.960 --> 19:47.120
just doesn't refer to `widget`, for example,
19:47.120 --> 19:50.000
so you know we should be safe,
19:50.000 --> 19:52.559
but while I'm here...
19:52.559 --> 19:53.840
okay, well, then we can do that later.
19:53.840 --> 19:55.679
Well, that's actually the next warning,
19:55.679 --> 00:19:58.080
exactly. So here we see that this is
00:19:58.080 --> 00:20:00.000
using the dynamically-scoped dialect,
00:20:00.000 --> 00:20:02.799
so we convert it to lexical-scoped.
20:02.799 --> 20:04.559
Of course, this may introduce errors,
20:04.559 --> 20:07.200
but we hope it doesn't.
20:07.200 --> 20:08.880
And actually, it was a good change here,
20:08.880 --> 20:12.080
because if you see again,
20:12.080 --> 00:20:14.240
this actually evals expressions
00:20:14.240 --> 00:20:16.159
that appear here in `args`,
20:16.159 --> 20:18.480
and so these are expressions
20:18.480 --> 20:21.039
that are passed here.
20:21.039 --> 20:23.679
So this expression here used to be
20:23.679 --> 00:20:24.480
evaluated with dynamic scoping,
00:20:24.480 --> 00:20:28.000
even though it appears to be normal code
00:20:28.000 --> 00:20:29.760
within this file, which says
00:20:29.760 --> 00:20:32.559
it's using lexical scoping,
20:32.559 --> 20:34.400
and so there are some remnants
20:34.400 --> 20:36.640
of dynamic scoping all over the place
20:36.640 --> 00:20:37.840
in Emacs still, because we have
00:20:37.840 --> 00:20:43.679
those calls of `eval` with a nil argument.
20:44.880 --> 20:47.039
Here we have `cons`...
20:47.039 --> 20:50.400
that needs to be `hash quoted`.
20:52.400 --> 00:20:54.080
Oh, and we have a reference
00:20:54.080 --> 00:20:56.720
to this variable `enwc-edit-id'.
00:20:56.720 --> 00:20:57.520
So this is clearly
00:20:57.520 --> 00:21:00.400
a dynamic-scoped variable.
21:00.400 --> 21:02.000
We can either add a `defvar`
21:02.000 --> 21:03.440
to silence the warning,
21:03.440 --> 00:21:06.799
or maybe we can `require` the package.
21:06.799 --> 21:10.080
The file that defines it...
21:14.080 --> 21:17.360
So let's see where it's defined.
21:17.360 --> 21:21.200
Here it's defined in `enwc.el`,
21:21.200 --> 00:21:23.440
so I'm going to try just to add
00:21:23.440 --> 00:21:25.039
the dependency.
21:25.039 --> 00:21:27.840
I'm going to `require` here. This is risky.
21:27.840 --> 21:30.159
We'll see when we compile a file later,
21:30.159 --> 21:32.320
we may get a circular dependency
21:32.320 --> 21:34.720
because of it.
21:34.720 --> 21:36.320
If that's the case, we're going to
21:36.320 --> 00:21:38.320
have to remove this `require`
00:21:38.320 --> 00:21:42.000
and instead put `defvar`s.
21:42.000 --> 21:42.559
Sometimes it's worth actually
21:42.559 --> 21:44.640
looking further at the various files
21:44.640 --> 00:21:48.080
to see how to redefine the dependencies
21:48.080 --> 21:49.840
to break those circular dependencies,
21:49.840 --> 21:52.320
but it's often not really
21:52.320 --> 21:54.720
worth the trouble.
21:55.679 --> 00:21:58.400
Oh, no, that's not what--
00:21:58.400 --> 00:22:01.440
I'm not going to the right place...
00:22:01.440 --> 00:22:07.039
Here I was. So here `edit-map`.
22:07.039 --> 22:09.760
Well, we can probably...
22:09.760 --> 22:12.159
it may disappear or...
22:12.159 --> 22:13.760
oh, I see.
22:13.760 --> 22:16.320
Okay, so this `edit-map` actually is
22:16.320 --> 22:18.559
defined in this very file.
22:18.559 --> 00:22:20.240
It's just that it's defined later.
00:22:20.240 --> 00:22:21.600
So all we need to do
00:22:21.600 --> 00:22:24.320
is to move this definition
00:22:24.320 --> 00:22:27.200
to before its first use,
22:27.200 --> 22:28.960
since otherwise it's going to be taken
22:28.960 --> 22:33.520
as lexically-scoped, which we don't want.
22:33.520 --> 22:35.360
And while I'm here, I see this `copy-keymap`.
22:35.360 --> 22:38.400
I don't like `copy-keymap`,
22:38.400 --> 22:40.960
so I'm going to change this
22:40.960 --> 22:44.080
to a normal keymap,
22:44.080 --> 22:46.159
and then I'm just going to use
22:46.159 --> 22:50.080
`set-keymap-parent` instead of `copy-keymap`
22:50.080 --> 00:22:51.600
to get basically the same result,
00:22:51.600 --> 00:22:55.280
but without having copied anything.
22:55.280 --> 22:57.760
And this one will disappear...
22:57.760 --> 23:00.240
this one as well-- or should hopefully,
23:00.240 --> 23:03.360
thanks to the `require`.
23:03.360 --> 23:09.840
Here we have a `hash` missing,
23:09.840 --> 00:23:11.840
and we have some functions
00:23:11.840 --> 00:23:14.000
which are unknown,
23:14.000 --> 00:23:14.666
so let's see...
00:23:14.666 --> 00:23:18.240
Where is this function defined?
23:18.240 --> 23:21.679
Nowhere. Huh, wonderful, okay.
23:21.679 --> 00:23:25.200
So we'll just leave it like it is,
00:23:25.200 --> 00:23:27.120
and that's going to be
00:23:27.120 --> 00:23:31.360
for the author of the package to fix.
23:31.360 --> 23:37.120
How about this one?
23:37.120 --> 23:40.240
Oh, okay, so it's defined in `enwc.el`
23:40.240 --> 00:23:41.679
so presumably,
00:23:41.679 --> 00:23:44.559
this is going to disappear as well.
23:50.159 --> 23:51.030
One more...
23:56.159 --> 23:58.640
Okay, so this one
23:58.640 --> 23:59.919
is just like the previous one.
23:59.919 --> 24:04.000
We're going to leave it at that.
24:04.000 --> 24:06.720
And this is it! Huh, wonderful.
24:06.720 --> 24:10.000
So let's recompile.
24:16.080 --> 24:23.520
Oh, we have a warning for `fin`.
24:25.679 --> 00:24:28.640
This variable seems not to be used
00:24:28.640 --> 00:24:32.000
anywhere in the file, so we're just
24:32.000 --> 00:24:33.440
going to remove it.
00:24:33.440 --> 00:24:34.880
I leave it there just in case
00:24:34.880 --> 00:24:36.000
someone needs later on
00:24:36.000 --> 00:24:37.679
to look for a `fin` variable
00:24:37.679 --> 00:24:39.760
to see where it used to be.
24:39.760 --> 24:41.600
Again, you know, maybe it's actually used...
24:41.600 --> 24:43.519
yeah, dynamic scoping somehow,
24:43.519 --> 24:46.159
but given the short name,
24:46.159 --> 24:48.960
I presume this is not the case.
24:48.960 --> 24:51.200
Here, oh, that's the code removed
24:51.200 --> 24:52.559
that had a hash missing.
24:52.559 --> 24:54.159
That's the one that's not defined.
24:54.159 --> 24:56.799
This one is not defined,
24:56.799 --> 24:58.000
and this is it.
24:58.000 --> 25:03.039
Let's make a last recompilation
25:03.039 --> 25:06.080
to see if we missed yet something else.
25:06.080 --> 25:07.919
Nope, and that's it, okay.
25:07.919 --> 25:11.200
Well, here we go; we're done.
25:11.200 --> 00:25:14.240
Okay so this was it.
00:25:14.240 --> 00:25:15.440
You've seen, I think,
25:15.440 --> 25:18.000
pretty much examples of all of those,
25:18.000 --> 25:20.159
and I hope you enjoyed it.
25:20.960 --> 25:22.580
Lessons to take home:
25:22.580 --> 25:23.919
use the byte compiler.
25:23.919 --> 25:26.000
You can also use `flymake-mode` instead.
25:26.000 --> 00:25:31.600
I recommend enabling it as much as you can,
25:31.600 --> 25:33.520
and head the warnings.
25:33.520 --> 25:35.440
Follow the warnings. Try to fix them.
25:35.440 --> 25:37.200
If you can fix all of the warnings,
25:37.200 --> 00:25:38.080
it's always much better,
00:25:38.080 --> 00:25:39.200
because then the new warnings
00:25:39.200 --> 00:25:40.960
really show up.
25:40.960 --> 25:42.880
And once you've done it, it's really
25:42.880 --> 00:25:44.559
kind of-- because there's always
00:25:44.559 --> 00:25:46.799
new things coming up.
25:46.799 --> 25:48.799
And I think this is it.
25:48.799 --> 00:25:50.720
I hope you liked it, and thank you
00:25:50.720 --> 00:25:56.000
for attending this presentation. Bye.
00:25:56.000 --> 00:25:57.000
[captions by Hannah Miller]
