Live CEOing Ep 763: Language Design in the Wolfram Language [DiffTools and More]

Okay. Hello, everyone. Welcome to another Wolfram language design review, part of our Language Completeness and Consistency series. Although I actually have to say that this topic doesn't seem like it's really related to that, but looks like we're looking at diff tools here. Can we try and dispatch this one here, this data set bottom space thing? Because it looks like that's a. Yeah, that's. That's pretty trivial, straightforward issue.

Right, so this was. Right, so this was something you requested and you know, that had not reserved the space underneath. And so it doesn't reserve the space underneath. And the only change is. Right, that little hover thing used to not have a border. And we decided, since it can now cover.

I don't understand it. What does the data set do in the case where there isn't a thing that says other here? I don't understand what's. Well, what does dataset do if it's plain?

The only point being that the other is there, so you can see it being covered up.

Okay, but if I do this, then.

It will bleed into the next cell. Potentially into the next cell. Yes.

Okay. Why is it the case that when in the hover that I'm not seeing a hover when I'm to the right of that content there?

I don't know that we have a really good answer to that. That was something that we looked at and it has something to do with Tully's original implementation and we don't entirely know the answer to that.

So I think. I think it should be the case that you get this hover where whenever you're in the cell. Right. Whenever you're in this data set cell, it doesn't require that you're on top of the content to get the hover.

That makes sense to me. And so we can definitely look into that.

It might not be the easiest thing to implement.

Okay, well, I think what's there right now is not super useful, I have to say.

The problem is. Well, I mean, let's be fair. This is the worst case scenario, you know, because those things are tiny.

Yeah, I get it. You might not even notice if those things were bigger.

Yeah, but. But the problem is you need to. You need to have a box to attach the hover effect to. And if, if you're looking to fill out the contents, then you need to introduce like a pane box or something like that, and then that to. Okay, but then how are you going to auto size? Well, it's more about. Once you've introduced pain boxes, then does column sizing work in the same way it did before, or does it have knock on effects that are undesirable?

Right. So is this just a consequence of Thale insisting on sort of a minimal column width? Can we. Well, I guess that some might not do.

I mean, it's trivial to wrap a paint box around everything. What's non trivial is setting the size of the paint box. That's the hard part. In a way that works with whatever logic is auto sizing the columns right now. So there, you know, there might be something that will just work. But I'm not confident. Not at all confident.

All right. Okay. So can I ask, should the keys.

Also be clickable anywhere inside the cell or should you have to click on the key?

You just sent this out as an example, right? I don't know. Yeah, yeah. I mean, that seems wrong that that doesn't work, that it only works when you're out of the content area.

So both have the hover and be clickable?

Yeah, I think so.

Okay.

I mean, I see the clickable, the clickability. Okay. The question of whether the whole cell should be clickable as opposed to just. I kind of think that there's a question of should the whole cell light up when you're in it or should only the content area light up?

Yeah, it looks a little strange for the font to be changing colors, but then have that key to a mouse over of the whole region. I look a little strange.

I agree, I agree with you. So it's not obvious what we want to do. I would argue that, You know, I'd argue that the whole cell, that there is a. That we could have something where, for example, the border of the whole cell lights up when you're in it.

So the right click behavior doesn't require you to be right. Or maybe it does.

Okay, I'm not seeing that. See, I'm not seeing that right click if I go there, if I hover. What the hell? Why isn't that lighting up when I'm hovering?

Why should it light up? That's data. I mean, why should it light up?

No, but look at this, look at this. Look at the right click here. Okay. The right click here does not give position. Doesn't let me.

Right, right. This is a consequence of the same. Same issue.

This is pretty horrifying.

You know, also, just as I said, for dealing with attached cells, I mean, same thing for the context menu. You have to have a box to latch onto.

Yeah, I get the implementation issue and the way it's done right now. I, I'M I think this isn't right. I mean, I think that shouldn't be different. I think I should be able to find the location of that cell. You know, and honestly, as soon as I go in the cell, I would like it to show me that's the location of the cell.

Yeah, I definitely agree that that would be desirable. You know, I'm not going to promise that on any particular timeline because I don't.

