Also you can open the Toolbar Insert Cells. (Menu/View/Toolbars/Insert cells).

No Master Bug, limitation has always been that way.
No Regression

Reopening because it is RFE
in 3.6.1 not implemented yet
In Excel 2003 is context menu item which opens dialog with variants:
- Insert with shifting columns rightwards
- Insert with shifting rows downwards
- Insert column
- Insert row

In Calc the same dialog resides in Insert->Cells and assigned on Ctrl-+ by default.
IMHO it is naturally to add it to context menu, because context menu is almost empty.

Confirming, marking as NEW and prioritizing as Enhancement - Medium. Probably useful for quite a few people, also easy to implement

Thanks for reporting

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

Thank you, Sasha and Joel, for re-opening this.  For whatever reason, I missed Florian's posts in my email.  I am now using LO 3.5.6.2 on Win7 (as well as Excel 2003 - depending on the project).  I really hope that this enhancement can be accomplished soon.

The questions are:
1) What existing(?) function?
   (I do not know anything like "Insert Cut Cells")

do we want to 

2) add to what to what context menu? 
   (Why is "Paste" in context menu not enough? For me that works fine, I can
   select whether I want to overwrite or to shift existing contents)

Currently we have a "Make it look like in EXCEL" request, too imprecise for an easy fix and for NEW due to <https://wiki.documentfoundation.org/BugTriage#Process>  item 5

To be honest: I don't understand this request. Can somebody contribute a "real life problem" with a sample document and clear description what should be improved?

@Rainer: In the context menu, how can you "select whether I want to overwrite or to shift existing contents"? I have no option there in LibreOffice, but only "paste" which overwrites the content.

Created attachment 68612 [details]
Hwo To Presentation

What's so bad with proceeding as shown in the HoTo?

@Gerry:
I asked for a real life example and got a "I don't know how to" comment ...

Created attachment 68644 [details]
Paste Special not available on Linux

Dear Rainer,

I think I now understand the confusion. Is it possible that this "Paste Special" feature is simply not available on Linux?

Please see the attached screenshot. LibreOffice only offers "Paste", but nothing else. Also, if I try to choose Edit -> Paste Special simply nothing happens.

Detailled description of the screenshot: I had following sheet:
a a 

System: Ubuntu 11.10, LibreOffice 3.5.4.2 Build ID: 350m1(Build:2) PPA.

I also never get this prompt asking me if I want to shift cells. I only get the overwrite prompt which warns me that I'm about to overwrite stuff. 

Bodhi Linux
LibO:3.6.1.2

Sorry, I accidentally hit the Save button:

This is how my example sheet looked like:
a	a	a	a	a	a
a	a	a	a	a	a
a	a	a	a	a	a
c	c	c	c	c	c
c	c	c	c	c	c
c	c	c	c	c	c
b	b	b	b	b	b
b	b	b	b	b	b
b	b	b	b	b	b

However, I wanted to insert the "b"-rows before the "c"-rows so that the sheet looks like this:
a	a	a	a	a	a
a	a	a	a	a	a
a	a	a	a	a	a
b	b	b	b	b	b
b	b	b	b	b	b
b	b	b	b	b	b
c	c	c	c	c	c
c	c	c	c	c	c
c	c	c	c	c	c

In Linx there are only two possibilities to solve this issue:
(1) Mouse and click: Insert manually three empty rows before the "c"-rows and cut&paste the "b"-rows over these created empty rows.
(2) The people-who-search-for-shortcuts-approach: http://help.libreoffice.org/Calc/Moving_Cells_by_Drag-and-Drop To be honest, for very long time I did not know that this feature existed. 

I suggest that this Moving_Cells_by_Drag-and-Drop should be accessible by the context menu.

This still is not NEW, we have several unclear observations.

So I think we should first do some research concerning the unavailable 'Paste Special', what would be a real bug.

For this new situation I should contribute a Step by step instruction for my  Attachment 2012-10-16 08:15 UTC to avoid any misunderstanding and to narrow down the problem.

