 Let's get started. I'm Dan Leigham, my talk is, it's time for a Ruby editor. So it's time for a Ruby editor. What on earth am I talking about? I've got plenty of Ruby editors out there, right? Well, when I say Ruby editor, I have a particular kind of thing in mind. I'm thinking of a self-posting editor. A self-posting editor is an editor or an idea that's written in the same language that it's used to edit. So it's like a circle of them. And there are quite a few of these. There are a lot of these around. Almost certainly use them at one time or another. Some examples, the editor of the language. Padra, Pearl ID, Eclipse, a Java ID, Wing from Python. Another one is Small Talk. The development environment is written in Small Talk itself. So you've probably been using these, and these are popular editors. Why are self-posting editors so interesting? A few reasons. First of all, integration. They're written in the same language that they're used for. They usually run in the same language, run time as the language you're using. So features such as syntax analysis or a debug in, are usually easier to come by and more powerful. It's also more convenient. You already know the language, the editor is written in, so if you want to extend it, you can do that very easily. It's a lot of fun. Sometimes you want to drop down and just mess around and you're ready to even do that. People enjoy tweaking and proving their editors. They can do that. That relies on you actually liking the language that you use, but I think that most of us here, that should be true. And finally, there's a lot of power in having an editor that's implemented in the same language. What I mean by that is, every extra ID has a plugin API. Now if plugin API is written in the same language as the editor is implemented in, that means you can usually do a lot more. You can write plugins that reach down to the guts of the editing changes. You're not limited by a language divide. So for all these reasons, sub-listing editors are popular. And they exist in the Ruby world as well. You've probably used at least one of them, especially if you started with Ruby a few years ago. There's an ID for free ride, which is pretty good to stable IDE written in Ruby and used to edit Ruby. It has very clean internals. We learned a lot from it. And sadly now, a dead project that's in Ruby history that I'm sure a lot of you are familiar with. A more modern example of a Ruby sub-listing Ruby editor is Arcadia. Arcadia is, again, written in Ruby. It's aimed at Rubyists. It has some good features for editing Ruby, like there's an outline view, you can see on the right, and a debugger, and so on. So if that use case is particularly important to you, this might be a good choice. Another sub-listing Ruby editor is Diacos. This is a curses editor written in Ruby 1.9. So you might like to use it for when you show into your servers and edit Ruby code on there. And again, extensible in Ruby. So sub-listing Ruby editor already exists, for sure. But sadly, they haven't seen a very wide adoption compared to other languages in particular. If I was to walk around here, down the aisles and look at what you're all using to code right now, I don't think I would see any one of these. And in fact, out of interest, has anyone used these? Does anyone use these? Which one do you use? I use Diacos. Diacos, yeah. It's a good edit. So not as popular as sub-listing editors have been. Another languages, I think that's a little bit sad because it feels like we're missing something that other programmers have in other languages. So what I'd like to introduce to you today is a new self-hosted Ruby editor called Red Car. Red Car is written almost entirely in Ruby. It runs on the JRU platform using the SWT GUI toolkit. So it is cross-platform completely. You can install it as a gem. And if anyone would like to install it during this talk, please feel free to threaten the wifi. And if you have any problems, I'll be happy to help you out. Or any questions that you have to answer after the talk. And what I'm going to do now is give a brief demo of Red Car. I'm going to keep it short because you've all seen editors before. So, oh, this is going to be, okay. So, this is going to be a point. So, this is Red Car editing project. It happens to be Red Car itself. I'm going to open up a file. And in that, you can see the syntax property. I can do some typing, a very useful one. I can, I've got snippets available. There is syntax checking. So if I was typing in stupid like this and save it, it should be marked, yep. Has a syntax and it'll tell you exactly what that is. Some simple feature that I want to show you because I want to show you the implementation later is go to line. Okay, I'm going to see how much of this I can do without looking at the screen. This is going to be interesting. So you can see at the bottom, there's a go to line command. There's a bar that's popped up. Try and drag that up for you. I can just jump to the location. Pretty simple, but I want to show you how it works later. So, slightly more useful, more interesting. If I put my cursor inside this storage word here across command tune, it will take me to the definition of the task. So if I select that and open search, I can see all the currencies of that in my project. This is pretty quick because red car has been indexing my project in the background using receipt. So the search is very fast, which is another good reason to be on JRuby because we were able to just get the lucene jar drop in and start using it. That was terrific. With a small raffle, I think it'd be good for someone. If we haven't been on JRuby, getting cross platform indexing solution and working with a heck of a lot more work than a few days working was to get this working. Some features that seem simple, but if you are using particular, I'd say you may be feeling the lack of, it's just really weird. That's another interesting thing is we have, I can't see the menus, it's just wasn't possible. We have a really good record. So this is like an IRB session inside red car. Don't know the entire question there. So you can execute code and play around in here. I can play around with the red car API. Say hello to you all, like so. So you can see this is really a nice way to fill around the side of red car and get handle on what APIs are like. And the press okay, so it will turn on okay. And something slightly more useful. So I've got a document there. That's the fine file document. And it's a Ruby object I can play around with. I can ask it for a line count. So that means that 115 lines, which is correct. I can do slightly more involved things with my document such as I can run up across all the lines, replace each one. This block will be passed to the current line. So I can take that line and say modified, or I can say if the line contains permission, then let's leave it there. So if I execute that, you'll notice that you can do editing on multiple lines here because it's not only evaluated on the press command there. Yeah, so I've been able to, yeah, it's out of definition to the end of every line there. So you can use this to mess around, but you can also use this to script the editor and to do more complex document manipulations that you might be interested in. It feels a lot like the Firebug console if you've used Firefox. You know, that same kind of being able to just make very anything from a console. There's one more thing I want to show you in this demo, which I promised I would do in the abstract, and that is to create a new command for Red Car and add it to menus right here. So we're gonna do that before we finish the demo. There's a My Plugin plugin, which is an easy way to get started with Red Car started adding new things. If I go to Edit My Plugin, it will open up and I can start playing. So the hello world command, you already saw how I was implanted, it's just a message box. We're gonna add a new command. What we're gonna suppose is that for some reason, you wanted to be able to reverse all the text in your document. Not only it comes up very often, which is why there's no command for it already. We're gonna implement this to create command in Red Car. You subclass the other tab command, or just the command class, and then you implement a execute method. The execute method contains the code that should learn when the command is right. So what we're gonna do is we have the doc available to us already here. So we're gonna set the text on the document to be, well, the text the document currently has. Reversed. Naturally, I'm gonna use cars to make sure there are steps, you can see my characters as well. And that's that. We now define the command, we wanna put it in the menus as well. So I'm going to add it to the menus, do it yourself there. And you can see there's so many plugins, so let me write them in two items, and you can see that that corresponds to these menu items here. So let's have the command we just created. And also see we've got auto-continue in it as well. So save that, and now it has not shown the menus, because what we need to do now is tell the webcast to reload this plugin to us. This is the plugin manager, let's store the plugins in the webcast, you can go down to my plugin and hit reload. Then you can go back to here, you can find that again, and there's a new command in the menu. So if we hit reverse text for the good look, that reverses the text. You can see lots of goodies. That's how you know it's really, it's really reversed it. And then you can obviously put it back to how it was before. So I hope that gave some idea of how easy it is to get started adding new things in Redcar. I believe with the current release there's another thing, which is that if you install the gem with pseudo, you need to win Redcar and pseudo to do this. And I'll fix that for the next one, because that's a bit of a test. And that concludes the demo version of the talk. So let's switch back to the presentation. Okay, great. Did you have a question? Yeah, if it's not good. No, but how easy would it be to add a key strip? Quite easy for, if you wanted it in menu, just a key strip on its own in a document. Isn't something that we do yet? I'm planning to keep on doing overhaul as soon as I get a chance. Okay, so everything you saw there, as I said, implemented in menu. Which is a morning break up. Everything's implemented in menu. So the API that we used to implement all these features, and I can show you right now. So the speed bar example you saw of go to line, we call that speed bar. Similar to what you get in Firefox, when you search or something. It looked like that. Very simple. There are some more complex ones. This is the simplest one. And the implementation of that, also, very simple. If you want to create a speed bar like this in one of your plugins in Redcar, all you have to do is create a new class, the go to line speed bar, that inherits from the default speed bar class. And then for everything in the speed bar, you need to declare line by line, exactly this. So the first thing in the speed bar is a go to line label. So we say that's what we've got. Then there's a text box, and there's a button. And the block that's given to the button method is called when that button is pressed by the user. And because this is so simple, I can actually show you the implementation of this. First thing we do, we get the line number that the user wants to move to. And that line method that's there in the block is automatically generated from the text box name that we gave. So that's how it gets the value of that when you press the button. We turn that into an integer, shift it by form. Then we validate that it's in the correct bounds. And if it is, we move the cursor, scroll the window, and close the speed bar. And that's the complete implementation for that. Take it from Redcar, no cheating or anything. So again, it's quite easy to create these kind of features in there. Another example of an API, I'd like to show you. These things. So you probably recognize these from TechMate. The one on the top left is the fuzzy file finder. We also have a jump to class or method and switching views. TechMate uses these in a few places and Redcar uses them all over the place because they're really a nice input convention. And they're very easy to print in Redcar. We call them filter list dialogues because that's conceptually what you're doing, filtering and choosing from a list. And to create your own one of these, you subclass a filter list dialogue and define two methods. Update list, give them a filter. So whenever the user types a new filter into that list, that method will be called and you can return a list back again, which we've been populated with. And the filter on the rank bar is a helpful method provided for you to influence the sorting and ranking algorithm. And then you also implement a selected method. And Redcar will call that when the user makes a selection and you perform whatever action you want. So because these are really easy to create, you tend to do some favor thing because they are a nice way of jumping around at this. Now I want to emphasize that these APIs aren't plug-in APIs per se. Because in Redcar, there's no such thing as a plug-in API. There's just Redcar. There's just the APIs. And that's because in Redcar, everything is a plug-in, okay? There's no distinction between core features and extension features. We've got a lot of plug-ins in core. Here's a truncating list of some of them. I'd like to expand one of the plug-ins and show you a little bit of what's inside in the Redcar plug-in. Every Redcar plug-in looks a little bit like a mini Rumi library, right? It's got a live directory with code inside. It has features and specs. It has tests just for that plug-in. It has views. So that search result you saw will be a ERB template that's rendered so they live inside there as well. There's a plug-in Rb definition file, which lets tells Redcar exactly what the name of the plug-in is, the version number, and whether it has any of the dependencies of the plug-ins that it needs to be loaded. I said that the plug-ins have features. Here's an example of the kind of features we have. This is the feature that tests the auto pair, which is when in Redcar you type a quote mark, it will automatically insert a closing quote. So you can see that test in versus an item. When I open a new Reddit tab and I type quote, then the contents should be quote, cursor, quote. Similarly for parentheses. And then the final one is if I type quote, the prospects face shouldn't be anything then. It should have automatically removed the quotes. And these go on and on. We have these sort of features for pretty much every plug-in in the system. And every API it shows you already has a set of helper steps. So you can do a full integration test of your new filter list dialogue without having to know how the tool works at all. Because you can use those steps to test it. And that's what we approach people to do when they're writing that couple of minutes. So I've shown you a lot of code so far. I'd like to take a step back and talk a little bit about philosophy of Redcar. But there will be more code. Because so far it's a bit like text-made, but it's written in Ruby. What's the actual point of this? So first of all, first and foremost, Redcar is an editor in the text-made tradition. If you use Redcar, sorry, if you use text-made all the time, you might not have sat on the floor about what makes it such a great editor. But the things that jump out to me as making text-made great, it has great commands for text-slinging. And sometimes when you're thinking of figuring it all out, someone will show you some new thing, and you discover another layer. And so there's a lot of power there. Text-made has a philosophy of declarative extensions. So the themes, the grounds, and the snippets, they're all declared as XMAP. They're not code, which allows text-made to remain a very small editor with very well-defined APIs, rather than becoming huge, and still support hundreds of languages. You can write text-made commands in any language just about, which means that for you, text-made can usually be, is almost a self-posting editor. And a lot of the commands in text-made are written in Ruby, which is one of the reasons why it's so popular in our community. And finally, text-made is built on regular expressions. The features are implemented in them, and if you know regular expressions, you'll get a lot more out of the editor. And I think it's true to say that before text-made, editors and IDs did not make such common use of regular expressions. So that's something text-made has brought as well. And there are a lot of editors now that exist since text-made, but very self-consciously placed themselves inside the text-made tradition, because of the new ideas that text-made did bring to editor. So I should say, from text-made, we use text-made's open source bundles. We use the syntax highlighting, we have text-made themes and text-made snippets, because when our created text-made, he made the bundles open source. So there's a lot of editors that use those now, and we do as well. So I should say, thank you, down on my guard, and to any one who's contributed to text-made bundles, because you've been part of what's helped as a bootstrap recommender, and making a great editorial team. So, as well as all these features that text-made has, there's a sort of philosophy, there's a sort of coherence to text-made. And I can best illustrate that by showing you what text-made isn't. With apologies to my friend, who gave me this speech on, who actually implemented a bunch of these plugins. This is a powerful editor. You can tell, look at it. You can feel the power. I don't know what you're talking about. But it's not. And if you need any particular functionality or display there, then you need it. It's useful to you, you've got to have it. But it's still not the direction red car is going in. When I'm using an editor like this, when I have used this sort of thing in the past, it's always felt to me like, I'm sitting at a pub table outside trying to do some work, and I've got stacks of pages there. But it's a windy day. So anything could blow away at any moment. I'm going to keep my hand on this one. We keep track of that one. I don't know what that one's going to blow away as well. I'm going to keep track of everything. If I lose anything for a second, I'm going to lose track of what's going on. So maybe that's just me, but that's how I feel when I use this kind of thing. I much prefer the text-made workflow. Perhaps just it better fits inside my tiny mind just to have these few elements with organizational structure on the side with files to edit and with an HTML preview there. So there's three things that text-made has. Directories, files, HTML previews. I'm implementing these in Ruby, and I'm thinking these things could be more general. Let's take directories to start with. Breakup has directory view. At the same time, over there on the left, you don't just have directories, you can also have bookmarks. They have rate taxes. And these are examples of the category. You get a lot in editors and under-news. Class outline views to do this and so on. And they're all examples of the dominant organizational metaphor that you get in editors and ids, which are treats. So in red, that would say, it's not just a directory you have over there. It's any kind of tree. It's where you keep all the things that organize your work. They live over here. And if you want to implement a new tree of your own, there are two classes for you to define. You need a top-level tree which has a method called top, with the top-level elements. And then it's a recursive definition. I'm going to use, for example, an imaginary node taking plug-in, but it's not going to do well on that too much. And then each row in the tree is a node which has an icon, a text, and every row has to have children, which are more nodes. And also a leaf method to tell you whether it's the bottom of the tree or not. And if you define those two classes and have them to a red car, it'll put the tree you implemented in the sidebar there for you. So they're very easy to create new ones if you want to. So we've generalized this organizational structure to any kind of tree. It's not just direct trees. Moving on to a similar thing with files. Implementing files and thinking, well, it's only a coincidence that these files could be any one of a number of things. You already see a couple of examples. You've got, you've got a file for one thing. You saw the record. That's also editable. And in general, there are lots of things you can edit which you just, they're textual and you want to be able to edit them. Commit entrance or notes or blog posts. Any red car, they're all examples of things called documents. And a document, the tiny feature of a document is it's textual, you edit it. But at the same time, it's representative of some resource that sits behind the document. It might be a file or it might be a running by the instance or it might be a WordPress blog installation API if you're editing blog posts. So to implement your own document, again, very simple. Actually, there's a little bit more on this, but this is a poor bit. There's a title method that appears in the tab. You have to be able to read it from somewhere. So if it's the file you're reading out from disk, you have to be able to commit it. So if it's a file, you're saving that to disk. In the case of a note-taking plugin, you might be reading that from a SQL identity. So if you're not, and maybe the notes are saved in SQL identity as well. So if you have those two things, we might have implemented your own document in Redcar. You can see where I'm going. HTML previews. In TextMate, there's static HTML file that gives the appearance of dynamic nature. In Redcar, you can get much more complex interactions. So you already saw a search view with the search results. That's done inside HTML view. You saw the plugin manager as well. Another one is the task manager. And in general, there are lots of things you might want to display with HTML and then to an ID, like documentation, like command output. And in Redcar, we've got these things. Webviews. I'm looking for a better name. In fact, my code letters will be raising the eyebrows at the same because you won't write any remersals. But they seem to be distinctive of what they did. But Webview in Redcar has two parts. It has a Ruby controller, which is an object that you create. And it has a JavaScript side and an HTML side that lives inside the browser in that tab. And they can intercommunicate. The only restriction being that they have to communicate with objects that can be serialized as JSON. Let's take a look at how that looks if you can imagine a plugin to a view to search to all your notes in this imaginary notebook. Unifying a node search controller. The index method that you define is special. It has to return the HTML, which is displayed. And then you can define any other methods you want. So in this case, we're defining a search notes method that takes a query. That's it. That's instantiated and passed to Redcar. And it displays that in the Webview. Then in the Webview, there's some JavaScript. And the JavaScript might look something like this. It's been a jQuery. When you click on the search button, it can call that search notes method we define on a JavaScript object called control, which is made available by Redcar. And that's how you get that communication back and forth. So this is how the search view is implemented in Redcar that I showed you before. When you press the search button, it collects the JavaScript, the JavaScript collects the values from the form and calls a method on Ruby control. And then receives the results back and inserts them in the string. So we've taken each of the three things from the TextMate workflow and generalized it, making them a little bit more powerful. So what we've done is created an opinionated editor. You can extend it in any way you want, but this is where different things live. We've got a single organizing tool, the tree. It's not completely general, but it's close. And if you have an overview of anything, an organizational view on anything in a plugin, they live over here, so you know where to find them. Editing text is the dominant interaction in any editor or an ID. So that has to find a place and it has its own thing. But again, it can be anything. And for everything else, any kind of custom interaction you need or any kind of funerary display, I'm putting them in a practical way. We've got the web views. So with these three things, people are starting to create some really interesting plugins for a class and really complex things. And it's starting to look more and more like an IDE. Which is something that I always said that it was never gonna be. But it still feels like an editor because it's opinionated about where it's going to live. So if it is an IDE, it's an IDE that feels like an editor. It's a platform on which you can create whatever you want. But at the same time, everything remains comprehensible and your workflow remains simple and sane. I'd like to talk a little bit about the community around Red Car. We have an open commit policy. So if you get a Patrick's at the master, you put on the Red Car team on GitHub and you can commit to master straightaway. So it's something that a Rumbinius project did and the Patrick project did to do its success. And we now have seven contributors, seven regular contributors to Red Car. Tim, over there, is speaking today about adding C extensions to JRuby, which seems like an interesting topic, so you should head over to that. All these seven people, Delisa, Alex, and Matt, Charlie, this is their first Ruby project they contributed to. Which I hope means that Red Car's bringing more people in to Ruby, which is great. And we have more than 35 other contributors as well, which has made a lot of progress over the last three or four months. These are the releases just from the last three or four months. I have hope to get not quite nine out for this conference, but it's not quite there yet. That will have the online project search, some JavaScript syntax checking, and there's a lot of things in there. That should be out soon, by which I mean Sunday. Okay. So given all the part of my work's left, what opportunities are left for people who might be interested in contributing to Red Car? Well, we need a Ruby debugger. There's lots of prior art on this, so you should be able to find some examples of what kind of need to do. We need breakpoints and we need a debugger. The Red Car is currently very simple. It runs inside Red Car, you can't load your project code into it, so you can't get anything by the script console. We need to be able to load project codes that you need to be able to send code from your documents into the record, and that should be an interesting project to take along. Tech to make some multi-language editor. I would like Red Car to be a multi-language editor as well. If any of you came to the Green Regents talk earlier today in this room, you'll know that a lot is possible with JVB in terms of integrating other languages on the JVN. We want to support that Red Car. We have a pretty good closure record already, but it's very simple. So if there's anyone here who uses Red Car, but it's interesting, kind of interesting in closure, I don't know if there will be anyone like that here, but if there are, you can contribute to Red Car. You can add closure support, you can work on closure on a meta level when you're belating the runtime and you will learn a lot by doing that. I wish I actually had time to do that to be honest. Another small thing, the web views are very manly. We're writing a lot of the HTML out of itself. If anyone here is interested in Rails 3, we'd love someone to come along and take action to help us from Rails 3, which is, first, we all work for an extensible map and bring them into Red Car so that we can use them in the web views and we can use them in the web controllers. So if anyone's interested in Rails 3 and Red Car, that'll be a fun project to take on and you get something done quite quickly at the end of that as well. I want to emphasize that this is not yet one-pointed project. So it lacks a certain polish. There are some things that you'd expect to find that aren't there. For instance, like incremental search is work. We don't have that. We've also got quite a slow start of time. Sorry. One of the Red Car's running, it's pretty quick. Loading a project is instantaneous, for instance, which is great. But I hope you can see past the rough edges and see some potential here and come and join us and help make Red Car a great review of it. And hopefully, in the future, when we come, I'll be able to walk down to us here, take a look at what people are using and see them using a Ruby Editor written in Ruby. So thank you all for listening. If anyone has any questions, maybe it's time. How hard would it be to add Emacs and VI key bindings? I said earlier that I'm planning a key binding overall. One of the things I'd like to do is to make swappable key maps. I think doing that is a way that you could say, this command swaps out key map for this one would enable the V-Mode as big as you could say and then press I. It swaps out that key map for a new set of key maps. So that's on the roadmap. Anyone else? Yes? So I understand the point, but now you're adding another one, which is important. Which is interesting, because you would think, was there a purpose that you're going to enter? Or is it focused on Ruby first and that it's just a weird dichotomy? I see. It's focused on Ruby. But I wouldn't be averse to adding other languages on an equal footing. I suspect that it will always be with Ruby in the core and we will have some kind of translation layer. So at the moment, focused on Ruby, but it shouldn't have to be. It's on the JVM. There's a lot of fun stuff we can do. I hear the questions. What's the best way to get up to speed with the API? I know it. What's the best way to get up to speed with the API? I would say, look at some of the plugins. So you might have to look at the macros plugin or you might have to look at the declarations plugin, which is the thing to jump to declarations. Looking at the code, it's still the best way of knowing where it can come in. So, any questions? Yeah. You had a question from earlier. Yeah, actually I've kind of abandoned that question, but one of the things that's interesting about self-hosting editors, we were talking about this the other day, is that they have access to like the AST in the language so that you can do smarter refactoring and navigation. How much does Red Car support that and what types of tricks can you do with refactoring from, with your whole honor project? So the question was, how to use JVM in Red Car to get better refactoring support? And something we do for that already is the syntax checkup. That loads JVM, uses the JVM, syntax parser to check syntax. And for other languages as well, and we have a JavaScript checkup as well, we use Ryder for that to do JavaScript checkup. And as for further interesting and firmly refactoring things, I think that would be a very interesting project to take on, but no one's done much with that yet. Someone did it with the R-Sense plugin, which gives you some more advanced code completion and I think some refactories, but it's the obvious thing to do, it's just there's a million on these things. Yes. What about, how hard would it be to do a collaborative editor? Now, didn't someone, Tim, didn't someone say that we're gonna start working on that? Collaborative editor. Okay, maybe that was just loose talk in IRC. I know nothing about that. In the sense that you can modify anything in the editor and there's some very good hooks for adding new things. For instance, I suppose at the back end of the document could be something clever, I don't know. I think it would be as easy as that to be an editor at any editor. It's possible to edit files using SFP on other rows and if not done, how easy would that be? We have a remote project plugin, which is not very well maintained because as far as I'm aware, none of the content is actually gonna use it, but it does work, it can be made to work quite easily. I'm looking towards other ways of using remote projects because in terms of all that new C indexing that's going on and you won't get those features. So, a much better option I'm exploring is using R-Sync to keep two equestries in close sync all the time, which allows you to have all the great project features in a remote project as well. But still to be decided, finally, that's where we're going to go. Yes? Is there a go-to place for red card bundles or plugins? The red card organization on GitHub has a red card-bundles repo in it and it's a clone of the text-made bundles with some minor modifications. Can you install... Yes, you can. I mean, can you bundle onto the camera? Bundles? Not quite. Something I'd like to add, especially if we have the other Ruby gems or the every language support that would be great. Obviously, it is to customize one of the tree view, for example. Like, can you use just the HTML to customize them with their words? The tree view is... This is how easy it is to customize the appearance of a tree. The tree view is a Guru widget. So, apart from changing the icons, at the moment, there's no support for reskinning that at all. Okay. Yes? So, I think this is a great idea for the unit because it's simple and especially because it's free. But it's not trivial to install. You guys might need to make that install. Well, for Ruby, it's the same. I would... I think for Ruby, it's quite easy to install as a gem. But before 1.0, I would like to get 1.0 install for the tree platforms. But right now, just making it easy for Ruby is to install it as the priority. And yes, for beginners, one of the places that's being used in real life now is people who are doing Ruby training. For people who are new to Ruby, it's just said, just download this. And they've been able to get up, start everybody in the Ruby editor in their training sessions. So, yeah, for beginners. Anyone else? Does it support, like, block editing? Like, you know, in text mail, like, you might hold out an option. Yeah. And select that area. If you select something that's Control-B, it will switch to a block selection. Control-B goes back again. Oh. Or Command-B in Mac. And when you're doing the code navigation, does it have, like, a stack where you can, like, now get you new method called for it? Sounds like that. Can we wrap that up? Better using different gem sets, switching around a lot. Is there some way to set it up so that you're using one installation on the right part? There's no support for that. It installs as a gem, so it should play fairly well with an RBM. Except there's a common resource directory where it stores its jobs, so you may run into a little bit of trouble. Try that and let us know how you've been doing it. Yeah? I just wanted to comment that. I'm using it with RBL. I just want to be installing for each version of Ruby, but all my gem sets will be at 192. It works fine with it. Okay, sounds like a good experience with RBM. You have a question, isn't it? Does it use a split screen enemy? Yes, it does. Only two ways, but I don't know if I was lucky. Yes? You can actually install it in a global gem set which is available on all the gem sets. You can install it in a free-true Ruby. Free-true Ruby would just be installed. Yes. Okay. You could even just have one installed and use RBM proper to get it. Sounds like there's a bunch of ways to do this. Someone should write up the best variant on the team. Please. Any more questions? Okay, thank you very much.