[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PSPP-BUG: [bug #57274] Ctrl+V and Paste paste different things.

From: Friedrich Beckmann
Subject: PSPP-BUG: [bug #57274] Ctrl+V and Paste paste different things.
Date: Sat, 11 Jul 2020 06:01:42 -0400 (EDT)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

Follow-up Comment #6, bug #57274 (project pspp):

The idea is that all three ways of doing Copy/Cut/Paste have the same effect.
Without the patches the main menu and the key always work on the store and the
context menu always works on the editable.

With the patches it is now distinguished if an editable is open or not. If an
editable is open, then clipboard always works on the editable as you would
expect it. The difference becomes obvious with the following test:

1. Create a string variable with width 12
2. Enter text "appletree" in the data view
3. Click twice on the cell to open the editable => blue frame appears
4. Select the letters "apple" from the text

Now compare (without patches)
5A. Copy via main menu or <CTRL>c  => appletree is in the clipboard
5B. Copy via context menu => apple is in the clipboard

6. Click once into an empty cell 
7. Paste with <CTRL>v (or key or context)

Case (A) => appletree is in the new cell
Case (B) => apple is in the new cell

Expected behaviour: The selection was on the editable and there should be
"apple" in the clipboard regardless how you copy.

With the patches it does not matter if you copy/paste/cut via main menu, key
or context menu. It only matters if your focus is currently in an editable or
not which is the behaviour that is compliant with usual gui behaviour. If you
do "Cut" instead of "Copy", then in A the complete cell is deleted while in B
only the text "apple". If you paste then the main menu and key always replace
the complete text while paste via context inserts the clipboard at the current
cursor position.

The behaviour in the description below "Pasting in the sheet" and "Pasting in
the Cell Edit" is now consistent because you either open an editable or not.
With commits 


the string in the editable is nearly already a valid number except that there
is a "Newline" at the end of the "5.00". If you select a cell range and paste
it into the open editable, then the text with tabs and newlines is pasted at
the current cursor position. This results in an invalid number but that is at
least obvious. It would also be compliant with user expectation because you
are currently editing the text in the cell. While writing this and testing in
psppire I noticed that Copy and Cut behave differently:

1. Create a numeric variable with default settings
2. Goto dataview
3. Enter 5.00 in the cell
4. Click once on the cell => no blue frame
5. "Copy" via <CTRL>c => 5.00<NEWLINE> is in the clipboard
6. "Cut" via <CTRL>x => 5.00 without NEWLINE is in the clipboard

So we could change the Copy behaviour such that for a single cell copy no
NEWLINE is appended as in "Cut". Then pasting into an empty editable would
result in the correct numeric value right away.

I think the unexpected and buggy behaviour is that clipboard operation behaves
differently depending on how you trigger the clipboard action.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]