Fine. Not for this meeting offline. Have a think about it. See whether there's an easy way to do it. And UX wise, to me, lighting up the border of the cell you're in seems like a good idea.

Can we light up the border?

I don't know. I don't know.

The. Yeah. Too much to say for this meeting. I. I can. We can talk about it.

All right, well, we'll have a private meeting with John and. And.

Yeah, right. But I mean, I think that the, the particular question you're asking, it's a win. What we've got here now, I think looks really good. I like the border. I like the BO of its. You know, the reasons why we had to have that border. I think the gor border is a good thing. Okay. I mean, the fact that I might go and try and click down there and then it's gone by the time I get my mouse over there is unfortunate, but that's the way it is. That's the nature of. Of hovery type stuff.

Yep.

Okay, let us. Let us go, Diffie.

Okay.

Right, so we had a meeting. Right? Well, we, we had one meeting in LCC and I think a dedicated meeting and so. Yep, that's allowing you to get the. The latest version.

Yeah. So you are. So this meeting will be with the same version of Diff Tools that anyone can get from the Paclit repository today.

Great. Okay. All right, you have to warm me up because I feel a little bit forgotten where we got to last time. Okay, let me see what that does. Diff of that.

Right, so that used to return a summary box that you would then use Diff View to visualize.

No, it used to return just a completely naked list with some red and some green.

Oh, that's right.

And one of the things that we had decided in the last meeting was that we wanted some sort of chrome around the output.

Okay. So I think that Chrome, graphic design wise, I think it's a bit too big and too heavy, which is why Billy is here. Right. And I'm also totally mystified by the lists. Colon 1 edit. What does that mean.

It means that it's detected that you're comparing lists and that it has seen one edit and the edit is changing.

B and C to D. Okay, first point. The fact that it says you've got a list. Well, I can see I've got a list. You see what I'm saying? That's your internal.

I hear what you're saying.

Yeah. So it's, it's more obvious here. It's less obvious for other kinds of things that you're diffing.

Okay. I think we gotta find a way to.

So, and this is a good example, you know the. When you're diffing strings, you can diff by character, by word or by line.

Okay. Okay.

Now, I'm not necessarily defending the current presentation, but I think we do need something.

I don't disagree, but I think the best thing to do would be if I've got, you know, diff. The cat was on the mat. The dog. I'm going to put that in. The dog was on the hat. Okay, so that's a character level thing.

And, and maybe maybe do a copy down. And is it the third argument, Louis, an option?

Granularity.

What is it called?

Diff.

Granularity. Arrow quote.

Words.

Okay. All right. So to me, if we've got this Chrome and you've got this word here, you might as well have it this be a pull down where you can select do I want characters or words or whatever. Maybe not.

Keep in mind, this isn't just a view, this is an object.

No, I understand. Well, okay, so, so first point here is. Okay, so the first thing we're talking about here is this thing is an object whose normal form, Splafaroo. What should that do? Clearly not.

I don't, I don't know. But you can, you can do input form at least.

Actually, maybe it's more instructive to copy that output and paste it into an input cell because this is another key feature.

Oh, right, that's the bug I reported last night.

No, copy that. No, this is. This was supposed to work.

Okay, what. What should I do?

It was supposed to have seen.

Look at the sub box.

So put your cursor in the percent seven and start typing.

Out of seven.

Yeah.

Or out of whatever.

Or out of.

Yeah, one of these outputs. I see. So it minimalizes that.

Yeah.

For better or worse.

And, and, and you know, and also helps to, you know, give you confidence that this is indeed a computable object.

Yes. Okay. All right. I mean, clearly this. I know how this font Ends up being bigger than this font here. Just seems crazy. But that's just a detail. Makes sense. That is detail. Yes. Yeah. Okay. So, I mean, I have another question, which is presumably the color scheme for what's first. I mean, like, I don't know. Maybe it's just me, but I see red means you're removing from. This is the removed things, and that's the added thing. Green means add, red means remove.

This is. This is very standard.

Okay.

I mean, you know, the shades might be slightly different from one place to the next, but. But the use of red and green is, unfortunately for colorblind folks, extremely standard.

