Just as other editors do, I think that it would be useful to have an option to sort the lines alphabetically, in both orders, ascending and descending. Thank you.
This could be handled by Bug 11097.
Sincerely, one of the reasons because I opened the Bug 11097 was the need to sort lines, he he he. However, since it's not easy to implement a feature to pipe text to commands, and because ordering lines can be considered somewhat of general use, I decided to open this new report. In my opinion, it would be useful to count with something like this, out-of-the-box.
My workaround for this is to create a bash alias in ~/.bash_aliases or ~/.bashrc like: alias sortclipboard='xclip -selection c -o | sort | xclip -selection c -i' When I need to sort text I just end it to the clipboard with Ctrl+C and run 'sortclipboard' in a terminal emulator. This is ok to me (I have an idle terminal window already opened most of the time) but I still wish a basic sorting feature could be added to mousepad, built-in or through external commands (Bug 11097). PS: Is there a roadmap or a priority list for mousepad bugs/feature requests?
+1 voting for this as well, it's a very desired feature. (Piping would work as well.)
Created attachment 9274 diff The attached diff adds this functionality. It uses gtk_source_buffer_sort_lines() which was introduced in GTK 3.18: https://developer.gnome.org/gtksourceview/stable/GtkSourceBuffer.html#gtk-source-buffer-sort-lines It would probably make sense to expose the flags and column parameters via a small dialog window.
(In reply to Theo Linkspfeifer from comment #5) > Created attachment 9274 > diff > > The attached diff adds this functionality. It uses > gtk_source_buffer_sort_lines() which was introduced in GTK 3.18: > > https://developer.gnome.org/gtksourceview/stable/GtkSourceBuffer.html#gtk- > source-buffer-sort-lines > > It would probably make sense to expose the flags and column parameters via a > small dialog window. LGTM!
Looks OK except it breaks building with with Gtk/GtkSourceView 2.
(In reply to Matthew Brush from comment #7) > Looks OK except it breaks building with with Gtk/GtkSourceView 2. Do you think we should keep supporting gtk2 now that Xfce is fully gtk3-based?
(In reply to Andre Miranda from comment #8) > (In reply to Matthew Brush from comment #7) > > Looks OK except it breaks building with with Gtk/GtkSourceView 2. > Do you think we should keep supporting gtk2 now that Xfce is fully > gtk3-based? I don't feel very strongly, though I personally dislike GTK+3 for a variety of reasons. My main reason for maintaining GTK+2 is that IMO, there's no point to remove it if it's not a large maintenance burden, since it allows newer Mousepads to be used on older or non-Xfce distros. If the other developers want to drop GTK+2 support because it is becoming a maintenance burden (ex. this patch), I'm OK with that. I don't think we should do it by just breaking the build without properly removing it though. If there is a desire to drop it, maybe someone could make a new bug report for that, to discuss what all needs to be removed/updated/fixed, and then once it's done we could merge this patch as is?
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/apps/mousepad/-/issues/12. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev