I can't see any special Mac hint for this on <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>, so I believe reporter simply uses the wrong keys?

@Martin Peter
This is not a good place for "I don't remember" problems, please use <http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>.

Please check whether Help hints work for you!

Hallo Rainer,

i justed tried this on my windows machine, and it works over there (LO 3.5.6.2).
On the windows box just pressing alt while D&D makes exactly what it should - it _moves_ the selected column from one place to another.

On my mac machine pressing alt while D&D copies the column instead of moving it.

As for the "i don't remember" problem, where are one step further.

This problem obviously wasn't unique to me and apparently it had been solved for win systems:
http://ask.libreoffice.org/en/question/1143/how-to-move-columnsrows-in-lo35/

Do you need more information?

Thanks for any help to come.

Martin

Hm, I also have a (different?) problem with LibO 3.4 and 3.5.4 on Ubunu on VirtualBox, because alt+mouseclick is for windowsmanager (as mentioned on ask.libreoffice). I wonder whether this also is a current Linux Problem. 
Of course this problem is completely different to reporter's, the sum might be thet this <alt+drag&drop> is a "WIN only" solution and works nowhere else?

Roman, can you confirm this problem?

(In reply to comment #3)
> Roman, can you confirm this problem?

Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3 (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and all their combinations), the column does neither move nor gets copied at all; the only thing that changes sometimes is the number of selected columns.

But maybe I am just too stupid, or was not patient enough ...

(In reply to comment #4)
A little more detailed description

1. fill the first three fielda (A1,B1,C1) of row 1 with random data
   (for example "a","b","c")
2. select colum C by clicking the column header 
3. <Alt> (or whatever required for Mac)
4. Click into C2, keep mouse button pushed
5. Start moving mouse pointer to the left
   Mouse pointer changes to "Not here" in C2
6. When you have trespassed border C->B Mouse pointer changes to "Move",
   Border between coluns B-A becomes bold
7. When you have reach middle of Be release mouse button
   > Contents of columns B,C have interchanged.
That's the way how it works with WIN, and this does not work under Ubuntu (May be because of other reasons).

If a last attempt failed please please make this one new for Markus, he already fixed other bugs ("Bug 46230 - EDITING: impossible to perform a drag & drop of entire row/column").

Some Hints:
In German help you find instructions under "Zellen per Ziehen&Ablegen verschieben", please check after we have finished here whether Help has to be amended.
Mouse pointer View see "Ziehen&Ablegen innerhalb der LibreOffice-Dokumente"

(In reply to comment #4)
> (In reply to comment #3)
> > Roman, can you confirm this problem?
> 
> Well, I have tried the steps given in comment #0 with LibreOffice 3.6.4.3
> (Build ID: 2ef5aff) on Mac OS X 10.6.8, and I see a problem, but a different
> one: no matter what combination of keys I press (Cmd, Alt, Ctrl, Shift, and
> all their combinations), the column does neither move nor gets copied at
> all; the only thing that changes sometimes is the number of selected columns.
> 
> But maybe I am just too stupid, or was not patient enough ...

Hi. I guess you are trying do drag the column by clicking on the header. The dragging operation should be started with a click into the column-selection. The selection itself is achieved by clicking the column-header once, after selecting, you drag the selected fields.

The key to hold for (expected) moving of columns should by ALT as i found out by now. In Win it works just fine.

Regards

@ Rainer Bielefeld: thank you very much for your detailed instructions!

Testing with LibreOffice 3.6.4.3 on Mac OS X 10.6.8 (Intel), I get the following results.


(I) Pressing no keys at all
---------------------------

When I follow Rainer’s instructions from comment #5, but do NOT press any key, i.e. leave out step 2, and just drag column C between column A and B, I would expect the following result:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |b      |       | ...

But I get this result:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |       |       | ...

I.e., the contents of column C overwrite the contents of column b, instead of ousting them.

But this is not a bug, because the LibreOffice help says (in section “moving cells by drag and drop”):

No key:     Cells are moved and overwrite the cells in the target area.
            Source cells are emptied.

Strange, but so it reads, and therefore this is what is expected.


(II) Pressing Alt key
---------------------
Following Rainer’s instructions from comment #5, including keeping the <Alt> key pressed during the whole drag-and-drop action, I get the following contents in Columns A to D after step 7:

   |   A   |   B   |   C   |   D   | ...
-------------------------------------------------
1  |a      |c      |b      |c      | ...

So column C has been *copied* (not moved) between columns A and B.

On Mac OS, pressing <Alt> is often used for copying data instead of moving them. So this could be intended behaviour.

The LibreOffice help says (in section “moving cells by drag and drop”):

Option key   Cells are moved and shift the cells in the target area
             to the right or to the bottom. Source cells are emptied,
             except if you move within the same rows on the same sheet.
             If you move within the same rows on the same sheet,
             the cells in the target area shift to the right,
             and then the whole row shifts to fill the source area.

I confess that IMHO this description is somewhat irritating. There should not be any “except if...” clauses in descriptions of expected behaviour.
But if I understand the description corectly, the current behaviour is correct: the “except if you move within the same rows on the same sheet” applies, and so the source cells are not emptied.


Do you want me to test more key combinations? Until now, I only see irritating descriptions, but not a bug. But maybe I am just too stupid for this kind of tests. (I prefer real bugs that crash LibreOffice ;-)

(In reply to comment #7)
> But maybe I am just too stupid for this kind of tests.
> (I prefer real bugs that crash LibreOffice ;-)

Sorry for the loose wording. What I wanted to say is: IMHO the expected behaviour, as described by the LibreOffice help in the section “moving cells by drag and drop”, is so irritating and counter-counterintuitive, at least when we speak about dragging and dropping whole columns or rows, that I feel frustrated by judging what is a bug or not, because the expected behaviour feels like a bug to me ...

So, just tell me if you want me to test more key combinations, and I will describe my results, but if the results are a bug or not a bug should be judged by somebody else. (I would just regard the complete expected behaviour as a bug.)

(In reply to comment #8)
> (In reply to comment #7)
> > But maybe I am just too stupid for this kind of tests.
> > (I prefer real bugs that crash LibreOffice ;-)
> 
> Sorry for the loose wording. What I wanted to say is: IMHO the expected
> behaviour, as described by the LibreOffice help in the section “moving cells
> by drag and drop”, is so irritating and counter-counterintuitive, at least
> when we speak about dragging and dropping whole columns or rows, that I feel
> frustrated by judging what is a bug or not, because the expected behaviour
> feels like a bug to me ...
> 
> So, just tell me if you want me to test more key combinations, and I will
> describe my results, but if the results are a bug or not a bug should be
> judged by somebody else. (I would just regard the complete expected
> behaviour as a bug.)

Thanks for your efforts.

Is it intended, that LibrOffice on Mac lacks the moving-columns-capability, which exists in the Windows version of Libre Office?

Regards
Martin

(In reply to comment #9)
> Is it intended, that LibrOffice on Mac lacks the moving-columns-capability,
> which exists in the Windows version of Libre Office?

This is what the LibreOffice help says:

> No key
> Cells are moved and overwrite the cells in the target area.
> Source cells are emptied.
>
> Command key
> Cells are copied and overwrite the cells in the target area.
> Source cells stay as they are.
>
> Command+Shift keys
> Links to the source cells are inserted and overwrite the cells
> in the target area. Source cells stay as they are.
>
> Option key
> Cells are moved and shift the cells in the target area to the right
> or to the bottom. Source cells are emptied, except if you move within
> the same rows on the same sheet. If you move within the same rows
> on the same sheet, the cells in the target area shift to the right,
> and then the whole row shifts to fill the source area.
>
> Option+Command keys
> Cells are copied and shift the cells in the target area to the right
> or to the bottom. Source cells stay as they are.
>
> Option+Command+Shift keys
> Links to the source cells are inserted and shift the cells in the target
> area to the right or to the bottom. Source cells stay as they are.


Can you find the alluded “moving-columns-capability” in this list?
If not, it is really missing ...

(In reply to comment #10)
Currently it looks as if Mac LibO is lacking this function.

Additional there might be a Help problem, but I d not know whether Mac has it's own Help texts different from WIN Help?

From where is the Help citation? In WIKIHELP 
<https://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop>
I only find the non-Mac wording, and in Manual 3.4 "Using Spreadsheets in LibreOffice" I can't find anything concerning this drag and drop.

Created attachment 72059 [details]
Screenshot for bug 58440, showing the page from LibreOffice Help in LibO 3.6.4.3 on Mac OS X



(In reply to comment #11)
> From where is the Help citation?

From the “LibreOffice Help”, available inside of the LibreOffice application via the “Help” menu; the page is entitled “Moving Cells by Drag-and-Drop”, and available when I select “LibreOffice Calc” from the pop-up menu at the top left of the Help menu, switch to the “Index” tab, and search the index for “moving; cells by drag and drop”. Please cf. the attached screenshot. It shows the US English version of the help.

(In reply to comment #11)
> Additional there might be a Help problem, but I d not know whether Mac has
> it's own Help texts different from WIN Help?

I would guess it has, because (cf. my screenshot) the help text talks about the Command key, which is specific to Mac OS X. But please compare the text visible on my screenshot to the version available in LibreOffice for Windows. If there are any substantial differences, it is clear that there are platform-specific versions of the LibreOffice help.

Created attachment 72990 [details]
Screenshots comparing overwrite - ousting mode

(In reply to comment #13)
Due to comment and screenshot Help seems ok, that's a plausible equivalent of the function I expect and see in WIN

The Mac test seems to be:
1. fill the first three fielda (A1,B1,C1) of row 1 with random data
   (for example "a","b","c")
2. select colum C by clicking the column header 
3. Click into C2, keep mouse button pushed
4. Start moving mouse pointer to the left
   Mouse pointer changes to "Not here" in C2
6. When you have trespassed border C->B Mouse pointer changes to "Move",
   Border around column B between become bold
7. When you reached middle of B2 press <Alt> (or whatever required for Mac)
   Black border at right of column B should disappear, what announces that 
   column D will shift right old column b contents.
8. Release mouse button
   > Contents of columns B,C have interchanged.

The question is  whether you can find any Key (combination) what will let disappear right border in step 6

*** Bug 61116 has been marked as a duplicate of this bug. ***

Created attachment 75119 [details]
Screenshot of LO Help on shortcuts for moving cells

(In reply to comment #14)
> [...]
> 7. When you reached middle of B2 press <Alt> (or whatever required for Mac)
>    Black border at right of column B should disappear, what announces that 
>    column D will shift right old column b contents.
> 8. Release mouse button
>    Contents of columns B,C have interchanged.
> 
> The question is  whether you can find any Key (combination) what will let
> disappear right border in step 6

The key combination, that lets te right border disappear on mac are "alt" or "alt + ctrl". 

While the result of the drag&drop operation with both key/key-combinations is identical, the behaviou while performing the operation is slightly different.

1) D&D Column C and pressing "alt":
 * A green "+" icon appears next to the pointer, indicating a copy operation
 * The right border dissappears
 * Result: C ousted B to the right, but a copy has been created instead of moving now it looks like this:
  |  A  |  B  |  C  |  D  |
----------------------------
1 |  a  |  c  |  b  |  c  |


2) D&D Column C and pressing "alt + ctrl":
 * The right border dissappears (no icon appears)
 * Result: see above, exactly as 1) when pressing "alt"


So 1) and 2) have the same result, while the appearing "+"icon whilst performing the drag and drop operation is the only difference.

Although it isn't documented I suppose the combination "alt + ctrl" to be ment for "moving" columns because it lacks the "+" icon but it's still removing the right border as one would expect for the moving operation.

LIBRE OFFICE HELP

I attached a screenshot of the mac manual with the drag and drop shortcuts (attachment 75119 [details]). It is somewhat confusing and even erroneous. The "Command" key is beeing confused with the "Control" key. For example: using the Command key alone has no effect at all, whilst performing drag & drop operations on cells, rows or columns - the help claims the opposite. So, the help seems to be messed up seriously at this point.

So, is there any key combination that allows the rows/columns to be moved by dragging?

*** Bug 61116 has been marked as a duplicate of this bug. ***

(In reply to comment #18)
> So, is there any key combination that allows the rows/columns to be moved by
> dragging?

No, not to my knowledge. That's why i filed this issue. I consider this a OSX specific application bug in combination with an erroneous documentation.

I've also checked with 4.0 version - same issue. And, also checked with the latest version of Open Office - same issue. This is a very common (missing) functionality to me, wonder how other people are coping with the issue.

(In reply to comment #20)
> (In reply to comment #18)
> > So, is there any key combination that allows the rows/columns to be moved by
> > dragging?
> 
> No, not to my knowledge. That's why i filed this issue. I consider this a
> OSX specific application bug in combination with an erroneous documentation.

I totally agree: this is an OSX SPECIFIC BUG since ever.
I had the same issue with OpenOffice but only on OSX platform.
I never had problems on Windows versions.

On OSX I never had the chance to move&insert cells with drag&drop.
As Martin well explained on #17: two different GUI behavior -> same result.

I was waiting for the new release but this limitation persists.

Marking as NEW due to last comment

Any idea when this recurring bug under OSX will be adressed ?
Latest version to this day under OSX (4.0.4.2) has the bug. Too bad !

If you're going to up the importance please tell us why - we tend to not like just priorities jumping up. Use this flowchart: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg to help guide you in determining the appropriate priority.

According to the flowchart, marking it as HIGH doesn't seem outrageous to me : this bug is a productivity killer and surprinsingly it's been around for quite a long time. In the end, it could lead users to head for some other piece of software. I doubt it should be too difficult to fix, but I might be wrong on this one, as I'm not a developer.

Feel free to lower it back, and thank you to the community for the hard work. It's a great piece of software despite of all.

Best regards.

This should be HIGH priority!

This problem is still not resolved in 4.1.4.2 release. Instead of "moving cells" by alt-drag&drop (as described in help file) the software does a copy&insert. Nothing gets overwritten, but data gets duplicated. If you want to rearrange a bunch of rows (lets say each row represents a country and you want to sort these rows by drag&drop) you and up with a lot of duplicated rows and often end up deleting the wrong ones. It really cost me a lot of time compared to LO Windows an all Excel versions!

PLEASE FIX!

Alex

Please don't update version - version is oldest version the problem is confirmed on.

The bug is still present with the same behavior in every OSX version since it was noticed.

In the future please pay closer attention to prompts - version is "earliest version" and when you change it to a later version a big warning comes up saying that it's supposed to be earliest version. Reverting last change.

Confirming that the problem still exists years after reporting 
Tested with LibreOffice 4.4 on recent Mac OSX OS (Yosemite, El Capitan).

Confirm the bug still exists in 5.3.3 on macOS. Dragging with CTRL+ALT copies instead of moves a column, although no "+" icon is shown next to the mouse cursor.

I can confirm that this still exists in LibreOffice Version: 5.4.0.3 on MacOs 10.12.6

Dragging a column as described, while holding the alt key results in the column being copied rather than moved.

The same to me but in my case it doen't work at all, I'm using LO 5.4.2.2 x64 on Windows 10 PRO x64

I can confirm this behavior on LibreOffice Version: 6.0.2.1 on Mac.

Since making a copy by pressing the option-key (also named 'alt'-key) is commonly used in Mac OSX system-wide, it makes sense that a column also gets copied that way.

But if I press option+command while pasting in Finder for instance: then it moves the previously selected file there.

On the other hand: in Numbers app moving columns works simply by pressing and holding the primary mouse button on the column title and then drag and drop it to the desired destination.
I would suggest that way as the most intuitive way to do it in LibreOffice on Mac.

Using a Mac - alt/option copies, but doesn't move the rows/columns.

Any idea when this will be fixed or is this not perceived as a problem?

Bug ist still present:

Version: 6.2.4.2
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU-Threads: 4; BS: Mac OS X 10.14.5; UI-Render: GL; VCL: osx; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded

Behaviour is still present.

Version: 7.0.0.3
Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e
CPU threads: 4; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

This is such a basic bit of functionality, and to get it so wrong... I really don't understand how this has been overlooked for almost 8 years. The "ALT to copy" functionality which is currently exhibited is contrary to the LibreOffice documentation (as mentioned earlier in this thread), but *does* match the conventions of macOS. Having said that, there is still currently no way in LibreOffice Calc for macOS to simply rearrange rows and columns like one is able to in MS Excel or Google Sheets.

"NEW" is not a reasonable status for this issue to have. Is this issue WONTFIX? If not, what is the expected timeframe in which this will be addressed?

Created attachment 171246 [details]
demonstration of rows reordering in Google Sheets

This isn't MacOS-specific. On Linux (GTK3 version), dragging rows/columns is impossible, no matter if you select them first, use alt/ctrl/shift/ctrl+alt/ctrl+shift/alt+shit while dragging with the mouse, etc. There just is no way to reorder rows/columns at all, as far as I can tell. Do I need to file a new bug about that platform specifically, or should we just adjust the title and platforms of this bug to reflect that?

Alt+dragging cells works, but not rows/columns, and I don't care about cells because I could use cut & paste for those. Cut & paste doesn't work for rows/columns however, because you need to be able to insert "between" other rows/columns.

Meanwhile, Google Sheets lets you reorder simply by selecting the rows/columns and then dragging them around, no keyboard modifiers required, which makes a ton more sense in my view (because if I wanted to drag-select multiple rows/columns, I wouldn't be clicking/selecting first). You can see that behavior in action in the gif file I am attaching now.

I did some messing around with it and found a workaround. Holding down Option will copy the currently selected column and allow it to be inserted next to a target column. The original column could then be deleted.

I haven't tested this on Linux (will try to do that later) or Windows, so I'm not sure if there's a similar workaround.

Excel supports moving cells by:

1. select a column/row
2. hold shift while clicking at the edge of the column next to a cell, not the header
3. release the click in the desired location before releasing shift

This works on my Mac (Catalina).

Comment #43 is still valid as of LO 7.6.1.2

(In reply to QA Administrators from comment #44)
> If the bug is present, please leave a comment that includes the information
> from Help - About LibreOffice.

*** Bug 136389 has been marked as a duplicate of this bug. ***

Updated title and added two duplicates: There's a few problems that are interlinked

I have uploaded a test case with a table copy-pasted from the Help section describing the keyboard shortcuts and how they should work

Some operations work as advertised, while others do not
Using control instead of command fixes some of the issues, but not all, so there is something wrong somewhere :)

Created attachment 191638 [details]
Test case with current bug behavior in LO 24.2

Upping priority to High and added URL link to documentation.

This is such an old bug, that a ton of things has changed in aspects touching on this bug. Documentation has changed, macOS keyboard shortcut handling has changed.

I revisited https://help.libreoffice.org/7.6/en-US/text/scalc/guide/move_dragdrop.html?&DbPAR=SHARED&System=MAC and tried to reproduce the documented behavior:

✅ No key: Cells are moved and overwrite the cells in the target area. Source cells are emptied

❌ Command key: Cells are copied and overwrite the cells in the target area. Source cells stay as they are.
In my test, whenever I select a cell, press cmd and try to drag the selected cell over another cell, the cells between are highlighted. While I would call this expected behavior, documentation about this is then false.

❌ Command+Shift keys: Links to the source cells are inserted and overwrite the cells in the target area. Source cells stay as they are.
Same as command only key.

❌ Option key: Cells are moved and shift the cells in the target area to the right or to the bottom. Source cells are emptied, except if you move within the same rows on the same sheet.
In my test this did nothing. No content was copied or moved when dragging A7 to A3 with all cell fields filled with test text.

❌ Option+Command keys: Cells are copied and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
In my test this did nothing.

Option+Command+Shift keys: Links to the source cells are inserted and shift the cells in the target area to the right or to the bottom. Source cells stay as they are.
In my test this did nothing.

Test environment:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 0f6f5048d223731aa52b768a77244d0208711391
CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Raster; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

> This is such an old bug, that a ton of things has changed in aspects touching on this bug. Documentation has changed, macOS keyboard shortcut handling has changed.

Contrary to what I previously said in comment #42, on Linux with 7.6.x (and presumably the upcoming 24.2) on Linux I can confirm that selecting the whole row/column and then alt-dragging the cells (not the column/row header) works. I don't know if I somehow had not observed correctly back then, or if the behavior indeed changed since 2021. I don't know if this works for Mac (or Windows) users now.

This trick (when it works) remains very counterintuitive though, and this bug report has become a bit confusing in scope. I'd like again to propose the "Google Sheets" UX behavior for all platforms as per comment #42; would it make sense to make a new simple ticket out of that (to start fresh with a simpler scope), or it'll just be considered a duplicate of this one here?

(In reply to steve from comment #51)
> I revisited
> https://help.libreoffice.org/7.6/en-US/text/scalc/guide/move_dragdrop.
> html?&DbPAR=SHARED&System=MAC and tried to reproduce the documented behavior:
> 

> ❌ Command key: Cells are copied and overwrite the cells in the target area.
> Source cells stay as they are.


> In my test, whenever I select a cell, press cmd and try to drag 

In case it is not clear, the procedure is (AFAICT):

1. Select the range area you want to copy/move/link_to. If it is only one cell, press the mouse button on the desired cell, move it slightly out of the cell and return it back to the desired cell, without releasing the mouse button.
2. Release the mouse. The intended area is now marked (painted/colored) as selected.
3. Press the mouse button on some point _within_ the selected area; do not release the mouse button.
4. Drag the mouse in such a way that the selected area covers the intended destination area.
5. Without releasing yet the mouse button, now add the additional keyboard combination key(s) if needed (according to the desired action to be performed), and keep the whole combination still pressed.
6. When the expected result is shown on your expected destination area (with different "border" and pointer styles according to the expected action), release the mouse button (only). > The expected result should be performed now.
7. Only now release the additional keyboard combination keys, if any such combination was used in step 5.

I am not saying it is the most user-friendly procedure, but it is the procedure that is described in the official help documentation for LO 7.6 (or at least that is the way I understand it, and that's how I proceed in LO Calc).

Reading the docs, it sounds like holding Option will cause the cells to move.

It does not. The original cell or row remains unchanged.

It doesn't help that the mouse pointer doesn't change to give an indication of what the different modifier key combinations will do.