We can reset it if we want.

Yes, yes, we can. And I think, Lou, do you have a preset colorblind theme or.

I don't quite have theme support spun up yet, but once that's accessible, then, yes, there's one waiting to spring into action. I just don't quite have the pipes done.

Okay, so. All right, let's. Let's take a look. I mean, I want to come back to this because there's things I want to see what you're doing, what happens for notebooks. Can I see that somehow? Or even a whole cell? How do I. How do I see that?

Sure.

So.

Well, one thing you can do is you can go to the palette menu and bring up the go to. There should be a Diff Tools submenu about halfway down, and there's a compare cells palette.

Okay, how does that work?

Right, so you click on one cell that you want to compare and, you know, click. You say, then click on the Use selected cell and do that for the other, and voila, you get.

Okay, so let me consider a use case that I might actually have. Right.

So, you know, you can just do it just to see it work. You can do it real quick with the N9 and N10 cells. Th. Those are. Those would be sensible inputs.

Okay, so I hit this. Use selected cell. I hit this. I say, use selected cell. And now what? Oh, I see. It just took a while to come up. Is this really scalable, what you have here for multiple cells and so on?

It's. I mean, yeah, it's. It's going to struggle with giant cells. Yes.

What does it do with graphics?

Currently, it does nothing special for graphics.

If I make a disk, you know, three disks that are in the same place and one of the disks in a different place, do we have any hope of being able to indicate that in a sensible way?

The next thing I was intending to do was to diff Graphics as, as images, as bitmaps. I haven't yet thought about diffing graphics as, you know, sets of vectors.

So I, I, I don't think that doing any kind of vector diff in the way that you're imagining, Steven, can possibly be in the remit of something we would ship for the next release.

Yeah, okay. I mean, we could diff compression.

Yeah, we can certainly diff the box expressions.

Yeah. I don't know how useful that is.

Well, in some cases it is actually.

Right. And. Right. I mean, if it really is two disks, you know, if you're comparing something with two disks and something with two disks. Right. I mean, the boxes are practically identical to the input form of the graphics. And so I would think that in that particular case that would actually be pretty useful because you could just see, oh, the coordinates of the second guy are different. Now, if you're going to diff to outputs from plot, which is ginormous, then, yeah, that's hopeless.

And also, plot is not engineered for something that looks like reproducibility across a range of inputs. I mean, it may make decisions to do something radically different based on inputs that don't seem radically different. Right.

Yeah.

And Steven, if you want to try this, I think you can just, you know, create the two inputs and then wrap them in expression cell and diff them. And that will give you the cell diff that you were thinking of.

Yeah. Okay, but let me just understand. Okay, so a use case that I would have is, is I've got two versions of a thing I'm writing, and they have certain diffs. And what would I typically want to do? I would typically want to take those diffs and for example, accept or reject diffs. Do we have a mechanism for doing that?

That's not something I've gotten to yet. It's obviously something I want to have the ability to. We have applying all of a particular diff as a sort of single patch object from one expression to create another expression. I don't have, you know, take, I want this one, I don't want this one, I want to reverse this one. That's not something I've built out.

Yeah. So basically we've been spending some Polish time, but the Polish time has all been on the diff side, not on the merge side.

I see, but so, so what you imagine is that one of these diff objects has essentially a stream of micro diffs. Is that true?

Right. We're typically called hunks in the diff world. Each change set is called a Hunk.

Okay, but so, so do we have. I mean, if I say hunks, you know, if I one day would I be able to say hunks of a diff and it would give me a list of hunks or hunks list or something of the diff.

That's reasonable. Yes.

That would give me a bunch of other diffs, basically, which are the micro.

I mean, one of the things that we definitely want to do is have some kind of algebra of diffs, you know, a way to split up and merge and otherwise, you know, sort of transform sets of diffs.

Right. So, I mean, roughly what we're looking at here. Let's think about this for a second. I mean, you know.

Each.

We thought about this a bit in the last meeting and one of the conclusions we came to, or tentative conclusions was to work towards a diff modify function analogous to molecule modify that would be able to do these sorts of things.

