https://bugs.documentfoundation.org/show_bug.cgi?id=146103

--- Comment #17 from Colin <that.man.co...@gmail.com> ---
(In reply to Mike Kaganski from comment #16)
> (In reply to Colin from comment #12)
> > If you can't see the difference between pasting directly with the ALT option
> > and being presented with the non-ALT option dialogue and using the non-ALT
> > option and getting the same non-ALT option dialogue then that says more
> > about your interpretation than anything else.
> 
> Uh? Let's see. (I won't go deep into human language, like "she suddenly
> entered the room" not mentioning opening the door doesn't mean she managed
> to come through closed door - well, help *is* written is rather human
> language...)
> 
> (In reply to stragu from comment #1)
> > Shortcut is documented here:
> > 
> > https://help.libreoffice.org/7.2/en-US/text/shared/04/01010000.
> > html?&DbPAR=WRITER&System=UNIX
> 
> (In reply to Colin from comment #10)
> > file:///C:/Program%20Files/LibreOffice/help/en-GB/text/shared/01/
> > pasteunformatted.html?System=WIN&DbPAR=CALC&HID=.uno:
> > PasteUnformatted#bm_id411584805874366
> > From F1 Help
> 
> Let's read the help page. It's titled: "General Shortcut Keys in
> LibreOffice". *General* means something common for *all* modules:
> Writer/Impress/Draw/Calc/Math/Base. And indeed, the page describes the
> shortcuts that are *available* in all/most of those.
> 
> What does it mean: the "paste as plain text" command shortcut is available
> in a module? It means that the related command is applicable, and the
> shortcut is assigned. But it does *not* necessarily mean that the command
> would do exactly same things in all those modules. E.g., when pasted into
> Writer's main text flow, or into any drawing shape's text, it would simply
> add the text characters replacing current text selection; but if you e.g.
> paste it into Draw's main window, it would *create a new shape* with the
> text; and curiously, if you have one or multiple shapes already selected
> (not in text edit mode) there, pasting plain text would *not* replace those
> shapes, but remove the selection, and add another text shape. So its effects
> are defined in all modules, but depends on concrete module's specifics. And
> in Calc, the effect of pasting plain text *is* module-specific; so help only
> mentioning the characteristics of the command that are *common* for all
> modules (end result inheriting formatting of insertion place), and omitting
> the differing parts, is quite natural.
> 
> > Me - just a user who observed a change that wasn't particularly productive
> > and reported it
> 
> Let's see what "not particularly productive" is in the current behavior.
> 
> When you paste *any* text into *Calc* (software created to work with
> *tables*), there are only two options: either put it all into a single cell,
> or to distribute it according some rules across the rows and columns.
> There's no third option. So when you paste plain text, the same choice needs
> to be done. *If* you wanted to put it all into a single cell, we would
> discuss the "paste into Formula bar, or in cell's edit mode" ... but you
> explicitly told that you expect the text to go into several cells
> automatically, so let's go on.
> 
> When you paste data in HTML format, cells boundaries are explicitly defined
> by HTML tags. When you paste data in RTF, StarCalc, OOXML, .... other
> complex formats, all of those formats have some specific defined structure
> that describes the program where a row, column, a cell starts, and where it
> ends. And Calc does not need anything from user to decide how to distribute
> the data into cells: it's all in the data format itself.
> 
> But when a plain text comes to Calc, the data has only text characters, no
> metadata that would tell how that data is organized. The following lines all
> define *possible*, real-life structured plain text data formats:
> 
>   1.0$,2.0$,3.0$,4.0$,5.0$
>   1;"2";"three and
>   a half";4;5
>   2021-12-09 09:29 "event1" "failure"
>   09/12/21 9:29 "event2" "success"
>   000123;foo;bar
>   000025295;bar;baz
>   1,0RUR|2,0RUR|3,0RUR|4,0RUR|5,0RUR
>   1€  2€      3€      4€      5€
> 
> And there's nothing in those strings that explicitly tells Calc that e.g.
> next-to-last line uses pipe character as separator, not comma.
> 
> This is absolutely common - that the plain text may come with different cell
> separators; different decimal separators; different currencies; different
> time formats ... and only user may tell Calc, which rules it must use to
> interpret the plain character stream, when it splits the text into cells;
> tries to recognize numbers/dates there; maybe it must explicitly *not* try
> to interpret something as number, to not transform ids in the form of
> "000123" into 123 - where the count of characters in the id may have own
> significance...
> 
> And in Calc, the *specifics* of the application mean that *whenever you
> paste multiline plain text*, Calc needs specific directions from user to
> know what to do with that text. That is what Import Text dialog does, that
> is what it did since the beginning, and will keep doing - because otherwise
> there's *no* way to expect sensible, reasonable results. This is just what
> spreadsheet specifics dictate.
> 
> Even if you paste from Calc itself, choosing plain text strips all the
> accompanying information, and Calc has no way to know it comes from itself;
> even if it knew, people could want to split the text that accidentally was
> in a single cell, into several cells ... so no, your proposal could not be
> reasonable, and will not be implemented.
> 
> Closing NOTABUG.

That presents as a very convoluted way of saying "I don't know how to fix
something that historically has directly pasted the data into the column of
cells but it doesn't do that now so I will just ignore it" - Bravo.
Semantics - If your girlfriend used to be able to directly transfer her
presence from one room to another without opening the connecting door and now
can't achieve that, then I'm afraid you have also broken your girlfriend. Live
with it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to