Description: In LibreOffice Writer tables the cut of selected rows/columns removes only the contents. In Microsoft Word the cut removes the full row/column. It would be more user friendly to imitate this behavior. Steps to Reproduce: 1. Create a document in Microsoft Word. 2. Insert a table and fill the cells with data. 3. Select a row and cut it. 4. Notice, that the row of the table disappeared. 5. Create a document in LibreOffice Writer. 6. Insert a table and fill the cells with data. 7. Select a row and cut it. Actual Results: In LibreOffice Writer tables the cut of selected rows removes only the contents. The same happens with columns. Expected Results: LibreOffice Writer should remove the full rows and full columns with cutting. Reproducible: Always User Profile Reset: No Additional Info: LibreOffice details: Version: 6.4.0.0.alpha0+ (x64) Build ID: 0d90da9ea0a23c9c4afac62025208559b1496a0e CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: threaded
Created attachment 154481 [details] Screenshot of the original document side by side in Word and Writer
Created attachment 154482 [details] Example file from Word
Created attachment 154483 [details] Example file from Writer
I think it's an enhancement. And if it will be realize then I think we'll need option for toggle behavior Heiko, what do you think about this request?
Why should we copycat MSO? I mean is the cut operation necessarily meant for the table (plus content) or the content (without the container aka table).
(In reply to Heiko Tietze from comment #5) > Why should we copycat MSO? I mean is the cut operation necessarily meant for > the table (plus content) or the content (without the container aka table). This is for the case when the user selects a full row/column. Then cuts it. The user intention here is that they want to move the full row/column to a different position, so the container should go too. Not because Word does so, but because this makes a lot of sense from user POV.
(In reply to NISZ LibreOffice Team from comment #6) > (In reply to Heiko Tietze from comment #5) > > Why should we copycat MSO? I mean is the cut operation necessarily meant for > > the table (plus content) or the content (without the container aka table). > > This is for the case when the user selects a full row/column. Then cuts it. > The user intention here is that they want to move the full row/column to a > different position, so the container should go too. > Not because Word does so, but because this makes a lot of sense from user > POV. How do you know that this is the user's intention? He might as well want to move the content of the row or column to a differnt position and fill the row or column with a new content. In addition, the behaviour is consistent with Calc.
(In reply to Gerhard Weydt from comment #7) > How do you know that this is the user's intention? He might as well want to > move the content of the row or column to a differnt position and fill the > row or column with a new content. Unfortunately, there is no simple way to cut and move table rows in Writer, but that's the user's intention, too, see https://ask.libreoffice.org/en/question/158283/how-to-cutmove-rows-in-writer-tables/ or https://bz.apache.org/ooo/show_bug.cgi?id=81990 (from 2007). > In addition, the behaviour is consistent with Calc. Calc is not perfect, but there is a (hidden) 1-step way to move rows or selected cells using drag & drop with Alt: 1. Press Shift-Space to select a row. 2. Drag & drop the selected row (by clicking on one of the cells of the selection). Before releasing the mouse button, press Alt and release mouse button. In Writer, the easiest is a 3-step way (insert an empty row, copy, delete the original): 1. Insert an empty row by the appropriate icon (or Alt-Insert and Up/Down arrow). 2. Select the row by clicking before the table row. 3. Drag & drop the selected content to the empty row. 4. Delete the row by the appropriate icon (or Alt-Delete and Up or Down). The suggested enhancement won't remove Copy/Paste. As you can see in the history of LibreOffice, fixing similar usability bugs was very important, for example https://bz.apache.org/ooo/show_bug.cgi?id=10256 "allow single click selection of table cells, rows, and columns" from 2002 was implemented in OpenOffice.org 2 in 2004 based on the specification http://specs.openoffice.org/writer/selection_enhancement/Text-table_selection_enhancement.sxw So the task is not only cutting the whole line easily, but its simple insertion, too, ie. moving the line. We could extend also the Move Up/Down functions mentioned in https://ask.libreoffice.org/en/question/158283/how-to-cutmove-rows-in-writer-tables/, so important to simplify table handling in Writer.
(In reply to László Németh from comment #8) > The suggested enhancement won't remove Copy/Paste. And when wanted: removing content of selected cells/rows etc is done with DEL or even BackSpace. I think this will be a useful enhancement for the users >> +1 & apart from that: thanks for all effort put in these, László, Gabor, *** :)
I also agree with this!
Point of clarification: In Word, it is possible to cut both (1) only the contents of a row, and (2) the full row. However, when cutting
Ah, please ignore my previous comment. I'm using an old version of Word (2003) so it's probably not very relevant.
Comparative analysis and suggestions In MSO Word, 1. Cut always cuts the selected column, not only its text content. 2. Rows have a text-only and a full selection with different Cut operations: 2.A Selection by mouse clicking in front of the row or in front of the text of the first cell result "full" selection, where Cut cuts the complete table rows. After that, Paste in the first table column results insertion of the table rows over the actual row. 2.B Selection by mouse or text cursor movement results text-only row selection, where Cut cuts only the text content, leaving empty cells. After that, Paste results overwriting of the actual cell content. Possible LO extensions - Support MSO's full row selection mode (2.A), keeping also the recent behavior (2.B). - LibreOffice has already had a quick row/column insertion mode and deletion mode (Alt-Delete). I suggest a similar quick row/column selection by extending Ctrl-A mode with a row & column selection states or using similar Ctrl-Shift-arrow selection as in Calc (that could work after a Ctrl-A in cells with multiword cell content). See https://help.libreoffice.org/Writer/Shortcut_Keys_for_Writer#Shortcut_Keys_for_Tables_in_LibreOffice_Writer
@Cor: thanks for your kind words! :) The comparative analysis didn't mention the visual functions of the table UI: MSO 2016 has got a visual row insertion mode (plus sign in a circle before the table). But the biggest difference is the quick table moving (top left corner little square with arrow cross) and resizing (bottom right corner tiny square), likely there is an old bug report for these.
(In reply to László Németh from comment #13) > - Support MSO's full row selection mode (2.A), keeping also the recent > behavior (2.B). > > - LibreOffice has already had a quick row/column insertion mode and deletion > mode (Alt-Delete). I suggest a similar quick row/column selection by > extending Ctrl-A mode with a row & column selection states or using similar > Ctrl-Shift-arrow selection as in Calc (that could work after a Ctrl-A in > cells with multiword cell content). See This topic was on the agenda for the design meeting. And while Gerhard mentioned that s/he not always want to change the table structure, there is general acceptance to the change. And the MSO way with selection beyond the border allows both workflows. Ideally we add a formatting mark after the row/col that can be selected.
I'm sorry, there is no visual difference between the "cut/empty table row" modes, only the way of the selection in MSO. You can select the row boundary character outside the table in cell by cell selection mode, too, pressing Shift-Right at the and of the table row, but that won't result "cut table row" mode. Only clicking in front of the row (called enhanced table selection in LibreOffice) does it. It seems, the enhanced table selection mode was modeled after MSO's implementation in 2004, so it's worth to complete it with "cut table row" mode. Half of the implementation: https://gerrit.libreoffice.org/#/c/81503/ The "cut table column" mode has an extra difference: default tables in Writer have got a fixed width, and deletion of table columns changes the width of the next columns, not the table width, as in MSO.
The next half of the implementation of the table row insert mode: https://gerrit.libreoffice.org/#/c/81699/ With this patch, Copy/Cut with enhanced table selection results table row insertion mode, and the next Paste inserts the table rows of the clipboard above the actual table row, like in MSO.
Single patch with row/column cut & insertion: https://gerrit.libreoffice.org/#/c/81503/ I decided to limit insertion only to the Cut operation, ie. Copy doesn't result insertion of table rows/columns later. (Especially in the case of table columns would be annoying to change Copy, because LibreOffice deletes/inserts the columns with changing the width of the other columns in the table, keeping the original table width, while MSO keeps the original column width instead of the table width).
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c8b1efbad48fa9697c0b1afbe4753bbbc3c4c5c tdf#127759 Writer: add table row/column insert mode It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Full commit description: tdf#127759 Writer: add table row/column insert mode using enhanced table selection. When the table rows or columns are selected by enhanced table selection, ie. clicking in front of them, next Cut operation cuts the selected rows or columns completely without leaving empty cells. Pasting them results insertion before the actual row/column instead of overwriting the actual and the next rows/columns. This greatly speeds up moving table rows and columns, like in MSO.
Works pretty nice for both columns and rows. But while testing with master it crashes often. I don't have a clear workflow to test, sometimes it happens on click at the table boundary, sometimes when setting a color. But always cells flash on multiselection. Can you reproduce the issues, Laszlo?
(In reply to Heiko Tietze from comment #21) Few week-old debug build flashed to me without my patches, too, but the fresh one seems to be ok. I wasn't able to reproduce crashing, but maybe it is related to the slowness of the non-optimized build. Thanks for your feedback!
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2fbf0f418ccb25010add33449d4e42b8b3f7fd0b tdf#148791 tdf#64902 tdf#127759 sw: fix row insert/paste It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-7-3": https://git.libreoffice.org/core/commit/c52acf9d1935b95a8279b760212553c0c3b4b267 tdf#148791 tdf#64902 tdf#127759 sw: fix row insert/paste It will be available in 7.3.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.