Description: Cutting selected cells in Calc results in any direct formatting being removed. I couldn't believe this behavior and thought that there must be some way to change it, but the answers here confirm that doing so is not possible: https://ask.libreoffice.org/t/how-to-prevent-cell-formatting-being-removed-when-values-are-cut/53102 I'm sure this bug report will prompt recriminations about using styles rather than direct formatting, but from my perspective, the issue is one of consistency: if you direct format a table cell in Writer (e.g., select a cell and bold it), select the cell, and cut it, it does not revert any direct formatting made to the cut cell. (Please, please, please don't apply my plea for consistency in the direction of changing the behavior of cutting Writer table cells to match the current Calc behavior; I can't fathom why anyone would want the current Calc behavior in the first place.) My first choice would be to change the Calc behavior to match that of Writer tables -- cutting removes the *contents* of the cell (with its formatting), but does *not* affect the formatting of the cell itself. My second choice would be to provide a configuration option, similar to what the current "delete contents" function provides, but allowing setting defaults for cut behavior rather than having to choose them each time. Steps to Reproduce: 1. Direct format a cell in a Calc spreadsheet, e.g., bold it. 2. Type some text in the cell. 3. Cut that cell. 4. Type new text in that cell. Actual Results: The new text is formatted in the default formatting of the cell, before the direct formatting changes were made. Expected Results: The new text should be formatted according to the direct formatting of the cell before the cut. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
This is not a bug. Cut removes the _cell_, that includes all cell formatting, same as Copy copies the entire cell including all formatting. And same as Copy-Paste, Cut is meant to be followed by Paste including all formatting. If you want to delete content only then either use Del, or Backspace and choose what to delete.
I'm confused and disappointed by how easily this report was dismissed. 1) Can you explain why there is a discrepancy between the way that cut functions in Calc and the way it functions in Writer tables? Why does cut in Calc "remove the cell" but cut in Writer does not? What is the conceptual difference between them that would make sense to an ordinary user? 2) Why is it so easy to dismiss what is clearly a confusing and inefficient demand placed on users, as evidenced by the thread from the ask forums I linked to? Why should people have to perform an action in two steps -- copy then delete -- that conceptually should require only one step? If changing the default behavior is deemed beyond the pale, then I would at least like to make the *option* to change the default cut behavior into an enhancement request. Thank you.
Feature has been requested before in bug 64028, closing as a duplicate. Thanks! *** This bug has been marked as a duplicate of bug 64028 ***
as requested in bug 64028
(In reply to Eike Rathke from comment #1) > This is not a bug. Cut removes the _cell_, that includes all cell > formatting, same as Copy copies the entire cell including all formatting. > And same as Copy-Paste, Cut is meant to be followed by Paste including all > formatting. > > If you want to delete content only then either use Del, or Backspace and > choose what to delete. Indeed, that is how I work with this for ages.. So (just as 64028) WFM
OK, here we go again. It seemed that some progress was being made on this issue, so I will simply reiterate the main points from my comments here and in bug 64028: 1) There are many posts that one can find requesting this feature in LO, in Excel, and in Google Sheets, which I linked to here: https://bugs.documentfoundation.org/show_bug.cgi?id=64028#c8 More such requests were linked by Stephane here: https://bugs.documentfoundation.org/show_bug.cgi?id=161192#c2 2) As I wrote in comment 2, the current behavior of cut in Calc (and other spreadsheets) differs from cutting cells in a Writer Table (and tables in other programs?) -- where the formatting of the source cell is preserved -- but I can see no logic behind that. 3) Heiko suggested an elegantly simple way to implement this enhancement here: https://bugs.documentfoundation.org/show_bug.cgi?id=64028#c11. To summarize: the enhancement I am requesting seems fairly simple (introduce a new uno command combining copy and delete that can be bound to ctrl-x) and has been requested by multiple users in multiple fora. The fact that it can currently be accomplished in two steps does not change the fact that making it doable in one step using a standard keystroke would greatly increase efficiency, for what seems to be a small cost in implementation. I therefore request that other users and developers be given a chance to have their voices heard (in addition to the voices linked in the comments mentioned above) about this issue before unilaterally declaring it unnecessary. Thank you.
Thanks for making your voice heard, William. This also allows me to give some clarification. (In reply to William Friedman from comment #6) > 1) There are many posts that one can find requesting this feature in LO, in > Excel, and in Google Sheets, which I linked ... The number of times an idea is mentioned, doesn't have to mean that it is good or correct. > 2) As I wrote in comment 2, the current behavior of cut in Calc (and other > spreadsheets) differs from cutting cells in a Writer Table .... > but I can see no logic behind that. A spreadsheet is not a text document, > 3) Heiko suggested an elegantly simple way to implement this enhancement > here: https://bugs.documentfoundation.org/show_bug.cgi?id=64028#c11. > ... The initial description of the request was at least not clear, and I found it hard to understand Heiko's interpretation. The last explanation from the OP is IMO orthogonal to the initial request.. > I therefore request that other users and developers be given a chance to There is free speech here, as you can notice, as long as people try to behave well. (Sad enough leading to -luckily few- examples where people think that just expressing their own ideas without apparently enough efforts to understand others or underlying techniques, is s virtue, not realizing that it is not the social behavior that makes a community flow&grow. [sorry for this rant]) > have their voices heard (in addition to the voices linked in the comments If any capable developer wants to implement such a thing as an option, no one will stop him/her. But it's my bet that these people will not spent time on developing an alternative to existing simple fast common key strokes ;) > mentioned above) about this issue before unilaterally declaring it > unnecessary. Thank you. Speaking about capable developers: I referred to comment 1.
I set 64028 back to new, see my comment there. *** This bug has been marked as a duplicate of bug 64028 ***