Bug 64028 - Enhancement: option to retain cell formating in Calc when <Ctrl> X is used to cut contents of a cell
Summary: Enhancement: option to retain cell formating in Calc when <Ctrl> X is used to...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 156088 (view as bug list)
Depends on:
Blocks: Calc-Cells Cut-Copy
  Show dependency treegraph
 
Reported: 2013-04-28 23:45 UTC by MR Zenwiz
Modified: 2023-06-29 03:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MR Zenwiz 2013-04-28 23:45:35 UTC
This has happened now at least five times in a row.

I use ^X to cut the contents of a cell to transfer it to another cell, and Calc forgets what the format in that cell was.  I have to reformat the cell to get it back.

Most of my Calc cells are formatted for currency, with a few exceptions, all in the same spreadsheet.

This is really irritating and totally wrong.

Please fix.

Thank you.
Comment 1 V Stuart Foote 2013-04-30 00:22:16 UTC
MR Zenwiz, so is your complaint that the pasted copy of the cell is unformatted, or that you have cleared the formatting of the existing cell?

<Ctrl>+X will cut ALL information, clearing formatting. That is by design.

If you want to retain formatting on the source cell, you need to <Ctrl>+C to copy, and then delete the content with a back space where default is to leave formatting intact.

As to pasting with <Ctrl>+V, or <Ctrl><Shift>+V (for Paste Special) those will paste ALL including formatting by default.

It is all working correctly for me.

Perhaps clear your per user configuration and see if default gets you back to expected actions.

If adjusting your use of <Ctrl>+X and/or clearing your configuration sets things right, please close this as Not a Bug.
Comment 2 MR Zenwiz 2013-04-30 01:11:23 UTC
Clarification:

^X cuts everything from the source cell, including the formatting, causeing the source cell to revert to the default format.

If this is by design, it is incorrect design and needs to be fixed.

The purpose of the "cut" function is to delete the data being cut from its current location so the data can be pasted into a new location.

If this is by design, then a new function that performs cutting the data without disturbing the underlying format should be instituted.  That is, there should be a "cut (data only)" function and a separate "cut all" function.

I can see where this might be applicable when one is cutting an entire row or column, but not with individual cells.

According to at least one person, on Windows 7, the cut does not change the format of the source cell.  I contend that this should be the default behavior for single cells.

If the implementers/designers disagree, I suggest considering this as an RFC.
Comment 3 V Stuart Foote 2013-04-30 01:34:54 UTC
Have adjusted summary and setting New as a low priority enhancement request.

<Ctrl>+X has had this function since early OpenOffice era https://issues.apache.org/ooo/show_bug.cgi?id=8461

If you are serious about seeing this long present behavior changed you must flesh out how you would expect it to behave.  Perhaps a "Cut special" <Ctrl><Alt>+X to complement "Paste special" <Ctrl><Alt>+V.

But please be aware that this is not a bug--LibreOffice and Apache OpenOffice function as designed regards the <Ctrl>+X Cut function in Calc and clearing formatting of source cells.

Windows builds do clear formatting of source cells when a <Ctrl>+X cut occurs.
Comment 4 V Stuart Foote 2013-04-30 02:01:24 UTC
(In reply to comment #3)
> 
> ... Perhaps a "Cut special"
> <Ctrl><Alt>+X to complement "Paste special" <Ctrl><Alt>+V.

Sorry, correct that to read "Cut special" <Ctrl><Shift>+X to complement "Paste special" <Ctrl><Shift>+V.

The <Ctrl><Alt>+V is Windows generic for paste special but is not assigned in LibreOffice which uses the KDE/GNOME norm.
Comment 5 Cor Nouws 2013-04-30 08:57:58 UTC
(In reply to comment #0)
> [...]
> I use ^X to cut the contents of a cell to transfer it to another cell, and
> Calc forgets what the format in that cell was.  I have to reformat the cell
> to get it back.
> [...]
> This is really irritating and totally wrong.
> 
> Please fix.

Please fix your workflow :-)

  as V Stuart already clearly explained

IMHO this is absolutely a no fix, since it's basic behaviour spreadsheets in general.
Comment 6 Thomas Lendo 2017-07-24 14:08:17 UTC
For me, this enhancement request is still valid and I run into the same problems as the bug opener. Cutting a cell or moving it with the mouse destroys the cell style and reset it back to Default style.

This may be intended by the developer and common in spreadsheet programs, but it is a different behavior than in Writer. In Writer you can cut a paragraph with a specific style. If you don't delete the empty paragraph, the style is still active and you can write text that is formatted with the same style as the cut text had applied.

I also need Writer's behavior in some of my Calc spreadsheet documents where every column has it's own style (accessible via Styles and Formatting sidebar panel). Now if you move a cell from one row to another row in the same column, the empty cell is really empty and hasn't the column's style anymore - but I only want to cut content and not style.

The clipboard still can contain content + formatting. User can paste without formatting to insert only text in another cell. But the cell where you have done the cut should keep its style.

I see that it will be not practicable to change this for the mass of users who ignore styles, but an own cut command mentioned by Stuart would help for users who use styles in Calc.

Another solution would be an option in Tools > Options > Calc > General where the user can change the cut behavior in cells. But that would be less optimal.
Comment 7 Stéphane Guillou (stragu) 2023-06-29 00:33:16 UTC
*** Bug 156088 has been marked as a duplicate of this bug. ***
Comment 8 William Friedman 2023-06-29 03:13:18 UTC
I opened a duplicate bug report/enhancement request today, more than 10 years after the original request. 

While it is true that both Google Sheets and Excel evince this behavior, it is also true that users have been trying to work around it for years 
(re: Excel, see: https://stackoverflow.com/questions/29122940/keeping-the-formatting-of-the-cut-cells-preserved and https://www.reddit.com/r/excel/comments/3dkbk3/how_can_i_cut_and_paste_text_from_a_cell_but_keep/; 
re: Google Sheets, see: https://www.reddit.com/r/googlesheets/comments/jpf7tv/moving_data_without_losing_formatting_in_columns/).

I wish I understood the origins of this behavior in the spreadsheet world. It seems so counter-intuitive to how cut behavior works generally (remove the data, leave the source formatting) that there must be a reason that it was implemented this way the first time. What surprises me is the dismissive reactions to the suggestion that this behavior is undesirable to some users in some (many? most?) use cases, and the apparent lack of interest in providing what appears to be a small customization enhancement. This is all the more surprising given the extensive dialog box offered for deleting a cell. Why should "cut" be treated with absolute uniformity when "delete", a component action of "cut", is extensively customizable?

I hope that a developer some day concurs that a customizable cut command would raise Calc's usefulness in the experience of some unknown but non-zero number of spreadsheet users. Thank you in advance to that developer!