reproduced in:

Version: 7.2.4.1 / LibreOffice Community
Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

and

Version: 7.1.8.1 / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

(using 7.1.6.2 as earliest affected as 7.1.8 is not available)

Shortcut works as expected in Writer.

Shortcut is documented here:

https://help.libreoffice.org/7.2/en-US/text/shared/04/01010000.html?&DbPAR=WRITER&System=UNIX

Shortcut is not assigned to anything in versions 6.2.5.2 or 7.0.6.2

I don't see a bug here: the text indeed gets pasted as plain text; and for plain multi-line text, we use CSV-like dialog (since forever): how would you like to convert plain text into cells.

(In reply to Mike Kaganski from comment #2)
> I don't see a bug here: the text indeed gets pasted as plain text; and for
> plain multi-line text, we use CSV-like dialog (since forever): how would you
> like to convert plain text into cells.
Agreed, many Calc users understand this "pasting as plain text equals to importing text as csv format" feature and use it frequently.

As an alternative, if one really wants to paste a lot of text into a single cell, they can press the drop-down arrow at the right of the formula bar, then paste into the expanded formula bar.

(In reply to Mike Kaganski from comment #2)
> I don't see a bug here: the text indeed gets pasted as plain text; and for
> plain multi-line text, we use CSV-like dialog (since forever): how would you
> like to convert plain text into cells.

Perhaps my report wasn't explicit enough - although I don't see how I can incorporate things that are not on the agenda into a report identifying that  new/recent changes have been introduced into the manner in which a paste special has "always" been processed.
Attached is a screen dump. It shows a matrix selected and captured from the internet. As the source doesn't appear to utilise a  LO recognisable array, the capture is simply a stream of data elements with a CR after each item - 242 of them.
The intention was never to post it all into a single cell and it's certainly not needed as Stripped hypertext or any of the other alternatives.
The perennial reports of the cut & paste functionality not working effectively prompted the creation of a simple receiving helper sheet which automatically took the stream of "cells" into a single column from where the two-dimensional array was reconstructed and all the other sheets in the file then referenced the reconstructed matrix.
CTRL+ALT+SHFT+V was the only one of the many cut and past choices that actually did what it said on the box - immediately post all this data at the focussed location. I can confirm the older pasting errors now appear to have been fixed.
Before the recent fix, it just stuck the data where it was intended, certainly since COVID-19 was introduced to the world. The clue is in the name - it's been pasting data into cells without any further requests to clarify what is required since 2019 - which I accede, is not "forever".
Perhaps it was remiss of me not to mention that I didn't wish to paste all the data elements into one massive 64K cell - is that a common occurrence?
The function has been broken for some time and recent remediation has fixed it so it doesn't work the way the users have become accustomed.
If it was always intended to permit an "immediate" function to ask irrelevant questions then I agree - it probably isn't a bug. 
My guess would be that the recent change just introduced a slight glitch - which is what I thought I was reporting.

Created attachment 176814 [details]
Screen dump

(In reply to Colin from comment #4)
> Before the recent fix, it just stuck the data where it was intended,
> certainly since COVID-19 was introduced to the world. The clue is in the
> name - it's been pasting data into cells without any further requests to
> clarify what is required since 2019 - which I accede, is not "forever".

Well...

I decided to screen-record all versions since 5.4 (just *before* the Ctrl+Shift+Alt+V vas introduced [1]), through 6.0 till 7.0 (I decided to skip 7.1 and 7.2, since those were confirmed to have the described behavior in comment 1). Recording 5.4 was to illustrate that pasting plain text was behaving this way was already prior to introducing the shortcut. In all other versions, I used the mentioned shortcut for pasting (after demonstrating that it was assigned). All the versions were the first releases in the branch (after which, no functional change happened, only bugfix releases followed).

https://imgur.com/iW6RwSC - 5.4.0
https://imgur.com/WE6cy3l - 6.0.0
https://imgur.com/tU0Wkgn - 6.1.0
https://imgur.com/Z8xrQYD - 6.2.0
https://imgur.com/EfdklBB - 6.3.0
https://imgur.com/j5qUNLA - 6.4.0
https://imgur.com/Tfr0JCt - 7.0.0

The release schedule is at https://wiki.documentfoundation.org/ReleasePlan (6.3 - 7.3), and https://wiki.documentfoundation.org/ReleasePlan/Archive (6.2 and earlier), so you can check the dates of the releases.

For completeness, I also checked the behavior of OOo 3.2.0, as well as AOO 4.1.0 (using the same procedure, just using the paste button's drop down menu). Naturally, the result was the same - CSV dialog appeared.

So I still think I was correct stating that it was ~forever this way; I would be curious to learn which specific version behaved differently.

[1] https://wiki.documentfoundation.org/ReleaseNotes/6.0#Pasting:_unformatted_text

(In reply to Mike Kaganski from comment #6)
> (In reply to Colin from comment #4)

> 
> So I still think I was correct stating that it was ~forever this way; I
> would be curious to learn which specific version behaved differently.
> 
> [1]
> https://wiki.documentfoundation.org/ReleaseNotes/6.0#Pasting:
> _unformatted_text

Bug 136762, where it was specifically mentioned in comment #11 of 7th November 2020, certainly traces it back to 6.4.6.2.*
Unfortunately, my oldest backup is also from November 2020 which appears to have lost the creation date in the LO Properties register. It does however identify the last time it was printed as July 2020. From the data accumulated within I can confirm 312 days of operation and 800+ revisions.
It would have been a point during those early days of general pasting problems precipitating the necessity to ascertain the identified workaround, that I was fully cognisant of the fact that ALT+ pasted the copy buffer contents without intervention.
* I have no idea when I installed 6.4.6.2 so I cannot confirm anything earlier than that release.

(In reply to Colin from comment #7)
> Bug 136762, where it was specifically mentioned in comment #11 of 7th
> November 2020, certainly traces it back to 6.4.6.2.*

Reading carefully, I do not see a clear statement there that pasting using Ctrl+Alt+Shift+V does *not* show a dialog; only that - unlike the other paste method - its result is not formatted. Which was perfectly fine: the dialog was not relevant for the discussed detail that you emphasized - regarding keeping rich formatting (bold/color/font name, etc.), which can't be changed in pasting plain text, regardless you mention the dialog or not.

However, I went ahead, visited https://downloadarchive.documentfoundation.org, and downloaded the version in question. And you know what? You will be shocked - or maybe you won't - to learn that it also shows CSV dialog on pasting using that key combination:

https://imgur.com/vAlNgoo

(Indeed, that was obvious from comment 6, where I shown that 6.4 was tested, and as I told there, after initial 6.4.0 release, there were no feature change, only bug fix releases - which 6.4.6.2 was.)

So I did quite a big chunk of work trying to reproduce the claimed "correct" behavior (which I know had never been, but I never just ignore claims). I repeat: it was always this way. And until there's some demonstration from you - e.g., a screen cast, or clear repro steps, - I would suggest to close the issue as invalid (it claims things that are not true). I set it to NEEDINFO - please provide the missing data, so that we could confirm and proceed.

Created attachment 176820 [details]
Screen dump from LOCalc help

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
file:///C:/Program%20Files/LibreOffice/help/en-GB/text/shared/01/pasteunformatted.html?System=WIN&DbPAR=CALC&HID=.uno:PasteUnformatted#bm_id411584805874366
From your colleague's above post

(In reply to Colin from comment #9)

What do you think you show by that? The underlined places tell you the truth. Pasting using Ctrl+Alt+Shift+V results in the pasted result having formatting (font/size/etc.) of the target place. Ctrl+Shift+V shows Paste Special dialog. (Note that the dialog we are discussing here is *not* "Paste Special", it's titled "Text import".

(In reply to Mike Kaganski from comment #11)
> (In reply to Colin from comment #9)
> 
> What do you think you show by that? The underlined places tell you the
> truth. Pasting using Ctrl+Alt+Shift+V results in the pasted result having
> formatting (font/size/etc.) of the target place. Ctrl+Shift+V shows Paste
> Special dialog. (Note that the dialog we are discussing here is *not* "Paste
> Special", it's titled "Text import".

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.
Despite your inexplicable unwillingness to accept the bug report it's still not functioning as it did before somebody "fixed" it. Perhaps if you had said it's only a nominal issue so we won't fix it as the user can just ensure one of the other options isn't activated and gives that user the "wrong" result as opposed to digging the deepest trench you can manage in an endeavour to prove you are right then we wouldn't be having this conversation.
Think of the old adage "You may never be wrong but you're not always right"
Me - just a user who observed a change that wasn't particularly productive and reported it
You - whatever you wish from life

(In reply to Colin from comment #12)
> (In reply to Mike Kaganski from comment #11)
> > (In reply to Colin from comment #9)
> > 
> > (Note that the dialog we are discussing here is *not* "Paste
> > Special", it's titled "Text import".
> 
>and is erroneously provided when the user directly commands "Paste Unformatted Text CTRL+ALT+SHFT+V functionality" - why else would the key combination exist?

Image attached

Created attachment 176823 [details]
Composite screen image

(In reply to Colin from comment #14)
> Created attachment 176823 [details]
> Composite screen image

Please draw your own line between the command and either of the two unselected responses. Whichever one you choose it's not what the USER asked for.

(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.

(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.

(In reply to Colin from comment #12)
> Despite your inexplicable unwillingness to accept the bug report it's still
> not functioning as it did before somebody "fixed" it.
No.

It seems you try hard to describe how you see the situation, but fails to understand how other people see it.

As Mike has listed in comment 6, the "Paste Unformatted Text" action, whether invoked from menu, or invoked via shortcut Ctrl+Alt+Shift+V, *always* brought up the "Text Import" dialog which you don't like, when pasting multi-line text.

However, that's the intended behavior.  When you used some old version that behavior was broken, and it pasted the text into a column of cells.  You may liked this different behavior and relied on it for your workflow, but it was never intended and developers (at least Mike) didn't know about it.  Therefore Mike asked you in comment 8, to either provide a screencast, or reproducible steps (which old version, on which platform, sample text to copy and paste, etc.) for that behavior that you like, but he didn't know about.  That way maybe the developers can figure out the reason for that behavior, and make it possible for someone to add it as an alternative option.  But you completely ignored his request.

You think someone made changes and got rid of the behavior you like.  That may be true, but many people have never seen that behavior (Mike hasn't, neither have I).  And if you don't help other people reproducing that behavior, nobody can help you much -- they wouldn't know where to start.  You are always welcome to investigate yourself and provide patches to bring back the behavior you like, but if you want cooperation from others, you need to provide ways for them to see that behavior first.

And please don't get emotional in Bugzilla discussions, it doesn't help anyone.

(In reply to Ming Hua from comment #18)
> (In reply to Colin from comment #12)
> > Despite your inexplicable unwillingness to accept the bug report it's still
> > not functioning as it did before somebody "fixed" it.
> No.
> 
> It seems you try hard to describe how you see the situation, but fails to
> understand how other people see it.
> 
> As Mike has listed in comment 6, the "Paste Unformatted Text" action,
> whether invoked from menu, or invoked via shortcut Ctrl+Alt+Shift+V,
> *always* brought up the "Text Import" dialog which you don't like, when
> pasting multi-line text.

As I identified. I actually utilised that behaviour to help define a workaround in another bug report so, being told it was a figment of my imagination was the really offensive part. Also, it's not that I dislike the dialogue - I was just reporting that it appeared to have changed and I doubt anybody would view "extra steps" as an improvement
> 
> However, that's the intended behavior.  When you used some old version that
> behavior was broken, and it pasted the text into a column of cells.  You may
> liked this different behavior and relied on it for your workflow, but it was
> never intended and developers (at least Mike) didn't know about it.

OK, I accept that you have properly explained the situation but that older version was also in the 7 series which has recently moved on to 7.2.4.1. I think the thing changed for me during the previous update which was probably later than 7.2.2.2

> Therefore Mike asked you in comment 8, to either provide a screencast, or
> reproducible steps

Perhaps Mike could also provide some indication as to how one can provide a screencast or dump of something that no longer exists - the reproducibility is that it no longer functions which nobody seems to have accepted as the raison d'etre for the report in the first place. There's not a scientist on the planet - computer or otherwise - who can prove something doesn't exist, only that they have been unable to find it.

> And if you don't help other people reproducing that
> behavior, nobody can help you much -- they wouldn't know where to start.

I accept that as well, but, nobody should try to belittle a user's lack of computer science knowledge with what was deemed an offensive lecture.

Perhaps look at Mike's long list of examples defining some of the myriad potential formats and ask yourself, "what did they all have in common". The carriage return at the end of the line - which during my utilisation of the function was being interpreted by Calc as "let's use this as an end of record or new cell in the user-defined direction of travel when the return key is pressed" or whatever the terminology may be. That is the simplest example, of precisely what I had observed it doing and found it difficult to believe nobody could see (or believe my observation) that it had changed. 

> You are always welcome to investigate yourself and provide patches to bring
> back the behavior you like, but if you want cooperation from others, you
> need to provide ways for them to see that behaviour first.

If I could I would but as I can't, I won't bother breaking it further. And, no matter how politely you say it, I suspect you already know that - were you subconsciously trying to make another point?
 
> And please don't get emotional in Bugzilla discussions, it doesn't help
> anyone.

 When somebody intimates that an inability to demonstrate this particular non-occurring anomaly, scientifically demonstrates that it doesn't exist, that is tantamount to telling the user - you're a liar. Trust me - I didn't get emotional about it. I just have a tendency to indulge in what could be defined as an aggressive defence ;)).

All purely academic now. Mike has declared it NOTABUG so I assume it's gonna stay as it is "always and forever".

Thanks for trying to pour oil on troubled waters

(In reply to Colin from comment #19)
> being told it was a figment of my
> imagination was the really offensive part.

This is a way of telling "I can't make mistakes, and my memory is infallible; whenever you provide any evidence of the opposite, you insult me personally". Well, yes, reasonable approach to communicate.

> Perhaps Mike could also provide some indication as to how one can provide a
> screencast or dump of something that no longer exists - the reproducibility
> is that it no longer functions which nobody seems to have accepted as the
> raison d'etre for the report in the first place. There's not a scientist on
> the planet - computer or otherwise - who can prove something doesn't exist,
> only that they have been unable to find it.

(In reply to Mike Kaganski from comment #8)
> However, I went ahead, visited
> https://downloadarchive.documentfoundation.org, and downloaded the version
> in question.

I believe I indicated this using the specific address where one could download the older versions of software. Even if you can't repro something not existing in a new version, I *suppose* one who claims that the change was recent and in LibreOffice, would agree that *then* some older versions (that worked as the user wants) would still provide the wanted behavior. Or does the user believe that "recent fix" magically fixed also all older versions, too?

> I accept that as well, but, nobody should try to belittle a user's lack of
> computer science knowledge with what was deemed an offensive lecture.

I have *no* idea about your "computer science knowledge". Additionally, I myself have *no* proper "computer science" education, started as a user, and everything I know was self-taught. I never "belittle" anyone; but others may easily show that they do not appreciate great effort put into *listening to user* (would you claim I did not *understand* your issue?), trying to *reproduce it* (don't you see I honestly tried it and spent much time on it?), explaining the reason behind it based on own knowledge so that *you* could see the reasons ... and instead, the people can easily see they are arrogant, with the "I do not listen; I have no intention to understand *you*; I will not accept me being wrong; I will declare any disagreement as a personal insult; and the bottom line is - whatever I say is a sacred USER request, and you must just go and implement as I said, and anything else is you belittling me" approach.

(In reply to Colin from comment #19)
> (In reply to Ming Hua from comment #18)
> > You are always welcome to investigate yourself and provide patches to bring
> > back the behavior you like, but if you want cooperation from others, you
> > need to provide ways for them to see that behaviour first.
> 
> If I could I would but as I can't, I won't bother breaking it further. And,
> no matter how politely you say it, I suspect you already know that - were
> you subconsciously trying to make another point?
Well, I did have some guesses.

But it was not some point I was subconsciously trying to make.  Now that you've confirmed my guess, I can state my point very loud and clear: In the world of open source where a lot of work are done by volunteers, people who can code and people who can't code are never going to have equal status.  The users can report bugs, file requests for enhancement, make suggestions, but ultimately it's the volunteer developers who are doing the hard work.  So as a user I try to be respectful to developers and defer to their judgement.  I also tell all users who listen to me that they should do the same.

You may disagree and that's fine, I could be wrong about this.  I'm just writing all these out so that you don't take my original words as some sort of slight or condescension.

(In reply to Mike Kaganski from comment #20)
> (In reply to Colin from comment #19)
> > being told it was a figment of my
> > imagination was the really offensive part.
> 
> This is a way of telling "I can't make mistakes, and my memory is
> infallible; whenever you provide any evidence of the opposite, you insult me
> personally". Well, yes, reasonable approach to communicate.
> 
> > Perhaps Mike could also provide some indication as to how one can provide a
> > screencast or dump of something that no longer exists - the reproducibility
> > is that it no longer functions which nobody seems to have accepted as the
> > raison d'etre for the report in the first place. There's not a scientist on
> > the planet - computer or otherwise - who can prove something doesn't exist,
> > only that they have been unable to find it.
> 
> (In reply to Mike Kaganski from comment #8)
> > However, I went ahead, visited
> > https://downloadarchive.documentfoundation.org, and downloaded the version
> > in question.
> 
> I believe I indicated this using the specific address where one could
> download the older versions of software. Even if you can't repro something
> not existing in a new version, I *suppose* one who claims that the change
> was recent and in LibreOffice, would agree that *then* some older versions
> (that worked as the user wants) would still provide the wanted behavior. Or
> does the user believe that "recent fix" magically fixed also all older
> versions, too?
> 
> > I accept that as well, but, nobody should try to belittle a user's lack of
> > computer science knowledge with what was deemed an offensive lecture.
> 
> I have *no* idea about your "computer science knowledge". Additionally, I
> myself have *no* proper "computer science" education, started as a user, and
> everything I know was self-taught. I never "belittle" anyone; but others may
> easily show that they do not appreciate great effort put into *listening to
> user* (would you claim I did not *understand* your issue?), trying to
> *reproduce it* (don't you see I honestly tried it and spent much time on
> it?), explaining the reason behind it based on own knowledge so that *you*
> could see the reasons ... and instead, the people can easily see they are
> arrogant, with the "I do not listen; I have no intention to understand
> *you*; I will not accept me being wrong; I will declare any disagreement as
> a personal insult; and the bottom line is - whatever I say is a sacred USER
> request, and you must just go and implement as I said, and anything else is
> you belittling me" approach.

Did you even notice all the "whataboutery" in your comment?

I am fully aware that you are a member of the Core Engineering Team at Collabora so you undoubtedly have more knowledge of the product than just a simple user.
You don't accept my point of view that I experienced it first hand and I don't accept your assertions that I imagined it - Does that work?
I found the "auto-uninterupted-paste" bug quite useful and it's regrettable that it's been fixed. If nobody reported it as a bug it doesn't surprise me that the developers have little or no knowledge of the "feature".
I didn't file what I thought was a "genuine bug report" identifying something that had gone on the missing list which in reality seems to be the probable result of the recently released fix on 13672.
Perhaps it should be a feature request instead as I see little value in giving the user the choice to just "paste as is" and letting any carriage returns in the data be treated as carriage returns - without actually "pasting as is". 
Shall we reset?

(In reply to Ming Hua from comment #21)
> (In reply to Colin from comment #19)
> > (In reply to Ming Hua from comment #18)

> 
> You may disagree and that's fine, I could be wrong about this.  I'm just
> writing all these out so that you don't take my original words as some sort
> of slight or condescension.

As I said "Thanks for trying to pour oil on troubled waters"

(In reply to Colin from comment #22)
> You don't accept my point of view that I experienced it first hand and I
> don't accept your assertions that I imagined it - Does that work?

No. I do not "accept or do not accept" - I test and demonstrate. Whatever you say (and whatever I say) must be demonstrated; trying to say "my words are same-weight evidence as your screencasts based on my words" is lunacy.

> Perhaps it should be a feature request instead as I see little value in
> giving the user the choice to just "paste as is" and letting any carriage
> returns in the data be treated as carriage returns - without actually
> "pasting as is". 
> Shall we reset?

I already did that (treated your issue as a feature request) in comment 16; there I didn't discuss reproducibility of the wanted behavior, but just discussed its own merits. I tried to explain it in depth; and you still failed to see that (1) newlines are present in the row having the "three and<NEWLINE>a half" - that depends on user-definable string separators, and (2) even if you break text into lines (ignoring this possible and standardized ), you still don't know how to split single rows into cells (it would only create a single column from random multiline data). Well, my whole effort was confronted with "deeming it an offensive lecture".

(In reply to Mike Kaganski from comment #25)
> (In reply to Colin from comment #22)
>  I think now by people who
> shy their ignorance in what they indeed are not obliged to know).

I think something got lost in the translation. People who - what is - "shy"?