Steps how to reproduce with parallel installation of Master "LOdev  3.7.0.0.alpha0+   -  ENGLISH UI / German Locale  [Build ID: 747ecb]"  {tinderbox: @16, pull time 2012-10-08 09:46:32} on German WIN7 Home Premium (64bit) with separate User Profile for Master Branch:

1. Launch LibO
2. Blank New Spreadsheet from LibO Start Center using "New Spreadsheet" Button
3. Type "1" into A1
4. Use Autofill to fill column until A16
6. Select A1:B7 using mouse
5. Use Autofill to fill rows A1:A16 until  column D as shown in screenshots
8. Right click B7
   > Context menu appears
9. 'Copy' 
10. Click C11
11. rigt Click C11
    > Context menu appears
12. Click 'Paste Special' in context menu
    Dialog appears  as shown in "How To Presentation"

I also can reproduce that correct behavior on Ubuntu 12.04 (VirtualBox) with LibO 3.5.4.2.


Now an other case what might be related to garrys screenshot.
Gerry's screen shot shows a completely different situation, he selected a complete row(?) and right clicked on a row header(!). As the name "context menu" says the contents of that menu is context sensitive and so we have to investigate every context separately.

I can't reproduce Gerry's observation with a.m. Ubuntu LibO and a proceeding a little different from Gerris proceeding:

11. Launch LibO Spreas sheet from Application selector
12. do nothing
13. Type "1" into A1
14. Use Autofill to fill column until A16
16. Select A1:B7 using mouse
15. Use Autofill to fill rows A1:A16 until  column D as shown in screenshots
16. Click on Page Heading "7"
    > Row becomes selected
17. Right Click on Page Heading 7
18. In context menu click 'Copy'
19. Right Click on Page Heading 7
20. In context menu click 'Paste Special'
    Dialog appears  as shown in "How To Presentation"
21. Paste special with "Shift Cells down" 
    will work as expected, shifts rows including selecte one down
     and pastes clipboard to so created empty row


I CAN  reproduce Gerry's observation with a.m. Ubuntu LibO and a proceeding similar to what might have been Gerry's. I did not try to follow exactly  Gerry's proceeding, because screenshot seems to show that He copied empty cells A12:F20, and "Paste Nothing" seems not to be a very interesting case

31. Launch LibO Spreas sheet from Application selector
32. do nothing
33. Type "1" into A1
34. Use Autofill to fill column until A16
36. Select A1:B7 using mouse
35. Use Autofill to fill rows A1:A16 until  column D as shown in screenshots
36. Select C13:D16 using Mouse
    > Range becomes highlighted
37. Right Click D16
38. In context menu click 'Copy'
39. Right Click on Page Heading 7
    Context menu WITHOUT paste special appears
That looks like bug in context menu, BUT althoug Paste special exists and seem active in menu 'Edit', it will do nothing.

WIN LibO 3.5.2 won't even offer a paste function in Context menu for this case, Master 3.7.0 works fine, offers Paste special and shifts cells

But now I understand that I was wrong concerning Gerry's intentions, I believe He wanted to cut and paste, and screenshot shows cut contents? 

New test 

41. Create spreadsheet as whon in Gerry's ASCII art
42. Select all "b" (but not the complete rows)
43. rightclick last "b" (bottom right)
44. click 'Cut' in contxt menu
    all "b" disappear
