Sublime-like search bar in Xed
by clem 38

Xed, the text editor, was given a brand new search and replace bar.


When performing a search, the text is no longer obstructed by a dialog box. Instead, the search bar appears at the bottom of the editor.

The search is progressive and you can simply jump from one result to the next by pressing Enter. You might be used to this kind of search already, as it is similar in other applications such as Firefox.

This search bar was inspired by Sublime, which many in the team use for development.

38 thoughts on “Sublime-like search bar in Xed

  1. Jacques Sep 29,2016 09:59

    Brilliant! This will make things so much easier.

  2. TheBestPessimist Sep 29,2016 11:48

    why aren’t you simply using sublime as a text editor in linux mint? why do you have to create a new one, and then work on already existing features in other programs, and bring those in them?

    this can be related to extremely many things linux does this way.

    i’m sure that manpower could be used to fix some other bugs instead of recreating the wheel for the hundredth time.


    • clem Sep 29,2016 13:12

      Ok, that’s a very good question. The answer is obvious to me, but maybe not to everyone.

      First, this is not a “new” text editor. This is “Xed”, which before that was called “Pluma”, and which before that was called “Gedit” (note that Pluma and Gedit still exist and provide new versions, but that’s beyond the point here). What you are looking at here, is the same editor we’ve been using since we started in 2006, and the same editor other Linux users used before us before then. It’s nothing new.

      In contrast, Sublime just got here, obviously it’s new in town.

      Second, Sublime is both proprietary and commercial. Its proprietary nature is an issue long term (and also short term as a philosophical issue for some users). Its commercial nature obviously prevents us from shipping it (how do you ship something that costs money within something free? assuming you had the license to do that in the first place).

      Third, Sublime is great for development. Do we need Sublime to open plain text files? No.

      There are many other cool features in Sublime. Some of them are completely irrelevant when it’s not about development… and others could improve Xed greatly (and so we add them).

      • TheBestPessimist Sep 29,2016 14:45


        After reading this, and also reading the following comments, i will ask this (as this may show the point i’m trying to make better understood): why aren’t the plugins from gedit (or pluma?) supported out of the box?

        What i understand from what you said is that this is just a “reskin” maybe, so that this editor looks better with linuxmint?

        Anyhow, my question is again: why not just use gedit, and add that lovely search (and maybe a setting to use the new (this) search mode or the former one), why did you have to (again, this seems to me it happens WAY to often) create a sort-of-a-new-but-not-quite-a-new-texeditor.

        This question is related to the linux spirit in general: why actually make an existing product better? Why not fork it, and then modify it so hard that most of everything that was working with the previous product (plugins, configs?) is not working with your variant, just because you want it to look a little better. Why cant the old product be skinned? Why can’t the old product be improved with, in my opinion, way less work that it is required to modify your new product?

        This is a question i have never understood about linux and open source in general.

        Sorry if this is a bad question, but this is how i feel about the topic.

        • KDB Sep 29,2016 15:02

          Look at the way animals/life has evolved on earth and it should give you a beginning of answer.
          The second part is: because we can.

        • Peter Sep 29,2016 15:27

          You say things, that I thought as well, before joining the Xapp development. The problem with pluma, gedit, etc. is that they belong to certain desktop environment. They have internally dependencies to these DEs, that Xapps plan to get rid of.

          Currently, Xapps are not much different from their ancestors, but they will be after some time. However, we will still backport useful things, such as bugfixes etc. from them. And hopefully, DE-specific development (inventing the wheel over and over again, just from a single environment) will cease after some time.

          The philosophy behind is:
          1) We remove dependencies to have application that are DE-agnostic, re-adding functionality in a way that it works on all platforms independently.
          2) To generate libraries that can be reused from others, within xapps and outside. For instance, to blank monitors in a generic way.
          3) Generate a culture around xapps, to help newcomers, to document things better, and to generate cleaner code (in terms of coding standards, and other things).

          I am new to this development team, which is a group of volunteers, that try to solve exaclty the from-you-mentioned problem, that old products often are kind-of jailed into their DE. We had many useful discussions about why to fork things again. In the first place it seems the wrong turn, but hopefully, after some time we have less dependencies and can start with a software development that is for the Linux world and not only for certain DEs or distros. But hey, it takes time to get started…


          • clem Sep 29,2016 15:39

            I think point 1. is largely achieved. These apps are compatible with the DEs we targeted (Cinnamon, MATE, Xfce) and they can receive support for other DEs if people from these get involved. That was done in preparation for their first releases (and when some of it was considered a bug, it was also backported into the MATE apps too… for instance I don’t think atril launches mate-settings-daemon anymore).

            We’re just getting started with point 2.

            And there’s another point which is important: cost. It costs much more to develop Pluma and patch Gedit and do nothing about Leafpad, and it doesn’t let us go forward. It’s much cheaper to develop Xed, especially if it’s for everybody and it gains momentum in other distributions. It means every single hour we put into it, improves most of the desktops we’re shipping. It means no more patching and using applications which aren’t designed for us (Gedit 3.x is a great text editor, but it is designed for GNOME). It’s very hard to justify working on Pluma and it’s not a long term solution to think we can patch and freeze Gedit indefinitely (not to mention it lowers the quality of GNOME whereas the non-patched version of Gedit fits like a glove).

        • clem Sep 29,2016 15:28

          That’s ok.

          There are two types of plugins: C plugins, and Python plugins.

          There’s a continuous line of support and inheritance for C plugins, from Gedit 2.x, to Pluma, to Xed.

          Python plugins are problematic because their loader either uses PyGTK (which only works with GTK+) or libpeas (which only works with GTK3).

          Gedit 3.x lost compatibility with Gedit 2.x python plugins.

          Pluma kept compatibility with Gedit 2.x python plugins as long as it was built with GTK+. It looses it if you build it with GTK3.

          Xed lost compatibility with Pluma python plugins because it is built with GTK3. The difference with Pluma is that it does not need to support GTK+ though, so we are indeed planning to add libpeas support.

          In terms of features, you mentioned a “reskin”, you’re looking at it the wrong way. There is a continuous line of development between Gedit 2.x and Xed. At each fork, you’ve got two new lines, two separate paths. Gedit 2.x turned into both Gedit 3.x and Pluma. Pluma turned into both Pluma and Xed.

          I don’t know if I’m clear when I say that… but Xed never “lost” support for Gedit 3.x plugins, it never had it. Neither Gedit 2.x, nor Pluma, nor Xed ever worked with Gedit 3.x plugins. That said, once we port libpeas support, that’ll be a different story. I hope that makes sense. I know it’s quite technical and a bit confusing.

          PS: Another WIP for us is to integrate core features into Xed itself. In many occasions we’ve seen plugins which should not be plugins. These do not need to wait for libpeas support to be integrated, as we can implement their features into Xed directly. I’ll give you an example to make it clearer. A plugin which adds a View->Hide statusbar toggle button has no reason to exist. Either it’s a good idea and we add that feature into Xed itself, or it isn’t and we stop talking about it.

        • Peter Sep 29,2016 15:38

          ps. let me add here, that this post is my personal experience and how I think about Xapps development with some salt from discussions I had with other developers. It is overall a new idea, but the main point as I have understood is, that we do not want solely adapt to our taste of look-and-feel. BTH, if that would be the case, then I would 100% agree with you when you say


          In contrast, xapp development aims to a more generic way of doing things, it is more about backend and dependencies, and to generate software for everyone, not just to promote a certain environment.

      • TheBestPessimist Sep 29,2016 16:04

        I understand your opinion about doing things more generic, and trust me, i totally agree.

        but i still have a problem with this (and only time will tell): why would other use your product? i mean why would debian (hehehe, never) use the new suite of programs that you created? or when will the people from canonicalintegrate this into their ubuntu.

        From all i can see (with my limited experience) everybody wants to create a new standard of apps which then to be used by everyone else, yet noone agrees to a certain “format”. (after reading this sentence, and modifying it a few times, it still does not make that much sense — sorry :( )
        and this is how we reach the ~there are 3 types of line endings and mine is better so why wont you use it?~ problem.

        Ah, in the end thank you for trying to explain me your vision, and i hope there will be a future where i could actually use linux on my parents pc (no games) without having trouble 1/3 times when i insert a usb stick.

        • Nate Sep 30,2016 18:03


          The problem is exactly as TheBestPessimist suspects: if nobody else ends up using your new standard, all you’ve done is further confuse things with more largely-similar options, and your new “standard” winds up something that’s used mostly by you.

          If Xapps are actually intended to be used across many different distros, that’s going to have to be a major effort, undertaken deliberately, and with resources behind it. It isn’t just going to happen by itself, because all of the owners and maintainers of other distros that you want to adopt Xapps already have things that seem to work fine or that they have put a lot of time into developing. Convincing everyone else to jump on your bandwagon is a huge task. I’d like to see that succeed, but it won’t happen with just a wish and a prayer.

          • clem Sep 30,2016 18:52

            They don’t need to be adopted by any other distribution to succeed. Their goal isn’t to take over the “competition”. They’re already succeeding at solving some of the issues we had in Linux Mint (freezing/patching GNOME apps, and not affording to develop MATE/Xfce ones). Opening them to the entire Linux community just helps, it helps other distributions adopt them and it helps developers from outside of Mint take an interest in them. We know right well we’re alone at the start of a project like this, and it wouldn’t get started if we didn’t have the resources to maintain it by ourselves. By the time it gains momentum, it thrives. But no matter what, it’s already a success.

            Afaik they’re already in Arch and OpenSUSE and they’re likely to become available in more and more distributions. When it comes to Debian, it takes longer, especially if somebody objects. I remember Josselin Mouette objecting to MATE getting in for instance and an Ubuntu developer wondering why we supported it. But like any distribution out there, if their users want something, they end up supporting it. Debian now has both MATE and Cinnamon in its repositories and they participate in their development.

            Cinnamon was started the exact same way as the XApps, its cost was much higher and we didn’t know if it would be successful outside of Mint. It didn’t matter though, because we could do it and because we needed it.

            Our job is to work on Linux Mint. If it needs something and we can afford it, it happens. If that something can be developed with others in mind and we all benefit from that, then even better. It’s that simple.

            You might have noticed the small number of XApps. There’s a reason for that. They have a cost and they represent a particular need. When the decision was taken to start these apps that cost was run and that need was assessed for Linux Mint. If these apps get adopted outside of Mint, the need grows obviously, but the cost goes down. With 3 editions in Linux Mint alone, these already get used by millions of users, so even more than with Cinnamon, we’ll get the feedback we need on these. To support technologies we don’t use (GTK 3.22 right now for instance), we’ll need them to gain momentum in Arch and Fedora, just like Cinnamon, and it’s not something we absolutely “need”, it’s something which helps.

            I hope that makes sense.

          • Anand Oct 1,2016 04:30

            This reply itself can be a blog post, well said. Should feature in FAQ for XApps :)

    • lestcape Oct 3,2016 20:31

      TheBestPessimist, in your point of view it’s more easy convince the development of an application that merge your code, because it’s better in this way for all distros, and not matter if the app it’s development for GNome, will be good support other DE, or will be more easy create a fork and do by your own…

      In my personal experience, with unity-gtk-module (called before appmenu-gtk), what you say are really not possible, and more than a real incompatibility, this occurs just because a name (unity) and only some hacks. As a result, this package was droped for Arch repositories.

      This is what happend:

      This is a temporal an unofficial solution in Arch:

      Please tell me if you can, that this is better than fork unity-gtk-module and redistribute it as a cross desktop packages…

      I only need to say thank, for all development that take on account the work of others..

  3. sviperz Sep 29,2016 11:49

    Do you guys planning to port a text processor plugin from Gedit. Kinda powerful tool!

    • clem Sep 29,2016 13:15

      Hi, no.

      I’m planning to integrate line sorting within Xed itself (again, similar to Sublime and unlike the existing plugin, press F9, all your selected lines get sorted, no dialog, no questions asked) and support for Python plugins over libpeas (that’s already done in Gedit 3.x and I think we should port it).

  4. KDB Sep 29,2016 13:26

    HI Clem,

    Good work!
    Does it support regular expression search?

    • clem Sep 29,2016 13:53

      I knew somebody was going to ask :)

      No, not yet anyhow. I know Sublime does :)

      • KDB Sep 29,2016 13:59

        Hi Clem,

        No problem. I know gedit had a plugin for this job. Maybe it can be ported easily. Or maybe Pluma had this plugin.
        I will investigate this when I will have a few minutes available.

        • clem Sep 29,2016 14:11

          Ok, let me know.

          The search features remained unchanged here, the work impacted the UI itself. Looking at the code, search is implemented by use of GtkIter, but I see support for regex in GtkSourceView, so we might be able to do it this way and even to simplify some of the code here.

  5. martywd Sep 29,2016 15:25

    Any word on when ‘xed’ with this new search format be available to download/upgrade/install?

    • clem Sep 29,2016 15:31

      We’re upstream so we wear two hats when working on Cinnamon and the XApps. We’re both providers and consumers here. Tags, versions and releases follow the needs expressed by the consumers. So you can be sure to see it fit the Linux Mint release cycle (new versions landing in LMDE first, and then in Mint 18.1), but if other distributions need to get it in they can be released before that.

      • martywd Sep 29,2016 19:57

        Ok, thanks for the additional info, Clem.

        I guess I should have mentioned… I’m running LM 18 MATE 64-bit (on three machines) and _very_happy_ I will add.

  6. Alex Sep 29,2016 21:07

    Please, add an option to clear search history on exit. Many thanks in advance!

  7. Anand Sep 30,2016 03:37

    Wow, nice. AA Icon is for Match case and quote for entire word?
    Number of matches found would be useful to display. (available in Firefox)

  8. Alex Sep 30,2016 12:58

    to clem: Yes, it would be nice to have an option not to remember recent searches. Now I have to run in the terminal “gsettings reset org.x.editor history-search-for” command to clear the search history.

  9. kneekoo Sep 30,2016 13:22

    Very nice adition! :) A counter for the number of matches would also be nice, along with a distinct highlight for the current match (can’t see it in the screenshot) and have that reflected in the counter: 3/14 when you’re positioned on the third match out of 14.

    Also, switching the character set from the bottom/status bar would be great.

  10. kneekoo Sep 30,2016 13:37

    By the way, Geany has a great feature that highlights all the instances of a word when you double-click it. It’s not in the core Geany code, but I always install the add-ons and enable that feature because it’s really easy to spot where I used a variable or just some string.

    It behaves like this:
    1. You double-click a word, and the word gets selected (just like in any editor);
    2. All the instances of that word will be highlighted throughout the text;
    3. You can click here and there without affecting the highlights;
    4. If you double-click anywhere (an empty line, another word, or one of the highlighted words), the highlights will turn off and if your double-click was pointed on another word, we’re back to #1.

    To be precise, it’s not just about words, but string sequences. You can even double-click indentation to highlight the other indentations of the same length.

    Just in case you’re not familiar with this Geany feature, it’s in the geany-plugin-addons package. You can activate it by going to Tools -> Plugin Manager. Tick the Active checkbox of the Addons plugin, then click Preferences and tick “Mark all occurrences of a word when double-clicking it”.

  11. DaveW Oct 2,2016 13:36

    Is the option to parse escape sequences (e. g. \n) now a default, or can it no longer be done?

    • clem Oct 2,2016 18:39

      hi Dave, escape sequences are now always parsed. You can search for “\n” by typing “\\n”.

  12. binoyte Oct 6,2016 07:13


    **YES**! I use sublime text mainly for editing markdown / plain-text because of :

    * sublime is able to wrap at user defined column
    * **sublime is able to center wrapped text**
    * markdown-editing plugin
    * multi selection editing

  13. ian clark Oct 18,2016 09:10

    this looks really neat! i hate how the search box blocks its own results – stupid! when will xed be available? i’m using an ancient gedit in mint 17.3

    • clem Oct 19,2016 11:15

      Hi Ian,

      It’s targeted at LMDE 2 and Mint 18.1, but it should work for Mint 17 if you compile it yourself. Here are roughly the steps involved

      apt install git dpkg-dev
      git clone
      cd xed

      It will complain if you’re missing any build-dependencies (i.e. packages required to build it). If that’ s the case, simply install them and try to build again. Once complete, it will produce .deb packages in your home directory.

  14. Ben Aceler Nov 11,2016 09:55

    Well, it is not Sublime-like, it is Eclipse-like :-)

    Eclipse had this feature long ago. Good thing, even Sublime copied that :-)

  15. Houston Hall Jan 5,2017 19:51

    Feature or Bug with xed 1.2.2? (I submitted a bug report just the same)
    When the mouse is used to save a text file by clicking on the save button, the cursor disappears. After which, you most click within the text area to redisplay the cursor/position.
    The same does not happen if one saves using the keyboard shortcut (ctrl + s). Also, the bug/feature is not present in xed 1.0.6.

    I realize this is a minor issue but xed is a great app and I would hate to see a simple regression (if that’s the case.)
    Thanks Clem for you hard work and dedication to Linux Mint.

Comments are closed.