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]