45. Click row heading of first "c" row (what, BTW, is wrong, a paste will fill
    all the clumns of the row(s) with "b" and not only as many columns as 
    were filled with "b" in step 42
46. right click row heading of first "c" row
    Indeed, Context menu does not contain paste special.
Menu 'Edit -> Paste special' here shows the same problem as described after step 39, does not work.
Paste from context menu will work as expected, overwrite all "c" and fill lines completely until end with "b"
WIN LibO 3.5.6.2 in step 46 does not offer a paste at all
    
Results in step 46 with parallel installation of Master "LOdev  3.7.0.0.alpha0+:
Paste Special will be offered, dialog only allows "don't shift" and "shift right", I can't understand why "shift down is not allowed", and "shift right" is nonsense, can not be done, I will submit a separate bug for this.  'Don't shift' and 'Shift Right' work fine.
Menu 'Edit -> Paste Special' works the same way as context menu.
Same results with LibO 3.6.3.1

So the question for now is:
Can you confirm that the "Step 46 problem" is fixed for LibO 3.6.3.1 and 3.7.0 under Linux (as i see it for WIN)?

Please excuse me for long comment, but I think it's necessary to figure out what exactly the remaining problem is.

It appears that because Gerry had a different problem, and because Rainer could not understand (?) my original request, that this "bug report" has now been diverted to deal with something else.

Now I am confused.  

Unless someone with authority restores the original focus of this request, then I guess I'll take my original enhancement request and create a new bug report.

Rainer, I think you got to the root of the problem.

From my understanding user is asking for us to include a separate paste option that is for "don't overwrite" similar to how Excel does it. Paste special isn't intuitive for a user to think of when they are pasting something (this usually is for pasting only numbers, or only formats, etc...). Excel has an option called "insert copied cells", where this is "paste while shifting" and then a regular paste which is "overwrite"

This is when we select a column or row to cut and then paste somewhere else

If I'm understanding this correct, I still see it as a valid request even if it the functionality is already available by going to paste-special

@Tim - don't open a new bug, Rainer is one of our leading QA people ;) Just need to figure out the exact request, let us know if I was correct in my summary above

Thank you, Joel, and yes, what you said is accurate.

To try and be more detailed and easier to understand:

In Excel, when you point to a cell, range, row, or column and right-click for the context menu, you normally see "Insert" as one of the options.  Choosing that will insert a blank row, column, or cell as appropriate, moving the existing existing data down or to the right.

However, when you choose to "cut" or "copy" a cell, range, row(s), or column(s), and then right-click on a destination cell, range, row, or column, THEN instead of "Insert", you see "Insert Cut Cells" (or "Insert Copy Cells").

Choosing "Insert Cut Cells" will delete the source cell, range, row(s), or column(s) from its original location and insert it into the destination location.  All cells between the original and the destination locations will move to make room for the source cells at the destination and to fill the gap created at the original location.

Choosing "Insert Copied Cells" will work similarly without deleting the source cells.  If it's rows being copied, the existing row at the destination gets moved down; if columns, the existing column at the destination is moved to the right.  If it's a cell or range being copied, you are asked whether to move existing cells down or to the right.

That is what I would like to see in LO.

Rainer I'd like to mark this as NEW again, can you confirm that this is a valid request? Basically just to add the option inside of the dialog that comes up upon right click instead of having to go to paste special. 

What it looks like in excel:

http://imgsrv.worldstart.com/mso-images/insert-copied-cells.gif

To be honest, I lost overview here. What do you think about closing this bug here, to open new separate bugs concerning the fond bugs and valid enhancement requests (if appropriate, with links to relevant comments in this Bug)?

Rainer - I prefer just editing the title here and marking as NEW. I think all the other stuff said, if someone else wants to open separate bugs that's fine but the root of this particular enhancement request is "Insert -> Insert Copied Cells..." which I think is completely valid.

Marking as such, Rainer, hope this works out :)

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

I'm not sure what's so difficult about this bug. LibreCalc just needs to implement the "Insert cut cells" context menu option from Excel.

Here's a screencast of a "real life problem": http://screencast.com/t/S5jtL4bz

(by the way, a screencast is worth a thousand words)

Well the code is there for anyone to poke at - feel free to do it if it's easy to do.

Our devs are working on some serious bugs -- some of which take days of experienced developer time and are critical for everyone, not just a convenient enhancement.

Another option is to of course pay someone to poke at the code - again it's all out there free and ready to be hacked