Would it modify the diff or would. Because.

Right.

Molecule modify modifies the molecule, not the modifier of the molecule.

Correct. So there'd be other, I mean, there'd be interactive gestures for applying the modified diff. But if what you really want is to modify the diff directly, then I think a diff modify function is a fine thing.

Fair enough. But I mean, I think, I mean, somehow to me, I can imagine a couple of scenarios. I'll give you an example. Editing stuff. Okay. I might have a long document. Somebody might have read it. There might be 10 typos in the document. The long hundred page document. Only ten typos are left. I don't really want to scroll through the whole document to see those 10 typos. Rather, what I want to be able to do in our environment would be just get me the list of those 10 typos with their context and I'll just click through and say accept, reject, et cetera, those things. And then I want to take that collection of diff like things and apply that to my original document. Does that make sense?

Yeah. Now, and by the way, something else that you might want to do is you might want to annotate the diff.

Yes, indeed.

Instead of directly applying it yourself, you kind of having a conversation with someone else who is also, you know, consuming that diff object.

Okay. By the way, have you guys seen the whole blog tool system that's been built for me over the past, I don't know, 10 years or something?

I have pieces of it, but you.

Should get a demo because it has a bunch of relevant stuff. From whom? I think, I don't actually know who built it. Maybe Jay Warrendorf built it. I'm not sure. Mark Long would certainly is a big user of it. I'll reach out to them. I do think, by the way, that those tools with a few very specific, you know, things that have, you know, SW comment or something as a, as a piece. But those tools should probably be packetized and, or put in WFR so we can, so people can create them, those kinds of things. Because that, that's been. I, I would say that that mechanism. Well, you should see how it works. You should see how it works. It's pretty good. I mean it's been, it's been gradually refined over about a 10 year period. And in some ways, you know, if the, if the goal is editor makes suggestions on a notebook, it's probably pretty well optimized for that. And it's not obvious that this is that what you have here. I mean one needs to think about how that what you have here merges with that. Does that make sense?

That's certainly not been our primary mission. I mean our primary mission is to, you know, to solve a bunch of core problems.

About code or what?

Well, about a variety of things. But you know, one of the big ones is notebook diff. Notebook merge in a fashion that is going to be friendly with version control. Yes, but that's not the only issue. You know, certainly I have, you know, in the past I have created, you know, one off diffing tools because, you know, I, I have these, you know, in my case it's often because I'm looking at bugs that have to do with cells and I have two cells that are mostly the same except where they aren't, or two expressions that are mostly the same except where they aren't. And I need to, I need to see the pieces that actually are different. But it's like a huge tree.

Right, okay, let's keep going on what we've got here because I think I'm the case of sort of the, the. You, you should look at these blog tool things. I mean, and you know, it's a slightly different case than probably you've been considering. It's the case where, you know, rather than two people having worked, it's like one person is the author, another person is the editor, which is not the usual code case. Right. The usual code case is different people are working on the same piece of, you know, same file and they, they modify different parts.

It's peers. Yeah.

Right.

Now, you know, I would say and it's also historical. It's, you know, it's archaeological as well.

That. That is. That is certainly one of my prime.

Use cases is what. Is to see what it was, what the code looked like at one point in the past.

Yes, either.

Either what it looked like or when that first came into being and why. Yeah, if. If the person wrote a useful commit message. Although oftentimes with the code I'm working with, I. I get to Rory Murtaugh initial commit.

So I know that commit.

Oh, that's the original commit in the source system.

Yes.

That's funny. Okay. The.

Fun bit of history, Rory was like boss number four for me, I think, in the company.

Interesting. Okay, no, somebody should tell him that we still. He's. He's still seen in the. In the archaeology. Okay. In any case, the. What was I going to.

So, I mean, we were just talking about, like, code archaeology and the difference between that and the authoring story.

Right. Okay. So the other, you know, the case of word processors and change tracking and word processors, that's much closer to the thing that we're doing with editing of notebooks, so to speak.

That is correct.

