Bug: Single-cell multi-line copy / paste failure

[tonypdmtr]

When copying a single cell (CTRL-C) that contains multi-line text, and then pasting it (CTRL-V) on another single cell, each line from the multi-line text fills another row of the table in the database.

This is totally wrong behavior.

[justinclift]

Ahhhh, I can imagine that some people would like 1-row-per-paste-line, and others would like 1-row-containing everything. We should probably make it configurable. 😄

[tonypdmtr]

But it already works correctly when multiple (multi-line) source cells are copy-pasted, So, why have a different behavior for the single source cell in the first place? To me this seems counter-productive.

There could be (like it is done in spreadsheets) a 'Special Copy' menu bar (e.g., Edit/SpecialCopy) option where the copy is performed in an alternate or user-defined way.

But don't you think the default behavior should be identical for either single or multi-cell source?

[justinclift]

Hmmm, this probably needs more thinking about. We'll need to wait for whoever might implement this, to think it through. 😄

[gordeyg]

IMO behavior we can see now is quite convenient. Definitely it should be kept as default one to avoid confusion of users that are used to it.
I think the best way to handle pending change would be "Multiline text copy" switch with "line per entry" and "all to one entry" values possible.
I would put it under View -> Preferences -> Data browser menu

[justinclift]

Maybe a "Special copy" command, letting the user choose its behaviour?

[gordeyg]

Agree, it will be better.
Are you meaning some kind of radio setting in menu bar which will change behavior until switched to other option or actually option for one time paste?

In first case if user will set option to all-to-one, pasting of multiline text will always lead to adding of one field per paste, while in second case it will only paste one entry for multiline text if user will click, let's say, Edit -> Paste -> Buffer to one entry.

Also, I'm confident setting name should be about pasting data, not copying. And it might be good to use Ctrl+v for entry-per-line paste and Ctrl+Shift+v for all-text-to-one (as in other programs, where Ctrl+V used for formatted input, while Ctrl+Shift+V for plain text entry)

[justinclift]

Oops, you're completely correct. "Special paste". 😇

[gordeyg]

But what about Mac OS users? Do they have menu bar? Have asked two people and they gave me different answers

[justinclift]

OSX users have a menu bar. It's in the normal spot that all OSX menu bars are.

For a special paste thing, I'm kind of thinking maybe a dialog would do for one time paste. Taking up screen real estate for everyone's UI, when only a few people will use the feature... probably not the right approach. At least to start with. 😄

Ctrl-Shift-v as the keyboard shortcut sounds like a good idea too. We'll need to ping @MKleusberg when he's back from holiday, to see what he thinks. 😄

[mgrojo]

@tonypdmtr

When copying a single cell (CTRL-C) that contains multi-line text, and then pasting it (CTRL-V) on another single cell, each line from the multi-line text fills another row of the table in the database.

This is totally wrong behavior.

This is no longer true, so I think this can be closed. We've made several improvements to the copy/paste behaviour with #1244:

• When copying and pasting from the application we never loose the cell structure. If we copy a multi-line cell, we paste a multi-line cell.
• When copying from another application, we parse the text and use tab as cell separator and end-on-line as row separator, so multi-line texts will be pasted as multiple cells.
• If someone wants to paste an external multi-line text as a single cell content, he must enter in editor mode, be it with the Edit Database Cell dock or the inline cell editor (F2 in cell) before pasting.

In this way we don't need any preference setting for the behaviour.

If you'd like to try, use our alpha build for the next release. I'll close this now as we want to make some clean-up before the release but feel free to comment further if you feel like we've closed this too early.