(In reply to comment #28)
> I'm not sure what's so difficult about this bug. LibreCalc just needs to
> implement the "Insert cut cells" context menu option from Excel.
> 
> Here's a screencast of a "real life problem":
> http://screencast.com/t/S5jtL4bz
> 
> (by the way, a screencast is worth a thousand words)

the screencast is very useful to understand what the enhancement request is about.
I agree that doing the same thing in Excel is much easier.

after saying that, I agree with Joel, if you have coding skills try doing it yourself... if you don't have, make a donation to LibO or hire a developer...

it worked for me..
https://bugs.freedesktop.org/show_bug.cgi?id=48729#c4

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

This would be a nice addition to Calc's functionality. As a spreadsheet user this is one function that I use on a daily basis. 

I always assumed this was asking too much from Calc. From the comments below it seems to be an Easy Hack... Can't it be included in some GSOC task?

In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise

I was just pointed to this bug after *years* of minor frustration at having to do the - insert new target row/columns, cut source row/columns, paste to the new blank target row/columns, delete original source columns - dance, I finally decided to ask for help on the users list, and after a short time, discovered that I had been totally missing BOTH the 'Paste Special' method, and much better, the ability to MOVE rows and columns using drag-n-drop, just as you can groups of selected cells (which I already knew about, and used a lot).

So, here are some points I'd like to make...

1. Anyone coming from Excel trying out Libreoffice (or Openoffice), who encounters this issue, will definitely declare this a problem, the severity determined by how often they use it - the more they use the Excel feature, the more serious the problem will appear to them.

2. The Help text that describes moving cells, does not mention anywhere that this also applies to entire rows and columns.

The Help documentation definitely needs to be updated. I will file a bug/enhancement for that in a bit, along with some suggested new text.

It simply never occurred to me to click (grab) down in the CONTENT after selecting a row or column. I must say it was a major revelation, followed by wailing and gnashing of teeth at the many years I have missed something so blatantly obvious (hindsight and all), floundering with the above roundabout way.

And since I, a SysAdmin, been doing I.T. related stuff, including end-user support for things like this and who considers himself very technically inclined, never figured this out myself using the Help or Google, and only did so after asking on the list (admittedly I should have done that years ago, but the fact is I didn't do this dance all that often, which is why I termed it a source of 'minor frustration' for me)), I venture to guess that most others would never discover the drag-n-drop method (which indeed is very cool!), and would be just one more potential user who tried Libreoffice and left in frustration.

I'm not saying Libreoffice should try to emulate every single Excel feature, but the ones that are very useful, and may not be too much work, should absolutely be considered.

3. The 'Paste Special' still leaves the source row/columns in place.

I consider this a bug. If you CUT an entire row/column, it should CUT the entire row/column, not just the content in the cells in the row/column.

Does anyone know if there is already a bug open for that? If not I'll open one later, when I enter the bug for updating the documentation.

4. I really like the new (to me) graphical drag-n-drop method, but for most cases I think the Excel way is quicker and what I'd prefer to use - just select the row/columns you want to move, right-click > Cut[Copy], then "right-click > Insert Cut[Copied] Row(s)[Column(s)" on the row/column header above/to-the-left-of which you want to insert the Cut[Copied] row/columns.

Note: Excel options are labeled 'Insert Cut[Copied] Cells', regardless of if you cut/copied a group of cells, or entire row/columns.

I think this is wrong. Libreoffice, if this is implemented, should distinguish between 'cells', and entire row/columns. If the user cut just a group of selected cells within a sheet, then the choice should say 'Cells', but if they selected entire row/columns, then the choice should reflect that as 'Rows' (or 'Columns').

I think if Libreoffice implemented both ways, and documented these properly, it would be yet another way that it can be considered superior to MSO...

Documentation enhancement bug 75609 opened...

How do I donate to have this done?

I really don't have time to poke through the massive codebase, but all the pieces are there:

* the Paste Special + Shift cells down functionality
* keyboard handling to intercept Ctrl+Shift++/= (control shift plus/equals)

When done, I can't imagine the patch will be more complicated than 10 lines of code. If it is, that suggests a need for refactoring the paste special functionality.

@Dan -

There is no direct "Pay for fixes" within TDF (we have no developers). Some have used freedomsponsors.org and then place the link in the bug itself.

The other option is paid support (outside of TDF) but I can guarantee that it'd be too expensive for such a minor task. Even thinking it'd take 5-10 hours to implement (finding the relevant code, patching it, testing it, submitting it) you're talking about several hundred dollars.

So - I suppose options are to bid on freedomsponsor (not supported by TDF in any ways), reach out to companies who offer support (probably very expensive) or possibly ping individual certified developers and ask for a quote: http://www.documentfoundation.org/certification/developers/

EasyHack? Doesn't this bug qualify as an EasyHack? It would be great if a developer could have a look at it.

needsDevEval (see whiteboard) is the equivalent of "proposed Easy Hack" - an easy hack requires an expert developer to give code pointers and be willing to mentor...it's not enough just to say "this looks easy."

Hello, as an Excel and LibreOffice Calc user, I also want to reinforce the comments made earlier by these two gentlemen.  There is a real need for the "Insert Copied Cells" and "Insert Cut Cells" functionality in LibreOffice Calc, implemented as close as possible to the functionality of Excel.  Excel spreadsheet users use these functions all the time.

The usage is well described in these three comments.

Tim Deaton 2011-08-08 10:13:29 UTC
https://bugs.documentfoundation.org/show_bug.cgi?id=39936#c0

Tim Deaton 2012-10-18 02:38:01 UTC 
https://bugs.documentfoundation.org/show_bug.cgi?id=39936#c23

Charles 2014-02-28 12:26:07 UTC 
https://bugs.documentfoundation.org/show_bug.cgi?id=39936#c34

I can see from Google that this has been on the request list for a very long time.  It would be "just awesome" to see it finally incorporated into LibreOffice Calc, which is a great application in so many ways.

Thanks for keeping this feature enhancement request alive.

(In reply to Dan Dascalescu from comment #43)
> After a Windows crash, I gave LibreOffice, now at version 5, another chance.
> 
> However, the annoying ergonomics of moving a large group of cells via
> "select the new location and then | Edit | Paste Special | Shift Cells Down"
> prevents me from adopting LO.
> 

You don't have to go to the "edit" drop down - you can just right click and then go to "paste special"

As far as it being implemented....patches welcome ;)

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

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

+1

maybe we can start by writing a macro

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

Changing priority back to 'medium' since the number of duplicates is lower than 5

I set back to High. This may even be "highest" in Calc. 
Note, even that's not the only criteria, that number of duplicates is more than 5.

I'm putting to highest. I checked and there was no highest enhancements at all, that I find wrong. Per normal distribution, few per component are fine. 
There are multiple criteria: number of duplicates, users, frequency of use, but also ease of implementation (useless to put highest for a completely new feature). By all that criteria, this one is highest.

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

I think, this basic function is missing in LibO. See also comment "https://superuser.com/questions/663629/move-rows-with-the-keyboard-in-calc". The use of "Paste Special" with option "Shift cells down" will not delete source cells like it does the corresponding Excel function "Insert Cut cells". It's a tragedy - since 2011 a large number of up to 320 updates of LibO has been released, but there was no progress in implementing this basic feature. LibO has a problem with usability!

Vote +1 for adding this feature.
To be clear:
(a)If user "Copy" then "Insert Copied Rows/Columns",
  the source lines remain.
(b)If user "Cut" then "Insert Copied Rows/Columns",
  the source lines are removed (completely removed, not just blanked.).
(c)both right-click menu commands, and keyboard shortcuts

The reason this feature is important is because the existing "insert blank lines" method requires the operator to count the lines many times, which is prone to mistakes and time consuming. For example, if you need to move several columns, you would:
(1)count how many columns, say 61.
(2)write that down on paper.
(3)go to the destination, carefully count the planned insertion to select a range of 61 columns.
(4)double check that you really inserted 61 (or more) blank columns, because if there were only 60, that will be a disaster.
(5)memorize the data around the destination, to detect overruns, onto paper.
(6)cut (or copy) and paste the columns.
(7)scroll to the end of paste area and check whether you haven't made an overrun or underrun.
And if you want to copy, instead of moving, then repeat step (3)-(7) for the number of destinations you want to insert.

With this feature, the pasting part will become a matter of just 2 clicks, and no mistakes.

Actually, I also want an extra feature that Excel doesn't have yet:
Give 2 choices of where to insert, agains the cell border.
(a)Insert Copied Rows/Columns before the border, ie. "I want to add this INTO the tail of that table"
(b)Insert Copied Rows/Columns after the border, ie. "I want to move this right below to but OUTSIDE of that table"
This affects
(1)Whether the existing border line graphics stay below the insertion, or above it.
(2)Whether the cell formula range (such as sum() function, named variables, sort/filter range etc.) should be extended or not.
I want this because currently I am wasting a significant time re-drawing the border line for tables and checking/correcting broken sum() source ranges.

  > Xisco Faulí 2019-11-29 13:29:45 UTC
  >Changing priority back to 'medium' since the number of duplicates is lower than 5

Appalling criteria.
I think we are expected to carefully research past reports to avoid duplicates, so count of duplicates should never be taken as a measure of popularity.
Please don't do it again.

Ahh, I'm terribly sorry, I overlooked that the insert feature part was already implemented in "Paste Special".
But why is the "Shift cells" optioned grayed out when you select the destination to column A (ie. I want to paste them to the left of A)?

And I still want configurability to pull them up to the top level in context menu.

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

Although this feature is added to "selective paste", when performing the cut operation, the original row or column is not deleted after the move. This should be improved, only the original row or column is deleted after the move.

In addition, I hope to separate the secondary page from the selective paste and add it to the right menu.

Please add my +1 to this request.

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

Really need this. Work around is many steps. To cut a row and insert it below, have to first create a new row, then cut and paste, then delete the old empty row.
Calc Spreadsheets can be much too large to do it with Drag and Drop.

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

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

I've wanted to see this feature added to Calc for years, and wondered why it's never been addressed.  The "drag&drop" method works, but is hard to use if scrolling is involved

Maybe someone can summarize the function to be implemented? Reading 65 comments is quite time consuming to get to the exact point in this enhancment request. Maybe someone may upload the screencast again since it does not work for me anymore.

So hopefully I can implement it.

Created attachment 186171 [details]
Insert Cut+Copied Rows+Columns

Screenshots for desired behaviour, as seen in MS Excel.

For whoever attempts to implement this feature, the precise combination of keys should be evaluated carefully. Currently, using the mouse and some other key(s) already performs some action in Calc (which are not the same in other spreadsheet tools). Whichever similar or related new feature/behavior, it should also consider the current effects of mouse and keys combinations, so to make it consistent and easy to remember (instead of making it more confusing to recall which combination does what in which context).

Maybe using the same keys as other tools would be preferable, but then current combinations in Calc might need a review.

(In reply to SD from comment #67)
> Created attachment 186171 [details]
> Insert Cut+Copied Rows+Columns
> 
> Screenshots for desired behaviour, as seen in MS Excel.

"Insert from clipboard" could be slightly better rephrasing

Please add the right click menu option for insert cut/copied cells

Balázs, are you still hoping to work on this?

(In reply to Stéphane Guillou (stragu) from comment #72)
> Balázs, are you still hoping to work on this?

Ohh I forget about it. :) I am currently working on those new calc functions, but yeah would be nice to finish this one as well. Already had a halfly finished  patch, but would still have a lot work on this. But if someone else would like to work on it feel free and will send the patch. (hopefully will find it.)