GNOME Bugzilla – Bug 19827
Wishlist: make delete and other commands work on discontinuous selections
Last modified: 2018-05-22 12:59:23 UTC
Package: gnumeric Version: 0.56 Severity: wishlist I would like to see cut, copy, delete, etc (basically anything that throws up an error now if you try to use it) to work on discontinuous selections (of rows, cells, or what have you). -- Henry House ------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-27 12:33 ------- This bug was previously known as bug 19827 at http://bugs.gnome.org/ http://bugs.gnome.org/show_bug.cgi?id=19827 Originally filed under the Gnumeric product and general component. The original reporter (hajhouse@houseag.com) of this bug does not have an account here. Reassigning to the exporter, debbugs-export@bugzilla.gnome.org. Reassigning to the default owner of the component, jgoldberg@home.com.
This is a very low priority. It gets tricky from a user perspective to explain how pasting a set of discontinuous regions works. I would not want to try and remember offsets.
2.0.x bug?
wishlist
*** Bug 122883 has been marked as a duplicate of this bug. ***
*** Bug 314007 has been marked as a duplicate of this bug. ***
*** Bug 433968 has been marked as a duplicate of this bug. ***
Hi, it would be great if someone could talk about the future of this problem. Is it: 1) too hard to fix - fixing it would break application and features (undo) -> wontfix. 2) could be fixed [hard], but would this would involve a lot of changes. -> Timeline for changes. 3) could be fixed, but there is no good solution - it is like opening the box of Pandora. -> Name the problems, so someone could look into them. Please write something and explain, okay? I get this bug sometimes on big tables and every time I come here to check the page, nothing changes. I know that it is not easy, but there should be a better start point, so the people could talk/vote about it.
The problems are not fundamental, but that fixing this requires a substantial amount of work on a command-by-command basis. Realistically, I do not see it happening anytime soon given the available resources.
Personally I don't think that this would be really to difficult to fix but my head starts spinning when I try to figure out what should really happen: Let's consider the delete command. Say we have a selection of B2:D4, F4:H6, D8:F10. If the user selects delete, do we have a single movement of the remaining cells, (ie. shift up or left) or one for each sub region. Will the user be confused about these compounded movements? For example if we shift everything to the left, then I4 moves to C4 but I5 moves only to F5. For the copy command on the other hand, how do we place three separate region on the clipboard (say as html). One large table containing 3 subregions?
*** Bug 662042 has been marked as a duplicate of this bug. ***
*** Bug 698494 has been marked as a duplicate of this bug. ***
*** Bug 733466 has been marked as a duplicate of this bug. ***
*** Bug 758997 has been marked as a duplicate of this bug. ***
-- 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/gnumeric/issues/3.