And in the world at large, to what extent is kind of like, I'm going to write my documents in. In Git type thing with git and have multiple people working on it, versus I'm going to do it in a word processor where it's going to have change tracking. How do people view those two things? I mean, I've certainly heard of people, like a decade ago, I heard people. Everybody was enthusiastic, oh, we're going to use Git to do all of our, you know, collaborative editing type stuff.

I think it depends on the field and the kind of getting the conventions in the field. I mean, like, for example, it's my understanding that legal folks are, you know, I don't hear of some, you know, mass movement to plain text and diffs and that sort of thing. You know, they're. They're, as far as I know, they use. Are using change tracking in word or comparable word processors, and they're very happy with it.

Yes, that is my impression also, because. Because the typical thing is that there isn't usually contention in a single document. So I'm saying, in other words, it's like person A modifies it, then person B puts in their changes, then person C puts in that changes.

Yes. Or if. If they do diverge, then there's. They know they're diverging and someone's responsible for, you know, opening the various copies and synthesizing them in some way.

Right. Whereas the case of programming where, you know, I don't actually know why that's so different, because I. Why is it different? I mean, it's. Because the pieces of code. Yeah. It's kind of funny because in a document, right, it could be the case that somebody changed. This is an interesting point. I mean, in a legal document, for example, it could be the case that somebody changed the definition at the beginning of the document. And the truth is that that should blow up a bunch of other changes that were made, but nobody knows that. Right. Whereas with code, it's just not going to work.

Right. It won't even compile.

Right.

Well. Or, you know, sometimes in the worst case scenario, you end up with something that compiles but introduces a sneaky bug. Fortunately, that's rare. But it does happen.

Right?

Right. Sandra is commenting that sometimes these things that have simultaneous collaborative editing are useful. Yeah, I mean, I, I see that from time to time. I mean.

Yeah.

And yeah, I, I was also going to say, I think the, the legal folks, you know, tend to be more templated. Right. There's a template for, you know, this kind of document and then, you know, you fill in and tweak for whatever. Whereas in code, you know, typically you need to write something for this feature, right. Which may be a completely standard thing, but you still need to, you know, write it in this language, in this code organization to make it fit.

So that feels you're saying it's written more from scratch. I don't know. Some legal documents are written from scratch, but I think, I mean, in, I mean, okay, there's a completely separate path and I don't know how that relates to all of this, which is the collaborating, collaborative editing effort in the cloud. I mean, collaborating editing effort, collaborative editing on the desktop. We've actually had experiments with using the channel framework and so on. Right. Ten, five, ten years ago. Right. But. But I think that's a weird case that I don't think people really want, that is two people have notebooks. I mean, it's funny how this has evolved because the very existence of zoom like things has made it less important to, for example, be able to stream notebook content. I don't know why, because. What's that?

Yeah, I was going to say. So, you know, my impression is, right, I. Because quote, unquote, collaborative editing is either sequential. So, you know, person A writes something and then sends it out to their colleagues. And then person B says, how about this? And then we review and etc.

Yep.

Or, or people, you know, if it's really more simultaneous or, or asynchronous, then people will be using some, you know, Google Docs or you know, I work cloud or whatever it's called these days.

Because I mean I, I, I, I have, I have serious doubts as to whether anyone actually does literally simultaneous stuff. I mean, I, I suppose I can envision corner cases, but I think, you know, these, you know, you know, these platforms for simultaneous editing, it's really much more about lowering the friction of taking turns.

Yeah.

You know, if, if I don't have to save and send it to you to take a turn, if I just have to, if, if, if, you know, I, you just take the opportunity to say here, let me jump in and fix this, you know. Right. By the way, I mean taking turns is almost free.

Things like Dropbox don't even bother to try and do mergers. Right. They just say it's conflicted.

I.

That'S certainly the case for, for nextcloud. I don't know that I have enough experience with Dropbox.

So they don't do merge at the content level, but there is a merge problem they have to solve at the file level.

Sure.

You know, a file appeared in, in one client and was renamed in another client. And now what to do?

Right. Let's see.

Right.

But I've, I've certainly run into the problem where, you know, I was on a plane and edited something in nextcloud and then I landed and discovered that Carla had edited or whatever, you know, for appropriate values of Carla. And you know, and then it just yells at me and says, you know, I need to do something to fix this. So.

Interesting. Boy, somebody on a live stream complaining about my microphone, which surprises me, but interesting.

You sound fine to me.

Likewise.

Okay, so, well, all right. I mean just, just a separate issue which is in the cloud, we are certainly working towards a collaborative editing story which will probably be a cell by cell collaborative editing thing. And I don't know how that relates to any of this. I mean, for example, storing the information on who edited what when, which, I'm not sure how much we were planning to do that, but that symbolic structure might as well be the same structure. I mean, I'd like to remind you sort of cautionary tale in quotes. The story, you know, what I insisted got put in, I don't know, 15 years ago or something now of cell change times data. We now have at least a WFR that I think Lou wrote that gives you the symbolic structure of the history of your notebook. Right. Yes, I mean, I'm not sure if I've used that. I've certainly used it in the past with some hackiness. That's kind of the notebook archaeology story.

Presumably, to be clear, it's not the history of your notebook, it's the history of when content was either created or modified. So it's, it's like, it's like time series, but it's, it's not including the content of those changes.

Okay, but I mean, what I can imagine is that your calculus of diffs could be something that could come out of that. That is, I could ask the question, you know, how was my notebook built? That's essentially the git history question of, you know, how is Right.

Yeah. And you know, there have been, you know, various ways that people have used git to analyze source code bases, to answer big picture questions about how code evolved. And yes, in principle with this sort of thing, one could build those tools to be useful for notebooks as well.

Right, but so what I'm saying is in terms of how these things fit together, one could imagine that one could take a notebook and one could say, make a hunks list for this notebook. In principle.

Between two different revisions.

No, no, between. Between, between the big bang and where we are today. Notebook creation and where we are today.

Yeah, that's a series of so between in different revisions and gets.

I guess so. Yeah, yeah, yes. I mean it could be a. This was the state at this time and I mean clearly. And this relates to the wonderful world of multi way systems and so on. You could have these and that, that's where for example, in the. These, what are they called? CRTs, these. Oh gosh, what is that? It's this data structure.

CRDT maybe.

So what does that stand for?

Yeah, Conflict three resolution data type.

Yes. I mean that's one of its use cases is these collaborative editing environments. And that relates to this question about if you look at the graph of all histories, you know, do you have these conflicts in that graph? Otherwise known as rauncherly separated events in physics. Okay, let's go look at some more of this stuff. So first question is the graphic design here. And this is just really heavyweight as far as I'm concerned. I mean the main event should be whatever it is you're seeing in the actual diffs. And this stuff up here should be really light and Billy, I think that's just a question of, I mean, change the font size, maybe gray it down.

Okay.

I don't know whether it needs to label itself as hello I am a diff. Because I think it's pretty obvious from what. What it is. I think that arguably this should be a cool down for the ca. For the, for the characters versus words case. I am unconvinced that this, there are three edits here is important.

Well, it, I mean for this case, unclear. But for larger cases, I mean it's giving you an idea of just how many differences are there. What, you know, quantify it in some way.

So in the hundred page document that you were mentioning earlier with 10 changes.

Yeah, that's. That's a useful. Right. It would be even more useful if.

I could jump to them and there are three kinds of changes that it's going to flag. A change might be an addition, a removal or an edit.

Indeed.

Well, and breaking those out is also handy information.

It's kind of the indel versus substitution. Yeah, right. I would, by the way, I would put the edits. If you're going to list these, I would put the edits first. Or it's one edition, not one edition, four edits.

Okay.

And maybe you should say one insertion, one deletion. That might be clearer. See what I'm saying?

That's reasonable. Yes.

Especially as that, you know, follows the bioinformatics nomenclature as well.

No, I have no problem with the word insertion. That's fine.

Okay. I wonder if we need. If the graphic design is such that I don't know whether these are. I would assume that that should be space. Character. Space alignment there.

Well, right now, deploying the actual, you know, string, the in input string.

I know the unreviewed input strings.

