diff options
Diffstat (limited to '2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt')
| -rw-r--r-- | 2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt | 972 |
1 files changed, 972 insertions, 0 deletions
diff --git a/2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt b/2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt new file mode 100644 index 00000000..ba813a81 --- /dev/null +++ b/2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt @@ -0,0 +1,972 @@ +WEBVTT captioned by Lovro + +NOTE Introduction + +00:00:00.000 --> 00:00:01.540 +Hi everyone! + +00:00:01.640 --> 00:00:04.540 +Welcome to our talk on Parallel Text Replacement. + +00:00:04.640 --> 00:00:06.940 +My name is Lovro, and I'll be telling you about an + +00:00:07.040 --> 00:00:09.260 +interesting problem that my friend Valentino and I + +00:00:09.360 --> 00:00:11.660 +set out to solve one afternoon. + +00:00:11.760 --> 00:00:13.580 +We will describe the problem, take a look at some + +00:00:13.680 --> 00:00:16.780 +of the existing work and then present our solution. + +00:00:16.880 --> 00:00:18.980 +Afterwards, we will show some demos and conclude + +00:00:19.080 --> 00:00:21.420 +with a quick overview of the implementation. + +00:00:21.520 --> 00:00:23.340 +Let's get straight into it! + +NOTE Problem: Goal + +00:00:23.440 --> 00:00:25.700 +Here is a problem that most of us have dealt with + +00:00:25.800 --> 00:00:26.940 +at some point. + +00:00:27.040 --> 00:00:29.780 +Assume we have a piece of code such as the following. + +00:00:29.880 --> 00:00:32.420 +We use a code example here, but in general what we're + +00:00:32.520 --> 00:00:35.500 +about to discuss can be applied to any piece of text. + +00:00:35.600 --> 00:00:37.540 +After a bit of thinking, we decide that the names of + +00:00:37.640 --> 00:00:39.860 +the two variables, "foo" and "bar", should actually be + +00:00:39.960 --> 00:00:40.780 +swapped. + +00:00:40.880 --> 00:00:43.460 +That is, "foo" should be replaced with "bar", and "bar" + +00:00:43.560 --> 00:00:44.940 +should be replaced with "foo". + +00:00:45.040 --> 00:00:48.980 +The question is: what is a good way to achieve this? + +00:00:49.080 --> 00:00:51.660 +We could perform the edits manually if the code is + +00:00:51.760 --> 00:00:53.780 +small enough, and we might even be done reasonably + +00:00:53.880 --> 00:00:54.620 +quickly. + +00:00:54.720 --> 00:00:56.620 +However, consider two things. + +00:00:56.720 --> 00:00:58.860 +Imagine the usual case where there's just too much + +00:00:58.960 --> 00:01:00.660 +code to edit by hand. + +00:01:00.760 --> 00:01:03.580 +We have no other option than to automate the task. + +00:01:03.680 --> 00:01:06.020 +More importantly though, we have a whole programmable + +00:01:06.120 --> 00:01:08.180 +text editor right at our fingertips. + +00:01:08.280 --> 00:01:10.180 +We should object to doing things that the computer + +00:01:10.280 --> 00:01:12.260 +can do for us. + +NOTE Problem: Naive Multi-pass + +00:01:12.360 --> 00:01:15.460 +So, one way to automate it is by using our old friend + +00:01:15.560 --> 00:01:18.940 +query-replace (M-%) multiple times in a sequence. + +00:01:19.040 --> 00:01:22.140 +We first do a pass where we replace "foo" with "bar", + +00:01:22.240 --> 00:01:25.540 +then we do another pass where we replace "bar" with "foo". + +00:01:25.640 --> 00:01:26.860 +But that's clearly not right. + +00:01:26.960 --> 00:01:29.060 +We all know that this naive multi-pass approach + +00:01:29.160 --> 00:01:31.460 +doesn't work because it results in interference + +00:01:31.560 --> 00:01:34.100 +between the two replacements. + +NOTE Problem: Clever Multi-pass + +00:01:34.200 --> 00:01:36.700 +Instead, we have to be a bit more clever. + +00:01:36.800 --> 00:01:39.740 +We should first replace "foo" with a temporary string, + +00:01:39.840 --> 00:01:42.020 +in this case "oof", that we will call a "token". + +00:01:42.120 --> 00:01:45.380 +To avoid interference, we must be careful to ensure + +00:01:45.480 --> 00:01:48.020 +that the token does not contain whatever we're about + +00:01:48.120 --> 00:01:49.500 +to replace next. + +00:01:49.600 --> 00:01:52.620 +Then we do a second pass to replace "bar" with "foo", + +00:01:52.720 --> 00:01:55.980 +and finally a third pass to replace the token with "bar". + +00:01:56.080 --> 00:01:57.620 +This gives us the result we want. + +NOTE Problem: Terminology + +00:01:57.720 --> 00:02:01.820 +Putting the implementation aside for a moment, this style + +00:02:01.920 --> 00:02:05.500 +of text replacement, where we replace multiple sources + +00:02:05.600 --> 00:02:08.940 +with their targets, without running into interference + +00:02:09.040 --> 00:02:11.660 +issues between replacement pairs, is what we call + +00:02:11.760 --> 00:02:12.740 +a "parallel replacement". + +00:02:12.840 --> 00:02:16.260 +This is the essence of the problem we're trying to solve. + +00:02:16.360 --> 00:02:18.580 +The examples with swapping that we've shown so far + +00:02:18.680 --> 00:02:21.220 +are really just one of the many use cases that are + +00:02:21.320 --> 00:02:23.740 +supported by a general parallel replacement utility. + +00:02:25.040 --> 00:02:28.660 +To avoid confusion, let us clarify that the word "parallel" + +00:02:28.760 --> 00:02:31.660 +is not in reference to hardware parallelization, but + +00:02:31.760 --> 00:02:34.780 +rather comes from analogy with the Lisp let operator, + +00:02:34.880 --> 00:02:38.060 +where the bindings of variables are performed in parallel, + +00:02:38.160 --> 00:02:40.100 +rather than sequentially as in let*. + +00:02:40.200 --> 00:02:43.580 +Parallel in this context means that none of the bindings + +00:02:43.680 --> 00:02:46.780 +are in scope within any of the initial value forms. + +00:02:46.880 --> 00:02:50.100 +In other words, just like a let's initialization form + +00:02:50.200 --> 00:02:53.620 +cannot refer to any of the earlier bindings, a + +00:02:53.720 --> 00:02:56.660 +replacement pair's source should not be able to replace + +00:02:56.760 --> 00:03:00.100 +the previously substituted targets of any other pair. + +00:03:00.200 --> 00:03:03.340 +This is what we mean by "no interference". + +NOTE Problem: Scaling Multi-pass + +00:03:04.440 --> 00:03:07.900 +However, manually invoking multiple carefully chosen + +00:03:08.000 --> 00:03:11.420 +query-replace commands gets old very quickly. + +00:03:11.520 --> 00:03:14.100 +Say we scaled up the problem and wanted to perform n + +00:03:14.200 --> 00:03:18.220 +swaps instead of just two, e.g. to swap, or rather, + +00:03:18.320 --> 00:03:22.060 +rotate, "foo" to "bar", "bar" to "baz", "baz" to "quux" + +00:03:22.160 --> 00:03:23.700 +and "quux" to "foo". + +00:03:23.800 --> 00:03:26.260 +We would first have to perform n - 1 additional + +00:03:26.360 --> 00:03:29.140 +replacements to introduce the necessary tokens, + +00:03:29.240 --> 00:03:32.140 +effectively doubling the number of steps. + +00:03:32.240 --> 00:03:34.700 +Even if we tried to automate this, think about what + +00:03:34.800 --> 00:03:37.580 +tokens the code would have to generate if we had no + +00:03:37.680 --> 00:03:40.420 +prior knowledge of the replacement pairs given by the + +00:03:40.520 --> 00:03:41.460 +user. + +00:03:41.560 --> 00:03:44.060 +We would have to program defensively and use long + +00:03:44.160 --> 00:03:47.460 +randomly-generated strings that, one, hopefully do + +00:03:47.560 --> 00:03:50.180 +not interfere with any of the replacement pairs, + +00:03:50.280 --> 00:03:53.380 +and two, might slow down the search if they're overly long. + +00:03:53.480 --> 00:03:54.820 +Can we do better? + +NOTE Solution: Single-pass + +00:03:55.920 --> 00:03:56.740 +Yes we can! + +00:03:56.840 --> 00:03:59.580 +We can actually perform just a single pass. + +00:03:59.680 --> 00:04:02.180 +The trick is to alternate between the replacement + +00:04:02.280 --> 00:04:05.900 +pairs, replacing whichever source occurs the earliest, + +00:04:06.000 --> 00:04:08.340 +and making sure to continue scanning after the end + +00:04:08.440 --> 00:04:12.180 +of the substituted target in order to avoid interference. + +00:04:12.280 --> 00:04:14.420 +This interleaving of replacements is not something + +00:04:14.520 --> 00:04:17.140 +that's easy to do by hand with query-replace. + +NOTE Solution: Existing + +00:04:18.240 --> 00:04:20.860 +Since this is Emacs we're talking about, of course + +00:04:20.960 --> 00:04:23.460 +there already exist solutions that implement this idea. + +00:04:23.560 --> 00:04:25.860 +Here are few that we could find. + +00:04:25.960 --> 00:04:28.700 +The EmacsWiki has a page dedicated to this problem. + +00:04:28.800 --> 00:04:31.460 +Stack Overflow has an old post where a couple of + +00:04:31.560 --> 00:04:33.860 +users provided their solutions. + +00:04:33.960 --> 00:04:36.820 +Mastering Emacs also gives a method along with other + +00:04:36.920 --> 00:04:38.900 +interesting query-replace-regexp (C-M-%) patterns. + +00:04:39.000 --> 00:04:42.260 +More recently, Tony Zorman made a blogpost providing + +00:04:42.360 --> 00:04:44.980 +a solution with an interface based on query-replace. + +00:04:45.080 --> 00:04:47.540 +I encourage you to take a look at these solutions if + +00:04:47.640 --> 00:04:48.940 +you're interested in the details. + +00:04:50.040 --> 00:04:52.940 +But while a step in the right direction, these solutions + +00:04:53.040 --> 00:04:55.340 +are not satisfactory because they all lack one or + +00:04:55.440 --> 00:04:56.820 +more of the following. + +00:04:56.920 --> 00:04:59.900 +One, they are not completely automated and require + +00:05:00.000 --> 00:05:02.500 +the user to come up with a relatively complicated + +00:05:02.600 --> 00:05:05.380 +and verbose query-replace-regexp invocation. + +00:05:06.080 --> 00:05:08.940 +Two, they are restricted to performing only 2-element + +00:05:09.040 --> 00:05:11.780 +swaps rather than general parallel replacements. + +00:05:12.680 --> 00:05:15.060 +Three, they don't provide any sort of interactivity + +00:05:15.160 --> 00:05:17.820 +during replacement and instead perform it in one shot. + +00:05:18.620 --> 00:05:21.300 +Four, they don't attempt to integrate with the familiar + +00:05:21.400 --> 00:05:24.900 +query-replace interface, which supports skipping, undo, + +00:05:25.000 --> 00:05:28.340 +history and more advanced features like Lisp expressions + +00:05:28.440 --> 00:05:29.900 +and recursive query edits. + +00:05:30.700 --> 00:05:33.700 +Most importantly however, five, none of them were + +00:05:33.800 --> 00:05:36.380 +designed with regular expressions in mind and instead + +00:05:36.480 --> 00:05:38.460 +only ever consider literal strings. + +00:05:39.560 --> 00:05:43.060 +In fact, the only one that comes close is the + +00:05:43.160 --> 00:05:46.420 +half-automated solution that invokes query-replace-regexp + +00:05:46.520 --> 00:05:48.100 +with a specially crafted replacement. + +00:05:48.800 --> 00:05:51.660 +As an example, here's how you would use this technique + +00:05:51.760 --> 00:05:54.340 +to perform a 3-element parallel regex replacement. + +00:05:54.440 --> 00:05:57.740 +It uses the backslash-comma Lisp expression feature + +00:05:57.840 --> 00:06:01.180 +in order to choose the appropriate target to substitute. + +00:06:01.280 --> 00:06:03.700 +Aside from being very clumsy and tedious to write out, + +00:06:03.800 --> 00:06:06.860 +this approach makes it really hard to use more complex + +00:06:06.960 --> 00:06:09.260 +regular expressions that make use of capture groups + +00:06:09.360 --> 00:06:10.600 +themselves. + +00:06:10.800 --> 00:06:12.200 +This was the biggest limitation that we wanted + +00:06:12.200 --> 00:06:15.020 +to get rid of and the main motivation for our work. + +00:06:15.720 --> 00:06:19.820 +So, as an alternative to the existing zoo of 80% solutions, + +00:06:19.920 --> 00:06:24.140 +we aim to provide a 100% solution, one that handles + +00:06:24.240 --> 00:06:27.020 +regexes and consolidates all of the existing ideas + +00:06:27.120 --> 00:06:28.180 +into a single package. + +NOTE Solution: query-replace-parallel + +00:06:29.080 --> 00:06:31.260 +We call it query-replace-parallel. + +00:06:31.360 --> 00:06:34.060 +The package is free and open-source and can currently + +00:06:34.160 --> 00:06:37.300 +be found on GitHub under hokomo/query-replace-parallel. + +00:06:37.400 --> 00:06:40.140 +The name is not yet finalized and we're open to any + +00:06:40.240 --> 00:06:41.170 +suggestions. + +00:06:41.503 --> 00:06:43.180 +We hope to get it published on an Elisp + +00:06:43.280 --> 00:06:45.780 +package archive in the near future, but for now you + +00:06:45.880 --> 00:06:48.300 +can just download and load the main Elisp file manually. + +00:06:48.900 --> 00:06:51.300 +With all of that said, let's go through a few demos + +00:06:51.400 --> 00:06:54.140 +to illustrate some use cases and see how to use the package. + +NOTE Demonstration: Swap + +00:06:55.240 --> 00:06:57.460 +Our first demo is a simple swap, like the one we + +00:06:57.560 --> 00:06:59.140 +showed at the beginning of the presentation. + +00:06:59.240 --> 00:07:02.060 +This chunk of text is actually one of the tests + +00:07:02.160 --> 00:07:03.140 +from our package's code. + +00:07:03.840 --> 00:07:06.420 +Assuming we have loaded the package, we can execute + +00:07:06.520 --> 00:07:09.580 +the query-replace-parallel command, a parallel version + +00:07:09.680 --> 00:07:11.220 +of the standard query-replace. + +00:07:11.320 --> 00:07:13.940 +This command works with literal strings and will + +00:07:14.040 --> 00:07:15.900 +ask for each source and target in turn. + +00:07:16.000 --> 00:07:21.260 +Our goal is to replace "foo" with "bar" + +00:07:21.360 --> 00:07:22.180 +and "bar" with "foo". + +00:07:24.680 --> 00:07:26.940 +After inputting our replacements, we terminate the + +00:07:27.040 --> 00:07:29.060 +prompt by pressing enter with empty input. + +00:07:29.860 --> 00:07:32.500 +At this point, everything functions the same as in + +00:07:32.600 --> 00:07:34.380 +a standard query-replace invocation. + +00:07:35.280 --> 00:07:37.300 +The echo area shows the match and the replacement + +00:07:37.400 --> 00:07:38.603 +we're about to make. + +00:07:38.703 --> 00:07:40.220 +We can perform replacements, + +00:07:43.920 --> 00:07:46.403 +undo them, + +00:07:46.503 --> 00:07:49.103 +skip them, + +00:07:49.203 --> 00:07:50.140 +execute them until the end, + +00:07:50.240 --> 00:07:51.020 +and so on. + +NOTE Demonstration: LaTeX + +00:07:53.970 --> 00:07:56.180 +The second demo shows our first regex use case. + +00:07:56.280 --> 00:07:58.620 +Imagine we have the following LaTeX code. + +00:07:58.720 --> 00:08:01.380 +We realize that we haven't been completely consistent + +00:08:01.480 --> 00:08:03.940 +in our use and naming of macros, so we decide to + +00:08:04.040 --> 00:08:04.660 +fix the problem. + +00:08:05.536 --> 00:08:08.300 +This time we execute query-replace-parallel-regexp + +00:08:08.400 --> 00:08:10.900 +because we want to work with regex instead of literal + +00:08:11.000 --> 00:08:11.500 +strings. + +00:08:12.000 --> 00:08:13.420 +We want to achieve two things. + +00:08:13.520 --> 00:08:16.860 +First, we want to wrap all usages of the variable n + +00:08:16.960 --> 00:08:17.980 +with the natvar macro. + +00:08:18.080 --> 00:08:20.940 +Using the backslash-less-than and blackslash-greater-than + +00:08:21.040 --> 00:08:23.740 +constructs allows us to only match letters n not + +00:08:23.840 --> 00:08:25.260 +appearing as part of a larger word. + +00:08:25.360 --> 00:08:29.460 +Second, we want to rename natvar to intvar because + +00:08:29.560 --> 00:08:32.180 +the variables a, b and c are integers and not natural + +00:08:32.280 --> 00:08:32.700 +numbers. + +00:08:33.300 --> 00:08:35.660 +We enter empty input to terminate the prompt and can + +00:08:35.760 --> 00:08:37.180 +now perform the replacements. + +00:08:42.280 --> 00:08:44.380 +There we go, the fixes are done and we didn't have + +00:08:44.480 --> 00:08:46.100 +to think about in which order to apply them. + +NOTE Demonstration: Regex + +00:08:48.700 --> 00:08:50.900 +We now take a look at a more complicated regex + +00:08:51.000 --> 00:08:53.580 +example to demonstrate that even advanced query-replace + +00:08:53.680 --> 00:08:54.300 +features are supported. + +00:08:55.100 --> 00:08:57.340 +Each "foo" and "bar" in this example is followed by + +00:08:57.440 --> 00:08:57.740 +a number. + +00:08:58.440 --> 00:09:01.280 +The goal is to not only swap "foo" and "bar", but + +00:09:01.380 --> 00:09:03.620 +also increase or decrease the corresponding number. + +00:09:03.720 --> 00:09:06.500 +We first match "foo" and capture the number that + +00:09:06.600 --> 00:09:07.100 +follows it. + +00:09:07.200 --> 00:09:09.900 +For the target, we make use of the backslash-comma + +00:09:10.000 --> 00:09:12.500 +Lisp expression feature in order to replace the + +00:09:12.600 --> 00:09:14.940 +match with "bar" followed by the number's successor. + +00:09:15.540 --> 00:09:17.540 +We do the same thing for "bar", except that we + +00:09:17.640 --> 00:09:19.140 +replace the number with its predecessor. + +00:09:27.040 --> 00:09:29.020 +Performing the replacements, we can see how each + +00:09:29.120 --> 00:09:31.220 +number is incremented or decremented appropriately. + +NOTE Demonstration: Order + +00:09:36.320 --> 00:09:38.660 +We haven't covered it explicitly so some of you may + +00:09:38.760 --> 00:09:41.260 +be wondering how parallel replacement deals with + +00:09:41.360 --> 00:09:43.740 +overlapping matches and whether the order of the + +00:09:43.840 --> 00:09:45.380 +replacement pairs is significant. + +00:09:45.480 --> 00:09:47.860 +This demo will clarify the exact behavior. + +00:09:48.960 --> 00:09:51.700 +The first example has the sources "watch" and "stopwatch". + +00:09:57.500 --> 00:10:00.500 +Conceptually, the matches overlap, but the rule is + +00:10:00.600 --> 00:10:02.900 +that matches are always processed earliest first, + +00:10:03.000 --> 00:10:05.940 +regardless of their length or the ordering of the pairs. + +00:10:06.040 --> 00:10:08.980 +Therefore it is "stopwatch" that gets replaced, + +00:10:09.080 --> 00:10:10.940 +and not its substring "watch". + +00:10:16.040 --> 00:10:19.540 +The second example uses the sources "watch" and "watchword". + +00:10:19.640 --> 00:10:22.540 +Both of the matches now conceptually start at the same + +00:10:22.640 --> 00:10:23.020 +position. + +00:10:23.720 --> 00:10:26.300 +In situations like these the order of the pairs does + +00:10:26.400 --> 00:10:29.460 +matter, and ties are broken by prefering the pair that + +00:10:29.560 --> 00:10:32.180 +was entered first, which is behavior that is inherited + +00:10:32.280 --> 00:10:33.460 +from the Elisp regex engine. + +00:10:34.460 --> 00:10:37.380 +So, the substring "watch" in "watchword" is what gets + +00:10:37.480 --> 00:10:38.460 +replaced in this case. + +00:10:39.460 --> 00:10:41.740 +Situations where the order of the pairs is significant + +00:10:41.840 --> 00:10:44.740 +are not very common however, so the user generally + +00:10:44.840 --> 00:10:46.660 +doesn't have to worry about this edge case. + +00:10:46.760 --> 00:10:49.860 +The order only matters when two or more sources + +00:10:49.960 --> 00:10:52.340 +share the same prefix, as in this example. + +NOTE Demonstration: Fun + +00:10:54.440 --> 00:10:56.860 +The final demo tests the limits of the package and + +00:10:56.960 --> 00:10:59.660 +shows that it fully integrates with query-replace. + +00:10:59.760 --> 00:11:02.940 +It is really just for fun and can even serve as a + +00:11:03.040 --> 00:11:04.140 +small Emacs brainteaser. + +00:11:04.240 --> 00:11:05.460 +See if you can keep up! + +00:11:06.360 --> 00:11:09.060 +We open a directory and enter Writable Dired mode + +00:11:09.160 --> 00:11:11.780 +in order to rename the directories "foo" and "bar". + +00:11:11.880 --> 00:11:14.660 +Instead of doing it quickly by hand, we decide to + +00:11:14.760 --> 00:11:17.260 +show off and use query-replace-parallel-regexp. + +00:11:17.360 --> 00:11:19.900 +We enter our pairs and make use of the + +00:11:20.000 --> 00:11:22.380 +backslash-question-mark query edit feature. + +00:11:25.080 --> 00:11:27.820 +Now whenever we perform a replacement, the query + +00:11:27.920 --> 00:11:30.740 +edit makes Emacs stop and prompt us for additional + +00:11:30.840 --> 00:11:32.180 +input to use as the target. + +00:11:36.680 --> 00:11:39.140 +We confirm the renames and now enter the "bar-lib" + +00:11:39.240 --> 00:11:41.900 +directory in order to perform the same kind of + +00:11:42.000 --> 00:11:43.900 +replacement on "baz" and "quux". + +00:11:44.500 --> 00:11:47.820 +Rather than save time, we decide to be extra lazy + +00:11:47.920 --> 00:11:48.820 +and take the long route. + +00:11:48.920 --> 00:11:52.220 +We recall the first pair and initiate a recursive + +00:11:52.320 --> 00:11:54.460 +invocation of query-replace-parallel-regexp. + +00:11:54.560 --> 00:11:57.020 +We are now replacing the replacement. + +00:12:01.020 --> 00:12:04.540 +We apply our fixes and then do the same thing again + +00:12:04.640 --> 00:12:05.870 +with the second pair. + +00:12:05.970 --> 00:12:07.500 +Recall and recurse. + +00:12:16.300 --> 00:12:19.860 +We confirm the prompt and finally rename our directories. + +00:12:25.360 --> 00:12:26.620 +Wow, that really paid off. + +NOTE Implementation + +00:12:29.120 --> 00:12:31.380 +Before we finish, a few quick words about the + +00:12:31.480 --> 00:12:32.900 +implementation for the curious. + +00:12:33.300 --> 00:12:36.380 +Both query-replace-parallel and query-replace-parallel-regexp + +00:12:36.480 --> 00:12:39.140 +delegate to the complex perform-replace function + +00:12:39.240 --> 00:12:41.780 +which is the workhorse of query-replace's interactive + +00:12:41.880 --> 00:12:42.420 +mechanism. + +00:12:43.120 --> 00:12:45.420 +The way we achieve multiple interleaved replacements + +00:12:45.520 --> 00:12:49.020 +is by providing perform-replace with a big "matcher regex" + +00:12:49.120 --> 00:12:50.380 +and a special replacement function. + +00:12:50.480 --> 00:12:54.300 +Essentially, a complex parallel replacement like this + +00:12:54.400 --> 00:12:57.420 +is transformed into a standard replacement like this. + +00:12:57.520 --> 00:13:00.100 +This is similar to the trick shown earlier in the + +00:13:00.200 --> 00:13:00.780 +presentation. + +00:13:00.880 --> 00:13:03.820 +Each source is put in its own capture group to allow + +00:13:03.920 --> 00:13:06.340 +the replacement function to determine which one matched + +00:13:06.440 --> 00:13:08.380 +and return the appropriate target. + +00:13:08.980 --> 00:13:11.580 +However, we now take care to support arbitrary + +00:13:11.680 --> 00:13:13.380 +regular expressions as sources. + +00:13:13.480 --> 00:13:16.980 +We achieve this by converting each source regex into + +00:13:17.080 --> 00:13:19.820 +an equivalent one for which we can guarantee that its + +00:13:19.920 --> 00:13:22.820 +capture groups will not clash with our matcher regex. + +00:13:22.920 --> 00:13:25.900 +Information about this conversion is stored, and + +00:13:26.000 --> 00:13:28.220 +once the replacement function is called it has + +00:13:28.320 --> 00:13:30.260 +enough data to apply the replacement from the + +00:13:30.360 --> 00:13:32.020 +viewpoint of the original regex. + +00:13:32.720 --> 00:13:34.900 +The regex transformation is reliable because it + +00:13:35.000 --> 00:13:38.420 +uses the rx library, allowing us to treat regexes + +00:13:38.520 --> 00:13:41.940 +as s-expressions and avoid any nasty manual parsing. + +00:13:42.640 --> 00:13:46.540 +In fact, rx itself is based on one of Olin Shivers' + +00:13:46.640 --> 00:13:48.336 +100% solutions: + +00:13:48.436 --> 00:13:51.220 +SRE, or the S-expression regex notation. + +00:13:51.320 --> 00:13:54.340 +We all stand on the shoulders of many giants, so + +00:13:54.440 --> 00:13:56.500 +let's strive to design good solutions that we can + +00:13:56.600 --> 00:13:59.140 +all benefit from, many years into the future! + +00:13:59.240 --> 00:14:02.900 +Finally, because query-replace's core is not completely + +00:14:03.000 --> 00:14:06.060 +customizable, we did have to sprinkle in some advice + +00:14:06.160 --> 00:14:07.500 +to get certain things working. + +00:14:07.600 --> 00:14:11.060 +This concerns only minor cosmetic fixes and not the + +00:14:11.160 --> 00:14:13.940 +core replacement functionality, but we have nontheless + +00:14:14.040 --> 00:14:16.580 +tried to do it in the simplest and least intrusive way + +00:14:16.680 --> 00:14:17.140 +possible. + +NOTE End + +00:14:18.740 --> 00:14:21.580 +In conclusion, go download and play with the package. + +00:14:21.680 --> 00:14:24.460 +Even if you're not performing overlapping replacements, + +00:14:24.560 --> 00:14:26.780 +you can still use query-replace-parallel for the + +00:14:26.880 --> 00:14:29.620 +peace of mind knowing that things won't go wrong if + +00:14:29.720 --> 00:14:31.860 +you perform more than one replacement at a time. + +00:14:32.460 --> 00:14:34.540 +Feel free to let us know about any interesting or + +00:14:34.640 --> 00:14:37.460 +crazy use cases you might come up with, as well as + +00:14:37.560 --> 00:14:40.540 +improvements or bugs that make it only a 99% solution. + +00:14:40.640 --> 00:14:45.560 +Thanks for listening and have a great EmacsConf! |