path: root/2023/captions/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt

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!