GNOME Bugzilla – Bug 96436
Rectangular selection cut and paste
Last modified: 2018-05-02 13:45:41 UTC
A few text editors out there allow column blocks to be selected, cut, and paste (e.g., Nedit). Something like ctrl-click-drag will select an arbitrary block (sort of like a spreadsheet), and a special paste combo allows the selection to be pasted as a column, rather than a row.
I tried this in nedit. To clarify: If you control-click-drag a selection, you can select an arbitrary box of text without selecting the intermediate text. Which you can then paste. Not sure how useful it actually is :-)
I think it's a very useful feature. It would be reasonably difficult but not impossible to implement. I am very unlikely to have time in the near future, but a patch would certainly be welcome.
*** Bug 101590 has been marked as a duplicate of this bug. ***
*** Bug 111091 has been marked as a duplicate of this bug. ***
*** Bug 149020 has been marked as a duplicate of this bug. ***
*** Bug 150817 has been marked as a duplicate of this bug. ***
*** Bug 154619 has been marked as a duplicate of this bug. ***
changing summary for clarity... every time someone asks about this on irc, this bug is a pain to find.
*** Bug 329641 has been marked as a duplicate of this bug. ***
*** Bug 338229 has been marked as a duplicate of this bug. ***
For the record, bug 120276 implemented this feature for vte, maybe the patch there could help someone working on this...
The patch for vte is of no use. Implementing this is easy if one has the functional spec in hand. The problem is that the textview widget does not necessarily use a mono-width font, so it's not clear what rectangular means. That's what one needs to answer before any progress can be made in this bug.
"rectangular" could be the same area as "rectangular when used mono-width font" even if use non-mono-font
I'm one of the people who logged a duplicate and has been waiting for this feature to appear in GEdit for a couple of years now. How do KDE address this problem with KATE? Could we simply disable the option in the menu unless the user is running with a monospace font? Perhaps we should be able to change fonts in GEdit itself. It would be a good feature as users often want different fonts onscreen and when printing as typefaces are specialised for different media. I may not want to use a monospaced font when reading large amounts of text in GEdit but if I am dealing with lists that I need to block-cut, I would naturally switch to a monospace mode so that I could see exactly what I was selecting with the mouse. Thanks, D. Le Sage Hobart, Tasmania
Someone appears to finally be developing this patch. See: http://live.gnome.org/Gedit/Plugins/ColumnMode It appears that "Block selection/editing with keyboard or mouse" is not yet implemented. When this patch is feature complete/stable, can it please be added as one of the default plug-ins packaged with Gedit? Regards, D. Le Sage
*** Bug 349025 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > The patch for vte is of no use. Implementing this is easy if one has the > functional spec in hand. The problem is that the textview widget does not > necessarily use a mono-width font, so it's not clear what rectangular means. > That's what one needs to answer before any progress can be made in this bug. > Rectangular in non mono-width fonts could mean getting the nearest characters to the y coordenate of the selection's rectangle. I will post two screenshots of a text selection in Kate's Block Mode, one using mono-width font, and the other using a non mono-width font. It's clear that with a mono font the text selection is perfect, but still with non mono fonts this feature is very useful as it let you copy blocks of text that you would'nt in any other way. I hope this can give to a potential contributor an idea of what functionality we want to achieve.
Created attachment 134203 [details] Kate's editor in Block Mode with mono-width font Kate's editor in Block Mode with mono-width font
Created attachment 134204 [details] Kate's editor in Block Mode with mono-width font Kate's editor in Block Mode with mono-width font
Created attachment 134205 [details] Kate's editor in Block Mode with NON mono-width font Kate's editor in Block Mode with NON mono-width font You can use a kubuntu live cd to try Kate, to activate Block mode just select "Edit->Block Mode" menu option.
*** Bug 414394 has been marked as a duplicate of this bug. ***
Hi, I've opened a bounty for this bug at FreedomSponsors: http://www.freedomsponsors.org/core/issue/236/rectangular-selection-cut-and-paste I've initially thrown 50$ at it, if you are also interested in this feature please consider joining in and threw a few bucks at it. This way we can gather a small reward to thank any developer who can work on this feature and get it implemented. Have a nice weekend, :-)
Created attachment 357481 [details] [review] Implement rectangular text selection in GtkTextView
Created attachment 357482 [details] [review] gtksourceview.c: support new GtkTextView rectangular mode · Free Alt shorcut to be used for GtkTextView rectangular mode, use Ctrl+Alt instead for move-lines. · Ignore auto-indent when pressing ENTER if we're in rect mode. · Let Tab key bubble up to GtkTextView when in rect mode, so it can be handled properly.
Review of attachment 357481 [details] [review]: Thanks for working on this! Right now I'm just the annoying person with drive-by style nitpicks I noticed. Well, making those will let other people focus on the useful part of the review. :) Of course, these apply to any repeat instances of the same patterns; I won't point them all out individually. This is a pretty big changeset. Is it possible that you could split it into discrete commits by area affected? That might make it easier for people to review and you to update. It also means you can describe each component of the patchset in more detail, without having a 400 line commit message on one. ::: gtk/gtktextbtree.c @@ +2410,3 @@ +gchar* +_gtk_text_btree_get_rect_sel_text (GtkTextBuffer *buffer, + gboolean include_hidden, Please align the argument names ::: gtk/gtktextbuffer.c @@ +82,3 @@ + guint rect_mode : 1; + /* GSList that holds the set of individual ranges (one per each line) that + * conform the current rectangular selection. I guess "conform" should be 'compose' (not 'comprise', which means the opposite :P) @@ +83,3 @@ + /* GSList that holds the set of individual ranges (one per each line) that + * conform the current rectangular selection. + * A #GSList containing an even number of heap-allocated GtkTextIter elements, You could write #GtkTextIter to get a doc link. @@ +86,3 @@ + * two per range, eg. (start1,end1,start2,end2,..) with bottom to top order + * (visually bottom ranges are at the top of the list). You can use + * g_slist_reverse () to obtain a top to bottom order. */ We omit the space before the parentheses in doc comments (I've not tested whether this is needed for the name to render as a link). @@ +668,3 @@ + * @textbuffer: the object which received the signal + * + * The get-rect-ranges is a private signal that GtkTextBuffer will emit I would write ::get-rect-ranges instead of "The get-rect-ranges" @@ +669,3 @@ + * + * The get-rect-ranges is a private signal that GtkTextBuffer will emit + * prior to copy/modify/delete the text in a rectangular selection mode. copying/modifying/deleting, and change "in a" to just "in". @@ +670,3 @@ + * The get-rect-ranges is a private signal that GtkTextBuffer will emit + * prior to copy/modify/delete the text in a rectangular selection mode. + * This signal will be handled by the view layer (GtkTextLayout) which # before class names, and so on. @@ +671,3 @@ + * prior to copy/modify/delete the text in a rectangular selection mode. + * This signal will be handled by the view layer (GtkTextLayout) which + * @textbuffer: the object which received the signal Should this be "selection's individual ranges"? @@ +672,3 @@ + * This signal will be handled by the view layer (GtkTextLayout) which + * will save the current rectangular selection individual ranges in + * "so he" should be "so that it" @@ +3366,3 @@ + * (visually top ranges are at the start of the list). You can use + * g_slist_reverse() to obtain a bottom-to-top order. +gtk_text_buffer_get_rect_mode (GtkTextBuffer *buffer) As well as the AVAILABLE_IN macros in the header, there should be Since: 3.22 annotations in the source files. @@ +3368,3 @@ + * + **/ +{ Add a space between the type and the asterisk again. @@ +3740,3 @@ g_return_val_if_fail (GTK_IS_TEXT_BUFFER (src_buffer), NULL); + if (! g_object_get_data (G_OBJECT (src_buffer), "has-rect-text") Unlike e.g. GIMP, we don't put a space between the ! and its operand (afaics) @@ +3864,3 @@ + { + + if (g_object_get_data (G_OBJECT (src_buffer),"has-rect-text")) missing space after comma @@ +4463,3 @@ + * + * Implemented by means of a private signal handled by the view layer + You could add a # here to get a link in the generated documentation. @@ +4543,3 @@ + } + start = (GtkTextIter *) iters->data; + g_return_val_if_fail (gtk_text_iter_get_buffer (start) != buffer, FALSE); afaict we tend to let things be implicitly cast from void*, but I don't know if that's a strict requirement. ::: gtk/gtktextbuffer.h @@ +462,3 @@ + +GDK_AVAILABLE_IN_3_22 +gchar* gtk_text_buffer_get_rect_sel_text (GtkTextBuffer *buffer); The normal style for declarations is [type][space][asterisk][aligning spaces][name]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/gtk/issues/222.