Yeah, I, I think that for this pull down they should be plain English type stuff. If we're going to do it as a pull down like that.

If it's plain English, then are you removing the capitalization and if you're removing the capitalization, then is that going too far and strain from what the input form would be?

I'm not sure. I don't think it does. I think that people. I think if we have the right auto completion when you're actually entering it, it's probably okay. I really hate this.

What do you hate?

Lists.

Ah, okay.

Yeah, I understand. You know, to be honest, I'm not the happiest with it either. But I, you know, I haven't spent as much time maybe as I could thinking about how we could present that information, but I think we should present it in some way.

But what about the summary box rendering between in 13 and in 8 in your notebook? The fact that that mentions lists up top. Is that similarly distracting?

I think by the time it's a summary box, it's kind of incomprehensible. Anyway, I'm not as bothered by that. Look, I think what we want to do.

Also.

This isn't right. Because this isn't right. This isn't the right. There's another problem here. This says the unit of Stephen.

Stephen.

If we take, you know, if you copy in 13 and then you put the.

The.

The. No, no, no, the, the input above and you put strings, you know, you put strings around each of those two inputs.

Yeah, Okay, but I have a more serious problem. It's a very straightforward problem. This is not list. This is list element. It's the granularity of the thing that you are different.

Yes, it's.

It's not quite list elements. It's more sequences. There's a, there's an. A sequence that has been edited.

Okay, okay, so. So if I were to do, for example here, and this is made a.

Little bit more clear in the summary box. If you were to open that summary box, you would see that how the hunk is. Is presumed to be.

Okay, so let's take range of 10 here and then. Oops, then I want. What I want. There is. Oh yeah, that was separate list elements. That wasn't a sequence. I mean, it could have said the sequence was removed.

Yes, it's possible. There's a disconnect between counting of removals and counting of edits.

I should say three deletions anyway. Much clearer. But that's, that's irrelevant. I mean, I think here, let's say we go, you know, six, five, four here.

Maybe you really want to do abc. Something that's completely unrelated to. Yeah, that's three edits. That's. Try instead of abc, try, try delete the C and see what it does. Yeah, this seems like.

Yeah, yeah, there's something not quite right here.

Okay, so let me, Let me comment on your algebra of hunks or whatever. Clearly there are. It is not obvious. There are many forms given that you have certain operations. You know, if you have pure single element insertion, deletion, substitution, it's unique. But if you. As soon as you allow sequences, there isn't an obvious canonical form. See what I'm saying?

I don't understand what you mean by canonical. There's. There are multiple ways that one could.

Right. As soon as you have sequences, as we see in this case, there are multiple representations for one death.

Right?

One overall diff could be represented as you delete this, then you add this. Or you could represent it as you delete the sequence, you add the sequence, et cetera, et cetera, et cetera.

But is that fatal in any way?

No, it's not.

Well, but those two are different things. So think about the notebook case. When we have a cell now we know cell's provenance because we have expression uuids. We know if a cell has been edited or a cell has been added.

Fine.

So it's.

I, I understand. The point I'm making is in your calculus of hunk, I would expect that there is some simplify function. In other words, it is, I don't know, an important point, right? It's. It's. There's no, there isn't a canonical form. So in general.

Correct.

Okay. So there are multiple ways that can be represented and you know, to me.

The.

Here are a bunch of. It's sort of an interesting case because. It reminds me of these sort of combinator type. Apply this thing, apply many. Boy, it's weird because we also in principle have operations like this. Yeah. I mean, there's some data structures where they work like lists. There's some where they will be a mess, like even arrays or matrices. You know, you can't just go willy nilly and say I want to remove this block in this matrix. And you know, you, you get. In the case of lists, you can just remove blocks and there'll be a reasonable thing that you get out from it. In the case of a 2D data structure, you'll get a thing with holes in it, which is a whole different story. I mean, that's in a sense what we're dealing with in geometry. Anyway, never mind the. Okay, I, I'm.

Okay. So this, this next item has to do with.

I understand what this is. They are. I would think that appearance would be the better. What do you think? I mean, the.

So there are two different things that these are doing, right? One is show me the diff without the.