 So, everyone, welcome to the next talk by Mark Andrejtano about WIS editor. Did I pronounce it correctly? Yeah, more or less. Welcome to my talk. I'm Mark and I've been developing this editor for the last couple of years. So, first some historical context. Basically, as the talk mentions, we combine model editing with structural regular expressions. On the left, you kind of see the left branch, which is model editing from VI. And then we have right branch, which is from the Plan 9 editor, Sam and Acme. And to get a kind of feel for the audience, how many of you have used VI? Okay, so that's more than half. And how many of you have used one of the Plan 9 editors, for example, Sam or Acme? Okay, that's quite a few less. So, and then what is this all about? So, I would like to start with a quick demonstration to get you your interest. Basically, what we will do here is now we will try to select all comments which contain a to-do marker. For that, we use a structural regular expression to select all occurrences of to-do. Now, the editor created these to-do mark, these selections. And now, we use a text object to extend the selections to the current lecture token, meaning that the comments will then be selected. So, as you see here now, this worked for both multi-line comments and single-line comments. And now we delete this. And the next thing is we want to rename a function argument. So, we selected the first occurrence and then we search for the next. We skip one and finally we have what we want and we change the name of the argument. Then, we select the whole arguments and we split the selection in comma, remove leading and trailing white spaces and then we rotate selection contents around. So, by now, the argument order changed. And finally, we can also split selections by words and then align them, for example, to quickly format some code section. Yeah, that's for the demonstration. Now, back to our demonstration hour. So, the first thing is model editing, but I think we can quickly skip this as you're familiar with VI. So, it's basically just a concept that the same keys can be used for different stuff, depending on the context or the mode we're in. And here a quick example. So, we express something like we want to delete two inner blocks. And this is the underlying grammar. So, we have an operator which says what we want to do account how many times something should happen and then a text object hear it. And I really think that's the correct way to learn about the model editor in general is to consider the grammar underlying it. And for now, we still follow the same basic grammar as VI. So, we have a verb object form, meaning we first say what we want and then to what it should be applied. But we might change this, in fact, in the future, because we could as well have it the other way around with object verb or the meaning we first select what we want to do and then say what we want to do. And then the second thing which this editor does is structural regular expressions. And the name is a bit unfortunate because, well, it can be a bit ambitious, but it's basically the concept introduced by Rob Pike while he was working on the Plan 9 editors. And he basically realized that often the model of files as an array of lines is too limiting. It is, in some cases, much more elegant to express the range on which we want to operate based on regular expressions. And these are a few examples. So, for example, if we want to search and replace, we can first extract all occurrences of Emacs and then change it to VI. Note that this is all an interactive process. So, if we stop these pipelining commands in the middle, for example, if we would only extract all occurrences of Emacs, then you would be dropped into visual mode with selection for each match, but then further modify with your regular model editing commands. And then, for example, this would indent some range by first extracting the start of a line and then inserting a tab character before it. Similar, we can dedent by extracting all lines which start with a tab character and then once we've defined this range, we can delete it. And really, this structural regular expression command language is quite powerful because it has these looping and conditional syntaxes. So, what this here does is it selects all occurrences of Lua and then within that range, it selects all occurrences of lowercase l and then once we have this selection, it changes it to uppercase l, resulting in the correct capitalization. Then guards, what this command does, for example, is it changes all lowercase i words into uppercase i. It does this by extracting all words and then filtering the selection to only keep those matching lowercase i and further change it. And then, yeah, we can also integrate very well with external tools so this would just select a range delimited by start and end and then pipe it through sort. And we can also group commands. Yeah, this would result in the same outcome as the very first search and replace command by first selecting all occurrence of Emax and then before this selection, inserting a w and then deleting the original selection and appending an i. Yeah, and these slides are mostly for reference so we can define these ranges on which we want to apply something and then once we have such a range, we can do something with it. We can append text after it, insert text before it, change it completely or delete it. And as mentioned, we can interoperate with external commands and really the looping constructs are what makes this interesting. And conditionals, as we've also seen, so once we have a couple of selections we can filter them to only keep those matching a certain regular expression or only those which do not match a certain regular expression. So really what I would like to emphasize here is that selections are a core editing primitive of the editor. So it's really about an interactive workflow. Now you might think that in WIM, for example, you can do with visual block mode or with macros but I believe that this here is really a much nicer and interactive experience. And some stuff is really not possible, for example, like the selection rotation or alignment or at least not easily possible. So selections, yeah, besides these structural regular expression based commands we also have some key binding set up to, yeah, with more traditional like actions which create selections on the neighboring lines, for example. And of course, once we have selections, we can also remove them. Parts of this was also shown in demonstration. And then again, with multiple selection it allows us to do stuff like alignment, rotation and we can save and restore selections to marks. So, and then perform the regular set operations on them. So this, for example, allows them backwards workflows. So normally you would start with a selection and then split it up further until you have what you want. But sometimes you then realize that you want to restrict the action on an aria of your document which has no real common shape or form. So you would then save the current selections to a mark, drop the selection, mark it, mark new, a new region and then perform an intersection. Thereby restricting the region you operate on. So then a few implementation details. So we'll use Lua's scripting language for in-process configuration which is quite nice, I think, much better than WinScript at least. So the API is still in its infancy but you're able to map Lua functions to keys, implement new operators, motions or text objects. And really the design philosophy of the editor is to keep things simple, robust and fast. We try to restrict the functionality to strictly editing stuff. And as a result we're also really lightweight and easily deployable. For example, we have a statically linked muscle binary, statically linked against the muscle lip T binary which can be dropped on any Linux system and it should work out of the box. How it is done, we have around a small C code base of the editing core and then as I say at Lua as a runtime configuration and scripting language. And we have lots of future plans but not enough time at the moment to implement them. So what would be really nice eventually is to lift this kind of structural regular expressions onto the semantic of the document being edited. So if we had like the AST of the underlying document in memory then we could start like applying these queries to the document structure. And for example with selections we could extend them based on the AST. So if you have a selection in some expression we could grow it like outwards until you had the correct region you want to work with. And yeah, that's basically where your help is wanted. So if you are a C hacker or a Lua developer or some other person interested in model editing then feel free to join us. There's also lots of non-coding related tasks available. Packaging for example. Yeah, so to conclude it's not just the Vi clone. We do things differently and we are also not afraid to break existing conventions if it needs to be done. And I think it's a quite powerful combination of model editing with this SAM's structural regular expression based language coming from Plan 9 really emphasizing on this multiple selection based editing. Yeah, that's basically it. So if you have questions you can find us on IRC for example. On GitHub you can write an email and on the last slides I have a couple of links so if you go to the FOSTEM site download them. You can click on them, these are links. Also the papers here referenced by Rob Pike are quite interesting. Anything from Plan 9 for that matter. Yeah, and the last couple of slides are the keys used for the demo if someone wants to reproduce it then there's also a screencast mentioned. Yeah, happy to take questions. Thank you for the talk. One quick question. Exactly. So the question was how does this compare to Kakun? And yeah, Kakun has gone a bit further apart from VI in that it changed it said as you mentioned it changed the editing grammar and that's also an option for VI for FIST which we might consider in general. Kakun is a bit older but it's a really fine editor. It's also one of the influences I would say but we can later catch up if you want. Okay, thanks for your talk.