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.
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.
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.
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.
(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.
(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.
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.
*** Bug 156088 has been marked as a duplicate of this bug. ***
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!
*** Bug 161192 has been marked as a duplicate of this bug. ***
Coming from duplicate bug 161192, some relevant info: There is, in that duplicate, interest in having a UNO command to do this, so it can be tied to a shortcut. I like Ctrl + Shift + V as a default. I want to point to the significant interest from users in "formatless cut-and-paste/drag-and-drop", see for example: - https://ask.libreoffice.org/t/calc-how-do-i-drag-and-drop-contents-only-while-preserving-formatting-in-the-original-cell/2978 - https://ask.libreoffice.org/t/how-to-prevent-cell-formatting-being-removed-when-values-are-cut/53102 - https://ask.libreoffice.org/t/calc-can-i-cut-paste-the-contents-of-multiple-cells-at-once-without-affecting-references-and-formats/13971 - https://ask.libreoffice.org/t/preserve-formatting-during-drag-and-drop/44121 So definitely not an obscure idea.
Without reading the comments, the idea could be to introduce a command uno:CutAndKeepFormatting, essentially doing a .uno:Copy plus .uno:ClearContents, that users may assign to either a new shortcut or replace the existing ctrl+X.
(In reply to Heiko Tietze from comment #11) > Without reading the comments, the idea could be to introduce a command > uno:CutAndKeepFormatting, essentially doing a .uno:Copy plus > .uno:ClearContents, that users may assign to either a new shortcut or > replace the existing ctrl+X. To get this straight: the problem is not that Ctrl-X (or Ctrl-C) includes the formatting, but the problem is that pasting-as-is what has been cut/copied, overwrites the formatting of the target cell? I find the summary of the bug confusing :) And a command could better be uno:PasteAndKeepFormatTargetCell?
My understanding is that Cut should (optionally) not remove the source formatting. Pasting at the target offers all freedom around formatting.
(In reply to Heiko Tietze from comment #13) > My understanding is that Cut should (optionally) not remove the source > formatting. Pasting at the target offers all freedom around formatting. Same.
The problem I saw is that when I use cut <ctrl-X> to copy a cell and clear it, then paste <ctrl-V> into another cell, all the formatting that was in the original cell is gone in the pasted copy. I believe this should be an option, where the default is to preserve the original formatting when the copy is pasted. I hop that clears this up.
(In reply to Heiko Tietze from comment #13) > My understanding is that Cut should (optionally) not remove the source > formatting. Pasting at the target offers all freedom around formatting. (In reply to Stéphane Guillou (stragu) from comment #14) > (In reply to Heiko Tietze from comment #13) > > My understanding is that Cut should (optionally) not remove the source > > formatting. Pasting at the target offers all freedom around formatting. > Same. Is that what you read in comment #15?
Okay, let's verify again. (In reply to MR Zenwiz from comment #15) > ...all the formatting that was in the original cell is gone in the pasted copy This part is dubious. Let's say the source cell A1 = 1 has a yellow background. The target B1 is empty and white. By cutting A1 and pasting into B1 you get a white cell A1 and a yellow B1. If you copy A1, paste into B1 both cells are yellow, and after clearing the content of A1 you have a copy in B1 while A1 keeps the formatting. Is that what you want to achieve?
I guess this is more complex than I originally thought. My concern was that I have columns set up so the cells have the same properties in the whole column, like currency (not general), bold and/or italic. Color could also be included - that makes sense to me. When I want to move a cell from one column, with certain properties set, into another column, with or without those same properties set, the cut cell currenly appears unformatted in the pasted column - no format, no bold, no italics, etc., just plain, general appearance. I thought it should be a fairly simple matter to preserve the properties as it originally appeared in the source column when pasted into the target column. If that must include color and every other possible aspect of format, then, yes, at least optionally, it should be possible to paste exactly as-was into the target cell. I hope that makes this request clear.
(In reply to MR Zenwiz from comment #18) > I hope that makes this request clear. Sure - thanks for again explaining. Copy or cut, and choose Edit > Paste Special. That gives you all choices you need - reading from the various descriptions you gave here. If you run into trouble, the best place for help is either the mailing list or the ask-forum. You find the links/info under Help in Calc (& other modules). HTH, Cor
This went in a very strange direction, entirely different than the original request. The original request very clearly was not to have cut remove the formatting of the original cell, as the reported explicitly writes in comment 2: "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*." I therefore do not understand how the issue of cut removing the formatting of the *source* cell got conflated with an issue regarding pasting the cut content, which is totally irrelevant to the original complaint. Either this bug should be reopened and focused on the original request -- creating a cut option that does not remove the formatting of the cut cell -- or my supposedly but not-actually duplicate bug 156088 should be reopened as a valid enhancement request, per comment 6, 8, and the helpful suggestion of comment 11 to be able to configure cut to combine copy + delete contents (but not formatting). Thank you.
(In reply to William Friedman from comment #20) > ... > Either this bug should be reopened and focused on the original request -- > creating a cut option that does not remove the formatting of the cut cell -- I never understood this report like that - but may be my fault. > or my supposedly but not-actually duplicate bug 156088 should be reopened as NP for me :) > a valid enhancement request, per comment 6, 8, and the helpful suggestion of > comment 11 to be able to configure cut to combine copy + delete contents > (but not formatting). > > Thank you. Thank you too :)
For those interested, I have requested additional input on this issue at https://bugs.documentfoundation.org/show_bug.cgi?id=156088#c6.
I still think that this is a valid enhancement request, as moving data without formatting around in a formatted table (e.g. with borders or background colours) is - to me - the only use case of 'cut&paste'. O.c. there are also ppl who always move the complete cell with formatting around. But there is this not so small user group who wants to not touch formatting while moving cell data. Yes, it is possible to achieve this with 2 actions. The request is, i.m.v., to 'be able to link "ctr+x" to "cut only data" in the options and thus *save a lot of typing work*. So it is not about 'not being able to achieve a desired outcome' or about 'the correct thing a shortcut should be', but about being able to work faster by tweaking default behaviour of the software.
(In reply to Dominik Lenné from comment #23) > I still think that this is a valid enhancement request, as moving data > without formatting around in a formatted table (e.g. with borders or > background colours) is - to me - the only use case of 'cut&paste'. Ctrl+C and Del then Shift+Ctrl+Alt+V The latter can be assigned to a key (combination) of your preference. So Ctrl+C and Del is the 'hassle', right?
positive
(In reply to Cor Nouws from comment #24) > So Ctrl+C and Del is the 'hassle', right? (In reply to Dominik Lenné from comment #25) > positive Setting back to "new". I'm not sure why that was closed in the first place, we have: - OP saying that losing the format on cut is the problem in comment 2 - duplicate bug 161192 asking for something similar (where is was also argued that the main issue is the first step, because the "paste without affecting target format" is already possible with a Paste Special that remembers settings) - (ex-) duplicate bug 156088 asking for the same thing - comment 10 listing 4 ask.LO questions asking for the same thing (some referring to drag-and-drop instead of cutting) - comment 8 showing that users elsewhere are also looking for that I see there is opposition to the workflow, and I understand the default is fine, but seeing the above I can't see why an extra UNO command couldn't be created so users can assign a shortcut or add a toolbar button to help them out. I changed the summary to try to make it extra clear.
IMNSHO, suggesting that "cut" in a spreadsheet tool could be defined in a different way, or that the resulting action could be different than it has always been, is not acceptable. All spreadsheet tools define the actions of cut/copy/move/paste/reference/link in the same way, with the difference being in method/UX (and in some cases, formula's syntax), but not in what these actions actually do. In fact, there are limitations to what can be done to only-parts of a cell. The desired result could be easily thought of performing a series of actions (as mentioned already): 1. Copy the source cell (i.e. [CTRL]+[C] in Calc). 2. Delete the content (and only the content) of the source cell, leaving the cell format and everything else related to the cell untouched (i.e. [DEL] in Calc). 3. Focus on the destination/target cell. 4. Paste the cell you copied in step 1. The discussion seems to be focused on performing steps 1+2 easier, for some potential performance or frequency reason. I would suggest that users that are interested in this could create/record a macro (consisting in steps 1+2) and then assign a keyboard shortcut to it. Considering that: * there are (more-than-one) alternative ways to achieve the goal, and that... * when users gain more experience with spreadsheets then the need for this kind of layout corrections tend to be less frequent... ...IMHO the issue in question does not deserve more time from LO developers. There are many other aspects of Calc that are much more relevant (for users), and that have no current alternative available in Calc. If a developer would like to add some UNO command in order to achieve: "copy_cell + delete_cell's_content_only", ...that's up to such developer. Other than that, I would hope that the discussion is settled and that developers could use their time in more-relevant matters.
(In reply to Stéphane Guillou (stragu) from comment #26) > Setting back to "new". I'm not sure why that was closed in the first place, > we have: There are situations where encouraging the reporter/user having better understanding/explaining where to get that, is a much better way to handle*, than trying to find a 'solution' which is somehow weird/against the natural use. This bug, with the simple available options to do what the initial request appeared to be, and the extra additional/different issue in comment 18, IMO fits into that category, where proper understanding is the best help possible.
Thanks Ady for the comment. (In reply to ady from comment #28) > IMNSHO, suggesting that "cut" in a spreadsheet tool could be defined in a > different way, or that the resulting action could be different than it has > always been, is not acceptable. I definitely understand that the default shouldn't be changed, and also agree that we shouldn't even allow to change the default with an Options dialog tick box. > All spreadsheet tools define the actions of > cut/copy/move/paste/reference/link in the same way, with the difference > being in method/UX (and in some cases, formula's syntax), but not in what > these actions actually do. We offer plenty of paste customisation, so I am not too surprised that users might expect some customisation options for what cutting does. One might think "I'm able to paste without formatting, so why should the formatting always be taken away by a cutting action?" > Considering that: > * there are (more-than-one) alternative ways to achieve the goal, and > that... > * when users gain more experience with spreadsheets then the need for this > kind of layout corrections tend to be less frequent... > ...IMHO the issue in question does not deserve more time from LO developers. > There are many other aspects of Calc that are much more relevant (for > users), and that have no current alternative available in Calc. The enhancement request is of "low" priority currently, and could be an easyHack. (In reply to Cor Nouws from comment #29) > There are situations where encouraging the reporter/user having better > understanding/explaining where to get that, is a much better way to handle*, > than trying to find a 'solution' which is somehow weird/against the natural > use. > This bug, with the simple available options to do what the initial request > appeared to be, and the extra additional/different issue in comment 18, IMO > fits into that category, where proper understanding is the best help > possible. Of course, but: - we have to be careful not be pedantic about "this is how things should be done", especially when users repeatedly hit their head against something (which is the case here) - the bug was closed in comment 19 as "works for me", which should be for "there was a bug but it has somehow vanished". I understand that was based on a misunderstanding, focusing on only the paste step, which wasn't the focus anymore. If not offering an extra UNO command is what the community, and in particular the Design team, prefers, I'm perfectly fine with that. But in that case, let's close as "won't fix" with a recommendation to use macro and/or develop as extension. Heiko, would you like to put this one on the UX/Design meeting agenda so others in the team can have a say?
(In reply to Stéphane Guillou (stragu) from comment #30) > Heiko, would you like to put this one on the UX/Design meeting agenda so > others in the team can have a say? I see no need for further discussion. Your summary is correct.
the question is: do we help with a bug report for an option that, if it ever will be added, and looking at the confused comments, may well cause trouble too, whereas on the other hand there is a simple solution right away now, that people can learn with proper guidance from our community :)
Shift+ctrl+X does the trick now.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ec5e0d0cd7074a912415761f779b00f8b7117fcf Resolves tdf#64028 - Command to retain source cell on cut It will be available in 25.2.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.
I am going to test this in a couple of days. Thx for discussing it and putting work time into it.
(In reply to Cor Nouws from comment #32) > the question is: do we help with a bug report for an option that, if it ever > will be added, and looking at the confused comments, may well cause trouble > too, whereas on the other hand there is a simple solution right away now, > that people can learn with proper guidance from our community :) We should encourage users to learn and advance. (In reply to Heiko Tietze from comment #33) > Shift+ctrl+X does the trick now. Adding this "partial cut" was already controversial. Please do not add a shortcut as default. Let it be available for customization, not by default.
(In reply to ady from comment #36) > Adding this "partial cut" was already controversial. Please do not add a > shortcut as default. Let it be available for customization, not by default. Usually I advice to abstain from assigning shortcuts to all commands. But in this particular case I believe it is a workflow that affects many users. And since the clear association became available after solving bug 131688 I thought it makes sense. Please start a discussion in an extra ticket if I cannot convince you.
(In reply to Heiko Tietze from comment #37) > (In reply to ady from comment #36) > > Adding this "partial cut" was already controversial. Please do not add a > > shortcut as default. Let it be available for customization, not by default. > > Usually I advice to abstain from assigning shortcuts to all commands. But in > this particular case I believe it is a workflow that affects many users. And > since the clear association became available after solving bug 131688 I > thought it makes sense. Please start a discussion in an extra ticket if I > cannot convince you. No. Lazy and/or new users that don't care is not the same as every typical user. Adding this as default is not beneficial, for anyone. I would agree to help, but not to "help" in being lazy and to make advancements harder. There is more than one reason for this "partial cut" to be controversial, and it is not present in other tools either. Hmm, why would that be? This is not the first time when keyboard shortcuts are either added or changed just because. This shortcut should be optional only, not by default. I could add reasons for not convincing me, but I won't keep wasting my time.
(In reply to ady from comment #38) > Adding this as default is not beneficial, for anyone. We obviously have different opinions here. Let's keep an eye on it and remove the default shortcut in the next release if users complain.
(In reply to Heiko Tietze from comment #39) > (In reply to ady from comment #38) > > Adding this as default is not beneficial, for anyone. > We obviously have different opinions here. "Opinions" change a lot with experience with spreadsheet tools. What a user might request as a newbie might be discarded by the same user after gaining knowledge and experience. But if the user keeps its knowledge in the same basic level and the usage of spreadsheets is just that, basic, then having several hours (or weeks or whatever) of additional usage won't improve the initial perspective. The lack of clarity in explaining the request (as expressed by more than one comment in this report), and the fact that the request is at a minimum unusual for _experienced_ users should give you enough hints. This is the kind of request that entry-level users might ask for. With more knowledge and experience, the ways in which spreadsheets are used are not the same, and the mistakes and/or changes in layout requiring the kind of actions requested in this report are far less frequent. The request is controversial, even though multiple questions are cited as relevant or related. So I am fine with providing the possibility to achieve this requested action for such group of basic-level users while still promoting advancement, but I am not fine with promoting laziness and incorrect usage of spreadsheets, because (abusing) this action blocks what users should be learning to do in better ways. > Let's keep an eye on it and > remove the default shortcut in the next release if users complain. That is, plain simple, "BS". No one will waste time requesting to change this shortcut in some other report. You can already see this is controversial, and you don't need to make this a default. Users should not be forced to waste their time with this. Making the shortcut _optional_ (not default) is not only simpler and a more effective use of everyone's time; it is the right thing to do for a controversial action. Moreover, changing default shortcuts "just because" is bad policy. We (users) have seen it before, and we are still suffering such changes. Unfortunately, low-level knowledge of spreadsheets is negatively impacting development of Calc. This same matter arises in several tickets, and serious issues in Calc are kept unresolved, while users and developers waste resources (e.g. time) with minor aspects of the program, actually blocking advancements of both users and the program's development. Please don't make users (and developers) waste more time/resources on this. Allow the function, and/but make the shortcut optional.
I was just testing the command and we've got an issue that I think will create too much confusion: It's labelled "Cut but keep format", and the shortcut makes it look like a variation of cutting, but it does not behave like a cut in that it updates the cell references in the formulas (like a copy). So I don't think this resolves the original request, and there's too much confusion between command name + what it does (i.e. copy action) and how it is labelled + its shortcut (i.e. cut action). I unfortunately didn't think of that when the workaround "copy then delete contents" was suggested. @Heiko, I think we shouldn't keep it in its current form. What do you think?
This reference issue is nasty. I'll see if I can make the content move, otherwise we probably have to revert the patch.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dfe1f8fddeab73a75d9849aa59a95e8d52e55af4 Related tdf#64028 - COPYDELETE must not update references It will be available in 25.2.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.
Thanks Heiko, verified in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ba0e0093b0ed2816a18e54eef0a92220d7b04a4d CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded Added to release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F25.2&type=revision&diff=763548&oldid=762140
Note how *moving a cell with a mouse* (which was mentioned here, by the way), which definitely complements the cut-and-paste operation, also suffers from the same problem; and that it has no luxury of "having an easy way of doing what is wanted" (i.e., there is no way to do the mouse-move of a cell like "copy - delete - paste", without moving the cursor back, which is not trivial). IMO, it only needed a *configuration* (in the registrymodifications) controlling what to do with the source, not a new command; and that configuration needed to be applicable both to cut and to mouse-move.
(In reply to Mike Kaganski from comment #45) OTOH, the CUT command is likely to be used in macros, etc.; so having it unchanged is likely OK. The move is another case; so it needs a separate solution (here the configuration would be OK), and should be tracked separately - sorry for the noise.
"Move" could have been a nicer label instead "Cut but Keep Format". Although it needs a good tooltip to understand the procedure.